Charmed Quark Systems, Ltd. - Support Forums and Community

Actually I was wrong, not the align middle button, it's whatever the bottom left button is in the Tools tab.

It's to space them out evenly horizontally. It was likely some unusual initial relationship between them Can you give me more info about how they were related to each other spatially and how you selected and tried to space them?

Nevermind I was able to reproduce it. I think it's related to the order they were selected in (or their natural order if you lasso select them) so the wrong one gets picked as the starting point, and that can cause others to get pushed off the template.

I've been banging on the Z-Wave driver. I'm fairly close to the guts of a working scenario. The msg I/O stuff is pretty solid now. But I decided to give in and move to an asynchronous scheme for getting all of the individual units up and going. Synchronous is simpler, but it doesn't deal well with failures or possibly flaky units. This way, most of the work to get all of the info we need about each unit can be done by sending a msg and not waiting for the reply, and just going on to the next one. If the reply comes in, the unit stores that and sends out the next request. If it doesn't it will retry it in a while. In the meantime other units can continue going. So it allows for a lot more overlap, which should speed things up quite a bit.

That's another one of those 'flip it inside out' scenarios. Anyway, I was close to getting it back up to where I was before, but with this new scheme in place. I should hopefully get it to there tomorrow. I'll implement the getting of initial field values as part of that scheme as well, which is a missing bit currently.

Basically the driver will wait for a certain amount of time, checking the list of units to see if they all have reached ready state. When they do, it'll come online, or go back to regular state from replication state if it's post-replication. If some of them don't, then it'll give up and come online anyway and those will just remain with their fields in error state until they manage to get some data.

There were more complications to deal with, surprise, but I've started banging my way through it again. It's the usual thing, it goes a little further, deal with that, it goes a little further, deal with that. It's very tricky and lots of states to get through, and how those states change is complicated by many things. But I think I've got it basically correct.

It's may end up going to come on line before the fields are initialized. There are a fairly well defined set of states I can get to for any given module.

1. Was configured and new info from the unit matches that, so it's good
2. Was configured and new info conflicts with that (fail it until the user intervenes)
3. Was not configured but we got the manufacturer ids and we have support for that type in our library, so we can set it up automatically.
4. Was not configured and we either didn't get man ids or we did but no match, so has to wait for either the user to select something, or to select a generic handler if available, or for new support in the driver.
5. It failed in a reasonable time to respond to requests for information, so it's failed pending user action

At that point, we know which units we have that are viable (#1 and #3), and we can create handlers for those, let those handlers tell us what fields they need, and register them.

Then the driver can come online and the unit handlers will start getting their fields set up. Of course it would be nice to wait until all the fields are set up. But that could be a while in some cases, and a fairly ragged affair. Maybe I'll just pause for a bit to give the ones that are going to quickly get going to get going, then come online. The others will or will not fill in as time allows.

For non-listeners (battery powered, non-beaming), those we know won't have any values until they send us a wake-up on whatever period they are configured to do that. Our auto-config will set that to a somewhat aggressively short time, which will be a bit worse on batteries but a lot better to get those fields updated in a reasonable time.

Of course, in this new scheme, we could just automatically auto-config, and periodically re-do it to make sure it's still good. But since our driver is not the master, that's something of an issue, since we could undo changes made via the master controller.

As a secondary controller will this be able to respond to locks and the user codes used with them? Eg trigger an action based on what code is used to unlock the door?

That's not something that is affected by it's being a secondary or primary. Any controller can do that as long the code supports it and the lock is setup appropriately to send notifications to the controller, which will be the case for this driver.

Can I ask that we have a new actions added - CastTTS and CastWav - to allow us to cast audio to Google home devices and other cast supporting devices.

Having a mini in the how now as well allows me to play with the differences between the echo and google home (GH) and the GH has the ability to play audio cast to it. This is perfect for TTS announcements or playing wave file for when you dont have a client that is always on with a speaker.

If you find that the echo can support this type of functionality as well then similar commands for it as well.

So IÔÇÖm doing this with smarthings now and IÔÇÖll be able to do in CQC.

If 'casting' involves streaming the data to the device, then it can't be just a simple command. It'll have to be something that probably runs asynchronously in the background or something like that. So not a simple thing to do.