My test device had been sitting on this driver for a little while and I do see it updated Last Activity, cool.
I guess I don't understand why the device would ignore a Refresh command on the either driver but can be polled, but if y'all say it works, it works.
That driver is possibly configuring it to send the state every hour, I am not totally sure. Also some of the system drivers will filter out duplicated events which prevents the Last Activity from updating.
Hi Robert, I commented out the lines you suggested and also line 896 to get rid of the Heading and the report works well with just the 2 columns. I created a 2nd instance of the app with the intention of one instance providing a cloud report for inactive battery powered devices and the other instance for a Cloud report of Ikea Tradfri outlets (zigbee repeaters) as they have a tendency to ocasionally lock up and cause issues with other zigbee devices and then need resetting.
When the 2nd instance of the App is triggered it unfortunately overwrites the Cloud report of the 1st instance so I suspect part of the code needs changing to create a unique report? I was wondering if you could provide a clue as to what would need changing? Many thanks
I am not able to replicate this behavior, nor do I see from the code how it would be possible. To test, I created two instances of the app and viewed the cloud (and LAN) reports for each. The HTML served for each was as expected via each of the app's configurations, and loading a new one did not affect the contents of the old one, either before or after refreshing. If you are viewing this through a third-party app, is it possible something is going on there?
is there a way to set the inactivity detection to "the last time the device reported its status"?
the last activity at timestamp isn't working too well.
I have lots of devices that are idle (like motion detector in basement which I rarely enter) but then these devices regularly report their status like
However Device Activity check is reporting these devices as offline
The issue in your screenshot could probably be solved by the driver letting the platform filter events instead of doing so itself, but if there is indeed Zigbee activity behind that (as there probably is), this might be possible on C-8 and newer hubs as mentioned above, yes.
yah im confused as to why the App can't just use the platforms' activity logs.. i mean it's right there hehe clearly the device had activity (it reported its latest state) but this App/driver didnt consider that at all.
If an event is posted by the driver it updates the Last Activity date which is what this app uses. As already explained, some drivers filter out events instead of letting the platform take care of it as it is designed to do (I think old bad habits from SmartThings drivers). If no event is posted, the date does not update. The system log is just that, a log file of text, it is not a data point. Even though most drivers will send info logs for all events that is a totally separate things from the actual events being posted.
Hello.
Like many others, I use this app to figure out if a device has fallen off the mesh.
I noticed that Zigbee repeaters (e.g. Ikea Repeater) cannot be selected.
Manually, I figure out if this type of device is on or off the mesh, by clicking on one of the two buttons on the device page (get link quality, get route table), and then checking the Zigbee Logging page to see if this device has showed up.
Is it possible to include these types of devices?
If it doesn't show up, the driver must not implement any capabilities (in the Hubitat driver sense of the term). It doesn't really matter what driver you use for a repeater unless you want a specific attribute or command it offers, so another driver might work around your issue; otherwise, maybe you can convince someone to change the Ikea repeater driver.
I do have to say that I'm not sure this kind of device is really a good fit for this app, either (if a repeater stops working, your network must have some other problem), but it's not intentional. 
You can try this driver, however as Robert said, any other driver that implements a standard capability will work.
Enhancement request: make snooze of a device only snooze it for the group that alert is in.
Reason: I have a group that is triggered by battery going to 0%. I consider that a low priority alert, especially since most of my devices work past that point. I also have several groups for device being recently active. This is my high priority alert.
Last time I was away from home I had a device show up as 0% battery, so I snoozed it so that I would get an alert on it every day. Some time a few days later (after I got home), it actually died. But I didn't get an alert for activity. When I checked a few days later, the device showed up as snoozed on both groups in the report.
Hmm, interesting request. That would require re-working the way snooze works right now (it's tied to the device ID, so it applies everywhere). Not impossible; something I can consider if there is demand.
But one thing you might consider is making two separate parent instances of the app instead of separate groups. There are two independent reasons that this might help:
Put together, these are likely to be even better reasons.
I had meant to mention that as a workaround for snoozing in this case, but much like your reasons here, I don't want two separate notifications.
Thank you for considering it.
I'll still consider it for the future. But one of the reasons I noted there was "same schedule"--while here it sounds like a different one might actually be helpful to mitigate this in the first place. 
But I do want them done on the same schedule -- once a day, every day. I just find one (battery at 0%) not as important as the other (no longer responding).
(and it would be a downside to deal with two different inactive device reports, to select snooze)
But if you want to snooze "both" and use the same schedule, you're back to a single app with device-level snooze being the best choice--exactly how it is now. (My suggestion above was to consider whether different schedules might be a good idea for your use case as well, not a suggestion that you were already wanting it. Just an idea!)
In any case, this is something I can consider for the future, but there are a lot of other things I know I'm going to work on first, so no guarantees. Just trying to provide some possible solutions that would already work using existing functionality. Thanks for the idea!
Download the Hubitat app
