Did you save the changes? They won't take place until you save, since the server side driver has to re-register all of the fields.
If the lock uses the notification class to report changes, then the lock state trigger that gets sent out will have the code in it. The door lock class doesn't provide that information, strangely. The Yale locks do use notification. See the event trigger reference info:
http://www.charmedquark.com/Web2/CQCDocs...TriggerFmt
Check the lock state one. There is a code value. You can extract that info using the triggered event action target that is there in any triggered event actions.
TrigEvent::GetLockStatusInfo()
I'll get started on the docs before long, but basically any RGBW controllers have a field for setting the overall color, in HSV format (so hue, saturation, and value space separated.) The values are the same as those documented in the COlor Palette IV widget, which is what would often be used to set such things.
There's another one to set individual components, so
Red 50
to set the red component to 50%, and so forth.
Okay, that makes sense and yes once it was saved it was replicated over. For the Fibaro RGBW there appears to be no White, you have RGB but no W, how is White controlled? I'll have to play with the Color pallet IV widget this weekend.
White is separate. You can only change it using the component setting field, so:
White 100
and so forth.
Dean,
I dont see the Aeotec Multisensor 6 (ZW100-A) in the devices. Also, noe of my ecolink motion sensors are reporting their battery level.
I haven't done that one yet. It's going to be tricky, as all of those types are. I'll get it it probably tomorrow. On the motion sensors, are you getting motion triggers sent out correctly?
If you aren't getting triggers either, the most likely reason is that the auto-config hasn't been sent to them yet because they've never woken up, at least while the driver was running. When you approve units, any auto-config stuff is sent to them. If they are battery powered, that can't actually happen until they wake up. It's always a good thing to wake them up after approval to insure this happens. If you were to close the driver before the unit wakes up (and it can be a long time sometimes, like hours, maybe 8 hours in some cases, those msgs will never get sent.
If you want to be sure, you can always use the drop down on the unit to do a manual auto-config, then go make the unit wake up. Or, if it's one of those that will stay awake for a while, you can pre-wake it up, then do the auto-config and check the 'I know it is awake' check box, and it will send them right then and tell you if it worked or not.
The whole thing with battery powered units is a mess in Z-Wave. There's no way ultimately to win and make it really straightforward and guaranteed.
I'll have time this evening to finish up getting the trace for the Monoprice 4 in 1 to you as well as a new GE+ light switch. What's the status on the other units I sent you info on, the 2 different door switch types (Fibaro w/temp and Linear/GoControl w/2 opening inputs) and the motion with temp? I understand that all 3 are not simple binary, is there any additional info/traces, etc that you need from me?
You may have to send me those again. I was getting a bunch of files and documents and such, and I may have gotten confused at some point there. It would probably be best to name the files after the make/model instead of the unit id. The id is in the file itself. Having a whole bunch of files named unitX makes it hard for me to keep up. I try to figure them out and rename them, but it's easy to get lost.
Maybe a good naming scheme would be:
yourname_make_model.txt
That would make it a lot easier to keep up with. Otherwise everyone has a unit3 or unit4 and keeping up which which one is whose is hard.
Is the CtrlUnitId field for the zstick or the master controller? I am trying to set the associations correct for notifications.
That's the z-stick. Actually you don't even need to now. If you use the client side interface, the manual associations dialog will have a special entry in the list of units to add to the target which I think is [Driver], so you know that's the one.
Bizarrely, it's actually not easy to get the master controller's id. The only way I can see to get it is to watch from msgs from it during the replication process. Those have to come from it. But, otherwise, I can't see any way to get it.