I'm re-architecting my network because my router is approaching EoL.
I would be wonderfully helpful if there was a 'Comm Type' column on the Devices page. Values would be:
This would also be helpful when attempting to move away from one of the above comm types. e.g. Z-wave doesn't work well for us and I don't want to be dependent upon the cloud; I want to go all Zigbee, lets list all non-Zigbee devices.
The DNI field mostly gives that to you. It’s just a matter of reading the code of the matrix.
Zwave = 2 characters (standard) or 4 characters (LR in LR mode)
Zigbee = 4 characters
Virtual = UUID (Universally unique identifier - Wikipedia)
LAN = mac address (sometimes w/ colons sometimes w/o)
Cloud = no pattern that i’m aware of
Matter = I only have 1, it starts w/ an M. I’m sure someone can can let us know if all matter devices start w/ M in the DNI field.
Also under Settings in the System Settings section, you have Zwave/Zigbee/Matter details. Any of these links will show you all of your devices for that protocol.
My 4 Matter devices start with M also.
They do, but not if they have child devices, those pick up generic component DNI.
I like @Busthead idea, maybe not a separate column but a logo on the Status column, much like the home icon for the Homekit enabled devices.
Added the request to the list of maybe one day...
My 2 cents, The DNI field is about as technical and useful as device id for most users. If you're going for a more user friendly experience I’d hide DNI by default like device id and add a sortable protocol field.
Pie in the sky…
Having the protocol version included in the the protocol field as well would help with figuring out how many zwave 500 series you have left on your mesh. Matter seams to release a new version every 6 months, i could see how knowing the matter version could help with troubleshooting. I’m sure there is value on the zigbee side too.
Maybe protocol version would be better served on the respective zwave/zigbee/matter details page…
either way food for thought
... and if that column also included a slash through the data if the device is not connected to Hubitat, that would be even more useful...
What does that mean exactly? - If the device hadn't been paired or provisioned it wouldn't even show up on the device list - It's existence on the device list implies that it's "connected" - I believe they already do "strike-thru" for disabled devices, but I'm not 100% sure of that.
But perhaps our definitions of "connected" aren't exactly aligned...
I am guessing @calinatl is asking for heartbeat or health check type of information.
It may sound like a simple request, but there are many old threads around here that would demonstrate it’s anything but.
It’s also unrelated/off topic from the feature requested in the OP and the rest of the discussion in the thread.
I've had MANY instances of paired / provisioned devices, on the device list, which I have NOT intentionally disabled, dropping their connection to the Zwave, zigbee or wifi network ie no longer being connected. I usually don't know about this until a rule fails. To address this, I've deployed a community app that sends a daily notification of devices the hub has not heard from, but this is an imperfect solution at best.
Not exactly sure what heartbeat or health check info is, but it sounds good. I'm not familiar with the threads explaining why that is difficult to implement. Nor do I think my comment is unrelated/off topic from the OP's feature request, although you clearly think differently.
OP asked for a column on the devices page to show HOW the device is connected to Hubitat - ie via which protocol. My logic, and my resulting comment is, that if the powers that be consider such a column, they also consider using the same screen real estate to provide further information about the device connections - ie not merey HOW the device is supposed to be connected to Hubitat, but IF it actually is still connected to Hubitat.
Hubitat (or any other automation hub/platform) only knows if a device is connected/healthy if the devices says it is -- that proof-of-life may come in the form of responding to a command (Refresh or otherwise), or it may come in the form of a periodic check-in by the device (e.g. battery report, temp report, etc).
In between these "events", the hub has no way of knowing what the status of the device is - after all, how could it?
Robert's Device Activity Check app is great, as it can tell you if the hub hasn't heard anything from a given device w/in a time period that it should have heard something, so that's a pretty darn good monitoring solution.
Mains-powered devices typically support an on-demand Refresh command, so that is often an easy way to get a quick "are you still there?" confirmation from that device.
Battery devices are trickier -they don't typically repsond to an on-demand Refresh command... All things being equal, they only pipe up when they have something to say or when their designated wake-up period hits.
Some battery devices don't even have a set wake-up/check-in period and/or don't regularly report battery, and that makes those even tougher to keep an eye on, especially when they whatever they are monitoring rarely ever ever triggers (e.g. a leak sensor).
So this whole conundrum does not lend to a simple hub-controlled solution.
Sorry that may have been an overstatement on my part.
It’s a different feature request than the one made in the OP.
Yes, apparently we do have different assumptions around Zwave/ZB "connections" - Unlike Wifi (or at least TCP/IP), for various "Z" protocols there is no concept of a "connection", like a socket in TCP - The "Z" protocols are basically more like UDP, where a packet is tossed onto the mesh, and your likely to get to ACK/NACK or perhaps a callback on a SessionID. - See the details in the protocol spec (around page 27) in the following link:
But as @hydro311 notes, there is no "keep-alive" or session state maintained for a "connection", unlike TCP/IP - You just throw packets out there, when something needs to talk. - Hence the need for DAC (which Chris helpfully links), which nicely works on powered devices as the reply to a refresh command class, but "sleepy" devices (battery powered) need FLIRS, and other approaches to 'wake up" and respond.
So there really is no concept of "connected" in "Z" protocols - there is the last time they checked in, and they may or may-not reply to a refresh. And as @marktheknife the knife notes, there are LOTS of threads about "device health", which is what your talking about in your "idea of a connection".. it's just not a "defined state" in "Z protocols".
In TCP/IP there is clearly an active connection (or not) - as defined by socket state, 3-way handshakes, and keepalives, etc. - And even Matter has a concept of subscriptions - But that sort of "live connection" doesn't have meaning in UDP nor "Z" protocols - Hence it's hard to display, something that doesn't exist.
My 2 Zooz ZSE41 contact sensors both have 4 digit DNI's: 0108 and 0100.
Zwave max’s out at ~256 devices and devices are represented in hex as 00 - FF
You may have assigned the ZSE41 driver to a component device, the UI is wrong or you are confused.
I would post pics of this anomaly to back up your claim.
Those are probably LR devices. Check your Zwave Details.
welp, i learned something new Z-Wave Long Range (LR) uses a 12-bit addressing scheme, allowing for up to 4,000 nodes on a single network, significantly increasing the number of devices that can be connected compared to the traditional Z-Wave
This would also be useful if there were a way to see this (and filter on) for apps since you need to pause/stop those for a migration. Not sure if that might be a bit too complicated though if the connections in rule actions are cloud related.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
Download the Hubitat app
