Hue Bridge using xy instead of ct and hs?

I have several automations that save the state of Hue Bridge bulbs (via Hubitat's native integration) and restore them later, and lately, I've noticed that hasn't been working well. Digging into the problem, I found that Hubitat's device page wasn't updating with correct information when manipulated Hue bulbs on the Hue side (e.g., setting the default "Concentrate" scene should do CT mode with 4000K at 100%). Thinking something might be wrong with the Bridge integration app, I checked that it still had scheduled polls (which I have enabled and are showing) and tried manual refreshes of the Bridge device. Still nothing.

Digging deeper, I decided to look at the Hue API output via the debug/CLIP interface. After all, Hubitat can only parse what it gets, right? Turns out, that seems to be the problem. Any change I make in Hue seems to put the bulbs into "xy" mode, no matter if I do colors (which I'm pretty sure used to default to hs instead of xy, but I can't say for sure) or recalling a color-temperature scene like Bright, Read, Concentrate, or Relax. The only way I can it to do anything other than "xy" mode is by going to the color-temperature wheel and moving devices around there. Then it gets set to "ct"--until I save the scene and recall it later, in which case it goes to "xy" mode (but does recall the scene, presumably saved with those settings instead of ct) correctly. I can't figure out any way to get it to "hs" mode from the Hue app (the regular color wheel seems to keep it in xy), though API commands like those from Hubitat will do the trick to get it to either ct or hs mode.

For example, here's what I get if I recall a scene from Hue where a bulb is set to about 2882K using the color-temperature wheel, saving the scene, then recalling that scene:
image
From Hubitat, I can get the exact same thing except with "colormode": "ct" if I do a setColorTemperature(2882).

In any case, this is a problem since Hubitat can't read everything it needs when in xy mode. Has anyone else noticed this problem? Or can anyone think of a setting I might have changed on my Hue Bridge or elsewhere to cause this? The last Bridge firmware update I see was on 10/25/19, and the release notes don't look like they have anything that would affect this (not that they are necessarily a complete changelog). I'm also not sure how long this has been going on before I investigated (just now) and figured this out, so I can't really pinpoint anything that might have caused this--I just don't think it's Hubitat's fault given that I'm pretty sure this used to work as expected, at least when doing what are effectively CT operations on the Hue side, which it now seems difficult to get into via first-party methods. If this was indeed a recent firmware update, I'm guessing others would have noticed this, but I haven't heard anyone say anything so far. You can work around it if you only make changes from the Hubitat side, but I rely on both.

I welcome any ideas or comments anyone may have.

Thanks for reading!

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.