Charmed Quark Systems, Ltd. - Support Forums and Community

A classic video:

https://www.youtube.com/watch?v=0A7nMi-jUb8

This is me vs. the world.

Family night got called off so I got the manual config parameter management dialog done plus some more tweaks. I wasted all that good makeup. I'm going to go watch a movie. I'll hit the 'set the unit type' dialog tomorrow. I'll have to implement the code to download those files and update the driver to download them. As per previous discussion I don't want to install them on every machine this time (which is what the VRC0P does.) I want them just on the MS, so that they can be patched/added to and those changes picked up by all machines if needed.

I got the changes made to download the device info files from the MS, and updated the driver to get them from there, and got the type selection dialog done but not tested yet. I'll do that tomorrow. Then I'll have to gen up some generic one and two ways handlers and dig out some old ZW units and test the manual type selection and the generic handler.

I just realized I have nothing for thermostats at all, but I don't necessarily have to get that done before the first beta drop. I think I have a really old one. I might have to buy a more modern one to test with.

Alrighty, that was a day plus some. I got the type selection dialog worked out, which required a bit of twiddling to some underlying stuff since I failed to foresee a thing or two. And I got a one way generic dimmer/switch handler done and used that to work (so far) the manual selection of a unit type and the saving of that change getting picked up correctly. That required adding some protection to prevent the selection from getting undone by the normal scanning that the units do after startup or replication, where they can get manufacturer ids and might overwrite that manual selection.

I got the little dialog to display the unit info, but I didn't get the saving of it out to a file that you can send to us to use understand how to add support for that type of unit. I'll add that tomorrow.

I just noticed that, because these generic handler device info objects don't list any command classes (because they are generic and don't know what those might be) the unit info doesn't show any CCs after you have selected a generic device info file for the unit (because the unit doesn't do that scanning if it already has device info.) That's not a problem per se, since you can get the info for us before you make a selection, but there needs to be a way to retain that info. I guess it can check if the selected type is a generic one and don't try to copy the classes from the device info, just keep what is there from the unit scan.

I banged out a good number of bugs while working on the unit type selection stuff as well.

So, anyhoo, getting quite close. I really need to do a demo video so folks can see it before I get a drop out, but I keep just banging away instead.

Well, Z-Wave never fails to please... I got to looking at how to get the user code into lock state triggers, and that just sent me around in circles for hours. I eventually settled for an inelegant, but workable, solution.

For those locks that use the notification class to send lock state changes, I can get the user code out of that if it is provided.

For those that report async changes with the door lock class, it doesn't report that sort of thing. It can be queried if the lock supports the door lock logging class, but that's not useful in terms of sending out triggers. They have to go out right there when the state changes, so there's means to do a bunch of queries to the lock to get log entries until we find the last one that might be relevant.

In some cases some support notifications and door lock, but all I see it send is door lock. There maybe some configuration parameter to make them send notifications, but that information would have be dug up somewhere.

I added a generic handler for scene activators, i.e. button devices that send out scene activation command class messages, which are converted to User Action triggers. I can't actually test it, but it's pretty simple. This is for devices that just do that, not for devices that include that amongst other functionality. Those would require a separate handler. But for key fobs and wall buttons and button panels, as long as they send scene activation messages, this guy should work. It's like the old driver, the user action values are the unit name and the scene number (1 to whatever.)

You can configure it to send on any received button, or only if the scene number changes.

The issues of dealing with event triggers has continued to plague me, so I've been rearranging how that is handled. Hopefully my latest efforts (after many restarts today) will work out. There are a lot of weird issues involved, particularly when it turns out two or more command classes need to contribute to the value of a field. I'm about 85% finished with the changes. I'll hopefully solidify this tomorrow and put that behind me.

We're going to have to get Dean some PTSD meds after all this zWave work.

Thanks man! Any path to escape a non-customer-centric company like my current zWave solution is greatly appreciated.

It appears to be working out. I've got it building again and I've been going through a module at a time and updating each unit handler class appropriately and making sure they send the triggers as they should. I've got a few done and a few more to go, but it's going pretty quickly now that I've worked out the basic pattern.

OK, I think that's done. That was painful but definitely better now. It would have been far worse to do it later.