Thanks Robert, this looks promising
I like it. One suggestion. Specify in the report what triggered the device to make the report (activity, presence or battery). I have several devices set up that are monitored for both activity and battery. When one of those devices hit the report today, I had to look at the events and see if it was battery or activity.
Anyway, love the app. It works great and this even makes it better. Thanks again!
2 Likes
Hmm...I hadn't thought of that before but can see the value now. Would it be useful to just include the relevant data/metadata for the device instead of "Last Activity At" for all (unless it is a "Last Activity At" device, which was my original intent for this app and what I wrote a lot of things assuming)? Maybe for presence-based devices it would show "not present" (that's the value that would match if a device is on the report), for battery devices it would show the current level, and for the others it would show the last activity date like it currently does. Open to ideas on this.
There were already some oddities with presence monitoring, since the "presence" attribute changing to "not present" itself is considered "activity" by the platform, even though the point is to indicate that it isn't (so the date/time is usually not valuable for these devices already).
2 Likes
I like this idea. I think it would make the most sense.
I love this addition. Would it be possible to select the "inactivity detection method," before selecting the devices and limit the list by type?
I've just added the battery indicator to my reports and I found it difficult to identify the battery devices from a long list.
Thanks.
It would be possible, or the list could be filtered even with things in the order they are now. The only downside is that if you accidentally change types (or just do so out of curiosity), your existing device selections may be lost. But if no one minds that possibility, I'm thinking it would be a good idea, too.
2 Likes
No problem here. Worst case is you have to set things back up. Pretty easy to do in this app.
Greetings!
I've been working on some changes to this app and have the first beta of v2.0 up if anyone wants to try it out. For now, you'll need to manually install the code: https://raw.githubusercontent.com/RMoRobert/Hubitat/master/apps/DeviceActivityCheck/DeviceActivityCheck2.groovy (either copy/and paste, or use this as the raw import URL).
I still have some additional features I want to add, but because this addresses some changes requested above, I thought I'd throw it out there for now. Here are some changes:
- Device list filtered based on monitoring type (last activity, presence, or battery)--choose this first if you want to filter the list
- Notifications and reports show either last activity, presence, or battery level as the status (instead of just Last Activity date/time, which is not as meaningful for other monitoring types)
- Ability to choose different date/time formats for notifications vs. reports (check your settings for reports after upgrading if you want to use a different format for those)
No known issues, but let me know if you find anything.
2 Likes
Just installed it. Thanks for the update!
Great program. I was wondering if it would be possible to be able to refresh with RM. Either a virtual button or something to that effect?
Is there something the app's built-in refresh feature isn't doing that would make doing it from RM instead different? Since it will refresh--if configured to do so and any such devices are "inactive"--before running the report, it would be possible to do with Rule Machine if you also wanted to a send a notification (if there are inactive devices to report). In that case, use the "Or any time this switch is turned on" option and make RM turn on that switch (and off unless it does that on its own), which will trigger the notification.
Otherwise, you could certainly just make a rule that runs the "Refresh" command on your devices, but you'd have to choose them separately in the Rule, as there would of course be no connection between the two apps.
It seems that if I manually refresh in the app it takes items off the list from being refreshed but it does not seem to run automatically when you have a time for it to run set.
If by "the list" you mean the "View current report page," then the only thing that should remove them from either the real list on that page or the list of devices to be refreshed at the bottom is them no longer meeting the criteria--generally them having been refreshed, generating an event/activity, and no longer appearing on the list for that reason. This should work the same whether you use "Test notification now," the daily time-based notification, or the switch-based notification. All of these are a bit different from manually viewing the page in that doing so lets you wait however long you want between the first (pre-refresh) and second (post-refresh) views, whereas the automated methods wait a certain number of seconds plus a certain number of seconds per device, in an effort to give everything time to respond, though it's possible that for some devices that isn't enough.
I could certainly add an automated way to do just the refresh, but if there's an underlying problem that makes it not work in-app, I'd rather address that. (I'd also again suggest using this feature sparingly, but it should still work...)
I have it setup on 7 hubs in 6 locations. It sends me a daily report at 4am. I could get a report with a bunch of devices down to no report = no devices. I get a list of extenders for example, I then go to that hub and view the report and then refresh and the report again drops down to just a few to none at all. Sorry hard to explain.
Unfortunately, the activity version doesn't skip over the following lines:
In other words, this device has really been inactive for days, yet it shows as being active because every time the hub that it comes from does a backup, you get the "Hub mesh enabled/disabled".
I don't have control over that. It just reads the "Last Activity At" metadata from Hubitat, and if Hub Mesh causes that to be updated (which these look like device events it is generating, which definitely count), then that's how it is. I would recommend using this app on the "real" hub and not anything through Hub Mesh, HubConnect, etc. for this reason.
In related news, I have another feature planned for v2 that should let you aggregate notifications from multiple hubs into a single notification (not in the present beta, one reason I'm not considering this final). However, the app would still need to be configured on each "real" hub, so I wouldn't let that change anything about your setup now (or then).
Perhaps a good approach is that you put in the documentation for this app something like the following:
"It is highly reccomended that this app be used on the Hub that contains the base of Hub Mesh devices, and not the Hub Mesh reflection of that device, due to potential extraneous mesh messages on the Hub Mesh reflection."
I actually use it on all my hubs. Just select the devices that are local to each hub on each hub. It then names the message and you know which hub to look at.
1 Like
Do people actually read that? 
I do have it documented that this detection method uses the "Last Activity At" data, and this behavior is consistent with that because it appears to be getting updated for that device (whether it should or not is a different issue, but I didn't write Hub Mesh, and since it's a device event, it's at least consistent with what "real" events do). However, I see your point and could add a more specific note.
It might be better to detect this in-app and display a caution in the UI, at least until if/when this may change. I don't see a documented way to do this, but I wonder if the undocumented linkedDevice property I see on device objects is a (good) way... (won't help with third-party solutions like HubConnect though, which are really just LAN devices as far as Hubitat is concerned)
This is my recommended setup--and it's what I do.
But as I mentioned, I do have plans for a way to get multiple hub reports all consolidated into a single notification before I make v2 final (that way you don't get potentially one for each hub). It won't be a required setup, of course, but it's something I've wanted myself for a while. And it won't be radically different from the current setup--you'll still need to install the app on the "real" hub and choose the devices and configuration there.
This would be a very nice added feature. This app is much better at finding issues over battery monitoring because the batteries are not consistent at predicting failures in a timely manner. (or to timely and changing batteries before needed)
