@petro Thank you for your reply. When I referred to “well-spent design,” I was pointing to the overall UI/UX philosophy rather than suggesting this particular feature is groundbreaking.
It’s clear, though, that this is an expected feature even among top platforms, and the omission is something Home Assistant could and maybe should prioritize.
Here’s a quick diagram/table I drafted on your request illustrating what a typical routing map might look like for clarity. But remember, this is just an example I created for you:
But a table with one entry per device is just not how mesh networks operate. Zigbee and Z-Wave are not like Wi-Fi, with hub-and-spoke network paths, giving a single measure of LQI / RSSI.
Mesh networks are dynamic, with nodes choosing which of the routing peers they can see should carry a message on an instantaneous basis. You don’t get to choose, only monitor where the mesh may be weak.
Why am I telling you this? Because so many folk are used to Wi-Fi networks, and try to use similar engineering and sysadmin with mesh. Mesh is different.
@FloatingBoater Isn’t that what the last column in my example/draft table shows?
It shows 1 (zigbee) device with one or multiple pears/connected devices? And yes indeed, the device cannot be connected with itself. This is my mistake in the quickly drafted example. So for example (not shown in the table) Device 1 is connected to device 3 en 4. Of maybe in a Mesh network even more devices.
Or do you mean something different? Please clarify. Thank you.
No. Device 1 was connected to device 3 and device 4. It probably isn’t any more.
As @FloatingBoater says, these maps (and your table) may be useful if you’re trying to decide where to add another router. Apart from that, I’m not sure why you would want one.
I mean each mode is dynamically tracking the LQI of every other node it can see (within config limits; only when awake), and choosing which mains powered router to pass a message to. Some of my devices show 12x neighbours.
A table is fundamentally a 1:1 representation. Mesh is fundamentally 1:Many.
That’s why the ZHA network map is so messy - each node shows all other nodes it can see.
Even more complex… for each path between two nodes (A and B) should you show the signal from the perspective of node A or node B? They are different.
I assume ZHA picks one for colour coding and shows two numbers on a link (for mains powered router nodes, not battery as they sleep so probably don’t report as much data), with higher being better (e.g. >192 is green).
I’ve not actually pulled data from the ZHA API to know what is actually reported, but am just trying to show the complexity of representing mesh networks. IMHO, a table isn’t going to cut-it, except if you select ONE node to measure from.
To throw some constructive ideas out there:
ZHA already uses colour codes and shows bi-directional LQI as annotations like 200/185), however a “Show Issues Mode” might help by switching from the existing “emphasise good” to “emphasise bad” to make poor mesh LQI stand out more and putting working nodes into the background.
When was a dead node last seen? What was the battery level?
The existing ZHA diagram might also place nodes better, and have better zoom controls.
This could be as simple as configuring a standard library better - but like most engineering, the fact it doesn’t already, suggests much more work.
Generally, I’ve only used a mesh diagram to get a rough idea where there is a “thin patch” with nodes with fewer “neighbours”. The hard part of interpretation is the nodes show radio proximity - not physical and capturing the latter in 3D is orders of magnitude harder.
The graph sucks. That’s the bottom line. The text is hard to read. Lines are hairthin. The physics are wonky. The mesh is so big, it is in effect unusable for anyone with more than a few devices. And I can’t control-click on a device to see the device page.
I didn’t vote because I don’t want a list. The graph makes the most sense from a technical standpoint, and it works quite well for showing the mesh. That doesn’t mean the graph could use some improvements, however you aren’t asking for that.
I raised a similar ticket, closed because of its similarity to this. My own view of the visualisation page is that:
The zha visualisation screen
has no key indicating what colours and shapes mean. The docs aren’t clear on how to read the values off the connections (yes they’re rssi, but why are some a single number and others XX/YY. I never found a satisfactory answer. - now finally in this thread I hear that they’re bidirectional (in some cases)
does not remember if you place nodes in specific areas.
does not allow you to focus in on just the connections to one device. This would make troubleshooting easier
is next to impossible to use with a laptop glidepad
In short, my personal opinion is that this feature is overdue an accessibility overhaul.
In addition, with an appropriate interface this tool could also provide easier access to ZigBee binding so that specific switches continue to work directly if zha is down.
