Same error here. Uninstall and reinstall didn't solve the problem.
1 Like
I'm getting the same error now that I'm on 2.3.2.127. I last successfuly ran a manual report a few days ago, probably when I was running .126 or .125.
It is probably related to some hub updated: another app I use to send notifications - Lock History, developed by @thebearmay - is facing the same issue when I try to access some functions.
I took a look at this and, unfortunately, wasn't able to find anything wrong--nothing inside the page is throwing an error that I can see, and it even appears a proper Map gets generated for the page (this is ultimately the data type returned from the method, as far as I know, though it's not documented--logging it before returning it shows valid output with data I expect to see). I suspect there is something inside this Map that Hubitat does not like but isn't passing a useful error out to the logs about.
I will probably just end up re-doing page and see how far I can get before things break to get a better idea of where that might be. Or maybe I'll just get lucky and whatever I do this time won't break at all. 
I'm just really not sure how to troubleshoot with the lack of information, other than something about page rendering in 2.3.2 must have changed to cause this "error" (or blank page, depending on how I get there) compared to 2.3.1. Bad news is this will take me a bit longer; good news is that what I'd consider the main functionality of this app, actual notifications, is unaffected so this is just a display issue with the "view/test" page.
6 Likes
I found out messing with the Influx Logger app having a similar problem it is something with nested sections. If you comment out line 267 and the subsequent closing } at the bottom then it works (may not display exactly as intended?)
Other post with similar issue: InfluxDB Logger issue - #16 by jtp10181
2 Likes
Good eye, and thanks for catching that! (I actually didn't think nested sections were ever valid and probably didn't intend to to this at all--I'm guessing I only wanted the one inside the if, and I suspect I use to have only the one outside before more recent changes). I've tested this change on platform 2.3.2, and it works as expected. I've released a small update to the app, version 2.0.1, with just this change. Thanks again!
4 Likes
Robert - @bertabcd1234 Would it be possible to add an option to not run the app if a switch is on (or off). I use a virtual switch to disable most notifications when out of the country, both to reduce cellular costs, and the time shift of when I would get notified. Thanks.
This would be possible in the future. For now, you could just use a virtual switch instead of a schedule (I assume you're asking because you're using the built-in scheduler), then schedule the switch as you wish (e.g., with a rule). Then with however you schedule turning on that switch, just avoid doing it under whatever conditions you don't want it to happen. Just an idea for the moment!
2 Likes
All,
I've released version 2.1 with the following changes:
- Add a "snooze" feature to temporarily remove selected devices from notifications
- This is accessible from the View current report page
- For example, you may have a device with a dead battery that you plan on replacing in a couple days but know you aren't going to right now, so you can snooze/remove it from notifications for a couple days
- I would consider this feature experimental for now, but it worked as expected in my testing; let you know if you have any problems!
- Add
deviceHealthattribute as a detection method (this is not standard but is being proposed for use in some community drivers; I've also notedpresenceas "deprecated" to discourage its use for this feature instead of actual presence, but there are no functional changes to it) - Add button events as an additional method to trigger the sending of notifications (beyond the existing switch and time-based options)
As always, the app and update are available for install via either HPM or using the links and instructions in the first post.
11 Likes
At the moment I'm often seeing debug messages like snoozedDevices = null in the log, even though I've turned off logging.
The problem is probably the line 649: 
log.trace "snoozedDevices = ${state.snoozedDevices}"
Yep, left in there from testing, it seems! Posted v2.1.1 with this change (only change, no need to update if this doesn't bother you).
2 Likes
This doesn't seem to be working for me. I have 3 Z-wave devices I'm monitoring on activity and they aren't updating. I've put them on snooze the last two days, but by the next day they are back on the inactivity report. I've got the snooze period set for 72 (hours).
It's hard to debug as I'm away at the moment.
Interesting. I never tested with that long of a period (even though it's the default...), so it's possible there is something wrong with my math, or maybe something else entirely. While any devices are snoozed, you should see a snoozedDevices map in state, with the device ID being the key and the epoch time of the end snooze time being the value. If that's not right, it would explain what's happening. If it is right (and maybe disappears after checking?), there could be something else going on.
I suspect that might be enough about how it works for you to figure it out. But for anyone who is confused by my description and also having problems, I can tell you what I mean and where. 
Hello
Is it possible to get a notification as soon as possible when the device cross inactivity threshold?
Not with this app, no. It checks when the app is "triggered."
2 Likes
[quote="bertabcd1234, post:214, topic:42176"]
While any devices are snoozed, you should see a snoozedDevices map in state, with the device ID being the key[/quote]
I do see that:
But I keep getting the same devices being alerted about the next day. When I open the report, all the snooze buttons are unselected. I did check and those are the correct device IDs.
Those epoch times (with millisecs) look good, too, for a time in the future.
If you enable logging, you should see checkIfSnoozed(xxx) entries in logs, with xxx being the device ID, then either "Found snooze date..." or "No longer snoozed" entries for each (or "not snoozed" for everything else). If you see "No longer snoozed," it will also get removed from this map and should re-appear in the next notification (and be un-checked in the report page, etc.).
I haven't tested this much, so it's possible there is some error with the logic. I'll see if I can figure anything out. The above might help you see if there's anything odd, though, in the meantime.
I just checked now (17h later) and none of the devices are listed as snoozed. I didn't think of making sure debug logs are turned on; I'll do that now.
I noticed these two typos here in the advanced options:
Number of hours to remove deivce freom report with "snooze"
And, these are the earlier logs (without debug logging): 17:22:25 is when I refreshed the report - notice that it removed each entry from the map. A few seconds after I refreshed the report I started selecting devices (from the top - 1361 is the first device listed, 1265 is the second). I didn't think to look at the state yet.
FWIW, if I refresh the report now it still shows everything snoozed. I'll see if I can do it in a few hours before the report is next generated (I'm not sure I'll be back to the hotel by then).
Here is the log from when it sent last night's report.
All the epoch times in your hash are around Mon Feb 13 2023 19:06:28 GMT-0500 - but they should all be another 2 days out.
In fact, I just snoozed them, and it set the epoch time in the last to 1:42 from now...
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
1 Like
