Exposed lights doesn't turn on when scene executed

[abrvham]

Issue

Hello, When using a Home scene triggering Zigbee lights available on the hue app, those lights doesn't turn on most of the time. However, they are pretty responsive when turned on independently from Home.

On the logs, the two lights "turns off" few second after being turned on (however in reality, the lights never turned on) Note: When the lights are already turned on, they are responsive when the scene is triggered (the colors are changing). Note2: They work fine on the Hue App. Note3: The scenes triggers approx 10 lights (all of them are Hue lights unless those two light strips)

Log Messages

[10/11/2022, 11:23:27 PM] [Hue] Bar: homekit brightness changed from 100% to 100%
[10/11/2022, 11:23:27 PM] [Hue] Bar: homekit on changed from false to true
[10/11/2022, 11:23:27 PM] [Hue] Alcool: homekit on changed from false to true
[10/11/2022, 11:23:27 PM] [Hue] Alcool: homekit brightness changed from 100% to 100%
[10/11/2022, 11:23:40 PM] [Hue] Bar: set homekit on from true to false
[10/11/2022, 11:23:42 PM] [Hue] Alcool: set homekit on from true to false

Debug Files

homebridge-hue (1).json.gz homebrige.log.gz

The log file shows another plugin that fails but it's ok

[ebaauw]

I don't think this is an issue with Homebridge Hue. You've set nativeHomeKitLights, so Homebridge Hue only exposes the GLEDOPTO led strip controllers. The Hue lights are exposed natively by the Hue bridge.

I would have to see the log of Homebridge running in DEBUG mode to check that Homebridge Hue interacts correctly with the Hue bridge, but I think Homebridge Hue updates the HomeKit state when it polls the Hue bridge, after the Hue bridge has polled the GLEDOPTO controller.

In general, recalling a HomeKit scene is a bit of a denial-of-service attack on the Hue bridge. I think with recent firmware versions, the Hue bridge no longer throttles handling API requests, and generates the corresponding Zigbee messages immediately. With 10 lights, setting on/off, brightness, and colour, that probably results in 30 Zigbee messages, which would be more than the Zigbee network can handle. I would expect the bridge to retry, though, but I have no insights to the bridge internal workings. If the lights are already on, the bridge doesn't send the Zigbee messsages to turn them on, reducing the load to 10-20 messages, which the network still is able to handle.

You might try exposing the Hue lights through Homebridge Hue, so it can throttle the requests to the Hue bridge, to prevent flooding the Zigbee network. In general, I would advise to use Hue bridge/Zigbee scenes instead of HomeKit scenes, as these are far more responsive and reliable.

[abrvham]

Yes I was suspecting this Homekit protocol behavior to be responsible, but it's strange because it's only causing problem to those light strips. I have exposed every hue lights with Homebridge without any more luck, with a low "parallel requests" option and a maximum "Wait Time Put".

I think with recent firmware versions, the Hue bridge no longer throttles handling API requests That would explain why this problem occured quite recently.

I hope that the Matter arrival will change how everything is handled.

For now, the solution would be to add another Hue Bridge, right?

[ebaauw]

Yes I was suspecting this Homekit protocol behavior to be responsible, but it's strange because it's only causing problem to those light strips.

Could be the Hue bridge thinks the strips are unreachable (it doesn’t like non-Hue lights as well as Hue lights). Could be weird interaction between native HomeKit and API calls at the same time.

I have exposed every hue lights with Homebridge without any more luck

Did you change the HomeKit scenes to use the Homebridge-exposed lights instead?

For now, the solution would be to add another Hue Bridge, right?

Or use Zigbee / Hue bridge scenes.

I hope that the Matter arrival will change how everything is handled.

It won’t change anything for your existing Zigbee devices. The Hue bridge might provide an API based on Matter eventually, bridging the Zigbee lights. The lights themselves won’t talk Matter.

[abrvham]

Did you change the HomeKit scenes to use the Homebridge-exposed lights instead?

Yes.

It won’t change anything for your existing Zigbee devices. The Hue bridge might provide an API based on Matter eventually, bridging the Zigbee lights. The lights themselves won’t talk Matter.

Sure, but if part of the problem comes from the HomeKit -> Hue Bridge communication (that send one request per light parameter), then chances are the Matter protocol will handle things differently.

I've created a scene that fires only one request per light (turn on) and everything works fines and fast. It's when I add luminosity and color, that the problem start to occurs.

[abrvham]

Closing the issue as apparently nothing can be done on the homebridge part. Feel free to reopen if you want to add more information