[config] Fix Leviton Vizia RF+ device family. #2290
Conversation
Added support for VRCS2, VRCS4, VRCZ4, and VRR15 devices. Added detailed information about how to set indicator lights and configure scenes. Fixed configuration entry for RZP03 which was erroneously associated with the VRCS2 configuration file. Cleaned up product names and associated metadata.
| <!-- Each button toggles an individual scene on or off. Multiple scenes can be active at once. | ||
| By default the device will associate groups 1 and 2 with the local loads. | ||
| Do not auto associate the controller with group 1. --> | ||
| <Group index="1" max_associations="232" label="Button 1" auto="false"/> |
There was a problem hiding this comment.
If you do not auto associate, how does the controller get updates about state change? Maybe all Groups should be auto=true (group 1 is implicit)
There was a problem hiding this comment.
The scene controller and the loads are represented as different zwave nodes using multichannel encapsulation.
The scene controller has factory default associations with the local loads (relays) on the device. There's no need to associate the primary controller unless you want the primary controller to respond to scene changes itself. In my case, I just want the VRCS2 loads to be locally controlled (so they're very responsive).
The loads appear as separate binary switches. They seem to get auto-associated (somehow?) with the primary controller so they do report their state changes as expected.
Aside: My old Vera automation system had a nasty habit of purging factory default associations when setting up a new device. In the case of the VRCS2, it would remove the associations for the local loads and effectively break the switch behavior unless manually reconfigured. It took ages to figure out what was happening there.
| <!-- Indicator Lights --> | ||
| <!-- Use these messages to override the indicator lights. | ||
|
|
||
| 91 00 1D 0D 01 00 00 : Reset LEDs to locally controlled operation (default behavior). |
There was a problem hiding this comment.
Assuming I'm reading this correctly - its using the Manufactuter_Proprietary CC for Leds?
There was a problem hiding this comment.
That's correct. Unfortunately it doesn't support the "Indicator" command class.
| <!-- Each button toggles an individual scene on or off. Only one scene can be active at once. | ||
| If the device has a switch, then by default it will associate group 1 with the local load. | ||
| Do not auto associate the controller with group 1. --> | ||
| <Group index="1" max_associations="232" label="Button 1" auto="false"/> |
There was a problem hiding this comment.
Similarly, the VRCS4 presents its load as a separate device and auto-associated it to button 1 as the factory default. That said, 3 of the 4 buttons are useless out of the box unless additional associations are made.
So we could argue that auto-association with the primary controller is more essential for this one. I've made those associations manually for my case along with other configurations documented in this file.
Unfortunately, openzwave currently doesn't know how to configure the scenes such that it can distinguish between each button and it doesn't handle incoming scene actuator commands either. With that in mind, I don't think auto-association is a good idea just yet but I will defer to your judgement on the matter.
| corresponding scenes to be active. | ||
| --> | ||
| <CommandClass id="38"> | ||
| <State> |
There was a problem hiding this comment.
We need to port AfterMark to Compatibility rather than state.
There was a problem hiding this comment.
That sounds good. How about I remove this section from this patch for now and reintroduce it once the necessary command classes are implemented?
Alternatively, what would you think of encoding the "after mark" bit as an attribute of the CommandClass element itself because it fundamentally changes how the command class is interpreted?
| <!-- Each button toggles an individual zone on or off. Multiple zones can be active at once. | ||
| If the device has a switch, then by default it will associate group 1 with the local load. | ||
| Do not auto associate the controller with group 1. --> | ||
| <Group index="1" max_associations="232" label="Button 1" auto="false"/> |
| - Groups 1-4 are triggered when buttons 1-4 are pressed when their LED is not lit. | ||
| - Groups 5-8 are triggered when buttons 1-4 are pressed when their LED is already lit. | ||
|
|
||
| To configure the scenes, send SCENE_CONTROLLER_CONF_SET to associate scenes with |
There was a problem hiding this comment.
we don't support this CC.... so your saying a user should use the SendRaw to get this working?
| <Entry author="Jeff Brown - jeff.brown@gmail.com" date="29 June 2020" revision="1">Initial creation</Entry> | ||
| </ChangeLog> | ||
| </MetaData> | ||
| </Product> |
There was a problem hiding this comment.
The configs are undocumented. I haven't needed to poke them, assuming there are any.
The association groups are automatically detected just fine. There's only one group and it reports the state of the controlled load.
|
Regarding Aftermark - Only a few CommandClasses support it. You would need to update the COMMAND_CLASS_SWITCH_MULTILEVEL to also property support Aftermark:
Does this device advertise this as a Controlling CommandClass (rather than Controlled). If it does, you don't need to add it to the config file as a Aftermark Class. You can refer to the Basic CC to get some idea - Although that is also handling a lot of other corner cases as well. |
Yeah, that makes sense. I'll take a look at that project in a bit. In the meantime, I managed to work around the problem by handling these unhandled messages outside of openzwave. It works surprisingly well. ;)
Unfortunately it doesn't. I checked.
Thanks! |
|
Sorry I've been slow to take care of this because my local workarounds are working well enough. ;) I'll get on it in a bit. After some reflection, I think I may actually implement some of the missing command classes. We'll see. |
This config merits discussion on how to handle SWITCH_MULTILEVEL_START_LEVEL_CHANGE and SWITCH_MULTILEVEL_STOP_LEVEL_CHANGE commands sent by the controller to the associated actuator.
More information here: https://groups.google.com/forum/#!topic/openzwave/PbCrQyQODTo
I've tentatively added COMMAND_CLASS_SWITCH_MULTILEVEL together with State/AfterMark compatibility directives to VRCS4 and VRCZ4 to indicate that the device sends these commands (but doesn't handle them itself). These declarations fail "make xmltest" validation but they do work at runtime. Moreover, OpenZWave doesn't know how to handle the incoming level changes (it just logs them).
I think we should break this PR into two parts. (I'm including everything here for context.)
Thoughts?