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.
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?)
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!
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!
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 deviceHealth attribute as a detection method (this is not standard but is being proposed for use in some community drivers; I've also noted presence as "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.
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).
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.
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.
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
I greatly appreciate this app. It works very well for me but I've just disovered some wonky device driver behavior which cauases this app to not work for those device. The Sonoff SNZB-03 motion sensor driver sends a "notPresentCounter" event every three hours. Now this same behavior possibly/likely will be happenind from other Sonoff devices but I haven't had a dead battery with those.
The log also shows some stuff. ev:362023-03-16 02:56:48.036warnEvent interval INCORRECT, recovery mode (Normal) ACTIVE! If this is shown every hour for the same device and doesn't go away after three times, the device has probably fallen off and require a quick press of the reset button or possibly even re-pairing. It MAY also return within 24 hours, so patience MIGHT pay off.
dev:362023-03-16 02:56:48.033warnOne or several EXPECTED checkin events have been missed! Something MIGHT be wrong with the mesh for this device. Minutes since last checkin: 4251 (maximum expected 140)
dev:362023-03-16 01:56:48.039warnEvent interval INCORRECT, recovery mode (Normal) ACTIVE! If this is shown every hour for the same device and doesn't go away after three times, the device has probably fallen off and require a quick press of the reset button or possibly even re-pairing. It MAY also return within 24 hours, so patience MIGHT pay off.
dev:362023-03-16 01:56:48.037warnOne or several EXPECTED checkin events have been missed! Something MIGHT be wrong with the mesh for this device. Minutes since last checkin: 4191 (maximum expected 140)