Thanks for checking that out! Looks like I have a math error on line 671 when converting the duration to epoch time (not sure what I was thinking...and it's why I didn't see it in my tests with short snooze times). I should be able to actually publish this change tomorrow, but if you wanted to fix it in the meantime, changing that line to something like this should work:
Long snoozeUntil = now() + (snoozeDuration ?: defaultSnoozeDuration)*3_600_000
I've released version 2.1.2 with the above fix. As usual, HPM or manual install should both work.
This is the only change, so if you don't use the "snooze" feature, there is no reason to update (or not).
Thanks!
(and I'm finally back in the country so hopefully today I'll fix my devices so I don't need to snooze them anymore)
I greatly appreciate this app. It works very well for me but I've just disovered some wonky device driver behavior which cauases this app to not work for those device. The Sonoff SNZB-03 motion sensor driver sends a "notPresentCounter" event every three hours. Now this same behavior possibly/likely will be happenind from other Sonoff devices but I haven't had a dead battery with those.
The log also shows some stuff.
ev:362023-03-16 02:56:48.036warnEvent interval INCORRECT, recovery mode (Normal) ACTIVE! If this is shown every hour for the same device and doesn't go away after three times, the device has probably fallen off and require a quick press of the reset button or possibly even re-pairing. It MAY also return within 24 hours, so patience MIGHT pay off.
dev:362023-03-16 02:56:48.033warnOne or several EXPECTED checkin events have been missed! Something MIGHT be wrong with the mesh for this device. Minutes since last checkin: 4251 (maximum expected 140)
dev:362023-03-16 01:56:48.039warnEvent interval INCORRECT, recovery mode (Normal) ACTIVE! If this is shown every hour for the same device and doesn't go away after three times, the device has probably fallen off and require a quick press of the reset button or possibly even re-pairing. It MAY also return within 24 hours, so patience MIGHT pay off.
dev:362023-03-16 01:56:48.037warnOne or several EXPECTED checkin events have been missed! Something MIGHT be wrong with the mesh for this device. Minutes since last checkin: 4191 (maximum expected 140)
This is an oddity of that driver--it uses "presence" as a substitute for connection/health status, and it also generates events (attribute changes) for each missed interval or so. Events on Hubitat count as "activity" on the device. As noted, this app uses the "Last activity at" data on the device, which is also what I mean here with "activity." You can check this on the device detail page yourself and see that it will correspond. It is important to know how this device metadata works for any device you use with this detection method in the app.
The good news is that there are other detection methods available. Use a custom attribute, choose "presence" as the attribute, then "not present" as the value. That is how the driver you're using was intended to work, and this briefly caught on for this purpose among some authors, though I would not favor it anymore. Alternatively, there is a built-in driver for this device that only generates activity when there is some (and possibly even less often...), or there could be other community drivers that work differently.
The log entries you provided are coming from the device and are not related to anything this app would be looking at or generating.
@tony4 I can encourage you to start using the newly introduced healthCheck attribute in the Device Acticity Check app version 2.1.
All Sonoff Zigbee devices should be supported by custom drivers that have healtchCheck 'online' / 'offline' attributes. if any issues, these can be fixed.
The Sonoff Zigbee device drivers don't have the healthCheck attribute. I'm using the ones available as part of the Hubitat Package Manaager. Namespace oh-lalabs.com dated 2021-01-15.
However the deprecated "presence" attribute works for me.
Right, that is the exact family of drivers I was alluding to above regarding presence. Those drivers may still work, but they are no longer maintained, as the author no longer uses Hubitat. I might suggest an alternative. There are built-in drivers (where you'd need to monitor actual activity) and possibly other community options (which may or may not work differently). However, if the drivers you are using work for you, that's fine; you'll just need to use the option in Device Activity Check that is best suited to your driver.
@tony4 can you send me in a DM a list of all the Sonoff devices that you have? I will check what newer and supported drivers are available.
Robert:
Would it be difficult to add the ability to trap specific event types a device has reported (or not) during the inactivity threshold, rather than just looking for any activity? E.g., for a motion or contact sensors, track if the sensor has not reported motion or contact within the inactivity threshold. I'd like to know if/when my contact sensors stop reporting motion or contact events, even if they are still reporting battery, etc.
Make sense? Appreciate your consideration. 
Not very easily. The "Last Activity At" date in the driver is what it looks at, which is generally any event. If a device only generates certain events, there is another problem, but it didn't fall off your network.
But this would be pretty easy to do with a rule per device. Trigger with the attribute in question "changed," then make your first action a "Wait for event: elapsed time" for the desired time, and then the second action a notification or whatever you want. The Notifications app itself could also do this directly for supported devices/attributes (RM, of course, could work for any).
OK, thanks...I was starting to look into Notifications or RM, but wanted to ask first just in case it was an easy update to the app. Trying to be lazy/smart. 
Speaking of being lazy, could you send me the rule you make to accomplish this?
I don't have any such rules because this is not a use I have (and I honestly don't really understand the use case), but I pretty much described above exactly how it could be created. But even easier, if it's a device type/attribute that is supported by the Notifications app, just use that instead with the "for how long?" option, and it's even simpler to set up.
I have had motion/contact devices frequently "partially dropping off" of my C8...they stop reporting their core events (motion or contact) but keep reporting battery/temp/humidity/etc. So since DAC is only looking for any event it can't tell me that the devices are no longer reporting their core function (motion/contact), since the devices are still reporting the secondary events.
I'm thinking about making a couple additions/changes to the app and wonder what everyone thinks.
First, I want to revamp the report pages so they either live outside the regular Hubitat app UI or at least have an option that is easily accessible remotely (via a Hubitat cloud link). Here is my first attempt at that:
This isn't complete yet-- I want to add the "Snooze" checkboxes and other options that are there in the current, regular app page, which I might also keep around as a "legacy" option, but this is a start. The thought occurred to me that I might want an easier way to see things when away without needing to depend on the notification. And by "outside the regular app UI," I meant that this is an OAuth endpoint serving regular HTML, not part of the Hubitat app, so I provided my full browser screenshot for context.
Thinking more about a request above, I'm thinking about keeping more or less the current UI for device and group selection but making each group a "child app" of Device Activity Check. This would:
No screenshots for that yet, but I don't anticipate any significant changes as a result besides the effect mentioned above. For example, you'd still be able to configure a single "trigger" or schedule for reports/notifications in the parent app that apply to all groups/child apps--this would mostly be an internal change (and something I did not consider with the request above, nor am I sure this is even exactly what was asked, though I think it's a good idea).
If anyone has any strong opinions one way or the other, let me know.
any way to get access to the new zigbee ping status on the c8.
The external report sounds handy. Sometimes when I get the notification if I just check back a little bit later the device is not showing anymore for whatever reason, so this would let you check that more easily.
Yes this would be handy, I have a TON of devices in this app with 4-5 separate groups depending on the device type.
No, this is (intentionally) not stored in the database or accessible as part of the device object.
Why
Download the Hubitat app
