Super surprised to see this after it not being mentioned in the 2025.06 change logs, but here it is.
The big plus is it’s not bugging out all the time after selecting/zooming in on a device.
I would like to offer some feedback:
- The router/coordinator/end device colours are a bit too similar, esp router/coordinator
- What’s up with the lines? There’s no legend for them.
- We have solid lines, dashed lines, thin and thick version of both. There doesn’t seem to be a rhyme or reason
- I have 255 LQI solid and dashed lines. Plus grey lines aren’t just for offline devices… idk.
- I much preferred the colour lines based on LQI
- can an option be added to restore the LQI overlay on top of the lines?
- the only way to see the dedicated links to a specific device is to mouse over it, clicking it doesn’t “lock” that view in, which is annoying since you need to then mouse over each connection to see the LQI and loose sight of the dedicated links for the device you’re interested in.
Overall I would say the rendering engine for this is absolutely better, but I’m finding it a bit less informative than previously.
edit Just noticed that ESH had a blurb on this in his 2025.06 overview video. Seems this was designed for Bluetooth and they applied to ZHA as well for consistency. I would imagine some of my criticism would also apply to BT, but I’m not using BT to poke around.
100% agree with this. The use of blue, blue/green and slightly green/blue is a bizarre choice given the number of other colours that could be used.
I went to the source code for the ZHA network visualization and asked Github Copilot to summarize it. I cannot vouch for accuracy, but it more or less explains how I was interpreting the graph.
- Connection : Each line indicates a direct Zigbee connection (neighbor relationship or routing path) between two devices.
- Link Quality (LQI) : The thickness and color of the line reflect the Link Quality Indicator (LQI), which measures the signal quality between devices. Higher LQI means better connection.
- Directionality : Arrows or tooltips may show the direction of communication, e.g., from parent to child or between routers.
- Route Status : Solid lines typically indicate “active” routes, while dotted lines represent less important or backup connections.
- Tooltip Details : Hovering over a line shows additional info, such as device names, direction, and LQI values for both directions (if available).
- Solid line: Parent/Child relationship (main routing path).
- Dashed line: Other neighbor relationships or backup/secondary routes.
Edit: I also agree with the comments about the functionality, information, and presentation in the new graph.
I’m still struggling to come to terms with this version of the visualizer and wholeheartedly prefer the old one for usefulness.
I don’t find the rendering engine to be better. The physics engine makes it much more difficult to move objects around. Often the engine just gives up as if I lifted my finger off the mouse button soon after dragging and the items rearrange in strange ways. My computer is capable of displaying far more complex and dynamic 3D/2D objects in browser, but the visualizer engine makes me feel like I’m using a silk browser on a first generation Kindle instead. I have to turn off physics every time.
The colors are fine for devices but the choice for line thickness instead of color is much less helpful. Before I could quickly guesstimate the health of the mesh by how much red vs. green I was seeing. Now, it’s just an unhelpful monochromatic dot orgy. When I zoom in to look at individual lines it’s much easier to lose track of the devices that belong to that line or see where the lines from a device are connecting.
I agree with dephcon’s suggestions of having a colored LQI line option, and ability to “lock” in on devices (or a line) to temporarily isolate the related members and view/manipulate them more simply. Hovering just isn’t useful enough when you have more devices than a few.
It would also be nice to have a filter that could select LQI thresholds (low, medium, high) to help detect where problems could be. Even if the numbers can change, there might be regular troublemakers but I can’t identify them under the current version of the visualizer.
As a final request, a search field that would let me highlight a device with a specific temporary NWK id (since the visualizer has that information). It would save so much time from hovering over each device to attempt to find the culprit that caused a warning or error in the logs where it is sometimes confusingly only identified by it’s temporary NWK id. What’s the point of logging an id that changes anyway? You can’t go back in time to see what the id used to be. Why not use the IEEE, or the device name? Strange.
1 Like
