dresden-elektronik / deconz-rest-plugin

deCONZ REST-API plugin to control ZigBee devices
BSD 3-Clause "New" or "Revised" License
1.9k stars 502 forks source link

Hue lights dropping off mesh #2933

Closed simonbutton closed 4 years ago

simonbutton commented 4 years ago

I think this is an issue, but will describe what my problem is and seek advice. I have Home Assistant running on a NUC using Proxmox. I use the Deconz add-in along with the Conbee II an a USB extension lead (channel 25). I have around 20 sensors (combination of Tradfri motion and Smarthing Multipurpose along with a Hue outdoor sensor), around 80 Ikea lights (mosting GU10 and and E27) and 7 Philips Hue (LWB010). I also run 3 Ikea repeaters. The Mesh is well established (regularly check VNC and mesh appears to be solid with multiple green links into routers and a green link into every end point). Lights in general work very well most of the time. However, as I have added more lights and sensors in, the Philips Hue lights randomly but regularly drop off the mesh and become unresponsive. When I had less devices in the mesh, I did not see this occuring. Power cycling the unresponsive Hue light doesn't immediately fix this. Sometimes after hours the lights might rejoin the mesh, but not reliably and consistently. I note Conbee II supports 200 devices, but the Hue bridge is limited to 50 I believe. My question is are there limitations with the Hue bulbs working with Conbee II / Deconz when there are more than 50 devices?? Not sure if this is a device limitation issue or something else? Any ideas why the Hue lights are behaving like this?

Mimiix commented 4 years ago

Hi

This numbers wouldn't be a problem.

Can you provide me on which version of the deCONZ you are?

is the Conbee on the latest firmware?

ebaauw commented 4 years ago

the Philips Hue lights randomly but regularly drop off the mesh and become unresponsive

How did you determine that? Most likely, the coordinator has lost the route to the light, but the light itself is still happily connected to the network. Does it react to group commands? Can you control the light directly from a wireless switch?

When I had less devices in the mesh, I did not see this occuring.

The larger the network, the more likely for any latent routing issues to become visible.

Power cycling the unresponsive Hue light doesn't immediately fix this.

Normally, a device sends an announcement broadcast on startup. This message is used to re-determine the route to the device. If there's also a routing issue with one of the routers in between the device and the coordinator, it might not be enough.

Instead of power cycling, try to press 0 while the corresponding node is selected in the GUI. If that doesn't work, pressing L might (this should cause the device to leave and re-join the network, causing the same announcement broadcast as power cycling the light).

Sometimes after hours the lights might rejoin the mesh, but not reliably and consistently.

Smells like routing issues. See also https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261. Note that the map doesn't show active connections: it shows the neighbour tables as queried by the coordinator. When a device is unreachable by the coordinator the lines to it disappear.

I note Conbee II supports 200 devices, but the Hue bridge is limited to 50 I believe. My question is are there limitations with the Hue bulbs working with Conbee II / Deconz when there are more than 50 devices?

The 200 devices is a commercial limit. The 50 a technical, as the Hue bridge needs to poll the lights since Hue lights don't support attribute reporting (pushing their state). The more lights in the network, the longer before a light is next polled.

simonbutton commented 4 years ago

Hi

This numbers wouldn't be a problem.

Can you provide me on which version of the deCONZ you are?

is the Conbee on the latest firmware?

Deconz is 5.3.5 Conbee firmware is 264A0700

simonbutton commented 4 years ago

the Philips Hue lights randomly but regularly drop off the mesh and become unresponsive

How did you determine that? Most likely, the coordinator has lost the route to the light, but the light itself is still happily connected to the network. Does it react to group commands? Can you control the light directly from a wireless switch?

When I had less devices in the mesh, I did not see this occuring.

The larger the network, the more likely for any latent routing issues to become visible.

Power cycling the unresponsive Hue light doesn't immediately fix this.

Normally, a device sends an announcement broadcast on startup. This message is used to re-determine the route to the device. If there's also a routing issue with one of the routers in between the device and the coordinator, it might not be enough. Instead of power cycling, try to press 0 while the corresponding node is selected in the GUI. If that doesn't work, pressing L might (this should cause the device to leave and re-join the network, causing the same announcement broadcast as power cycling the light).

Sometimes after hours the lights might rejoin the mesh, but not reliably and consistently.

Smells like routing issues. See also #1261. Note that the map doesn't show active connections: it shows the neighbour tables as queried by the coordinator. When a device is unreachable by the coordinator the lines to it disappear.

I note Conbee II supports 200 devices, but the Hue bridge is limited to 50 I believe. My question is are there limitations with the Hue bulbs working with Conbee II / Deconz when there are more than 50 devices?

The 200 devices is a commercial limit. The 50 a technical, as the Hue bridge needs to poll the lights since Hue lights don't support attribute reporting (pushing their state). The more lights in the network, the longer before a light is next polled.

I determined they drop off the mesh by going into VNC and can drag the light router and the link is no longer connected to the router. I will see if the light reacts to group commands and report back.

I have tried pressing 0 in the GUI and can see the router indicator flash blue. But then when I try and turn the light on/off from Home Assistant, I see the same indicator flash red and I get this in the deconz log:

20:58:50:436 delay sending request 139 dt 3 ms to 0x00178801047D901E, ep: 0x0B cluster: 0x0006 onAir: 1

I have not tried to press L before, but will try this next time it happens.

simonbutton commented 4 years ago

@ebaauw I just had the Philips bulb go unresponsive. Went into VNC and initially hit 0 and could see it flash blue. There was no connections between this light router in the network diagram and I could not control the light from home assistant. I then hit L and a green connection appeared int the network diagram. However, I still could not turn the light on or off from home assistant. I then went into the deconz GUI and attempted to change the brightness for the group the light is in and could not adjust brightness.

It is worth noting I have 7 of these lights in my mesh, 4 of them have direct connections to the coordinator and the other 3 connect via other routers. It is only the 3 that connect via other routers that have this issue. Thanks for your help on this matter

ebaauw commented 4 years ago

It is only the 3 that connect via other routers that have this issue. Thanks for your help on this matter

Went into VNC and initially hit 0 and could see it flash blue. I then hit L and a green connection appeared int the network diagram.

The 0 sends a broadcast which (if still in the network) the device picks up and responds with a unicast to the coordinator. I think the L sends a unicast; it usually works right after a 0, but not all the time.

I then went into the deconz GUI and attempted to change the brightness for the group the light is in and could not adjust brightness.

How did you do that from the GUI? Did you change the Destination Settings? I find it easier to try this from the API (do a PUT of /groups/../action).

It is worth noting I have 7 of these lights in my mesh, 4 of them have direct connections to the coordinator and the other 3 connect via other routers. It is only the 3 that connect via other routers that have this issue.

I think it's the same root cause as issue as #1261. You might try and press 0 and L on the intermediary routers, or power cycle these instead of the unreachable Hue light.

Thanks for your help on this matter

I'm afraid I won't be of much help after determining the cause of the issue. Problem is that different manufacturers use different strategies to keep track of the routes across the mesh network. This is all handled in the firmware of the routers and the coordinator. Even if I would have had access to the source code for these, I have no experience here. I follow #1261 with great interest, but I'm not even sure I understand all the technical details.

I'm not sure if the issue can even be solved in the coordinator firmware alone. The use of source routing sounds promising, you might try the latest ConBee II firmware with that option enabled, from http://deconz.dresden-elektronik.de/deconz-firmware/?C=M;O=D. I understood that it increases the reachability of routers, but causes issue with the reachability of the Hue motion sensors.

stale[bot] commented 4 years ago

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.