What if you simply open the html file by clicking on the link on GitHub? Does that open correctly?
It opens up as a text file in Github. This is so weird.....
1 Like
Yes, it is weird. That at least rules out any issue in the downloading and storing of the file locally. there must be something funny with the way the browser is interpretting the contents. You could try removing the first line, but that is a fairly standard thing, so I wouldn't expect it to be the issue.
Not sure, but one thing that would make the visualization even more useful (and not dependent on data from XCTU) would be if there could be an 'accumulate' display mode in which existing 'via' connections from routers could be retained in the graph, with subsequent 'refreshes' of route table entries adding new connections to those which have already been discovered.
This would help complete the picture by including more devices (though still being subject to the limitation of only depicting 'first hop' routers in the path to any given device) since route table entries from any given load of the getChildandRouteinfo page only show 'via' connections from the most recent route discovery requests.
Of course it wouldn't account for dynamic topology changes (you would need some kind of a 'reset and reaccumulate' switch to account for those), but would still be useful for a stable mesh (and would give you an accurate depiction of which neighbor router the hub has used to reach a given device in the recent past).
@dandanache do you think this would be feasible?
3 Likes
@jameslslate have you been able to do these steps listed in this one post roughly 6 down from the top of this thread?
Getting that html file on your hub is what made it work for me.
For some reason downloading the html was not working for me. While on the github page I clicked the Raw button and then copied the raw text to the clipboard. Then I pasted that text into a text editor and saved it with the name zigbee-graph.html. At that point I followed @dandanache 's instructions.
3 Likes
Really a wonderful piece of work, Dan. Thank you!
2 Likes
I also get that Github page and not the graph page when trying the Github files that I download. See below.
This made it work. For some reason, none of the Github links worked when directly downloaded.
Thanks for figuring this out.
4 Likes
Updated the file with these changes:
- auto-refresh every 5 seconds
- keep old route links (dashed lines)
- drag node to fix its position, click to reset
- add legend for node and links colors
Thank you for your ideas!
10 Likes
Awesome update... most fun I've had watching my Zigbee network yet. Thanks!
3 Likes
Very nice update!
I'm working on dealing with "null" devices in my network, got a couple still to go, the graph correctly shows them as different dots because my two null devices have different addresses (which don't exist in the hub) but it has to zoom way out to show them. Not a big deal, but maybe it doesn't need to show them in another solar system 
and maybe replace "null" with the network ID?
Another idea, you could open the zigbee log websocket (ws://x.x.x.x.x/zigbeeLogsocket) and maybe animate the node showing the activity and update the latest LQI and RSSI values:
{"name":"Master Bedroom Television Power","id":57475,"profileId":260,"clusterId":2820,"sourceEndpoint":1,"destinationEndpoint":1,"groupId":0,"sequence":168,"lastHopLqi":255,"lastHopRssi":-72,"time":"2023-05-20 18:44:43.983","type":"zigbeeRx","deviceId":1318}
Thanks again! Very helpful.
3 Likes
2 Likes
I have seriously been waiting for something like this for a long time. I love the implementation and how it works and I am hoping that you will be able and are willing to add features to this.
It is so interesting to see that a Zigbee device that is only ~25 cm (~10 inches) away from a repeater, chooses to go to another one that is about 4 meters (13 feet) away instead.
One thing that would be great to see is a count of all paried Zigbee devices and a count of all reporting devices. This would give a great "at-a-glance" view of dropped devices.
3 Likes
This is pretty cool - thank you.
I uploaded it to Hubitat File Manager and run it right from there on my phone. Works great, but I am unable to dismiss the Legend panel on the new update and it greatly obscures the screen. Here are screenshots of the original and the new on my phone...
1 Like
Great work, @dandanache !
I am so happy now to see my C-8 Zigbee mesh visualized the way that I expected it to be.
This should become a part of Hubitat hub built-in apps/utilities!
6 Likes
How does one interpret the loops? I have a device routing through itself according to Hubitat (and visually). That doesn't make sense to me.
Suggestion, in the updateGraph() method there is:
setTimeout(() => Graph.zoomToFit(300, 30), 1500);
I'd suggest that only be done on first render as it keeps fighting with me when zoom out or in to go back to the zoom it wants.
I agree, but as much as I love Hubitat and the people behind it are great but, at the risk of being off topic and knowing that there is limited bandwidth for development, it does irk me that something like this was not in there to begin with. It's obviously possible as we now see, didn't take months to build, and yet, we've been left with an undocumented URL while Zigbee2Mqtt and others have more useful toolset visualizations. Especially with all the C8 zigbee issues, a focus on better diagnostics is more important than ever. /Rant Over 
/
7 Likes
The legend shows green as "battery device" but I think it is not the right description as I also have mains powered devices (which can be routers) showing up in green too when they are 2 hops away and not directly talking to Hubitat which I think is just a limitation of the data available, maybe purple for things 2 hops and beyond?
1 Like
You are right, trying to detect battery devices might do more harm than good. Due to limited data, a node is painted green if there are no incoming conection to it (no "particles" go towards it). On my small zigbee mesh (34 nodes) it looked like it works 
but it seems like this is is not the case for majority of setups.
I'm thinking to remove this "feature" if we cannot figure out a more reliable way to detect battery-powered devices.
1 Like
I like this a lot, will def look into it. Thank you for the tip!
3 Likes
