i've seen regular files included, not that I have used them myself.... Could a "dummy" driver at the very least not allow the html file to be downloaded to local storage? I think Smartly was the example I am thinking of...
The alternative I have used is to have a driver download the file and store it using @thebearmay 's excellent work over time to allow file storage.... 
Probably a conversation worth having on the HPM topic....
Easy enough to do, particularly with the new native local file methods, would just need to be added.
If nothing else, it feels like there could be some additional benefit to be gained through a driver, capturing more general Zigbee info, like the channel and I'm assuming a few other key details. Admittedly this is captured by Hub Info, but it could provide a "lighter" version more targeted to the Zigbee aspects of the HE setup. Aside from catering for the download of the html file, a driver could provide an iFrame to present this on a dashboard, or at least a link to it.
Sorry, but all I can picture is Kermit... No offense...
Really interesting tool, @dandanache !
Out of curiosity, how/why does outCost:0 mean "bad neighbor" ? When I read the SiLabs SDK docs:
I interpreted that as "a node that can be a repeater but is not currently repeating or has not for a while", but others here are much more knowledgeable than I am, so my interpretation might be wrong.
I don't know if this suggestion is practical, but it would be neat if one could somehow inject knowledge about their mesh into the tool (i.e. label those nodes known to be sleepy devices as such)
I am seeing some devices appear and then a short time later no longer being in the graph. Is there a way to keep showing them with the dotted lines like the other ones on the graph?
What drives the "new" (purple) representation for nodes / devices? I seem to have some that temporarily show up as purple them go Green soon after.
You're right, it doesn't. Not all devices that appear in the hub's neighbor table have strong enough links to be useable as routers (though they may appear in the neighbor tables of other routers and be usable by them as such) That's the point I was trying to make with this post.
I wonder if there are other possibilities too. Here's an interesting example I "discovered" using this viz tool:
Th Cuisine is a Sinopé thermostat. Strange, as those Sinopé are generally rock-solid repeaters... but this one reports outCost:0. The switch that is connected to it happens to be an Aqara WS-USC01 in-wall switch (no neutral - so probably not repeating?). What are the odds the Aqara switch has a malformed "neighbor message" leading to this outCost:0 ? Just spitballing.
I think the temporarily colored nodes are from this feature:
Hmmm... Then I'm wondering if there may be a slight glitch in this feature.... Not wanting to rip in given the positive vibe and awesomeness of this utility... 
Have I softened the feedback enough The purple colour seems to pop-up for existing devices then switch to green shortly after.... Not a major issue, just an observation of something that may need attention into the future.
Loving the discussion as well as the tool around the insight into what these numbers signify.
Suggestion: Search box, as you type it highlights the name (e.g. yellow text background) of the matching nodes and adjusts the zoom to make sure you can see it.
Clicking a node opens the Device Edit page.... This is so much fun when you aren't the developer... 
This is what happens when you ask for suggestions, I know all too well with my apps/drivers 
Hopefully users of mine have learnt updates can be incredibly sporadic.... Too many distractions... or just lazy weekends...
I don't think that's whats happening; probably just not seeing the actual (good) links that the Sinope is actively using. Its connection with the hub may indeed be more marginal than those. Any link status messages from the Aqara would be between it and the Sinope; they would have no bearing on the link status between the Sinope and the hub.
One limitation of the renderer is that it's not really capable of showing a complete map of the mesh; it differs from a true mesh mapping tool (like an XBEE/XCTU setup) in that the renderer's only receiving complete information about the hub's current neighbors, child devices, and recent route requests that are still in route table entries. An XBee extracts the equivalent info (via ZDO commands) that essentially perform a 'getChildandrouteInfo' for every router in the mesh and knits all the results together via XCTU and draws a complete map.
The existence of any device beyond that single hop bubble around the hub (like a link between one of the hub's neighbors and a router further out on the periphery of the mesh) will be shown only when it happens to appear in one of the route table entries as a destination 'via' one of the neighbors. Even then its topology may not be shown correctly.
This can result in some ambiguities in the resulting map... like child devices showing up with multiple links to routers (even when they haven't switched parents). For example I see this after letting the renderer run for a couple of hours with 5 Xiaomi devices that I know are child devices of a 'friendly' router (one of @iharyadi's environment sensors); that sensor's driver will always report its current child device count so I know when it has changed (it never does)... yet after many passes the renderer may begin to show one of the Xiaomi child devices with a link to another router (along with a link to its actual environment sensor parent)-- one of them dashed, meaning it was discovered prior to the 'solid' one.
I think what's happening in that case is that while the Xiaomi's actual parent link to the environment sensor hasn't changed, subsequent route discoveries turned up a route to the environment sensor that had a different 'first hop' (Zigbee routes aren't static; route discoveries run whenever a route hasn't been used for a minute or so, and can change based on current link costs). The second hop (not shown on the map) would still have been to the environment sensor (and then to the Xiaomi child). Yet the renderer drew a path from the new first hop to that child (because the newer route was now via an intermediate repeater and then on to the actual parent), making it appear that the child device has connections to two different routers.
Not sure there is any way around this limitation; it may lead to some incorrect assumptions about the current parent/child links (as well as any links further out than one hop from the hub). But it doesn't detract much from the utility of this tool considering its ease of use...
Since I just learned about Hubitat apps, I need a bit of help with app packaging so I reach out to you.
I created a new repository and, with some basic "copy-paste programming" I tried to put together a Hubitat app. Main inspiration came from @sburke781's "SimpleCSSEditor" way of pushing content to the File Manager:
I also created a PR against HPM repositories.
Thank you for your help!
Not to worry; the description as 'dead' is a tad alarmist. Rather than dead, more like a 'previously discovered, not the most recently discovered' route.... Zigbee routes aren't assumed to be static; previously discovered routes are assigned an 'age' and get rediscovered anyway if they haven't been used recently (even if they haven't been detected as failed).
Because there's constant link status traffic between Zigbee routers, neighbor links always get re-ranked, so routes change. It's a real differentiator from Z-Wave which relies on pre-calculated paths and never knows if they're good until tried, retried, and fail before ultimately ditching a last working route and trying another.
Definitely. At the moment, I have a outCost:0 that is actively routing:
Download the Hubitat app
