I'm considering more options for scheduling, but this is do-able already if you just use a virtual switch that gets turned on via whatever criteria you want, which in your case could be (or include) the presence sensor(s) arriving, perhaps with a small delay added in. The intent with the switch option for the moment was to allow more flexible options via rules, voice, or whatever--things like this.
1 Like
Great app. Please, please, please add "Last Update" as one of the "Inactivity detection methods."
Adding Last Update would enable your app to support leak sensors that only report activity when wet/dry but update more frequently.
Thx
I am not familiar with "last update," nor does it sound like a standard attribute or device metadata to me. Can you provide a screenshot or example of what you are looking for?
"Last Update Time" is a field of every Device Details table I believe.
It's not intuitive that this field could be used for alive/dead status but Insteon appears to be a use case.
That is not related to device activity and just reflects the last time you hit "Save Device" on the device page. It is also not accessible to apps so couldn't be used regardless.
Understood, [AS-IS] Insteon web socket driver causes the Last Update Time field to be updated frequently for some reason.
I will verify that this field is only updated if the sensors batteries have not died and if so, request that Hubitat expose the Last Update Time field to apps.
Thx
Hoping someone has some knowledge on this...
We have several samsung multipurpose sensors on several doors at my dads house....last time I was home over Thanksgiving a few months ago I replaced all his batteries and setup Device Activity Check ...when home over Christmas I found that his hub was unplugged...when I re-powered it and ran Activity Check every device failed for Activity check.. i selected one and did a refresh but that did not help. I'm not sure whether they have to be re-added or the batteries are really dead and whether having hub off would drain batteries more ....any ideas ?
Not every device will respond to a "Refresh," though most Zigbee devices will. Can't speak to that specific device, however.
The real question here doesn't seem like this app, however, but whether your device is really communicating with the hub. Since it's the ST Multisensor, you should be able to open or close it and see the a state update on the hub, or even just shake or rotate it and see the same if you didn't disable that reporting. If you don't see that happening, there is still a problem with the device. You should not need to re-pair after replacing batteries (it should just work), though for Zigbee devices, it's easy enough to try if you wanted to: don't remove the device from Hubitat, just put the hub and device into pairing mode, and it should recognize it as the same device (usually telling you so in the UI, though sometimes I've seen it do this and just not say anything).
1 Like
thanks for the input....i will try when I get back to my Dad's later today... I really love the app...the battery levels are so flaky so this is the perfect solution
I thought that having the hub unplugged would kill the batteries because the devices would go into a higher power mode trying to communicate. I thought this was why battery life seems very dependent on mesh strength. I’ve had ST contact sensors for years (going on 4) and have only replaced the batteries twice.
1 Like
For the Samsung leak sensors and motion sensors there was a firmware update as well that dramatically improved battery life. I had been replacing every 3-4 months. Haven’t replaced in over a year now.
2 Likes
I forgot about that. It effected the button device as well, which I use for temperature monitoring.
Sorry @bertabcd1234
We shouldn’t be posting this on the Device Activity check thread.
2 Likes
Is that a fairly fail safe procedure with the new HE Device Firmware Updater? Never attempted this but I have an ST Multipurpose V5 that eats batteries and I blamed it on the device location when maybe I need a firmware upgrade. Are you picking up the file from the vendor's site?
- model: multi
- application: 11
- firmwareMT: 1241-0020-00000011
- softwareBuild: 00000011
- manufacturer: Samjin
Sorry to sidetrack the thread...but it's battery related no 
FOLLOW UP - NO NEED TO SOIL THIS THREAD, I'm over in the right threads reading about Firmware Updating now. Sorry.
2 Likes
I've just "released" Device Activity Check v2, though some of you have probably been using it for a while. There was some more I wanted to do for v2 (aggregating notifications from multiple hubs into one notification), but I've decided this is enough new stuff for now, so I mostly just finally removed the beta label from v2. 
Biggest changes: device list is filtered based on detection method used (e.g., battery selection will only show battery devices; last activity shows all since every device has this), the ability to use a different date format in reports vs. notifications (after updating, make sure you have what you have your desired selections for whichever feature[s] you use--it's been so long since I made this change that I can't remember what the old defaults were...], and new formatting for reports (used to show date for all; now will show date if last activity or the relevant attribute values otherwise, which as discussed above, seems to make more sense).
If you prefer v1, it's still available from the /deprecated folder in the repo.
As usual, this is available in HPM or for manual install (see first post). Let me know if there are any issues!
1 Like
Thinking out loud here...and I'll say I've never needed this to bird dog a problem, but wouldn't it be cool to somehow use daily routing path information to further expand what you are able to report.
Without trying to suggest how to do this reliably and in a manner that would add value....here's some hypothetical report dialogues.
Device A appears to be inactive, I last heard from it on day x at y o'clock with a reported battery level of ZZ%, and it was last seen routing through x, then y repeater,
Device B appears to be inactive, I last heard from it on day x at y o'clock with a reported battery level of BB% and it was last seen routing through x repeater.
Potential conclusion (if both battery levels were not questionable) -
dang...I might have lost repeater "x".
This might be way more work than it's worth, or it may be impossible to capture and store the data without some other historical data capturing by HE. It is also something you could "conclude" with a little time looking at the situation and manually inspecting information on the hub.
But I'm just throwing this out there...in case it sparks anything in anyone else's mind as to how to accomplish it and if there would be value of doing so.
One of the things I worry about is that I lose a repeat-only repeater (i.e. not talkative by design and not monitored by your utility) that is really supportive of my topology ....and then things "heal" but really don't heal well enough... and then things limp along awhile without me realizing (as soon as I'd like to) that the repeater is kaput.
Thinking about this further, if the routing healed the path back to the hub in some way and no device(s) went absent you wouldn't know that important mesh supportive repeater was out right away.
So maybe a further feature here is to "report a change in repeater path". Gotta think that through because it might be too onerous to report given daily environmental changes...but I assume things settle down, or should, to where the same path could be assumed 95% of the time during normal daily operation...and reporting when it wasn't... might be meaningful.
Sorry, went a bit long thinking out loud here.
Great app! Exactly what I was looking for to keep tabs on my motion/temperature/leak/contact sensors when they go AWOL. I found it much easier to configure than Device Watchdog.
This works great except for my two Aeotec Siren 6. Any ideas on how to make them integrate?
They don't seem to check in by themselves, at least not very often. The refresh option doesn't help.
But they're completely online/healthy.
If they don't generate "activity" somehow, even with a refresh, I'm not sure what you can do (unless you actually want to run a regular command on them periodically, maybe with a rule, and that command does generates activity).
Alternatively, since it sounds like you do see some activity, you may wish to consider simply setting your time threshold to something longer. IMHO, this type of app is most useful for battery devices; mains-powered devices rarely "fall off" on their own in my experience--and certainly not from a dead battery and unreliable battery reporting. 
3 Likes
It actually seems they don't check in by themselves at all- at least not for the last 14 days.
I hooked a rule to reset the volume once a day. Good enough i guess!
Can you please change from a single notification with a list of inactive devices to one notification per inactive device?
iOS notifications are truncated without any way to read the entire text. Therefore, if more than two devices are inactive, I have to go to the Hubitat web UI and drill down into your Device Activity Check app to identify all devices which require attention.
