Part of the issue with Hubitat, I think, is that it works with so many different kinds of devices and there's no exact standard for the frequency with which a device might "check in," and Z-Wave and Zigbee (Hubitat's primary protocols) don't have a good way to just check if something is or isn't online. (There's actually a bit of hope here for Z-Wave devices that have a "wake up interval" configured, but most drivers don't make use of this for much, nor does the platform itself, plus it would only solve a part of this overall question.)
For comparison: SmartThings, a fairly similar hub, has a "Device Health" feature that is often made fun of by the community for inaccuracy (disabling it is a common suggestion), and even then it's not doing anything special--just sending a command to the device, like asking for a battery report or something fairly innocent on a periodic basis, seeing what happens, and considering there to be a problem if the device hasn't had activity within whatever timeframe.
Maybe somethjing platform-level will come along some day. (I don't think Hubitat has ever adopted a community app as a built-in app, though their terms do state that this is possible, and many community apps' licenses would certainly permit it.) In the meantime, I know lots of people use solutions like this app. My app is not the first to address this and will probably not be the last; I just wrote this one to meet specific wishes I have that nothing else addressed. You do have to have a feel for how often your devices need to check in (or if they report this information with "presence" as some community drivers do, which I added an option for--yes, the rare drivers that check themselves because the devices are predictable). This is an issue pretty much any solution would have given the above.
I found that the delay waiting for a device to refresh isn't long enough. I had a device show in my report tonight and found the device did indeed refresh.
This could very well be because these are regular zwave devices so I know they are talking "slowly". I changed the value in line 308 from 5000 to 7500 and will see if that is enough. From from I could tell by the documentation in your code, this was the line to change. I'll let you know how it works out.
That should work! I'll see about adding an option for this. Five seconds plus an added per-device delay was just a guess at sensible defaults on my part.
I just reviewed the logs to see how many devices were refreshed and it was only the one. I turned on debug logging to see how long it takes to refresh an old zwave device on a C5. I have a couple switches I rarely use so should see something in a day or two. These devices have never dropped from the network in the 5 years I have used them but this gives me something to play with that won't interfere with the WAF at Christmas time. LOL.
Good evening Robert. The same thing happened tonight with a device called "extra light". I had logging on for the app. If I am looking at this correctly there may be a bug .
I'm reading this as the program sent the refresh at 6:00:00. The device updated it's last activity at 6:00:00. The app waited until 6:00:08 to send notification but extra light was in the notification as last active yesterday at 10:54.
Am I missing something? If you need anything else let me know. When I ran the report again extra light was not on the list.
Hmm. I wonder if the platform caches devices, including all device information, when the app wakes up and never gets newer information (like "Last Activity At" even if that changes) after that. I know how to work around that issue for "regular" device attributes, but I don't know of a way to force non-cached readings for device (meta)data like this. I do have an idea, though, that might work if I re-think how the report is run after a refresh, using a runIn() to schedule it for a bit into the future instead of doing it right away in the same method. Stay tuned.
@bertabcd1234 When selecting devices would it be possible to have an option to select devices by type such as Contact, Motion, Switch, etc... This would allow selecting devices more quickly.
Without redoing the entire selection UI and making them be separate inputs, I don't think there's an easy way. But if there's interest in separating out by "type" in some sense, that is possible; I just though it would be easiest to have all devices under one input.
On a related note, platform-wide, I wish Hubitat would implement some sort of grouping or filtering for all device inputs (room? searching? type? Ctrl+F works OK-ish for the middle option, even if the particular device isn't visible, BTW), but I'm not counting on that changing any time soon.
I tend to add a lot of new devices and knowing that I have selected all devices of a certain type is convenient, but like you say I can and do search and add my devices this way currently.
Would definitely be an appreciated feature if Hubitat implemented the grouping at the platform level.
I have two hubs, one updated to the latest HE system and one just a version behind.
When they both were at 2.2.4 your App reported a pretty hefty list every day. All explainable by the inactivity of each device (all ZigBee).
Now the 2.2.5 hub reports nothing. I haven't analyzed this exhaustively but I am wondering if anyone is recognizing the battery reporting changes in 2.2.5 having an impact?
If those are Z-Wave devices, that's entirely possible (I think there was a fix for at least the generic contact sensor driver, but I can't remember what else was affected). But there's no reason to guess. This app just reads the same data shown by the "Last Activity At" field under "Device Details." If it's longer than your specified threshold, it gets put on the list. An event (check the "Events" tab/button on the device page) will update this for sure, but I believe any Z-Wave or Zigbee traffic that comes in does too, even if it it doesn't actually result in the creation of an event at the platform level.
@bertabcd1234
I've been testing out your app on my somewhat irregular Xiaomi devices.
Lately they have been behaving but I tried the Test Notification button (which your description says "Text" ) and nothing happens on my cell phone.
To clarify you don't really mean Text (SMS) as you do ask for a presence device?
If the report is blank and you test should you still receive a test notification (which I do not)?
No, that is a typo and is supposed to say "Test" (to match the wording of the button). Thanks for catching it! As for the actual notification, in most cases that would be a push notification--but there's nothing stopping you from SMS if you have a service (e.g., Twilio) set up to do that and can choose such a device with this app. It's not asking for a presence device, just one that supports push notifications (but the Hubitat mobile app device does both, for example).
If the would-be notification does not contain any "inactive" devices, then nothing is sent.
Good to know. I didn't get a PUSH bur the report is empty.
May I suggest that in order for a Test to comfirm the path it should at least send an empty report or just a notification that the communication path is working?
I have no SMS set up as I'm CDN so third world for free SMS to the likes of ST and Hubitat.
I'll consider adding an option to test the notification regardless, but all it does is call the deviceNotify() command on your selected device, so if that command works from the device page (something you can test manaully), it should work from the app.
HE doesn't provide free SMS anymore, either, even in the US. (But they did in early hub firmware versions.)
In order to send a text message, you could use the "email to SMS" gateway that all cell services use.
For example, with Telus in order to send a SMS message, I send out an email to: 4161234567@msg.telus.com
I love your app. Works great and is relatively simple (i.e. not bloated.)
I just installed a WaterCop water shutoff and would like to have a local indication of not responding. Something like being able to light a specific light etc. So if you get a few minutes and agree it would be great.
That's an interesting trick. I could use that for WebCore to target household phones instead of requiring everyone to install HE and presence.
I work for Telus but not the Mobility side.
Reading the ChangeLog is see "..ability to select multiple notification devices...."
I've only found the notification choices I have are two twilio addresses, one for me an one for my wife. Is there more options I couldn't find?
This input in the app just lets you choose devices that expose the notification capability, which is generally devices that implement the "Device Notify" command. Examples besides Twilio include the Hubitat mobile app device, Pushover, and likely other community solutions. The list you see, however, is based on the reported standard device capabilities, and the app happens to let you choose more than one such device now if so desired (it didn't before).
.
(But they did in early hub firmware versions.)
