Rgbgenie

[UpDryTwist]

Added support for RGBGenie switch (which should also improve support for other Sunricher switches, and maybe others). The RGBGenie is a rebranded Sunricher switch. It's wall-mounted, and offers a variety of controls for controlling RGB lights, including color setting, dimming, transition speed, and setting scenes. The version I have (ZW-3004) allows setting groups of devices, as well as three global scenes.

"Normal" mode for this switch would be to associate with your Z-Wave devices, and send them commands. It's supposed to be pretty quick and good at this. I wanted to use it to control a bunch of wifi lights, however, which meant I needed to receive its commands. I'm using python-openzwave + open-zwave.

The prior code expected to be SENDING commands to lights (and multi-association devices), so I needed to extend a bunch of the command classes so that they'd anticipate RECEIVING commands for color, etc.

I had to add a new configuration option -- MultiChannelSenderOnly -- to allow the code to behave properly when we have a device that will send us multi-channel commands, but does not expect to receive them.

I made three associated bug fixes or enhancements along the way:

• In Manager.cpp, I was getting a bunch of errors in an attempt to get a floating point precision from non-float types (e.g., strings and integers) (this was before I made any other code changes, so not as a result of extensions for this device, per se). I didn't trace this all the way down to source, but it didn't seem to be adding value to raise the exception, and it was causing initialization errors, so I converted this to logging an error.
• Color::decodeColor() had a bug where it was using the member array to do the decode, not the array passed in. This was probably just an oversight that hadn't been picked up elsewhere (probably because no one was using the method to decode any array other than the member).
• I added another (optional) configuration parameter, LogFilePath, to allow putting the log file somewhere else. Needed this in a Raspberry Pi to ensure that logging is happening in /var/log (which is sitting on a RAM disk), rather than hitting the twitchy SD card.

I'll be separately adding a pull request to python-openwave to support these changes there.

[UpDryTwist]

FYI, failing as I'm honestly not sure what to do about the sequence number in manufacturer_specific.xml, given that I'm far behind the main on this one. Just need to update that to whatever it's supposed to be (?).

[l3arcf]

Wouldn't you change the revision number to 133? Excuse my brevity here, I'm just wondering. It's certainly not my area of expertise.

[UpDryTwist]

I guess. But 133 was used previously in the master (which is now on something like 154), so I wasn't sure the proper number to use ... Anyhow, the XML compiles fine, it's just this one check, that I guess should be set to whatever the final master # is if this is accepted, + 1. (?).

[l3arcf]

Well, a clean slate on the check will get faster/better attention than a failing one. Good luck!