[hue] Improvements for exotic light models

[andrewfg]

This PR resolves many issues with "exotic" light models. In this context "exotic" mostly means lights made by third parties other than Philips / Signify ("Friends of Hue") which are therefore not certified for full compliance with the Hue API v2. Albeit it covers a special case with the Philips / Signify "Signe" model as well.

For testing purposes the JARs are here:

• OH 5.2.0-SNAPSHOT
• OH 5.3.0-SNAPSHOT

Specifically this PR does the following:

1. Some non certified lights fail to provide a minimum dimming level - see [hue] IKEA Trådfri bulb turns off when setting low brightness #21057 and currently in that case the binding substitutes a default value of 0.5. This was apparently too high for some. So this PR reduces that to 0.39 (aka 100/255) instead.

2. Some certified lights do provide a minimum dimming level of 0.0 (e.g. Philips Signe) and currently therefore sending 0.0 to the bulb fails to turn it off. So this PR overrides the 0.0 to 0.01 in order to ensure that a precise 0.0 command will turn the lamp off.

3. Some non certified lights fail to provide minimum and maximum supported Mirek values. So analogous to the case with dimming level above, this PR defaults to the min .. max range of 153Mk .. 500Mk.

4. Previously the binding did not use the Gamut provided by certified lights. It always used the default Gamut instead. As a general rule Philips / Signify lights do provide a Gamut, whereas non certified products generally do not. With this PR now we use the Gamut if provided, and only use the default if none is provided.

5. Some non certified lights provide invalid minimum and maximum supported Mirek values. So this PR checks those values and if necessary defaults to the min .. max range of 153Mk .. 500Mk.

6. The increase/decrease button support has been improved by adding support for the dimming_delta and color_temperature_delta fields in the Resource DTO, and having IncreaseDecreaseType commands use those fields.

7. As a consequence of the above changes, the thing handler calls a new extra added method that ensures the light state cache contains all the required parameters for minimum dimming level, mirek schema, and gamut -- be they provided by the device itself in its initial GET response, or otherwise using the system defaults.

8. Often non certified lights will respond to a PUT request with an HTTP 207 error rather than HTTP 200. In the past, when the bridge returned an HTTP 207 response "soft off" the binding would produce an INFO log output. This PR reduces that to DEBUG level.

9. On some non certified lights, when the bridge returned an HTTP 207 response, the devices would not send an SSE event update with the new state. This PR adds a loopback whereby the JSON of the PUT request that caused the 207 response is looped back to the binding as a dummy event. This prevents the states in the UI from "flapping".

10. In the prior version of the binding code I had wrongly assumed that the min .. max range of the dimming channels were "minimum dimming level .. 100%). This PR refactors the code so the min .. max range of the dimming channels are now "0% .. 100%" regardless of the actual minimum dimming level.

11. As a consequence of my misunderstanding about the min .. max range of the dimming channels, the binding was incorrectly calculating the threshold to be used when determining the changeover point between sending a hard on or a hard off command. This applied in particular to non certified products that do not provide their own minimum dimming level. This PR adds an extra Setters method that fixes the threshold and implements the hard on/off logic.

12. The prior version of the binding code would wrongly produce Channel State values of UNDEF in some cases when certain DTO fields were missing. Again in particular it occurred for non certified products. In this PR some UNDEF cases are eliminated, and instead an exception may be thrown at runtime (see next point).

13. .. therefore, in this PR now when a device delivers a DTO with incomplete data, rather than producing the opaque UNDEF state, the binding now logs the detailed error to DEBUG with a full stack trace instead. The extra transparency should help fixing future non certified light models.

14. In order to test the above changes I purchased both a Lidl Livarno TS0502A E27 CT bulb that should be similar to the TS0505A of @kaikreuzer and also an Ikea Tradfri 1055 lumen E27 bulb that should be similar to the Tradfri lamp of @jlaur, for testing the code. And as far as I can tell the errors reported in the below mentioned issues have now been resolved.

15. It seems that the (also non certified) "Ikea Tradfri" bulbs suffer the same bug as the "LK Wiser Dimmer". So this PR extends the same fix to those Tradfri bulbs.

16. Furthermore, if a room or zone contains such a Tradfri or LK Wiser light, then the bug also occurs on the respective room or zone. So this PR applies the same fix to such things. It also applies the fix to the "all lights zone".

17. The Junit tests have been adapted to the above.

