[config] Fix Leviton Vizia RF+ device family.

[j9brown]

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

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

Thoughts?

[Fishwaldo]

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

1. Only expose ValueID's that are appropriate for reporting in a Aftermark CC.
2. Make sure they are exposed as Read Only
3. 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]

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]

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.