I’m running openHAB 2.4.0-SNAPSHOT Build #1379 and have some issues with the Hue binding or its interaction with the ESH Framework. There have been previous reports of Hue status update issues, but they all seem to point to issues that have been marked as resolved/closed, like post #12974 or issue 3768.
Example scenario: Turning on a type 0220 (Hue white ambiance) light using whatever means (Hue Tab, Hue App, openHAB Basic UI), the dimmer slider gets updated at the next Hue status refresh but the color temperature slides stays at the far left (not representing the actual status).
The events.log when turning on a light shows that only the Dimmer status is updated, not the actual Color temperature.
// turning the light on
[vent.ItemStateChangedEvent] - DM_LftKitchenLight changed from 0 to 59
[vent.ItemStateChangedEvent] - SW_LftKitchenLight changed from OFF to ON
// changing the brightness twice
[vent.ItemStateChangedEvent] - DM_LftKitchenLight changed from 59 to 81
[vent.ItemStateChangedEvent] - DM_LftKitchenLight changed from 81 to 60
// changing the color temperature shows that it does know the original value (77)
// but it is not shown until I change it to something else.
[ome.event.ItemCommandEvent] - Item 'CT_LftKitchenLight' received command 34
[nt.ItemStatePredictedEvent] - CT_LftKitchenLight predicted to become 34
[vent.ItemStateChangedEvent] - CT_LftKitchenLight changed from 77 to 34
Is this an issue with the binding not sending the color temperature value but only the brightness, since that’s how Hue turns these lights on/of?
@cweitkamp ESH build 298 has failed, so the mentioned fix is not in snapshot 1381.
@michaeljoos The issue from noppes123 is different.
The fix was for color bulbs with xy color space and his issue is about white ambiance bulbs with ColorTemperature.
Yes, you are right. I have seen the RSS notification but have not checked the status. I am afraid then we have to wait a little longer.
@noppes123 I observed an issue with the color temperature for some of my bulbs too. Not for 220 bulbs but for 210 bulbs. My guess is that it relates to ESH #5762 which has changed the logic how the binding updates color temperature channels. If the bulb is not in color mode ct - which stands for color temperature - the state of the color temperature channel is set to NULL instead.
Reading ESH #5762, it seems to me like there is still some debate to come for the ‘final’ solution. But the use of the CT-mode parameter as proposed by @Kai is a nice and simple fix.
Anxiously waiting for the next ESH build to be included in OH… ;o)
Sorry to bring this ‘old’ topic back to live, but looking at PR #5762, it makes me wonder if the implementation in the Hue and the Zigbee binding are taking a different approach to the color mode issue.
On the Hue side of things, there seems to be concensus that the Color channel will always be valid even in CM=Color_temperature mode, while on the Zigbee side, it looks like they are considered as different and mutual exclusive?
Since I have both Philips Hue Ambiant White (=color_temperature) and Hue RGB lights, I take an interest in this as I am moving all logic away from the Hue bridge to OH…
Might I ask you to explain “mutual exclusive” in detail? What does it mean? Currently I cannot follow. Does the Zigbee binding not allow a thing to have both channels at the same time or does it rejected to send a color and a color temperature command at the same time? Thanks.
Let me add some details - from the Hue point of view - which, I guess, are true for Zigbee at all. We have to differentiate between three type of bulbs:
Colour Light
0x0200
Extended Colour Light
0x0210
Colour Temperature Light
0x0220
First one supports color only, second one color and color temperature and last but not least color temperature. Your problem statement is only valid for the Extended Colour Light. Isn’t it?
In the Hue developer API there is a complete core concept section to explain the color handling - I do not know if it is accessible without having an account. To wrap it up: The Hue API supports three different ways to set a color:
C.I.E. color space aka XY
color temperature from 2000K (warm) to 6500K (cold)
hue and saturation aka HSB
Those are conflicting - meaning they cannot be applied at the same time - thus the
following rule applies: xy beats ct beats hue, sat – Simple.
→ That was a quote …
Alright. Back to topic. Now we can discuss which approach could be the way to go.
// EDIT: Grrr, I am always struggling with those markdown tables …
Thank you for taking the time to explain things to me (and sorry for the late response).
I somewhat loosely used term ‘mutual exclusive’. What I meant was that per this discussion, the Zigbee binding has to deal with the fact that both color and color_temperature channels can have conflicting values/states (my understanding of this discussion), but only the active channel applies at that moment. In the referenced issue Kai proposed to always make the color channel leading as it is a kind of ‘super set’ of the color_temperature channel in the case of Hue
Could be that I totally misinterpreted the discussion in these two issue threads, but that triggered my previous post, nothing more.
And, indeed, I did specifically refer to the 0210 type extended color lights.
Yes, that is true. But I think you missed a very important point. The Zigbee binding communicates directly via the Zigbee protocol with all devices whereas the Hue binding communicates with a REST API provided by Philips - or should I better call them Signify now - We do not exactly know how the interface reacts when we send a request to it. But what I can tell you is that it takes care of such issues which the Zigbee binding is faceing. We can send a color command or a color temperature command regardless and the API will switch the color mode of the bulbs accordingly. Such approaches must be taken care of if you communicate with the bulbs directly.
When you will try to observe the color channel of a Hue bulb connect via Hue binding to OH2 you will see a not expected behavior. If you will set the bulb into color temperature mode in the Hue app you will receive an HSB value for the color temperature set. Now if you will switch to color mode, you will see that the color of the bulb itself will remain while the HSB value will change …
If you will try to do it the other way around and you will send the recognized HSB values as OH2 commands towards the bulbs the color of the light will change too, because the color mode remains the same …
Certainly not! I just want to fully understand how it works.
Spinned up a test setup with a few containers with OH2.5.0-M1, InfluxDB, Grafana and Influx-time-shift. Ready to rock…
