While looking at my zigbee graph this morning, I noticed a bunch of my contact sensors weren't displayed. When I go to the Devices tab on the graph, the "missing" devices are shown with a red dot next the them. If I click on any of them, I get a message that reads:
Device 20 does not exist on this hub. It was most likely deleted at some point. Please update your links.
What's strange is all of the missing devices are listed on the Devices page in the HE UI and all of them are working and correctly report open/close events and temperature. Is anyone else seeing this? Does anyone have any idea as to what's going on here?
Yes, I have the exact same thing. Only 16/30 ever show up. The non listed devices are working. Even after activating the non-listed devices they still do not show up.
It's a great app but without all my devices listed it's of limited use.
The data source for the graph is the Zigbee data the hub directly sees and reports at the /hub/zigbee/getChildAndRouteInfo endpoint. At any point in time that will only show the (up to) 32 devices directly connected to the hub, plus the last 16 (IIRC) routers the hub has seen, and the last 16 routes (IIRC) to non-directly connected neighbors.
Thus, when you first open the graph, you will only see a fraction of your mesh (if it is large). I only get about 42 out of 144 devices shown on my mesh.
The JavaScript code showing the graph of the mesh will continuously reload the getChildAndRouteInfo data, and will continually add to the graph as it sees new devices in the report.
E,g., I left the graph open for 6 hours and it had grown to showing 120 of my devices. That's because many of them are sleepy battery devices that only wakeup and send a message once in a while (some only once a day). It's important to note that the data on the graph for sleepy devices might be very stale.
It might be better if the hub (or an app feeding the graph) was saving the data from getChildAndRouteInfo internally and building up a last-known-route for each device. That way it would show a better map the moment you open it (albeit with possibly stale information). But that's not how it works today.
If you want a full picture of the mesh, I think you still currently need an xbee device (Everything Xbee).
I agree. Maybe I'm missing something but other than being pretty to look at, I'm not sure how this is in any way helpful if it only shows a portion of the map.
Yep, that childandroute info endpoint has always been a puzzle to me... I'm not complaining, as it's far better than nothing as a way to gauge high-level mesh health, but the fact it's never the full mesh picture (in my case anyway) makes it... well... kinda the equivalent of a non-contact voltage sensor WRT to a multimeter.
So yeah... Having a fancy graphical view of that childandrouteinfo page is kinda interesting I suppose, but it's not really anything new or more helpful.
I've tried waking up sleepy devices but that seems to have no effect on the graph.
I agree. If I have to wait 6 hours to get a populated view then I think that would be a better starting point. Maybe those routes that are not re-confirmed could display with a dotted line or something.
I'm pretty sure that's the intended use for getChildandrouteInfo, at least as described in Silicon Labs documentation. You see child devices and the state of links to neighbor routers (the only devices relevant to the hub for sending routed messages). You can easily tell if the hub is having issues (in reception or transmission) with its neighbors from the data it provides, but with just the hub's neighbor and child count (and not those of the other routers) you can't construct a complete mesh map.. there just isn't enough data about connections beyond the first hop from the hub.
That data exists in the neighbor and child tables of the other routers in the mesh, and that's what tools like Xbee/XCTU aggregate and use to construct actual mesh maps.
What getChildandRouteInfo does not provide (though it's mistakenly assumed to) is the contents of the hub's internal routing table.
That limits the renderer to depicting devices that show up in Route Table entries.. while those will populate when a route discovery request gets issued (for a route to a device not present in the internal routing table), how/when this eventually happens is indeterminate.
If needed routes are present in the internal routing table (and remain valid-- meaning they get properly ack'd at the routing layer), they need not be present in any Route Table entries shown in getChildandRouteInfo's data, and the renderer will be oblivious to them... those devices won't show up in the Zigbee picture.
On my C-3, I've let the renderer run for 8+ hours and it has never found more than 43 of the 74 Zigbee devices on my mesh. Those other 31 aren't missing, permanently asleep, or defective; their routes are evidently being sourced from the internal routing table and the renderer just isn't capable of seeing them.
I wonder if folks that are seeing 'complete' pictures within just a couple of hours are using newer series hubs (C-7 and later). Maybe the newer hubs are configured with smaller internal routing tables (than C-5 and earlier hubs) and are issuing more route discovery requests? While being quicker to draw a picture, that might not necessarily be a good thing (for performance) due to a lot of potentially unnecessary route discovery broadcasts...
I noticed after doing a refresh on the device page (mostly temp capable sensors) that it would update on the graph so long as there was a change in any of the state variables. For some of my lights, it actually needed an on/off state change to acquire the device.
So, I was thinking of making a 'instant gratification' webcore routine that could be triggered to run through all the devices and poll them in such a fashion. OR maybe someone smart (like a real programmer) could add an app that could do this on some trigger that could be attached to the Zigbee Graph app (built-in or user). The trigger could be as simple as another button added to the WebUI for the user based app. Something like 'update now'.
Does anyone think this could be a possibility? Again it would only be for that instant gratification, obsessive compulsive, need to know now, person like myself LOL.
The real advantage of this tool (Zigbee Graph), for me, is that it shows what repeaters are feeding which endpoint devices. If the endpoint device is sleepy and falls off, it really doesn't provide that reference I'm looking for so much.
