First, I tried to add a new ZigBee device (Aqara magnet) using the « standard way »: configuration | Integration | ZigBee “Configure” | + Add Device. On purpose, the device was located beyond two thick walls and is therefore out of range of the Coordinator. A router device (Philips hue bulb) is placed mid-way between the Coordinator and the Aqara device. The add device command fails.
Second, I have used on the Router device (Philips) the “add devices via this device” command. A window similar to the “normal” add device widows open and after a few seconds, the Aqara device is correctly discovered. I tested the behavior of the device in Lovelace and it reports correctly the close/open state.
This is quite interesting because this seems to indicate that when using the “normal” add device command only the Coordinator is looking for new devices and that the search is not “pushed” to the Routers. This is may be why most people recommend adding new devices close to the coordinator. Hopefully once added in the network and placed to their final location the mesh should heal itself and the parent of the end device should be transferred from the coordinator to the router?
I am still unclear about the meaning of LQI and RSSI values (see Reported LQI values for Zigbee devices with ZHA integration for interesting question/information). As stated in this reference, it is unclear if the LQI / RSSI only refer to the last hop or if the values take in account the complete path from the ZC to the ZED. In my test, the LQI for the ZR (Philips bulb) and the ZED (Aqara magnet) are equal to 255 and this seems very high as the devices are located far through wall?
Interesting also is the fact that the connection between the router and the end device show up on the network graph! As you know the arcs that tie the nodes together display LQI value(s). On a Coordinator (ZC) to Router (ZR) connection, there are two values v1/v2? Originally, I thought these two values represented max/min values. However, by looking at the content of the zigbee.db I have found that actually these two values correspond to the LQI in each direction of the link (strange no? why different values?). On a Router (ZR) to End Device (ZED) connection, only one LQI value is displayed. This probably make sense because only the children can initiate an exchange with its parent.
As I have moved the Philips Router device in a location placed between the coordinator and the Aqara weather end device the network should normally “heal itself” and switch the parent of the Aqara end device from the coordinator to the router. By doing so, the RSI would probably change from around 100 to around 255. There are a lot of articles on the subject of ZigBee network construction/healing. If I understand correctly, in my case the Aqara end device should keep track of a working but bad link to the coordinator, and use a better link to the coordinator through the router. All the different possible paths should be displayed on the graph (extracted from the routing table kept in devices?). As I understand, the process takes time and therefore I will allow 24 hours for this process to complete. If the link is not modified automatically, I will try to force it to happen using the “add devices via this device” command.
Found the following interesting information:
LQI less than 255 indicates packet loss. RSSI should ideally be something like -75 dB or above (e.g. -75 is better than -85).
Just installed the new ZigZag custom panel that displays a graphical layout of Zigbee devices and the connections between them. It was released yesterday from Zigzag-panel showing no graph but unfortunately it does not work for me Zigzag-panel showing no graph.
Your results are consistent with my experience and with what I believe is expected behavior of the Zigbee mesh.
One note about signal range… 2.4GHz signals can pass through many building materials quite well. Interior walls made of wood and drywall shouldn’t cause much of a problem. Concrete or brick is another matter, though. As is metal.
As for adding devices, my understanding is that ideally, you add your devices from the location in which they will be ultimately installed. When you click on “add devices from this device” in ZHA, my understanding is that ZHA will use that device to search for and configure new devices. If that device (coordinator or router) can’t pick up the signal from the new device you’re trying to add, the new device will not be added.
Whenever I add a new device, I try to pick a Router device that’s fairly close to the new device’s intended loction (i.e. pick a device I think will make a good parent) and then select the “add devices from this device” option from that device’s Device page in HA. That works 95% of the time. In the few cases where it doesn’t I move the new device a little closer to the Router device I’m trying use to add the new device, and then it has always worked.
This may be accurate. My understaning is that an LQI of 255 indicates no packet loss, not necessarily a perfect analog signal. Also, if the wall in question is wood/drywall, it shouldn’t attenuate the signal too much.
Excellent point about bidirectional communication - depending on the hardware and the environment, the RSSI and LQI values could certainly be asymmetric. In one direction, you have the Router/Coordinator transmitter interacting with the device’s receiver. In the other direction, you have a completely different transmitter (in the device) sending information to the Router/Coordinator’s receiver. One transmitter might be significantly more powerful than the other, or tx/rx antennas might be better or worse.
In the deCONZ UI, Endpoint devices always have a 0 for the second number - e.g., 255/0 or 110/0. Looking at my mesh, most of the pairs are withing 10 of each other; but a few have larger differences, such as 174/100.
I am in a very old house (build before 1800!) with walls that are about 60cm thick and 2.4GhZ has hard time to pass through. I have been obliged to add a Unifi mesh network with a lot of access points!
But for some reason ZigBee seems a bit better.
Good to know that we are getting same kind of results. I just added a new device (aqara push button) to the intermediate router. In order to correctly adopt the device I had to add it several times (?) but finally it works. Not so easy to test as a button does not have state so I had to test it in developer tools listening to “zha_event” events
I have also read somewhere (not sure if is true) that in the Xiaomi implementation end devices once connected to a parent (router or coordinator) do not try to find other ‘path’. Once connected they do not change link even if connection is no more working. …
The newly added device through the router is not connected by a link in the graph. So one is connected (the magnet) and the other one is not (the button). Therefore I am wandering if the problem of devices not showing is due to a problem of Xiaomi not reporting correctly the link information to the coordinator. So far the only one that report the link seems to be the magnet type device. As I have other magnet device from Xiaomi I will try to connect them directly to the coordinator and may be they will show up.
As I have mentioned the ‘ZigZag network display’ reports exactly the same information…
First contrary to what I have reported based on Internet information the Xiaomi Adara End devices (like the Aqara weather device) are performing network mesh optimization correctly.
Reminder about my current ZHA ZigBee test network topology (excluding the Zigbee devices managed by the Hue hub and therefore using a different PAN):
A Conbee II coordinator (ZC) connected to my RPi4 running HA.
Close to it an Aqara weather sensor + an Aqara motion sensor.
Far from the ZC (but still in RF range) an Aqara weather sensor.
Very far from the ZC (meaning out of range of the ZC) an Aqara button + an Aqara magnet sensor.
Located half way between the ZC and the “far /very far” ZED I have a Philips Hue bulb acting as a router (ZR). The ZR is in range with the ZC and in range with the “far” and “very far” ZED.
In order to add the “very far” ZED devices I had to adopt them using the adequate command from the ZR (i.e. not adopting directly from the ZC). The “close” and “far” ZED devices where adopted directly by the ZC.
Within less than two hours (unfortunately I can’t be more precise) the “far” Aqara weather device with a LQI of about 100 has been automatically re-routed from the ZC to the Philips ZR! Now the LQI for this device is 255.
Originally (yesterday evening) on the Zigbee network visualization graph, only the link between the ZC and the ZR did show up. This morning to my surprise all the links between the ZR and the three connected ZED also show up! Not sure why it took so much time for the graph to display these links. So now, all the links are showing EXCEPT the links between the ZED and the ZC.
I have learned a lot about the ZigBee network and routing concept by reading the Silicon lab UG103.2 document. LQI as its name imply is an indicator of the quality of the link between two nodes. It is used to find best possible routes. In the case of a ZED is help finding the best ‘parent’. This explain why the Aqara weather ZED device switched from the ZC (with LQI=103) to the ZR (with LQI=255).
As a reminder an LQI=255 means that no messages has been lost between the ZED and its parent this can happen even if the RSSI (received signal strength) is not very strong.
Generally for RSSI:
anything -60 dBm and above (meaning -50, -40, etc.) would be considered a very strong signal.
-75 dBm is usually OK for ZigBee home automation transmissions.
Anything at -80 dBm and below (meaning -85, -90, etc.) is mostly noise and you risk losing messages.
In my case, I had an LQI of 103 and a RSSI of -81 dBm for the far ZED (note that the device was still working correctly).
After removing the manually-installed zha-network-visualization-card, and moving to use ZHA Network Visualization, I noticed that the network address (nwk) showin in the device map ais now reported in decimal, rather than the traditional hexadecimal.
This is not consistant with the nwk format shown in the Lovelace card, which is reported in hex.
It would be nice if the nwk address value was reported with the same format in all places.
Is there a way to change the network address (nwk) in the device map to be shown in hex again?
The zha network visualization use the code developed for the custom:zha-network-visualization-card (now deprecated) and it has always displayed the NWK in decimal (just checked now)
The visualization now is included in HA core and as far as I know there no configuration options other than database_path and enable_quirks
I also notice that all your devices have a name in the top of the block like ‘Zigbee Bridge’ or ‘Temp4’ the I do not have? May be some alias name that you gave?
I also notice that all your devices have a name in the top of the block like ‘Zigbee Bridge’ or ‘Temp4’ the I do not have?
Interesting. Your lack device “friendly names” is a difference/detail and may help the developers figure out what is different between the two ZHA visualizations.
When a device gets added by ZHA, it gets automatically named something like Sonoff 14f559, which I’d never remember and thus would mean nothing to me.
I edit that “friendly name” for each Zigbee device so I can tell all the temperature sensors apart.
I’m also seeing this problem, but in my case it was after disconnecting my Conbee II stick and reconnecting it after two hours. One device (Aqara climate sensor) never displays a line even though it’s reporting data as usual. Re-pairing and re-naming does not help.
Was a Github issue opened on this? I think it’ll get more attention from the devs there.
I have a Sonoff SNZB-02 temperature end device that behaves similarly. It does not show any connection back to the coordinator and yet reports it’s data fine and continuous. It was originally ‘added VIA’ a Centralight RZHAC wall plug. I think the problem is that some interim devices may not report neighbors correctly. Especially occurs a lot with Aqara and Sonoff end devices. I’m not sure which device in the the relationship is ‘doing it wrong’, perhaps both. Pictures below show the Sonoff with no neighbor relationships being reported in ZHA. However, pictures also show a Aqara weather correctly reported as a neighbor. Both the Aqara and Sonoff devices seem to report ‘better’ when directly added to coordinator. I have yet to have one of my Aqara’s which are directly connected to the Sonoff Zigbee Tasmota’ed bridge not report a relationship. But maybe, from what I read, you are seeing this with your Conbee coordinator.
It’s a bit hard for me to tell what the dev’s focus in on for ZHA’s next releases. But, yes, you are correct, visibility needs to occur there. One problem I have, is has been difficult to collect good solid data to include in bug reports. A lot of moving parts in zigbee…
Thanks for chiming in @dproffer, yes it has been (re)-paired with Conbee II coordinator.
I have a Sonoff SNZB-02 temperature end device that behaves similarly. It does not show any connection back to the coordinator and yet reports it’s data fine and continuous. It was originally ‘added VIA’ a Centralight RZHAC wall plug. I think the problem is that some interim devices may not report neighbors correctly. Especially occurs a lot with Aqara and Sonoff end devices. I’m not sure which device in the the relationship is ‘doing it wrong’, perhaps both.
Thing is, I’m pretty sure I saw the link the very first time I paired the Aqara sensor with coordinator, so I’m not sure it’s an “Aqara issue” per-se.
Not really a promising sign when one of lead devs on the project uses a ‘shrug’ emoji
‘Adminiuga commented 24 days ago
But all the data in the map is based on what the devices are actually reporting. If the device are not reporting neighbours, then it won’t be present in the map 🤷 Can’t control what devices are reporting.’
Zigbee2MQTT is a solid stack, I ran it on a raspberry pi for over a year. I wanted to move off the rpi for HA server so I migrated my zigbee stuff to wifi as part of that. I’m poking around ZHA just mostly to see what is native to HA. Both Zigbee2MQTT and ZHA are solid and growing. Right now, based on my experience with both, I prefer that Zigbee2MQTT runs my devices thru MQTT, I am kind of a fan of MQTT in general. Also right now Zigbee2MQTT allows you to modify the functions of a zigbee device easier than ZHA, it still requires some coding work that is not basic. Both Zigbee2MQTT and ZHA are suffering the same pain in two important areas, 1st it seems like compatibility between zigbee devices is far from standard, I put zigbee in third place behind wifi and bluetooth for compatibility between devices from different vendors. And 2nd, firmware updates for Zigbee devices is at best tepid and I doubt it will ever be complete for either solution. For example, I doubt you will ever be able to update Phillips Hue devices firmware on either ZHA or Zigbee2MQTT. So if something important comes along for your Hue devices, you will still need to have a Hue hub and remove your device from ZHA or Zigbee2MQTT, pair it to Hue, do the firmware update, unpair from Hue, re pair with ZHA or Zigbee2MQTT… value in that???
