Polling the state of devices not supporting reporting

[HpLightcorner]

Issue

When using switches/dimmers from GLEDOPTO connected to a Hue bridge, a status set by using "the manual switch itself" is not correctly reflected Hue/Homebridge. This seems to be a known issue with polling as a workaround.

I am not sure if this is more of a Hue issue or if the Homebridge plugin can trigger polling the state of the device? With minimal guidance, I am willing to help and implement/test/contribute the feature :)

[ebaauw]

The Hue bridge, like any Zigbee gateway, keeps a cached copy of the state of Zigbee devices. API requests to get a device state are answered from this cache, and never cause any actual Zigbee messages. Obviously. API requests to change a device state do result in Zigbee messages. The Hue bridge, unlike any other Zigbee gateway, doesn’t setup Zigbee attribute reporting for lights, plugs, wired switches (devices exposed as lights resource). In fact, Hue lightoids don’t even support attribute reporting. Most non-Hue lightoids actually do support Zigbee attribute reporting, the Hue bridge just doesn’t configure it. The Hue bridge updates the cached light state by polling the devices, and with the predicted new state on an API call. The bridge polls about one light per second, so the more lights you have, the longer it takes between two polls of the same light. As long as you control your lightoids exclusively through the Hue bridge, and only use API calls with predictable results, this scheme works. When you control the lightoids otherwise (through Zigbee controllers that interact directly with the device, through traditional wall switches, through on-device physical buttons) it doesn’t. And this gets worse, the larger your Zigbee network. There’s nothing Homebridge Hue, or any Hue API client can do to address this issue. The only way to address it is to replace your Hue bridge with another Zigbee gateway, like deCONZ.

[HpLightcorner]

Excellent, thanks for the summary @ebaauw

I have been assuming that the Gateway keeps a cached copy of the network state - with all the additional information, I am now simply wondering why these GLEDOPTO switches are not reported correctly (even not within the Hue app itself). Assuming that the Hue bridge pools the switches once in a while (let's say every minute), it should update its state then (even if the buttons do not support reporting like the Hue original stuff).

I was wondering if the bridge firmware does not poll 3rd party lights. I will take the time and look into deCONZ - migrating the Network seems the best option then.

A workaround, for now, would also be if HomeKit force-sends every command. For example, The Hue Gateway assumes the switch to be off; I manually "overwrite the state to on using the wall switch" now, when I change a scene which sets the light to off within HomeKit again, instead of assuming the light is already off, it should just resend the command anyway. (I have seen this setting in another plugin; again, I am just educated guessing :))

[ebaauw]

Afaik the Hue bridge has no policy to treat non-Hue lightoids as second-class citizens, and should poll them just as often as Hue light. It’s been several years (and Hue bridge firmware versions) since I had a large Hue network, so that could have changed. You’d need to sniff the Zigbee network to be sure. I do know the Hue bridge tends to have issues communicating with non-Hue devices, marking them as unreachable. When there’s a hiccup while the device is being polled, the cached state won’t be updated.

Zigbee lights don’t accept state changes while off. Consequently, the Hue bridge will return an API error, if you try and change the state of a light it thinks is off. It might still send the corresponding Zigbee messages, but as I mentioned: it’s been a long time since I last looked at this. To prevent these API errors, Homebridge Hue will only make API calls to the Hue bridge, when the requested state from HomeKit differs from the state as reported by the Hue bridge. This might not have been the luckiest design decision, but the interaction with the Hue bridge is quite delegate and I won’t be changing this before Homebridge Hue2.