Initial Support for Zwave color bulbs #2376
Conversation
| # have a one node to one entity relationship, and the entity will | ||
| # include both the dimmer and the color zwave value. This allows a | ||
| # friendlier name assignment in this case. | ||
| return zwave.node_name(self._value.node) |
There was a problem hiding this comment.
How would this work for new devices that have multiple color changing elements? They would end up with the same name, no?
There was a problem hiding this comment.
We should not overwrite this method. I prefer consistency in naming (with the other Z-Wave devices) over the chance that a person would not want to rename the device as it is currently named. Chances are probably still small as people tend to name their lights to the location in the house instead of the vendor.
There was a problem hiding this comment.
That's fair enough. I'll go ahead and drop that portion.
For my devices, the dimming value has the label "Level", which means that when I name my lights for example "Living Room", it shows up in home assistant as "Living Room Level". I understand how that makes sense for a device with multiple elements, such as a multi sensor, but for the bulbs it doesn't look as nice, especially when they're side by side with hue bulbs, which don't have the extra baggage.
I might in the future look into a cleaner way to name entities in the zwave base class, but that can be it's own discussion.
|
I've pushed a commit removing the name override. I can squash these intermediate commits at the end of the process. I suspect more changes will be necessary based on tests from other products. |
|
Alright, looks good 🐬 Github can squash the commits. I'll merge it so that the people in dev can play with it . |
|
Just an additional note here on why it is programmed this way: The exclusivity of the 5 color channels is documented in this pdf: https://aeotec.freshdesk.com/helpdesk/attachments/6009584691 in section 5.7. As mentioned, I've only tested with this one bulb, and I suspect this is not how other vendor implementations behave. From what I can see here: https://github.com/OpenZWave/open-zwave/blob/master/config/zipato/RGBBulb.xml , the Zipato exposes color temperature through a configuration command class. It might be a better approach to write ZwaveColorLight as a sane implementation of the zwave standard for generic color support, and extend it for known vendor workarounds. I'm not sure if there's a similar precedence in home-assistant or if we'd rather avoid that type of code. |
|
There are several workarounds in the zwave code already. |
|
OK, I see some of the zwave workarounds. I'll work on a refactoring to isolate the vendor logic and submit another pull request. I can also try and implement logic for the Zipato bulb, since the documentation seems simple enough, but I'll need support from someone who can test it. |
|
How is it going with the RGBW-controlling? I have my Aeon Labs RGBW light (AE-LED-G5) up and running, but it is slightly frustrating that I can only controll the dimming function... Are there any (somewhat) simple ways of doing it today? |
|
The Aeon Labs bulb should be supported as of version 0.23. If it's not working, can you post your zwcfg.xml file somewhere? It's possible there are different revs that report different product ids. The bulb I tested reported Manufacturer id 0x86 and Product id 0x62. It calls itself the ZW098 LED Bulb. COMMAND_CLASS_COLOR also needs to be present. You'll also need to make sure libopenzwave is up to date. I believe color support was added in version 1.4. I've been using the home assistant docker image for my testing. |
|
Ahh, you are right! The strange thing is that i did not see color-thing when i looked in google chrome but it showed up when i used my iphone.. By the way, is it possible to have pre-define colors? (E.g buttons to pick some commn colors). It's a bit tricky to pick the color i want from the full color wheel.. |
|
Glad to hear it's working! I haven't heard of anyone else using it yet, so I was worried for a bit. Chrome might just need to clear cache or something. If you have any other issues you can tag/message me on the forums @armills so we aren't cluttering up this PR. As far as predefined colors go, you can supply a color name to the light.turn_on service in an automation as documented here https://home-assistant.io/components/light/ but there isn't currently a UI element for picking colors. |
Description:
Adds support for zwave color bulbs. Currently I've only been able to test with the Aeon labs bulb. I've attempted to make the code flexible, but the zwave color standard is a bit bizarre. For example, the aeon labs bulb I'm testing with supports RGB modes and color temperature, but only has options for warm or cold light, no spectrum in between. (See here: http://board.homeseer.com/showthread.php?p=1236443 )
If anyone has other zwave color bulbs, more testers would be great.
Pull request in home-assistant.io with documentation (if applicable): Not sure this actually calls for documentation change. It should all be automatically detected.
Checklist:
If user exposed functionality or configuration variables are added/changed:
If code communicates with devices:
toxrun successfully. Your PR cannot be merged unless tests pass