Thanks for information.
It is good to know that I am not the only one having problem with the visualization. I have several other Aqara devices to connect and I will see if they behave the same (on top of weather and motion type, I also have ‘magnet’ and ‘button’ type).
As you have indicated, refresh of data happen a very low rate I guess to save power. When looking at ‘last seen’ values it seems that the weather and motion devices can stay around one hour without sending data. Of course as soon as a motion is detected the motion sensor send data immediately for zone and occupancy. Zone stay on for about 2 mn and occupancy for 10 mn
I have one of my weather sensor very far for Conbee and the LQI was as low as to 55 but still the device operated very well. I was surprised to see that ZigBee seems to propagate better than the Wifi!
One of the experiment I want to try is to use a Philips bulb as a router between the Aqara EndDevice located very far and the Conbee. But as aqara ZED do not show connected it will be hard to know for sure it is indeed connected to the Philips ZR. What I can test is to place the Philips bulb mid-way between the Conbee ZC and Aqara ZED and see if RSSI/LQI improve when Philips bulb is powered?
@fantangelo use the link provided by @Sp4wN to install the zha-network-card it will display all the information you are looking for.
I use the following yaml to display ZigBee information (you will have to enter this in Raw configuration editor) :
- title: ZHA
path: zha
panel: true
icon: 'mdi:zigbee'
badges: []
cards:
- clickable: true
columns:
- name: Name
prop: name
- attr: available
id: available
modify: x || "false"
name: Online
- attr: manufacturer
name: Manufacturer
- attr: model
name: Model
- attr: device_type
name: Type
- attr: ieee
name: IEEE
- name: NWK
prop: nwk
- attr: rssi
name: RSSI
- attr: lqi
name: LQI
- attr: last_seen
name: Last Seen
- attr: power_source
name: Power Source
- attr: quirk_class
name: Quirk
sort_by: device_type
type: 'custom:zha-network-card'
Yes, I already use zha-network-card and it is great for a visual aid to see what is happening. Additionally what I would like to see are the RSSI, LQI and Last Seen values as attributes in the entities that are created. This would allow me to create automations that could trigger if any of those values are out of whack. I have done quite a bit of googling to see it this is possible without success and I do not know of any other way to access those values in templates or automations. thx
If you want to see your temperature sensors ‘in action’ a hair dryer or floor heater is a good ‘tool’
Interested to hear what you find. From my experience, with three Aqara end devices, LUMI Weather, LUMI Motion, LUMI Sensor Cube (it can be argued that this is a very difference ‘end device’ than the other two). Only the LUMI Sensor Cube will ‘hop’, aka have it parent be a device (router) other than the coordinator. In comparison with the LUMI Motion, I have a Ikea Motion sensor that does ‘hop’, it’s parent is a router and not the coordinator.
As far as I know the ConBee coordinator can have a maximum of 32 children (including End devices and routers). Therefore above 32 devices you must use routers.
There is an interesting article about building a ZigBee network as I indicated here
Many youtubers mention that in order to add a new device you have to place it close to the coordinator and these seems definitively a bad practice. The best solution seems to build your network incrementally starting from coordinator adding first the intermediate routers then finally your end devices that are assumed to be connected to these routers. Normally the network is self healing so at the end it should always work but it seems a good idea to build it as close as possible to its final “shape”. Currently I am only experimenting but in the future home I am about to build I intend to put smart plugs as routers (reliable always on routers).
I found that if you click on a ZigBee “router device” (in “configuration | devices” or directly clicking on router device in zha-network-card) you will see a “add devices via this device” command. From what I understand this forces to add the new device as a child to this router where if you use the add new device from the ZigBee integration the new device adoption is initiated by the coordinator (eventually this might end up in adoption through the router). I have not yet tried this command.
While talking about commands available from ZigBee device display I did not found any documentation about the following commands:
“reconfigure device”: what does this command do ?
“manage cluster”: What for? how to use it?
“ZigBee device signature”: Meanings of information returned by this command?
“remove device” just remove the adoption by the coordinator or also send information to the device to reset it? This is especially important for devices like Philips bulb that have to be reset in order to be readopted.
Good info, thanks! And good questions. This ‘add via a device’ is a new one to me today via you and another member. The wording seems to flow into the idea of having end devices ‘hang off’ of routers rather than only the coordinator. I think the proper term is a end device’s ‘parent’.
Much to learn!
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…