18. NOTE: in one of the issues below @kaikreuzer had mentioned that his light would revert to another color temperature state after some variable time between 12 and 45 seconds. My hypothesis is that you had the Hue App open on that light, since the Hue App is known to send refreshes of the state that it is displaying in its own UI from time to time. (I noticed this myself when testing..)

Resolves #21057
Resolves #21044
Resolves #21045
Resolves #21043
Resolves #21011

Signed-off-by: Andrew Fiddian-Green software@whitebear.ch

[Copilot]

Pull request overview

Copilot reviewed 17 out of 17 changed files in this pull request and generated 5 comments.

[jlaur]

Thanks for all these fixes and improvements! I'll try to have a look as soon as possible, and also get it into my production system for some testing.

One that I'm curious about:

15. It seems that the (also non certified) "Ikea Tradfri" bulbs suffer the same bug as the "LK Wiser Dimmer". So this PR extends the same fix to those Tradfri bulbs.

I actually never experienced that with any of my Trådfri bulbs (which I have a variety of). Are Trådfri bulbs still being sold? I thought IKEA switched to Thread entirely. Perhaps this is a firmware bug in newer bulbs? I assume this means you are not able to turn off such a bulb from the Hue app either?

In the specific case of LK Wiser (LK is Lauritz-Knudsen, a Danish part of Schneider Electric), apparently the Zigbee incompatibility stems from a Tuya implementation adopted by the subcontractor that did at least the initial Zigbee implementation for them.

[andrewfg]

Are Trådfri bulbs still being sold? I thought IKEA switched to Thread entirely.

To be frank, I don't know; I got it on eBay so I have no clue about its age.

I assume this means you are not able to turn off such a bulb from the Hue app either?

Nope. It works just fine in the App. (But the App dimmer slider only goes from 100% to 1% ..)

In the specific case of LK Wiser

Interesting. I think the Hue Bridge does accept Tuya lamps? If so I might buy one (on eBay) to test. PS elsewhere you mentioned a Light Solutions Dimmer-Switch-ZB3.0 which may perhaps also have the same issue (??)

[jlaur]

I assume this means you are not able to turn off such a bulb from the Hue app either?

Nope. It works just fine in the App. (But the App dimmer slider only goes from 100% to 1% ..)

I think it might be a different issue then. The issue with the LK Wiser dimmer is pretty clear, and it doesn't turn off from the app either. The details are in my blog post LK Fuga Wiser Wireless Dimmer hands-on. The app doesn't send transitiontime in the PUT request, and therefore it doesn't work. I don't know what this means in the lower levels, i.e. the Zigbee protocol. But when providing transitiontime, it works. It might be worth trying to send a PUT request to turn off your bulb using a simple curl command, so you can check if you see the same difference. That would be somewhat unexpected, since the Hue app still can't turn off my Wiser dimmers, so I don't think anything changed since then.

In the specific case of LK Wiser

Interesting. I think the Hue Bridge does accept Tuya lamps? If so I might buy one (on eBay) to test. PS elsewhere you mentioned a Light Solutions Dimmer-Switch-ZB3.0 which may perhaps also have the same issue (??)

I don't know how widespread the problem is, but I seem to remember on some forum that other users linked this to be a Tuya issue. So you might get "lucky" if you find some other cheap Tuya bulb or similar. The Light Solutions Dimmer Switch seems to be "playing by the rules" and fully Zigbee compliant. I have no issues turning it off. I only ever experienced this with Wiser products.

[jlaur]

Since it's not a general issue with TRÅDFRI, we might need to tweak something here. The work-around is to use dynamicsDuration which is Duration.ZERO as default. This will override the transition time for all TRÅDFRI bulbs from the 400 ms Hue default transition time (when not provided). See also #15323.

We can come back to this after #21062 (comment), which is still a bit confusing for me.

[andrewfg]

So my bulb with the bug is Model Id "TRADFRI bulb E27 WS globe 1055l" => perhaps you can give me the respective Ids of your bulbs that do not have the bug. Maybe there is some way to differentiate deeper?

HOWEVER, I also have Tradfri lights in my kitchen and in a display cabinet. And indeed those ones do not suffer from the bug e.g. below..

[andrewfg]

I think it might be a different issue then.

Well it might indeed be a different issue, but the solution is exactly the same -- namely (as you say) -- adding a dynamics duration to the command JSON payload (it actually doesn't matter whether the dynamics duration is 0 or something else; it just has to be present in the payload).