If making changes, can I make a suggestion on the Refresh before running report. Run the check task first, then if any devices are on the report AND on the refresh list, send the refresh only to those devices and check those devices again. That way you aren't sending Refresh to devices that already have been recently updated on a daily basis.
That is already the way it works.
1 Like
You shouldn't need to. Maybe there's something else going on, but I was able to reproduce the issue in my testing, and this fixed it for me.
OK cool. I wasn't sure, the wording made me think that wasn't the case and I didn't want to send out refresh to a bunch of devices everyday at the same time and overwhelm my radios. 
Thanks.
1 Like
I've just released version 1.4.5 of the app with further refinements to the "refresh" behavior (if you're curious, behind the scenes, it uses runIn() instead of pauseExecution(), since something about the latter appears to cause the app not to see new device activity after a refresh, perhaps a caching issue; this is only an option for actual notifications, so the "view current report" page that I really intended more or less only for setup and testing but I suppose some people might view regularly provides a "Refresh" button at the bottom if any inactive devices are configured for this option--so click it, then wait a few seconds, or a minute or so for large numbers of devices...which I generally wouldn't recommend for use with this feature, but I suppose everyone has their own use cases).
As usual, HPM should have the update. If you manually updated, this update affects only the child app.
4 Likes
Thanks for this, but there is a typo on line 283 - “aragraph” instead of “paragraph”
Was getting “ errorgroovy.lang.MissingMethodException: No signature of method: user_app_RMoRobert_Device_Activity_Check_1156.aragraph() is applicable for argument types: (java.lang.String) values: [No inactive devices to report] on line 283 (method pageViewReport)”
Hmm, thought I fixed that but must not have uploaded the change. For anyone who encounters this, that's the fix--just make it "paragraph." Also, it's more or less a good sign--it means all your devices are fine. 
I'll get this fixed next time I'm at my computer.
2 Likes
This has been updated. HPM should see an update soon, and manual installations can just copy/paste over the child app code as usual. (I kept the version 1.4.5 in the code and made it 1.4.5b in HPM to make it see it as a different version so you can update/re-update without a repair if you already updated.)
1 Like
Question on the logsa. Getting this since update, ignore?
app:3142021-08-16 16:00:00.155 warnUnsupported inactivity detection method for group 1; skipping
app:3142021-08-16 16:00:00.102 warnUnsupported inactivity detection method for group 1; skipping
app:3142021-08-15 16:00:00.225 warnUnsupported inactivity detection method for group 1; skipping
app:3142021-08-15 16:00:00.150 warnUnsupported inactivity detection method for group 1; skipping
How is group 1 configured? (This is the "underlying" group number and might be different from what you see in the UI; the App Status/gear icon page will have this number in the setting names and should give clues as to what it would be.) I can probably figure this out with a bit of playing around, but this would make it easier. I assume you do indeed have some method, currently either activity or presence, selected for the group.
Here are the settings. Haven't added any devices lately. Still got the error yesterday at 16:00. I checked all of the devices and presence is ON and they are all Present.
Turned on debug logging today.
This is just a message I chose for the app to log. It is not an error per se. 
I think I've figured out where this is coming from. It is generated by mistake, as the settings are correct and the app should work fine. I have an idea for how to address it. I'll try to get a fixed out later. Thanks for the report!
This has been addressed in version 1.4.6, available in either HPM or for manual install, as normal. (The issue affected the logs only and was not indicative of an actual problem.)
I notice a day or two ago, I think after one of the updates, but I no longer get date time stamps in my pushover activity log. Haven't changed anything.
Here is the setup. I tried a couple different date formats to see if that made a difference but it did not. If I view the current report it looks fine but what I get from Pushover has no date time stamps. I included a screenshot of the HE log with debug logging turned on, what I see listed in the log is what I see in my pushover notification. No date or time.
Found the issue--fixed in v1.4.7, just uploaded. Thanks for the report!
I really like and use this app. Thanks.
Is there a way to set a time delay when notifications are sent? I am currently getting them every 5 minutes. Not helpful when you are away from home and can't do anything to resolve them.
The app only sends notifications when it's "triggered," either by the daily time or the specified switch (or both). So, you should have complete control over that. Since you're apparently using the switch, I'd consider modifying when you turn it on to wait until you come home (easy with a rule), or use another virtual switch as an intermediary if you have other uses for that one and can't use it like this.
Also, 5 minutes is pretty frequent. FWIW, I do mine once a day at a time when I'm normally home. Just my preference.
OMG! Late last night I did set up a routine to turn on the switch every five minutes and I forgot until you replied. Yes I am going to change that time to about every 2 hours and remember next time a device exceeds the threshold I can just pause the switch routine.
I have already 4 groups and I am planning more. On the ST platform I use before I had to create a webcore routine to do this and with ST moving off groovy and the IDE it was time for me to move to greener pastures.
Just wanted to say this app is great. I brought up an issue with the refresh not working right due to a pause in the code and @bertabcd1234 fixed it proper, and it works great since. I was testing this along with another similar app, lets just say the other one has been deleted this week. I love how the test mode works with the refresh button, works awesome to verify everything is working, or also if I go in and resolve an issue with a device I can easily confirm. Also love the groups, I have sensors in a 12 hr group since they check in a lot, standard devices in a 24hr one with the refresh enabled, some lower use devices in a 36hr group, and finally presence sensors in a 48hr group (cause lets be honest sometimes I don't leave the house for 2 days...).
2 Likes
Greetings, all! I've released version 1.5 with some additions:
-
added battery level as an "inactivity detection method," in addition to the existing "Last Activity At" (default) and presence-based methods. (I'm personally planning on using this to see notifications for devices that might become inactive soon and not ones that literally are, so you may wish to use/interpret it slightly differently from the existing methods; but it seemed appropriate to include in this app to me. Or at least I wanted it. )
- when hitting "Done" in the app, warn messages will be written to "Logs" if you're using a detection method that is unlikely to work on a given device (so at the moment: if you choose "presence" for a device that doesn't report presence or "battery" for a device that doesn't report a "battery" attribute; "Last Activity At" will work for any device)--just seemed like it might be helpful since the device list isn't filtered (which I could do, at the risk of accidental clicks/changes erasing devices you've previously selected)
5 Likes
