Error message when old Philips Hue bulbs are requested to report status updates #110
Comments
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
I am seeing the same issue on my old Philips Hue bulbs. Following Reporting is set up: zigbee-herdsman executes the bind request, this takes 1s: Zigbee2MQTT reports a failure after 10s: I wonder if |
|
Looks like we are skipping binding / reporting when it is already set up. For the record here is what the whole sequence looks like with a recent Zigbee2MQTT install. Following Reporting is set up, zigbee-herdsman executes the bind followed by the ConfigureReporting request, this takes 1s (with a random message coming back 6s later): Zigbee2MQTT reports a failure after 20s: |
|
I managed to get around the issue by hardcoding the Philips Hue bulb models that were failing to report that way, works well but obviously too broad a fix to be reasonably upstreamed (see devices.js for reference): |
|
@Koenkk if I am not mistaken we have a try/catch for reporting somewhere for a different device already. I would say we do the same for the hue bulbs? Try to configure it, this we have reporting on older bulbs with old firmwares and newer devices that do support some reporting. But don't throw exceptions. Edit: here is the example I was talking about https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/devices.js#L951 |
|
@Koenkk: I just meant to share my hacky local fix if this behaviour bothers other people, I didn’t mean to suggest that upstream. Catching that the device doesn’t support reporting and logging that would work, but I would actually either blacklist these devices after the first time we see that behaviour or allow to configure bulbs not to use reporting in the configuration file. Another alternative is what you are suggesting: blacklist a series of firmware versions, though that could get very long really quickly. The reason I am looking into this at all is that my controller is hanging / crashing which causes my remotes to be unresponsive, and I thought binding / reporting failing might cause too much traffic and overwhelm the network / controller. It is stable after I put that hack in place, but there are many factors that could have lead to that. |
|
@ndfred can you share the |
|
Sure, I just looked through them and there are actually quite a few, I'll share one database entry for each model assuming they are all the same. I upgraded them all to the latest firmware they support. The color bulbs and light strip are really ancient, the white ambiance bulbs are more recent purchases. 8718696548738 - Philips Hue white ambiance E26/E27 (Router): 9290012573A - Philips Hue white and color ambiance E26/E27/E14 (Router): 7299355PH - Philips Hue white and color ambiance LightStrip (Router): |
|
And non of them support reporting, right? @sjorge I want to block setting up reporting based on the |
|
Not near the bulb, but only the very early firmware revision has reporting for genOnOff for me, so blocking it on anything from 2019 onwards seems fine I think.
~ sjorge
… On 21 Sep 2020, at 20:39, Koen Kanters ***@***.***> wrote:
And non of them support reporting, right?
@sjorge I want to block setting up reporting based on the swBuildId meaning we would block 5.127.1.26581 and 5.130.1.30000, does this match with your case?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Hue bulbs have auto update for Zigbee2MQTT right? If that is the case, I guess we can assume people who care enough to run reporting would have the latest firmware. As a side note, it would be nice to report a failure to set reporting immediately so people can see that in the logs right away, it took a while for me to have all the bulbs come back with a timeout failure. I don't know if that clogs some queue somewhere and delays other commands too. |
Koenkk
added a commit
to Koenkk/zigbee2mqtt
that referenced
this issue
Sep 22, 2020
|
@ndfred devices are never automatically updated. You always need to execute a command yourself to do this. In the latest dev branch reporting will not be set up anymore for the devices with your softwareBuildID. |
|
Just checked and it is all working well, thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi @Koenkk!
As requested in Koenkk/zigbee2mqtt#1064 (comment), I open this issue to track the problem.
The problem is that, after enabling 'reporting' in zigbee2mqtt's configuration file, some old Philips Hue bulbs report that they don't support the feature and zigbee-herdsman ignores the message and just waits until the timeout timer expires. Instead, I propose to catch that message, cancel the reporting timer and print something like "warn - Device 'x' doesn't allow reporting functionality."
Attached to this message you can find the packages captured by a CC2531 sniffer (my main controller is a new CC2652R) and zigbee2mqtt's log file, with debug enabled:
Wireshark - zigbee2mqtt.zip
zigbee2mqtt.txt
Don't hesitate to ask anything you want, please 😉
Thank you for your awesome support and best regards,
Aitor
The text was updated successfully, but these errors were encountered: