Closed raccettura closed 6 years ago
I'll confirm this @raccettura report, and add that this problem started occurring sometime before 0.56.
There was a prior version (I don't recall which) where the same bulbs actually did have full RGB control.
Not sure if this is relevant, but my hass setup includes GE Dimmable, OSRAM Tunable White and OSRAM RGBW bulbs. The GE dimmable (brightness only, no color temp or color) report supported_features: 32
whereas the OSRAM Tunable White and OSRAM RGBW bulbs report supported_features: 35
. I'm guessing there's a missing bit somewhere that's used to determine "Hi, I'm a color-controlled bulb."
Possibly related... I have 2 bulbs, after a restart 1 bulb dropped off. This also seems reproducible.
For the life of me I can't get my Lightify TW bulbs to stay connected. They become difficult to reach (only responding to 1 in 3 or 1 in 5 commands) then drop off entirely after a HASS restart.
I had assumed this was a range problem (despite a fair number of other bulbs and a switchable outlet in the house, which are all reachable), but I'm coming around to think it might be a bulb problem.
Just chiming in that after adding my Osram recessed RGBW bulb I only get the tunable colors and not the RGB spectrum. Would be nice to ditch the lightify hub but I want color to work properly :).
Additional info: this seems to be a problem with the frontend realizing the bulb has color capability, not a problem with zha controlling the bulb. After some experimentation, I realized I can successfully send color commands via the entities page in the frontend (as JSON arguments), and via automations. So somewhere between the zha component and the frontend, something is not realizing that the bulbs support color. The ZHA component, however, will send the color command (and it works)! I don't know the codebase well enough to understand where to look but hopefully this is useful intel..
@alterscape good find! I can confirm this as well, front end does not show RGB controls however the device responds to service calls correctly.
I have a feeling this bug may be caused by #9231 as RGBW bulbs are now treated as tunable only in the front end.
I agree. #9231 is the culprit.
Looks like this was supposed to be fixed by #9232, but I can definitely reproduce the problem still with my Osram Lightify RGBW bulbs. I'm going to take another stab at this and will reach out when I'm ready for some testing.
So far it looks like the color_capabilities attribute isn't being added to the Color Control cluster. Did you encounter anything like this when you were testing your change @jkl1337? I tried a couple attributes in that 0x400* range and those don't appear to be available either. I'll probably need to dig into bellows at this point.
I've got a branch started based on digging into the specs, but haven't had time to test on a real bulb. Is anyone able to give this a try? https://github.com/home-assistant/home-assistant/compare/dev...armills:zha-light-rgb
Well I didn't do anything with the Osram lamps. My testing was only on Hue bulbs. I can confirm that Hue bulbs report a sane value for ColorCapabilities. The ZLL spec says that the ColorCapabilities attribute is Mandatory, but it also says a bunch of other attributes are mandatory (like primary coordinates) that Hue bulbs don't even support so unfortunately following the spec may not work in all cases.
@armills the problem I'm having with my Osram bulbs is that the color_capabilities
attribute isn't defined at all, so it's defaulting to 0x10 (tunable).
Since it sounds like @jkl1337 is getting sane values back for that attribute on his Hue bulbs, I suppose the Osram bulbs may not be reporting correct values back for that.
I've got an Osram bulb on the way, so I'll be able to dig a little deeper with it. I'm a lot more inclined to believe that something is broken in our OSS stack, since the devices get certified for compliance. It's always possible, but I would want to definitively prove that before we start adding workarounds.
This is interesting. I can't read the color_capabilities
attribute with the bellows CLI as well.
hass@rpi01:~ $ bellows zcl -D /opt/hass/zigbee.db 84:18:26:00:00:08:3d:d9 3 768 read_attribute 16394
Attribute 16394 not successful. Status=134
134 translates to 0x86, which is UNSUPPORTED_ATTRIBUTE
according to the ZCL docs: "The specified attribute does not exist on the device."
Anybody make further progress on this? Kinda sucks to have $150 in bulbs basically worthless vs a $15 bulb.
@abriasffxi you can buy the lightify hub for like $20-30 or you can just use service calls to change teh color of the light, works fine too. i recommend using lightify products with their own hub.
What service call do I use?
light.turn_on and pass the color to it, the issue is the UI detects it as tunable but the bulb should respond to color change requests.
I'm working on this myself. Caught up on some refactoring of the color service calls first as a prerequisite. The problem is that these bulbs are using ZCL version 4 which doesn't include color_capabilities
. Going to try and get a fix in soon.
Using hass 0.56, added 2 bulbs via zha permit. The bulbs are both OSRAM Lightify RGB bulbs however they show up as tunable (color temp and brightness controls only).
Looking at them I see the following attributes:
I did notice this in the logs: