So I use Singled bulbs that don’t repeat, which is good. Everything has LQI of 255 to my controller. I have a small house, but many devices. Repeaters take my LQI to below 80 on many devices and ruin the network. Can I buy a zigbee switchable plug that won’t act as a repeater? Doesn’t sound like I can tell Zigbee not to use a node as a repeater.
Why would you do that. The more routers the better.
I agree. There’s a reason for Sengled not to repeat signals. Thier engineering staff got tired of answering questions about why a network was wrecked when people turned the bulbs off at the power source in a fixture. That generally doesn’t happen with sockets, switches, and outlets.
I’d be super super suprised if you find one.
That’s not what I have been seeing. Anything connected through a router has poor link quality. Things connected directly have great link quality.
LQI is often not a very useful metric. A value of 255 for LQI on quite a number of devices means the manufacturer’s firmware is not even trying to report a value and is just setting it to 255.
In picture below, these two Centralite switches always report LQI values of 255 to devices they are routing for. They are rather old Zigbee devices however have been doing a very good job of routing for many years, but none of their firmware versions has ever reported a LQI value other than 255.
Interesting, what do those graphs indicated to you? And curious, the label on the graphs are min, max and mean. None are actual values?
They are just tracking the history of the reported LQI values at that time – so they (Singled bulbs in this case) are not hard set at 255 based on this data. No, none are the actual values, but you can reverse the math – are you thinking these are just reporting 255 all the time and dropped packets are assigned 0 ? Even if that was the case, I can still see which struggle to keep a good connection. I can’t imagine it is reporting a 0 or min would be 0. I would argue MIN is the actual value, as that is the only way the MEAN results in what results. It appears to be a 10 or 15 minute sliding average.
You may have your own experiences and beliefs, but you go against the wisdom of the experts in the subject, including the manufacturers of the devices.
I really don’t know what a LQI of 255 makes a Zigbee connection more superior compared to a LQI of lets say 37
Out of my ~90 Zigbee devices here (routers and end devices) the “weakest” connection stays around 40. But it never ever let me down for years but that device just works as it should.
I am far from a expert. That said, I have spent a lot of time and coin diddling around with a LOT of mesh networks. Looking into a mesh network in general is a black hole as good inspections tools for some reason seem to be few and far between. Overlay that with the added complexity of Zigbee supporting battery (and even I believe line powered devices) that come and go at pretty much their own time frames. These networks are pretty hard to diagnose.
From my reading, to make matters worse are some holes in the Zigbee and perhaps 802.11.4 standards and holes in the documentation.
For example, as I understand it LQI is not really ‘standardized’ nor is it well documented. It is left totally up to the firmware to create this value based on nothing like RSSI, which does have a well documents set of standards that govern the number that the firmware generates. LQI is like me speaking US dollars and you speaking Singapore dollars and neither of us know the exchange rated between the two. I am not saying there are not setups where LQI values (if calculated) would not be useful. For example, perhaps between two identical devices and firmwares. As was stated by @Tamsy I have devices on my two Zigbee2MQTT networks that have LQI value from teens to 254 and I do not see any latency or non-communication issues that I can attribute to issues in the network (if I see any issues on these two, and I can say I have not had any burps in these networks outside two to three crashes of the Zigbee2MQTT main software in 2 years).
To the graph you published, devices have as many LQI values as connections to other devices. I believe these are graphs for Sengled bulbs that do not act as routers, are these LQI’s between a routing device and the bulb or between the coordinator and bulb? If these bulbs are acting as end devices, my understanding is that there will be a single LQI value (if generated) and it is generated by the coordinator or routing device. End devices do not create a LQI value from my experience. When you say that the LQI values drop to 80 when you added a router, from my experience 80 is a okay number. And I will say again, I am not sure I am buying that your 255 numbers are ‘real’.
Also, I do not see you specifying the make and firmware of your coordinator device. As a point, I believe if you read through the bugs and change log for the fancy pants ‘multi-protocol’ Matter/Zigbee coordinator device that a number of folks are having the unfortunate experience of using. It currently does NOT generate LQI numbers, but just sets the value to 255.
Another challenge in looking ‘into’ a zigbee mesh network is that most of the tools show a snapshot of device information at a point in time. I do not think the zigbee/802.11.4 network design allows for a good method to look at network stats in discrete and synchronized time periods. So to the lack of the raw data in the graphs, it is not possible to tell if the data points are all there and are in consistent intervals between readings.
Good luck, as others have said, I think you will be better served by placing a few solid routers around your abode as the framework for the mesh. I have found Jasco smart outlet and the Philips Hue white and color ambiance E26/E27 blub to be very solid routers, links below and a picture of them on one of my Zigbee2MQTT networks.
To chime in, I have my coordinator running in my garage 10-15 meters from my house. My highest LQI reported by my 70+ devices is 163, the lowest is 43 that five devices report. I have no issues with devices dropping out of the network, everything is solid and works as it is supposed to.
Another thing to consider; if I’m not mistaken Zigbee specification limits number of devices that can connect to single coordinator/router to 64 (and this includes devices are ‘composite’ - one physiucal device might contain several different subdevices, like switch and bulb in one). So forcing connections in your network to just coordinator might significally reduce numner of devices you might have in your system. Think of it like USB ports in your computer; if you have 4 ports you can connect only 4 peripherials. But if you add a hub, it might be way more…
Most coordinators can only have a max of 32 direct children.
Thank you for the insight. This is a Conbee II coordinator talking to Singled bulbs. No repeater presently in the network (I have disconnected them and want to get a week or two of data before I reintroduce the routers back into the network. You can clearly see that the device farthest from the coordinator is not doing as well without the routers (and what you can’t see is that my farthest-away devices no longer have the ability to connect without the routers). That said, my goal here is to collect data and diagnose behavior. So collecting the RSSI would be better than LQI? I will start collecting that too just to understand what I am seeing. Clearly, I need a mesh network, that’s the whole point here, but I want to understand my behavior without it (i.e.–if I am creating RF noise because I have a appliance sitting somewhere it doesn’t need to be (or a wirelessly-connected device that could just as easily have wifi turned off and connected via Ethernet), I should first consider moving the machine to a location causing less RF pollution in the area before trying to engineer around it. That said, my Zigbee channel is clean insofar as I can tell (I’ve moved all my WiFi to the high end of the spectrum and assigned Zigbee to the lowest)). Thank you for your thoughtful feedback.
What are your thoughts on what this is telling you? Again, I am not sure how to read statistical values. I am not sure why you don’t just look at the raw reports from the devices. I guess you could posit that at 10:15 something burped, however without some USD 10,000 Ghz spectrum monitoring equipment it is probably guessing.
You can noodle on this stuff for ad infinitum and probably not come up with a good answer. Or…
. Add some good routers. Allons-y!
Zigbee data rates are measured in bits per hours, and it has very robust checking and retransmission. IMHO, if we had a penny for every hour folks have wasted chasing non-existent RF interference issues on Zigbee networks, we would be rich folk. Not saying that RF interference does not exist, watch a hires video on you mobile via wifi and stand next to and kick on the microwave. But said, RF interference is pretty far down the list of problem causes for Zigbee IMHO.
I suspect that you are experiencing (probably) the 2 most common issues with zigbee (as I did) …
- The ‘visualisation’ tools are pretty, but not accurate
- For best effect, repeaters should be added before end devices
The fact that you’re not complaining about devices not connecting shows that you still have few zigbee devices and they are all with range of the controller. Nothing wrong with that, but not what zigbee was designed for.
With traditional networks like wi-fi there is a hard limit to the number of devices which can connect directly to the controller.
The main advantages of zigbee are (a) to allow much higher number of devices to connect, and (b) to improve reliability by creating multiple possible routes between controller to end device. It does this by connecting multiple repeaters to the controller, and repeaters connected to repeaters …
After reading through many many threads I followed the usual advice:
- determine the best zigbee and Wi-Fi channels for your environment (including considering neighbours wi-fi channels)
- purchase a few more zigbee repeaters - many also function as end devices (such as light bulbs) - and plan where to put them to maximise coverage
- delete all your zigbee devices and integration from HA, and reboot HA so you can start from scratch
- add your chosen zigbee integration and controller to HA. Change zigbee channel now if that is desired from step 1
- add repeater devices one at a time (to force them to join the new network, rather than resuming their old network)
- add end devices
- give it a day or two before looking at any visualisation
After recreating my zigbee network, my problems disappeared.
On the subject of visualisation, for interest here is my latest (from ZHA):
I have an extra couple of sensors which I haven’t decided where to place yet, and a few repeaters are also end devices - so the ratio of repeaters to end devices isn’t as high as it first looks.
Note that one of the repeaters shows green lines indicating strong links - but has actually been sitting on my desk powered off for over a month.
I also created a lovelace panel to help me see the current situation. Very few of my ZHA zigbee devices return RSSI, so I have recorded LQI and time last updated (to see if a device was failing to report):
After running both ZHA and Z2M (as well as several other zigbee network) for a number of years, I will agree 100% that ZHA’s visualization is crap. However Z2M visualization and other tools are very useful. Without good tooling (in the case of your point on coordinator connections a visual or count of coordinator connections) you are flying blind.
To your 2nd point, I agree a best practice is to design your network with a thought out router placement however zigbee and 802.11.4 handle reconfiguration of routes fine. I just tested this for a discussion on another thread today, removing and re-adding a router, the end devices reconfigured within 30 seconds or less, very little perception of a delay by operator. This should be you expectation of your network, not the exception. This on a Z2M network.
(just a reminder, there is no such thing as a repeater in zigbee or 802.11.4, and repeating using the word repeater around zigbee and 802.11.4 I do not think helps folks understand these networks, repeater is not the same as a router).
IMHO, second to the nightmare of Home Assistant’s scripting and automation design, ZHA is also doing a huge disservice to Home Assistant users.