Why isn't there a Zigbee Topology and Mesh Data for troubleshooting?

Troubleshooting connectivity is something that we all go through specially for mid-large projects. Z-wave's Topology tool and the nice Hubitat Z-wave Mesh Details App are such great tools that' i'm still learning about. Why isn't there any troubleshooting tools like this for zigbee? Looking at Hubitat's Zigbee settings and it's far far inferior from Z-wave Settings UI and data offering.

Have you tried the Z-Wave Mesh Tool?

Yes i have and i like it. I was wondering why zigbee doesn't have anything like this.

It would be nice! Either no one has spent the time to develop one, someone has but we are not aware, or it can’t be developed for some technical reason…

I shared a link you can use to get some more Zigbee information in your other post.

indeed. but with more zigbee devices out in the wild, i would imagine there would be more demand for this..

Tnx for the link, i saw it and well it isn't as pretty as the z-wave options! hehe

(PS, i didnt realize i made a similar thread already)

1 Like

There is the Xbee and it's associated tools for "sniffing" a zigbee network. Definitely not as simple as installing an app.

I primarily use zigbee, and it just works. I have six zwave glass break sensors. The biggest issue I run into is the lack of zigbee device drivers (on Hubitat) and the chinese making constant small changes on each production run to make them "incompatible", Latest instance for me was the Tuya 4 button scene switch. Earlier versions worked with the built in Hubitat driver later versions required a 3rd party driver. Physically the switch appearance never changed so its a crap shoot to know what you might get if you order something.

2 Likes

I've really found the Zwave device settings , topology, and the App Hubitat Z-wave Mesh Details, so fantastically useful for troubleshooting. I was wondering why there isn't similar stuff for Zigbee? The Zigbee settings page looks so sad. Is it because Zigbee doesn't offer the same amount of device data as Z-wave protocol?

2 Likes

You can use this link to get some Zigbee information:

http://hubitat.local/hub/zigbee/getChildAndRouteInfo

1 Like

+1 to your topic. I'm Zigbee only and intend to stay that way - except the tools available seem almost orphaned. I think in part it's because ZIGBEE WORKS! i pity zwave users although I'm about to take giant flack for that statement!
No tools, as there hasn't been a driving need ... zwave is always breaking and they have ta have the tools BAHAHAHA

Basically, yes. As i understand it, z-wave gives the controllers lots of information because the controllers are responsible for more. The ZigBee protocol is much less centralized so the coordinator doesn't have or need as much information (or to do as much work) for the system to function.

2 Likes

haha... good one :slight_smile:

Yeh im starting to think zigbee is glorified and upgraded 433mhz lol

Partly, zigbee mesh heals and constantly changes, unlike z-wave. there is less need for a debugging tool b/c there aren’t static routes.

that said, I do have several XBees and am able to access all the topology and routing info. It has occasionally been handy for debugging, but honestly the best part about the XBees is that they will connect to way more devices than a typical router, so they can provide some extra reliability to your network.

The reason Z-wave topology is so important is that Z-wave devices can only make 4 hops total between the controller hub and the end device. Zigbee devices can make as many hops as needed, so the mesh topology is far less important.

In my home, I have a collection of Z-wave, Zigbee, and Lutron Caseta devices. The Lutron devices are stable without fail. The Zigbee devices are mostly stable with the possible exception of Aqara devices that are not fully Zigbee HA compatible. Some newer Aqara devices are now Zigbee 3.0. I do not need to worry about Zigbee topology as the mesh repairs itself as needed. Devices rarely go off line.

I have far more difficulty keeping Z-wave devices online than I do other devices. I have to check the Z-wave details and topology every few days to make sure devices are functioning properly. If I find device that has dropped off the mesh, I have to reset it. Thus, I only purchase Z-wave devices when there is no comparable Zigbee device. An example of this is the ZOOZ ZEN15 Z-wave power monitoring plugs that I use to monitor my clothes washer, gas dryer and sump pump.

1 Like

There's a lot of raw Zigbee data available, and the protocol defines 'Zigbee device objects' and ZDO commands that enable an application to manage and map out the network (that's how Digi does it with XCTU).

Zigbee devices (even sleepy ones) track the following for each of their neighbor devices (table courtesy of Microchip Lightning Support ):


While Zigbee has the data (and has an api for the hub to access it), currently HE only provides access to the Hub's own child and neighbor table, recent route record requests, and (via Zigbee logging) last hop LQI/RSSI's.

Alternatively, SmartThings shows device routing and message stats (at least they are until the IDE goes away). For example, here's the info that the ST IDE shows for a contact sensor (routing through an Iris plug) via the IDE:

This Device (C466) ↔ Salt Light (1EA2) ↔ Home Hub
Metrics
Last Hop LQI: 255
Last Hop RSSI: -55
Received Messages From Device: 5356
Received Messages From Device (Duplicates): 4
Messages Transmitted to Device: 5371
Messages Transmitted to Device (Failures): 1
Updated Time: 2022-02-28 9:29 AM EST

Personally, I find the getChildandRouteinfo link that HE provides to be pretty good as an overall assessment of how the hub's 'first hop' links are performing, and those are the most important ones.

3 Likes

Hi Tony, Since you seem to be one of the most knowledgeable around zigbee, would you have any idea why a simultaneous channel swap between a C4 & a C7, would later (30+days) still affect pairing on the C7, even with devices previously existing on the C7, when they fall off and need re-paired, will not re-pair, I must shutoff the C4. Hubs are separated by about 10 feet.

Unless the C4 is totally off(power cut) nothing will pair to the C7. The current channels are 25 for C7 and 20 for C4, and prior, the channels were reversed.

Is there something about the routing table or firmware that would create a persistent link between devices and the original channel they used to be joined to?

Maybe I did a stupid thing by swapping 2 hubs' channels simultaneously, but it seemed like it should have worked since the channels don't overlap.

Strange; I can't think of a reason for this scenario.

When a Zigbee device is reset and is in join mode, its 'permit join' request broadcast is heard by all in-range routers regardless of their PAN ID; only those which are in 'permit join' mode (and have child slots available) will respond. If the device gets no response on a given channel, it will repeat the broadcast on all channels in turn.

Once paired it does retain the PAN ID, channel, and device ID of the parent that it joined in nonvolatile memory. But after a subsequent reset, that shouldn't interfere with joining a new PAN ID. Since all channels get scanned (if no response) during the join process, it shouldn't matter which one it was using on the network it was previously joined to.

You're pairing devices in place, right? So the relevant radio traffic during the join would be between the device and whatever Zigbee repeater that provides the best link (another reason why the proximity of the hubs shouldn't matter during the join).

Oddest thing I've encountered when trying to join a Zigbee device to HE happened when I bought a GE/Jasco Zigbee plug-in dimmer; it refused all attempts to join my C-3 (it was on channel 18). Before writing it off as defective I tried joining it to my SmartThings hub (which used channel 20); it joined immediately, so I knew the device wasn't dead. Just for kicks I changed HE to use channel 20; this time it paired immediately to the C-3. I changed the hub's channel back to 18; lo and behold the GE/Jasco plug followed the channel change to 18 as it should have (in less than a minute) and has worked flawlessly since. Still don't understand that one....

1 Like

Tony- Many thanks for the feedback.
Hmm, Interesting with the GE dimmer. I noticed ST has an unsecure rejoin option, wonder what HE is set to?
And yes I was trying to pair in place, and next to the hub and on top of the hub when the previous attempt failed.
I think I'm going to move my C4 from having the previous channel(20) used by my C7 and see what shakes out

1 Like