Unable to change between RGB and CCT modes #810
Comments
llamafilm
changed the title
|
From the log, you're only setting Brightness from HomeKit. If you did recall the HomeKit scenes while capturing they log, the don't include colour (temperature). Otherwise, please capture a debug log, while recalling the scenes.
|
|
The debug log I attached shows the attempt to switch between these two scenes. I do see that it's only changing brightness, and that's precisely the problem here.
|
Ah, that makes sense: the HomeKit runtime sees the scenes would set the Color Temperature (or Hue/Saturation) to their current values, and excludes them from the command sent to the accessory (i.c. Homebridge). Damn, no matter what I try, colour temperature continues to cause issues, see #121, #353, #571, #708. HomeKit doesn't cater for RGB+CCT lights, supporting both colour and colour temperature, wrongly thinking that colour temperature can be translated to Hue and Saturation always. When exposing the standard Color Temperature characteristic in addition to Hue/Saturation, the Color and Temperature wheels in Apple's Home app behave strangely. That's why I reverted to the custom Color Temperature, previously used by Hue. Unfortunately, HomeKit has no equivalent of I probably need to "invalidate" the Hue and Saturation values when setting Color Temperature and vice versa. And that without breaking HomeKit compliance, so they still need to have valid values. But then again, the Color wheel is likely to "jump" when setting the Temperature wheel in the Home app. I understand that the Eve lightstrip, now supporting adaptive lighting, actually exposes both Hue/Saturation and Color Temperature. Maybe Apple changed the HAP spec for the benefit of adaptive lighting, maybe Eve found a better workaround than I did, maybe the Home app behaves just as erraticly. I don't own that device, so I have to wait until Hue brings out adaptive lighting and see how they expose it, and how they invalidate the other attributes. |
Strike that. This issue is (at least in part) caused by the GLEDOPTO firmware, for not updating |
|
I sent a message to Eve app support as well, maybe they can shed some light on this.
How can the Gledopto controller help here? I thought it is receiving only |
|
Although the spec states differently ColorTemperature characteristic in combination with Hue/Saturation was kind of supported. If both three where added ColorTemperature was used to write when you select a Temperature in the Home App. One thing I noticed is that the Home app will always open the "color" color picker regardless what "type of color" was set previously (like Hue/Saturation vs ColorTemperature). That also applies to the Eve Light strip. I can't remember exactly, but I think that wasn't always the case. Edit: Would be really interesting and helpful to get hands on the latest spec 🙃 |
|
From the command-line these commands are working as expected, so I believe the controller is fine. What's not clear to me, is the problem with Eve or with the plugin? Is there some way to get debug logs from HomeKit itself to see what Eve is sending? |
|
I think there is some confusion here because there are two different ways of getting a white light. One way is by mixing R,G,B diodes. The other way is by using separate cool and warm white diodes. This allows a nicer quality of light without any weirdness from the color mixing. This is what the Gledopto does and it's the reason I bought it. So the light strip actually has 5 diodes - R,G,B, warm white, and cool white. With this method, I don't think it makes sense to translate x,y color values into mireds. |
Neither. The problem is a combination of the HAP specification and the GLEDOPTO firmware. Homebridge Hue is already working around the HAP spec issues, but currently is expecting RGB+CCT lights to behave like Hue lights that do the
Correct. Unfortunately, both HomeKit and the Zigbee standard (regarding scenes) fail to understand this. |
|
I see, that makes sense. Gledopto makes another version of these controllers that presents color and white as two separate lights. I guess that would have been more compatible with the current HAP spec. |
|
No can do. That’s what HomeKit is doing already, deciding it doesn’t need to send the desired state, so Homebridge Hue never gets to see the desired state (see the Homebridge log).
Eve only talks to the HomeKit runtime, using the HomeKit API. The HomeKit runtime talks to accessories (incl. Homebridge) over the HAP protocol. I wouldn’t know how to monitor the HomeKit API; I suppose the HomeKit app would need to provide something for that. To see the HAP messages, run I would need to compute and set the corresponding Hue/Saturation values when the controller is in |
|
Actually I think you have already done the necessary calculations. Here's the log with When I set the white scene, HAP tries to set color temperature to 195 (mireds, I think). When I set the red scene, HAP tries to set hue to 360. So HAP-NodeJS is sending the right commands matching what I have set in Eve. I believe the plugin compares this with the current state, and decides not to set hue / ct because it's the same. So all we need to do is send the command coming from HAP even if it seems redundant, translating hue/sat into x,y coordinates which your plugin can do already. White scene: Red scene P.S. Why do you need to translate hue/sat to x,y ? It seems like the light can accept either one? |
Zigbee uses the CIE 1931 colour space; HomeKit uses the RGB colour space. The translation of Hue and Saturation to |
Just to be sure, could you list the relevant part (aid 13) of
Indeed that's right - I stand corrected. So it's not the HomeKit runtime, but Homebridge Hue that discards the unchanged values. Still, assuming your Could you try v0.12.1-0? Install through Homebridge Config UI X, or |
Courtesy of Eve. It adds Brightness and Saturation to the scene for free. I could remove it by selecting and then de-selecting Color while editing the scene. |
|
I'm on 0.12.0 and the config UI doesn't show any updates. Is there a setting to use the beta branch instead? Here is the section of IdentifierCache, although I don't really know how to read this: I do believe the white scene is setting both saturation and color temp. This doesn't really make sense, but I guess saturation should be ignored in this case. |
|
I updated to 0.12.1 via command-line and now this is working! Thank you very much. Debug log attached for your reference. |
Install previous version from the Plugins panel.
Thanks. Your mapping is correct.
The UUIDs The UUIDs
|
Not at once (look at the timestamp). The first is when the API updates its cached based on the command received (and sent over Zigbee to the light). The second is when the API cache is update when the light is next polled (or when the sends an attribute report, for lights that support that). Set |
|
Cool! This is quite a complex project with layers - plugins, homebridge, and HAP itself. I appreciate all the work you and the other devs have done. One thing I notice now when switching between these two scenes: The hue / ct changes immediately, while the brightness fades for about 1 second. I think the fade time is built into the Gledopto controller because it always does this when controlled by the RF remote. So if I switch between my green and red scenes it does a fade. I don't think this is a problem at all, just an interesting note. |
|
So does it mean this particular light just doesn't support brightness value of 127, so when you send that command, it changes itself to either 126 or 128? |
That's good news. I think I prefer this approach over computing the Note how
Homebridge Hue doesn't specify a
Probably. You can check in the deCONZ GUI to be sure. I don't think GLEDOPTO does attribute reporting? Otherwise it could also be that you receive a report from before the transition has finished. |
Cool! I didn't know about this feature. If I use a transition time of 10 seconds and this works between green and red. But the transition between red and white is still instant, while the brightness fades over 10 seconds. I think this is fine for my needs now, but some people might have a problem in this scenario:
I guess the workaround is to set Eve sets transition time with a slider up to 3600 seconds so it's hard to set a precise value. Can this be done with |
You'd have to time the change of the colour to be issues right after the transition of the brightness fading has finished. You could do this from a series of gateway rules (using
Home doesn't support custom characteristics (like TransitionTime), Eve shows a slider, not providing precise control, unless you only use a small range. This is where I use Home+. I've fantasised about exposing multiple characteristics, for 0.1s, for 1s, for 10s, for 1m, for 10m, but that feels too geeky.
Sure, specify something like |
|
I have this "issue" with a Home(kit) -> Philips Hue -> Giderwel 1ID RGBCCT LED controller -> GIDERWEL RGBWW LED Strip Lights. The Philips Hue app switches between RBG or CT (not both at the same time) as if it was 2 separates lights. Indeed if I was to use the 2ID controller they would show up as 2 separate lights. What I was wondering, as a workaround for this combination of products, could homebridge-hue virtually split the RGB and CT lights so that they appear as 2 separate lights within Home(kit)? (i.e. 1 RGB lights, and a separate CT light that sends values to the same controller?) |
|
@mortonpd did you try the beta version 0.12.1 just published today? That solved it for me. |
Yes, I did try the update but no, it did not work. I traced the cause to the wrong ColorTemperature characteristic being set. It was being set to the EveHomeKit UUID instead of the HomeKit one of 000000CE-0000-1000-8000-0026BB765291.(NOTE: I do not have Eve anywhere in my setup) Tested a simple change in the code of setting and it started to work correctly for me. However, I now have a different issue where the color selected on the Temperature wheel is showing the Color selection instead of the Temperature value after updating the lights.
|
|
That sounds like a bug or limitation in Apple's Home app. That app does not have very good support for RGB+W lights. I suggest using Eve or some other app. |
|
This issue has become outdated with iOS 14.2 (or earlier iOS 14?) that handles colour temperature differently, since the introduction of Adaptive Lighting. See #814. |
Issue
I have a Gledopto RGB+CCT strip which presents as a single device with both color and white options. It's connected to Homebridge with deCONZ. I created two scenes with Eve. The night scene sets brightness = 50% and color = red. The day scene sets brightness = 100% and color temperature in white mode. When I switch between these two scenes, the brightness changes but the color stays the same.
It's curious that every time I set a scene, the log shows two state changes.
It looks like we need a way to change the
colormodebetweenxyandct. Is this possible? I don't see this exposed in Eve, but I figure it should happen automatically.Eve shows two separate parameters for Color and Color Temperature. Inside the Color are two tabs to choose color or white. This seems redundant, but nevertheless I have tried making the day scene both ways and I get the same result.
Log Messages
Setting day scene:
Setting night scene:
Debug Files
homebridge-hue.json.gz
homebridge.log.gz
The text was updated successfully, but these errors were encountered: