-
Notifications
You must be signed in to change notification settings - Fork 501
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deconz doesn't recognize anymore when a router is offline (ikea bulbs in this case) #6711
Comments
What types of lights are they (brand)? |
Ikea, but same behaviour have Sonoff ZBMini when I use them for testing pupose and then put in the drawer.. |
It's funny, I'm testing now. Seeing a blue dot when i'm doing any changes on it. After a w hile (now) it's going red but remains available.
Seems to be isolated at IKEA lights at this moment |
Can you check the DDF and see if it's gold? (for the bulbs?) Mine was "bronze" changed it to gold, did a hot reload and now it seems instantanious |
Status is "draft" for both. |
That's probably the issue. I've asked the devs to check, but it seems to be isolated to bulbs not having a DDF present. |
Brand wouldn’t be a determining factor here. Would need to know:
Unless you try and control a light over the API, the plugin wouldn’t mark If memory serves, IKEA lights would be setup using attribute reporting in legacy code. ZHA Hue lights don’t support attribute reporting, and deCONZ only configures attribute reporting (through DDF) for ZB3 Hue lights since v2.20. That would be consistent with the observations above. It would also mean, this will get solved as we move to DDFs, cleaning the legacy code. Note: using 20th century wall switches for your Zigbee lights is a bad idea. Any logic depending on I’m almost scared to suggest this, but if you (or rather your spouse) insists on using wall switches, you might try and increase the rate of periodic reporting, at least for |
In the case of TS: Via legacy code as the DDF was on draft. In my case: after changing Bronze to Gold (so it used DDF) it was "fixed". So looks like legacy only.
Also not a favor of "deprecating" as that breaks issues. In my experience so far, there is good reasoning to use it as it is. Mainly because i haven't seen proper and affordable replacements on wallswitches in the Netherlands and proper documentation for group usage. Nevertheless: I believe that discussion is not related to the issue at hand. Apparently we have 2 different "ways" on when a device is marked "unreachable". |
Please remember that Zigbee doesn't do connections (if it did, it would be easy to clear
Deprecating doesn't break anything, as it's purely documentation. Removing
I only linked the issue, because it explains how
Afaik, there is only one way, see linked issue. The variations in DDF vs legacy and reporting vs polling merely change how quickly deCONZ sends a unicast message to the device and can notice the missing response. |
Hi I think this is a massive issue for "normal" users because I expect the Phoscon App also uses "reachable" to show a device not greyed out. But in fact it's completely not showing the truth. Because the device is still working for example if you use the API to turn it on. I'm using deconz for years now and the most anoying thing is that there is no way a "normal" user can find out or see if a device is currently connected. Maybe I'm completely wrong about this, but really it is so anoying to see devices greyed out in Phoscon App but they are working absolutely fine! See screenshot: I hope this will be solved at some point and there is a explanation for the reason. Kind regards |
Going through some older Bug reports for cleanup.. I've just tested with the Ikea GU10 which uses a DDF how it behaves when powering the device physically off.
The reachable attribute was set to false after roughly 30 minutes, and the node in deCONZ as well light in Phoscon App is shown ass offline. Another test with Philips LWB004 E27 light running on legacy code without a DDF behaves also like that with the difference that the attribute polling is controlled by legacy code which focuses on on/off attribute with some hard set interval. The detection of offline also took roughly 30 minutes. Regardless of DDF or legacy code, there is a important "lazy" ramp-up to detect reachable devices. If the responses to neighbor tables requests aren't received other commands will be send with APS ACKs enabled automatically for better detection. The lazy here means that this takes time since the periodic neighbor table requests may take 10, 20, 30 minutes... This is mainly to not get tricked by temporary network hickups and work well in larger networks. Long story short, the detection is in place but can take a while. The DDFs provide the best option to control the intervals. While we can tweak the "consider offline after x failed responses" down for quicker detection this always has the danger of false positives especially in larger networks. Closing the issue for now since I consider the lazy detection is the best trade-off for a broad range of networks. |
Describe the bug
If a bulb is switched off by a wall switch, deconz continue to report it online.Steps to reproduce the behavior
Switch off a bulb by a physical wall switch and wait...........Expected behavior
I expect to see the device offline as beforeScreenshots
Luce Bagno -1 was shut down 12 hours ago.
Luce Cucina D1 & D1 were shut down 4hours ago.
Environment
deCONZ Logs
Additional context
The text was updated successfully, but these errors were encountered: