[hue] Reintroduce LK Wiser dimmer work-around for API v2

[jlaur]

Fixes #15315

[andrewfg]

see how I can best reduce runtime impact by caching the need for the work-around rather than string-comparing the modelId property for each command

@jlaur you would simply set a boolean flag in the updateProperties() method.

[jlaur]

see how I can best reduce runtime impact by caching the need for the work-around rather than string-comparing the modelId property for each command

@jlaur you would simply set a boolean flag in the updateProperties() method.

Yes, that was the old implementation. I just want to keep the code clean, and if there would be 10 booleans over time, it would start to get messy. But you are right, let's not over-engineer, we can always adapt if this would become a problem.

[andrewfg]

if there would be 10 booleans over time, it would start to get messy

I suppose you could have a List of references to different product specific patch methods that apply model specific overrides for different device models, and then call List.forEach(call respective patch method). But honestly I think that would be even more messy.

[andrewfg]

@jlaur apropos the Osram patch: The original discussion link http://www.everyhue.com/vanilla/discussion/1756/solved-lightify-turning-off (*) has disappeared. And from googling and ebay I am pretty sure that the old Osram GU10 lamp that had this bug, is not longer available to buy. So probably the issue would only apply to older migrated bulbs.

(*) and also the new forum link https://developers.meethue.com/ seems currently to be returning a "502 Bad Gateway" error..

[jlaur]

@jlaur apropos the Osram patch: The original discussion link http://www.everyhue.com/vanilla/discussion/1756/solved-lightify-turning-off (*) has disappeared. And from googling and ebay I am pretty sure that the old Osram GU10 lamp that had this bug, is not longer available to buy. So probably the issue would only apply to older migrated bulbs.

(*) and also the new forum link https://developers.meethue.com/ seems currently to be returning a "502 Bad Gateway" error..

Thanks, I also found that link no longer works. Since I don't have the details about the specifics here, I think I will scope the PR to only fix the LK Wiser issue. If anyone with an old bulb would experience issues, we could reimplement it then, and would have a chance to test it. There might be differences in the approach. I just re-verified that any transition time works with the LK Wiser Dimmer. I don't know if Osram needed a transition time of zero.

[andrewfg]

Apart from the above comment LGTM

[andrewfg]

I just re-verified that any transition time works with the LK Wiser Dimmer.

So probably the work around should check if there is already a transition time set in the DTO, and only if it is not set, then the patch should set a value of zero. This would eventually allow users to apply slow transitions.

---

EDIT: OK I see that you did already do the above in the latest commit.

[andrewfg]

LGTM

[andrewfg]

@cweitkamp / @jlaur I suggest to hold merging this PR until #15323 discussion is resolved.

[jlaur]

@cweitkamp / @jlaur I suggest to hold merging this PR until #15323 discussion is resolved.

I consider this a regression in 4.0 and would prefer to have it merged and cherry-picked into 4.0.x to be included in 4.0.2.

Depending on the outcome of #15323 it will either be refactored (most likely) or removed, but I don't see this as an obstacle. This is probably to be considered an enhancement and thus would be destined for 4.1.

[lolodomo]

LGTM, thank you

[jlaur]

@lolodomo - would you agree to cherry-pick this into the 4.0.x branch? This work-around already existed for API v1, so it's a regression.

[lolodomo]

Ok, fine.