[config] Fix Leviton Vizia RF+ device family. #2290

j9brown · 2020-07-03T21:38:56Z

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.)

Submit the overall fixes to the Vizia RF+ family of devices, omitting the multilevel switch compatibility directives.
Figure out how we should handle those messages properly and amend the configs as required once that's done.

Thoughts?

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.

Fishwaldo

See below on comments about supporting AfterMark.

Fishwaldo · 2020-07-06T05:27:35Z

config/leviton/vrcs2.xml

+      <!-- 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"/>


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)

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.

Fishwaldo · 2020-07-06T05:29:33Z

config/leviton/vrcs2.xml

+  <!-- 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).


Assuming I'm reading this correctly - its using the Manufactuter_Proprietary CC for Leds?

That's correct. Unfortunately it doesn't support the "Indicator" command class.

Fishwaldo · 2020-07-06T05:29:44Z

config/leviton/vrcs4.xml

+      <!-- 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"/>


same comment as above.

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.

Fishwaldo · 2020-07-06T05:30:47Z

config/leviton/vrcs4.xml

+       corresponding scenes to be active.
+  -->
+  <CommandClass id="38">
+    <State>


We need to port AfterMark to Compatibility rather than state.

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?

Fishwaldo · 2020-07-06T05:30:58Z

config/leviton/vrcz4.xml

+      <!-- 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"/>


same comment as others.

Fishwaldo · 2020-07-06T05:31:33Z

config/leviton/vrcs4.xml

+         - 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


we don't support this CC.... so your saying a user should use the SendRaw to get this working?

Yep. At least for now.

Fishwaldo · 2020-07-06T05:32:09Z

config/leviton/vrr15.xml

+      <Entry author="Jeff Brown - [email protected]" date="29 June 2020" revision="1">Initial creation</Entry>
+    </ChangeLog>
+  </MetaData>
+</Product>


No Config/Association Groups?

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.

Fishwaldo · 2020-07-06T05:38:13Z

Regarding Aftermark - Only a few CommandClasses support it. You would need to update the COMMAND_CLASS_SWITCH_MULTILEVEL to also property support Aftermark:

Only expose ValueID's that are appropriate for reporting in a Aftermark CC.
Make sure they are exposed as Read Only
override CommandClass::HandleIncommingMsg to decode SET messages and update appropriate ValueID's

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.

j9brown · 2020-07-10T22:36:37Z

Regarding Aftermark - Only a few CommandClasses support it. You would need to update the COMMAND_CLASS_SWITCH_MULTILEVEL to also property support Aftermark:

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. ;)

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.

Unfortunately it doesn't. I checked.

You can refer to the Basic CC to get some idea - Although that is also handling a lot of other corner cases as well.

Thanks!

j9brown · 2020-09-11T22:51:06Z

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.

Fishwaldo reviewed Jul 6, 2020

View reviewed changes

Fishwaldo added ConfigUpdate enhancement NotReady labels Jul 6, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[config] Fix Leviton Vizia RF+ device family. #2290

[config] Fix Leviton Vizia RF+ device family. #2290

j9brown commented Jul 3, 2020

Fishwaldo left a comment

Fishwaldo Jul 6, 2020

j9brown Jul 10, 2020

Fishwaldo Jul 6, 2020

j9brown Jul 10, 2020

Fishwaldo Jul 6, 2020

j9brown Jul 10, 2020

Fishwaldo Jul 6, 2020

j9brown Jul 10, 2020

Fishwaldo Jul 6, 2020

Fishwaldo Jul 6, 2020

j9brown Jul 10, 2020

Fishwaldo Jul 6, 2020

j9brown Jul 10, 2020

Fishwaldo commented Jul 6, 2020

j9brown commented Jul 10, 2020

j9brown commented Sep 11, 2020

[config] Fix Leviton Vizia RF+ device family. #2290

Are you sure you want to change the base?

[config] Fix Leviton Vizia RF+ device family. #2290

Conversation

j9brown commented Jul 3, 2020

Fishwaldo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Fishwaldo commented Jul 6, 2020

j9brown commented Jul 10, 2020

j9brown commented Sep 11, 2020