Would it be possible to introduce new capability, let's call it DevicePresence, DeviceStatus or somehow similar? The reasons for this:
It would stop misusing of Presence capability to report whether the device is connected to hub or dropped
It would also allow device to act as presence sensor, and report it's connection status at the same time
Filtering would work properly. Currently, when setting up a rule based on presence (person), all the sensors misusing this capability for connection status appears in the list too. And oposite, if I want to set up notification for any device dropped connection, I have to use Presence filter again, which shows all connection status + person presence devices.
@tomas1 It's the device that provides the attribute, not HE. HE just reads what's there. So unless an attribute specifically puts out "Device Presence" or "Device Status" in its firmware, there is no way for hubitat to make a distinction.
Yup. I hate using drivers that use Presence for this purpose, because those devices show up as Presence sensors, and they really aren't. In this context, "Presence" is used to indicate if a device is marked as online or offline.
zigbee2mqtt calls it "Availability", and the default configuration is like this:
Zigbee routers (and other line-powered devices) are marked as offline if they don't check in every 10 minutes.
Zigbee sleepy end devices are marked as offline if they don't check in every 25 hours.
That's not quite true. It's the driver who sets it. And driver can set only capabilities supported by HE.
See this portions of driver:
This is list of cababilities driver exposes (and it can expose only what HE supports):
Agreed. The limitation is that not all devices support a check in to assess DeviceAvailability. For example, I know that zigbee devices do support it. I don't know about z-wave or LAN connected devices.
Edit: for z-wave and LAN devices, I suppose the hub could schedule a periodic ping. So your proposed capability is definitely doable.
Capability is more of a "macro", it functions rather the same as an Attribute and Command in one word.
Defining an Attribute then altering the sendEvent to use the new Attribute would be functionally the same as having a Capability.
I say all this NOT to disagree with the idea/need, but to show how to do it BEFORE the request actually is found in a Release. Adding it to a Release is going to take a while BUT then getting all the drivers converted is even more time... what I mention can be added to drivers today, getting them working "better" until the Capability hits the street.
Having a standard attribute for all to use is a great idea.
The only thing is that all of the drivers will need to be updated to implement this. But at least having a capability will allow them to implement it in a standard way that all can follow. This will be a bit of work.
I've implemented a system on all of my device drivers and also created an app to notify me once a device stops checking in. From a high level this is what I do,
a custom attribute on the device called checkInInterval that defines how often a device should check in. (every device reports differently).
a custom setting that allows you to set the above attribute but also allows you to define weather it should ping on this schedule to force the check in if need on devices that don't automatically check in on an interval.
in the driver code I have an extra line that will update a data value with the last check in time every time a device does something that I consider a sign of it "being alive". I use a data value mainly because I don't want to flood event logs with a bunch of updates to this key and its less overhead.
My device monitor app will just read this data value and ensure that it has checked in, in the time specified by the interval and if not send me a notification and it runs every hour.
Doing it this way I know within the hour when a device hasn't checked in within its period and I can address it. It works well. Later on if they add a custom attribute for "online/offline" then I would just make it set that based on the above calculation as well.
I'm not saying this is the best way, just dropping my method here in case the HE team are thinking of doing something like this and can use some input.
I'm looking to do this specifically for my Honeywell Home integration - it seems to get booted from the Honeywell API every so often and I don't notice for many days. I re-authenticate and all is well, but I'd love to setup something to notify me when a device hasn't had an event (temp/hum change) over a certain time like a few hours.
Any ideas how to set a condition where the value hasn't changed in x time? Figure this is the quick and easy method since i'm looking at one thing right now.
Actually I think I figured out an easy method - trigger based on temp changed, set local variable to current date/time and then make condition where if the local variable value (minus) current date/time > 2 hours should be sufficient, no?
lol scratch that, it's not going to be that simple. I need to:
Trigger based on any temp sensor changed
Trigger on periodic schedule like every 2 hours
Action to set current date/time only if trigger by temp sensor change
Action to set current date/time only if trigger by periodic schedule
Condition to subtract 2 variables and if >90 minutes, sent notification
Assuming you mean attribute and not capability (the only one between the two that we can define custom), a few built-in drivers use networkStatus for this, with online or offline as two possible values — though among the ones I'm aware of, only for LAN devices where this is easily discernible. Z-Wave and Zigbee are, as we all know, a bit trickier, but they are still networks, so it's not a totally inappropriate name ... just to provide one idea!
Yes, I meant a custom attribute (edited my post).
It will be used from the device drivers (Z-Wave, Zigbee, LAN) to denote that the device is currently offline to HE hub.
So seems like a name deviceStatus with possible values 'online' or 'offline' will be OK for both Zigbee/ZWave and for the LAN devices...
For what it's worth, HA marks the state of an unreachable device as "unavailable". Which makes sense. HE will even accept such a status, BUT since RM only allow to test for predefine states (ex: switch on or off) this is currently useless.
What about adding that possibility to RM and other app instead?
This isn't right. RM Custom Attribute can use any attribute defined for a device. The attribute can be defined to be an ENUM, with values of [availalble, unavailable] defined. So yeah, the possible states should be predefined.
Could also go to the light side of the force. From what I can tell - going forward they are only supporting the attribute 'healthStatus" of the "healthCheck" capability as enum: [online, offline].
It does keep a nice KISS principle and finally is a standard on that sometimes curious platform.
One day, when and if Hubitat decides to add a standard "healthCheck" capability, the "healthStatus" events will be already available in some custom drivers.
Here are the first successful tests using the Device Watchdog ( thanks @bptworld ) app to send healthStatus offline notifications from devices that use the "Tuya Scene Switch TS004F" driver (dev. branch version 2.6.0):
This is the Device Watchdog app configuration : (just use the existing 'Special Tracking' options)
