I’ve made a tool to visualize Homey Zigbee networks:
The source code and documentation is here:
Feel free to use it as you like 
Nice overview of the zigbee network, and lot’s of information
From this screenshot it looks like Homey still provides only a partial view of the connections between nodes. In a normal Zigbee network, routers are connected to multiple other routers, but in the screenshot you’re showing the routers are only connected to one “upstream” router (or Homey itself).
It’s also unclear how Homey picks the route that it chooses to add to the routing table. Last used? Best LQI? Random?
This looks similar to what @martijnpoppen did here:
Are there specific reasons these need to live on GitHub, and couldn’t be made in to a Homey App, with a widget you could add to a Dashboard to show the map?
I quite like this app, but it doesn’t have a map widget, only a table showing device type and last seen time:
Don’t get me wrong, this is helpful. But I would love to see an app that had these features combined, so you could create a Dashboard that would help when you had issues… but also just be cool for the inner geek that loves those sort of details.
Would also be nice if like in the screenshot, it showed the Zigbee channel in a spectrum bar chart, but in grey in the background showed the WiFi channels that overlap (and maybe even which WiFi channel your Homey Pro/Bridge was using).
It baffles me why these aren’t standard features, either in the Homey web interface, or the developer tools interface. That table it provides is terrible when you’re trying to find faults or improve your network. Or am I asking too much of Homey?
EDIT:
Can anyone else answer this, as I’m at a loss… I bought a Homey Bridge to strengthen my Zigbee and Thread mesh networks, as it was advertised on the Athom web site as being able to do this. But for a while now, no matter how I view it (this script, the Zigbee Insights app, Homey’s dev tools) it shows the Bridge as not being connected. But it is added to my Homey Pro, and the device card shows as “Homey Bridge works properly and lets you connect with more devices”. Yet I have Zigbee end devices in that same room showing as weak signal. Is it just a fancy RGB paperweight, or is it just excluded from these tools somehow?
Thanks for creating this!
This is giving some nice insights in how my Zigbee network behaves.
Would it be possible to make the legend and link quality pane collapsable?
The result for my Zigbee network:
As you can see, I’ve got a couple of devices that appear to have no connection to Homey (upper left) these devices show a ? in the route column in the Zigbee table in the Developer Tools.
Also, there’s a lot of ghost devices. I’m curious to know if others see this to and if anyone can shed some light on this.
I’ve recently tried adding Innr GU10 spots, but have been unable to add them and after adding they appear as Unknown Devices. After a reboot they are no longer shown in the Zigbee table, could the Ghost devices be previously failed paring attempts?
How can the routing between e.g plug and light show up?
That means that the plug and light needs to provide the routing info?
Is that possible in zigbee?
I have a few of these showing also. But using the Zigbee Insights app, I can manually wake the devices by pressing a button on the device, and see it show up in the app as connected. But then reloading the Homey dev tools page it still shows as not connected. I think this is a limitation within Homey, and not related to this visualiser. It doesn’t seem to update the routes or parent nodes, even though the last seen time is updated to seconds ago.
Most of my bulbs, and LED strip, and a ceiling light fixture of mine are INNR, including many GU10 spots. You have to make sure you are selecting the correct variant from the INNR app in Homey when you are adding them, as it lists several different models. And if the GU10 bulbs are housed within a metal downlight fixture, that can cause signal interference. I found leaving the bulb hanging out of the fixture while pairing and then clipping it in solved that problem.
Failed pairings can leave generic Zigbee devices either in the Homey room you tried to pair within, or dump them in the “Home” root of the tree in the app. Deleting those devices should remove the ghost devices from your map view.
As far as I know, the Homey Bridge (in satellite mode) acts as ‘just’ a regular Zigbee router device in your Zigbee mesh network. So like any other mains powered device, e.g. a smart plug. The Homey Bridge does not have a Thread radio, so it won’t help your Thread network.
This is what I was expecting it to do though, to take part in my Zigbee mesh as a router device. But it just sits there doing absolutely nothing, zero Zigbee connections or child end devices routing through it. So just an RGB paperweight basically… unless I just have a duff one.
I still think this is really dumb. Homey Pro (2026) uses the same chip and radio channel as far as I am aware for both Zigbee and Thread. That’s why an instability in one network, can cause issues for the other. It’s very convenient having one device that does it all, until the gremlins start making an appearance 
Better network fault diagnosing tools would be really helpful. This visualiser certainly helps.
I too doubt that is possible with Zigbee. It’s a lightweight protocol, it doesn’t have all the routing overhead that for example TCP/IP has that allows you to query multiple routes to a host. Homey just keeps a table of the last known route an end device took. The nodes within the mesh don’t store any routing details, that would just increase memory and bandwidth requirements. Things Zigbee is designed to be sparing on.
Correct, but that chip is a different one than in the Homey Bidge. The Bridge has older hardware. I would not be surprised if Athom launches a new version of the Bridge with more current hardware. Also since they position the Bridge is as the go-to extension for Homey SHS.
Yes, the problem lies obviously in Homey as the vizualizer just displays data from Homey, but the fact it shows a ? is something new, this started recently (but I don’t know exactly when) and this also randomly and sporadically happens to powered devices in my case.
No, that doesn’t matter, when pairing the device will send it’s identifiers and the app will load the corresponding driver.
Problem with these GU10 spots are confirmed and supposedly being investigated with innr, the spots use the older Zigbee Light Link (ZLL) standard which Homey doesn’t play well with due to a bug as it has been explained. Strange thing is I have previously had the spots added to my Homey, but that was some time ago on a much older firmware.
In this case the devices weren’t actually added to Homey, the pairing proces bugs out mid pairing, they were only added to the Zigbee environment.
I saw and see zigbee devices with a ? since around 2 or 3 FW versions. With the previous FW the ? vanished after a while now it stays. The devices seem to work normaly so I ignored the ?
Yes. Router devices maintain a list of their connections (to other routers, and to end devices), and that list can be retrieved. Zigbee2MQTT can do this, for example, to build its network map.
Here’s a small part of my network:
Blue dots are routers, and as you can see, they mesh with each other (the whole point of Zigbee). The green dots are end devices, they only connect to a single router.
Of course they do, how else will they be able to know where to send a message? Or adjust to changes in the network? More info here.
Yes I can see that, so yes why does not homey provide that then?
So it’s only Homey’s implementation that only keeps track of last past path, and doesn’t store any mesh information
I think this is by design. Homey Bridge is meant as a cheap antenna for Homey Cloud, so that people that don’t want or can’t spend a lot on their smart home can still use Homey. That’s why it uses older hardware as well, probably cheaper than new hardware. But Matter and Thread cost lot of resources, resources that the ESP32 microcontroller in the Bridge doesn’t have. I think it might be possible for Athom to swap the Zigbee module for a SiliconLabs chip with Multi-PAN and run all the Matter logic on Homey Cloud, but it will still cost more resources for Athom.
Z2M doesn’t store mesh information either, but it can query it. It takes some time to build the map because it has to ask every router device about its neighbour table.
The Bridge simply uses a Zigbee chip that’s 18 years old, when Thread didn’t even exist. So it is be design, because the design is old.
ESPHome provides Thread support for ESP32’s, and there’s also a Matter component for it that supports Matter-over-Thread/WiFi/Ethernet. It runs on C-class ESP32’s as well, which aren’t necessarily the fastest of the ESP32’s. You can also run a TBR on an ESP32 if you want.
Besides that, the ESP32 was already capable of running Doom almost 10 years ago, so Matter and Thread really aren’t that big of a deal for it to run.
