@bertabcd1234 - Robert, does this work well with the new Hub Mesh? Just wondering, as I was thinking about putting it on my "Apps" hub as opposed to the Radio Hub. Seems like it should work with "Mesh shared" devices...but I haven't tried it yet.
S.
I have no idea. 
But I also think it should. From what I've seen, Hub Mesh transfers all device data/metadata, including "Last Activity At," exactly as they are on the original hub. With activity monitoring (the default type), Device Activity Check uses the "Last Activity At" value, so it should work if this is true. If it's not, I'd almost consider it a Hub Mesh bug.
With app/driver-based approaches like HubConnect or Link to Hub/Hub Link, you really only get activity on the remote hub when an event is generated, so I know that often doesn't work as expected. But I'm thinking Hub Mesh should...
The reason I don't know is that I still keep this app on the hub with the "real"/radio devices. It only runs when asked--either the daily schedule, the "triggering" virtual (or real) switch, or the "test" functions inside the app--so the impact should be minimal.
Thanks!
I may try it just for kicks. I had it on my device hub before I started moving devices to the new hub...but the question just occurred to me today. I'm thinking as you do...it should work!
I guess we'll see. I'll post it if I can make a certain determination!
Thanks again!
S.
Yes you shuld be right, Sorry for the truble, but I have no Idea wher I can find that menu. Please help me again. Thanks
This is located in the Device Activity Check app instance that you installed on Hubitat. From the Hubitat admin UI, go to "Apps" (in the left-side menu), then find the specific "Device Activity Check" instance in question (it is called that by default, but you may have re-named it). Then click the "Advanced" section heading, which will expand the section to reveal the option in my screenshot. Make sure that is turned off. Then, hit "Done" to save your changes.
Thanks I had old version 1.0.2 instead of 1.2.0 
I really like the Davice Activity Check utility. But, you knew there was a but didn't you , it appears to only support one notification device whereas most other Apps allow you to support multiple devices. This is a low priority request and not a big deal.
Also when you click on View Current Report to see the results on the web browser the time display is in GMT and not my current time zone. Again not a big deal.
What do you mean? I'm able to select multiple devices under the "push over" option so that multiple devices of mine get notifications.
This would be an easy thing to add, so I'll work on that for the next release. (I never bothered with this since I use a single "proxy" notification device in all of my apps, then have another app that devices what "real" devices that notification goes to. Another story.)
I don't have an option with that name (or actually allow multiple selections), but maybe you're thinking of Device Watchdog or a similar app that does (Device Monitor or the Cobra device app whose name I can't remember?).
I'll look into that--thanks for the report! I do not have that problem but have the "Use 'date/time format for notifications' for 'view current report' dates/times" option checked, which I suspect is the difference. I'm guessing I'm just not applying any format to this date/time without this option selected and it's coming out as GMT. Might have changed in a recent platform release or maybe I just didn't test that well enough...
I've just released version 1.3 with a few new features:
- The ability to send a "Refresh" command to selected devices before running a report (totally optional, and please be conservative with this usage--only choose devices you know will respond to refresh commands, which some battery devices will not; for more complex situations, you could consider using a rule instead of this option)
- The ability to choose multiple notification devices (as requested above)
- Default local timezone formatting on the "View Current Report" page (as noted above)
The update should be available in Hubitat Package Manager shortly if not already, and the updated code is also on GitHub for those who perform manual installation.
1 Like
Wow! I'm impressed with how fast you've worked on my comments.
But it has just occurred to me that I'd also like to see all those devices and how long it has been since they have responded even if they haven't exceeded the response time. Sorted by time since last response. So similar to your current View/Test Report but with an extra column for hours/minutes since last contact.
Now as far as the Refresh command goes I have no idea what devices I have would respond and which would not. So would it be useful to have a separate Refresh button with a display showing those devices which didn't respond? I have no idea so I'm just asking.
Thanks muchly, Tony
Hmm. I could maybe add an option on the "View current report" page to show all devices and not just "inactive" ones. But you can also check an individual device from its device page--the "Last Activity At" data is what my app reads. If you're just curious for setup, you could set this to an extremely low interval like 1 minute, then increase it to your desired interval after configuration. I'm not sure I'd see a use for such an option myself but am open to hearing potential use cases, but either of these are a workaround you can already do as-is. My main intent with this app is to use the notifications, with the "View current report" thing being something you can just use to test things while setting it up.
Where would this button be? In the "View current report" list? Again, that's just something I'd use while setting up the app. You can press the "Refresh" button/command on any device page, and it will send the command to the device. I'm hesitant to add more "features" to this page since I'm not sure that's really the best way to use this app, but this could just be because it's not a use case I considered.
Regarding what happens after a refresh command is sent: this is not something my app has a way of knowing, nor do I, so you'll just have to see if it does anything. 
(But in general, most Zigbee devices Hubitat supports respond to a refresh, even battery ones, except rare devices that do sleep like the Eria remote and, I think, Xiaomi and possibly Sonoff sensors. Most battery Z-Wave devices will not unless they are something like a lock or thermostat that needs to respond to commands when it might be sleeping. Most powered devices of either protocol will. But again, you'll have to know your particular devices here--or test them to see.)
Robert, thank you for a great app. It's very intuitive and and quite easy to use. The recent additions added even more flexibility.
I set up a separate group with my devices that need a refresh. There are 28 mains powered devices that need a refresh. Most are regular zwave, a few are zwave plus and 4 are zigbee. When testing notifications, I had 3 devices show as unresponsive. I tested again and only had one device. If I split the group will it help with the timing?
Second, I have a device that is respoding to the refresh request in the logs but device activity check is still showing it as unresponsive. I have tried several times with the same results. It's my "guest room repeater". Debug logs are attached. Any ideas?
Look at the "Last Activity At" date/time on the device page for your "Guest Room Repeater." My guess is that issuing a refresh() command (as this app does try to do, but you can also manually run from the device page) does not cause this value to be updated. That would be more of a question for the device or driver; the driver generating an event would for sure cause this value to be updated, but I think Hubitat does a bit of magic on its own behind the scenes for Z-Wave and Zigbee traffic that updates it regardless (not as sure about that since I don't think it's documented). If it does get updated, then maybe it's just taking a bit too long and DAC will have already evaluated the report by that point; that is something I could address by increasing or allowing more configuration over the delay time.
Thanks for the quick reply and I now see where you're pulling the activity data from. I was thinking it was from the logs because a refresh does not seem to update the event page for a device.
The last activity is not being updated so this would indeed seem to be an issue with the GENERIC ZIGBEE OUTLET driver included with the hub. I will see if I can find a different community driver.
I'll post an update if the built in refresh delay continues to not be long enough.
Again, thanks for the great app.
Yeah, I should have noted that a device/driver merely generating a log does not count as "activity" as far as Hubitat is concerned. I also don't have many smart plugs or switches in use with this app; those rarely "fall off" the network (I'm mostly concerned about battery devices where the battery may have died before notoriously unreliable battery level reports noted anything). But I think a refresh still generates "activity" on most I've checked, so I'm not sure about the particular ones you're using. Good luck!
I have only found a couple of mains powered devices that don't play nice and these Sylvania zigbee outlets are one of them. I haven't actually had a device fall off the network, other then the Hampton Bay zigbee fan controllers, and they are notorious for this behavior. Like you, I'm really looking to monitor the battery operated devices since battery reporting is pretty awful. Your code works really well for my battery devices, and most mains powered devices too.
Hats off to you for working this up.
I posted some time back surprised that this functionality wasn't an integral part of HE as it is in all pro grade security systems that employ any level of battery based sensors.
Still new to HE and I find myself wondering if stuff like this, that addresses a fundamental need (not a 'one off' at all) , eventually gets integrated after establishing credible utility...or if the folks rely on good natured contributors such as yourself to keep these maintained and functional as the platform evolves around them.
