hi
whats the correct image type?
I tried jpg and png
or is the URL wrong?
1 Like
you use âlocalâ instead of â/homeassistant/wwwâ
2 Likes
Released version 2.10.1 with teh following small fixes:
Fixed
- Fix top menu rendering on
2026.2.0 - Catch and display Z2M exceptions in the âConsoleâ tab (issue #7)
Have fun!
@dandanache - I really love your work! While a visualization map for Zigbee has been added a while back in ZHA, I feel like ZHA is lacking on the troubleshooting tools. I donât use Zigbee2MQTT because of the MQTT requirement⌠if it had websocket support, I would in a heartbeat given the added tools and features.
Itâs fun to watch the map form - reminds me of popping popcorn, but I was wondering whether there was away to have it persist - and just update when viewing in the interest of time.
Also, I noticed it said something about probing 40 or so devices, and in the log I think I counted 46, however I have 95. I did not count the ones shown on the map, but my guess is all 95 are there. Is the probing only for routers?
This will be fun to hunt down, but I was unaware so great to see this feature. I randomly see log entries about unknown devices and wonder whether something is not working right or it is devices from my neighbor.
To make up for some shortcomings of ZHA, I use this table a lot when troubleshooting issues. I was wondering whether a few additional - user selectable - columns could be added to your device list. The partial snapshot below shows all the columns that are available in this table:
(credit: custom:zha-network-card by dmulcahey - I believe one of the awesome ZHA developers)
The online column is an easy way to find devices with issues. NWK is how the logs reference the device so it is useful to figure out what device the logs are referring to. RSSI is helpful in the same context of when LQI is. IEEE would be nice in its own column for readability. And⌠it would be awesome if the data could be exported in a comma delimited file (csv) - but that is me being greedy 
I have lots of space to fill with more data 
1 Like
This is actually one of the reasons I like Z2M: my Zigbee mesh keeps humming along even when I restart HA. And MQTT is awesome for creating virtual entities and devices through its discovery topics. What I really donât like though, is that my Zigbee devices end up listed under the MQTT integration together with unrelated WiâFi devices that also use MQTT 
Since I get all the information needed to build the map in a single call to ZHA, I can build it instantly. I just reused the Z2M mechanism that queries each device one by one, and the âpopcorn effectâ exists purely because of that. Itâs actually mesmerizing to watch the map come into existence, but I get it⌠we live in the age of speed and shrinking attention spans. Iâll try to improve this.
The app keeps a processing queue. It starts with 1 (the coordinator), so initially youâll see âMapping⌠1 device to goâ
After the coordinator is queried, it is removed from the queue and all its neighbors are added. So if the coordinator has 25 neighbors, the message becomes âMapping⌠25 devices to goâ
As it processes each neighbor, it discovers more devices and updates the queue accordingly. Sometimes the number goes up. Thereâs no way around this with Z2M.
This looks like a very healthy Zigbee network, very few reddish lines. Nice!
I probably need to add something about this in the âAboutâ tab, or maybe just hide the warning message entirely. This has come up earlier in the thread. These arenât your neighborâs devices, but are old devices that used to be part of your mesh but are now gone. Ghosts that are angry you removed them and have come back to haunt your mesh! 
You are right, the device list needs some love: more columns, maybe some grouping, etc. Iâll see what I can.
Thanks for the feedback!
That is indeed a nice advantage, however I see the MQTT layer as an additional failure point that I can avoid by going direct. Anyway, just like ZwaveJS UI did, I hope Zigbee2MQTT will also gain a websocket connection so users can pick what they prefer.
Lol, it is indeed now that I am relaxed. When trying to figure out why a part of the house went unresponsive, I might not be in the mood for âcuteâ. For some reason random devices - usually Jasco - tend to freeze traffic in portions of the house. By power cycling that part of the house (or the device if possible), things start working again. I thought Zigbee would pick a different route if one stops working but it doesnât seem to work in these occasional cases. What has helped is removing Jasco devices, and updating to newer/better devices such as Inovelliâs products. Given most rooms have ceiling fans, I switched all my ceiling fan switches to Inovelli Blue fan controller switches thus creating a solid zigbee backbone with devices that canât be unplugged.
Most are from a Sonoff mmwave presence sensor that I am not even using. It appears that the red lines are often caused by specific devices. Whether that is true or not, Iâve been replacing them with alternative solutions. Seems like the strategy is working⌠for now, lol. Just jinxed myself!
I forget the details but I used to have bad issues with that. I believe it used to be with Zwave though⌠Any way for me to vanquish those ghosts? Rather than having the log entry hidden, Iâd like to fix the issue before I end up living in a haunted house 
Again, awesome work!!! Love it!
1 Like
Zigbee can heal pretty quickly if a repeater goes offline, but a single misbehaving repeater can wreak havoc in its vicinity. I avoid Tuya devices like the plague for exactly this reason.
The repeater that reported them still thinks theyâre part of the mesh. Sometimes they clear on their own, sometimes a simple power cycle of the repeater is enough. Other times you need to reset the repeater (reâpair it without removing it from the mesh so it gets rediscovered).
But the ghosts are most likely harmless, and you can do more damage in the process of removing them.
1 Like