See which of my Zigbee devices are repeaters?

My question is why isn't this a function in the settings part of the hub?

There are a lot of ends like that available. Too many available in the settings menu would just make a mess of things. All stuff like this is in the documentation...

See here https://docs.hubitat.com/index.php?title=Zigbee_Logs

1 Like

Is there a similar command for zwave?

Z-wave is a bit more comprehensive within the settings menu. In the case of z-wave, all mains powered devices are repeaters, battery powered devices are not. You can look at your z-wave details page to see the routes of all your devices.

1 Like

If you really want a similar endpoint, there is <hubIP>/zwaveNodeInfo. However, for Z-Wave, pretty much all of the useful stuff is already available from the Z-Wave Details page in the GUI, so I'd just go there.

It should also be noted that the Zigbee endpoint won't (necessarily) show you all repeating devices, just which ones the hub knows are repeating (because it can see that). An Xbee or third-party mapping tools may show more, but even then I think you'll just get a picture of what that device can see. To my knowledge, there isn't any way on the hub to see 100% of this picture in all cases. But, as mentioned above, the rule is generally that mains- or USB-powered devices are repeaters, while others arent. Sengled bulbs and first-gen Sengled plugs are two notable exceptions, and the Hampton Bay/King of Fans ceiling canopy controller is the only other one I know of. There are probably more--it's not as strict of a world as Z-Wave--but I'd be surprised if most people have one. :slight_smile:

3 Likes

You can also use Hubitat Z-Wave Mesh Details from Hubitat Package Manager

1 Like

Will this work on a C4?

Honestly I'm not sure but it should... Install hubitat package manager and see.. It will either run or not.

Error

TypeError: Cannot read properties of undefined (reading 'trim')

Is that from installing z-wave mesh details or trying to install hubitat package manager?

Installing, then running the zwave tool, occurs on run mesh details.

Then it may require a C5 and above...

No, the Z-Wave endpoint and the "new" Z-Wave Details page are only available on model C-7 or later. (This hub has both newer Z-Wave hardware and a different implementation compared to previous models.)

The community app mentioned above relies on at least the node info endpoint but possibly also the new Details page and will not work on earlier models, either. As nice as Hubitat Package Manager is, I think it's also nice to know where the app "really" came from or where to read more about it, and that's here: [BETA] A Z-Wave Mesh Tool [C7 and 2.2.4+ Only]

3 Likes

No C7 with zwave active, but seems to go further on it.
Sorry for the thread hijack.
Will post another, and more specific.

1 Like

Is this possible in Zigbee 3.0? Like, could a hypothetical future version of HE display a table of Zigbee devices in the settings, including indicating which are repeater-capable (whether or not they're currently repeating)? Or is it a fundamental limitation of the protocol that the hub can't access that information?

I think it require another zigbee radio to do something like that. @mike.maxwell probably could explain it better than I could.

I guess my question should be how would a novice know about that. Knowing your mesh health is very important when things aren't working. When I tried to make the leap out to my detached garage with my zigbee network that kind of info would have helped. At that point I did not know how useful the forums are.

To that point the forums are great but the average user isn't going to understand alot of this. I've had to pull hubitat out of 2 peoples houses because they couldn't understand how it worked. I downgraded them to Alexa only, which we all know sucks as stand alone.

My suggestion would be something like the battery monitor in the dashboard but using a graphical interface showing signal strength like your wifi router or cell phone. People would understand that.

Mesh is complicated. Having a signal bar won't help an average user because it's dynamic and having the strongest signal doesn't mean best route back to the hub.

1 Like

Everyone in Ha has to educate themselves to a degree. Every one of your questions can be answered in the manual. Or simply by asking others. There is a learning curve to everything. People are going to be willing to learn or not. I think HE is novice friendly for setup and using the basic apps included. Learning about how z-wave and zigbee works is another thing. Lots of people know how to drive a car but don't actually understand how the motor works

2 Likes

I mean, this is an argument that goes back to the earliest days of software. Which functions should and shouldn't be exposed as information or options to the users? What should be visible vs discoverable vs in the manual vs totally secret? I've been part of many such debates, and rather than saying "you can't expose everything" or "power users can figure it out if they need to, read the manual", I tend to want to ask "Is the tradeoff of adding this one more thing worth the clutter?"

I think in the case of Zigbee connectivity and a little bit of mesh info (at least the stuff available at getChildAndRouteInfo), my opinion is that yes it's worth the clutter to have that info discoverable from the UI, probably from Hub Settings. That's the decision HE made for Z-Wave, after all. It feels inconsistent to have it for one but not the other, and it's pretty useful info. The Zigbee info page is not so cluttered that it can't handle this additional info (or at least a link to it).

But anyway, I wasn't here for the debate, I was here to learn how to find the info. I'm glad I did; thanks all! Hopefully this thread will be here for the next person who is wondering, if in fact nothing is changed to make it more discoverable. Cheers.

4 Likes