I just discovered that I can no longer edit the device list for this App. Clicking on the current list no longer opens up the Device List for selection or deselection. I tried HPM Repair on it to no avail. It does work fine on another hub, however. Any ideas, other than recreating the whole thing?
Anything in Logs?
Soft reset/restore (most easily using the advanced option inside Settings > Reboot)?
If the selector shows up, there isn't really much the app can do to break that -- the list is under control of the platform.
Will replicate and check logs. I’d rather rebuild than semi-nuke things. I’m still recovering from multiple disasters, some self-made. Also, I wasn’t clear. The list isn’t empty, it doesn’t appear at all.
A soft reset and restore, or the equivalent option in "Reboot" under "Advanced" in the dialog, won't net a result where anything is "nuked" -- though, and perhaps this is what you mean, it does erase before restoring, as that is how the process works. That is true even you just restored a backup yourself without erasing anything yourself. If something goes wrong with that, you've got other problems (hardware failure?) that will appear sooner or later. Otherwise, this is harmless and is often a good troubleshooting step if you suspect database corruption. That is one possibility.
Without clues in Logs (or maybe a screenshot of the page in the app), I'd add only make sure you actually have a detection method specified, or consider just re-creating the app. But those other things would be good clues to have.
Recreated rule, deleted old rule, everything is fine. Thanks @bertabcd1234 , didn't have time for more troubleshooting.
1 Like
Hi! It looks like you have already asked this exact question. The answer is the same as last time:
2 Likes
Sorry for the duplicate inquiry but...
I don't "wish to use local or cloud report endpoints to view reports without using the app."
So it doesn't make sense to me that an app throws warnings and debug entries in my logs just because I don't use one of its functions, especially since debug logs are turned off.
Kinda like my car's engine light going on warning that there's a problem with the car because I don't use the radio...
Well, the answer is the same either way. 
Either ignore the log entries, or enable OAuth to make the ones related to this feature stop.
The OAuth warnings won't happen if the installation or upgrade instructions were properly followed. But they are again harmless except that this feature won't work if you try it (that is what I meant, not that they're appearing because you don't use the feature), and they'll only appear when you hit "Done" in the app, so probably not often enough to be concerned about even if you do nothing.
4 Likes
Okay, I just read every entry in this thread with the word "refresh" in it - how many times can we say refresh?
That said, I want to +1 this idea of allowing the user to set the delay time - here's why: I have two Z-Wave hubs, each with 50ish Z-Wave devices (not on same frequency). Both my meshes are amazing in that every device has many paths back to hub. The downside on that is it often delays time from command to response.
Additionally, most of my Z-Wave devices are mains-powered older switches, fans, dimmers, and outlets - meaning pre-Z-Wave+ and they do not "report" unless asked. This means when I trigger 40+ referesh commands on each network it takes several minutes before the last device has updated.
Before the masses chime in about "you have too many devices" - yes, I am aware. Imagine when I ran all these plus 60ish Zigbee all on a single C-5!? Now I have C-8Pro running automations and Zigbee and two C-8s running just the Z-Wave in hub mesh.
I do like this app so far - just found it and installed it yesterday. I previously used Device Watchdog from the long since unsupported BPTWorld - and it worked well, but has more complexity than I need.
Another question I'm bound to get is "why check activity on all those mains-powered devices?" Because they do fail occasionally - literally drop dead - and I want to know they are alive every 24 hours.
One solution I implemented today - I run DAC every day at 10:30am and I just changed inactivity to 25 hours - so I suspect I just fixed the slow reporting. Another option would be to use RM to run refresh on all my devices at other times of day. TBH I was triggering DW 4x daily for this same reason - but that is a ton of unnecessary chatter 4x daily.
Another thought - I know, just shoot me - what if, and I do understand this would be big change, when DAC is triggered it evaluates and then ONLY sends refresh to "inactive" devices, waits a period of time, THEN evaluates again and only reports on the second try?
Thanks Robert for all your contributions to the HE community - it is very much appreciated!
1 Like
That is pretty much how it already works. It does not send a refresh to every device.
While I do regret implementing this feature at all given the potential for misuse -- and I'd really look into why your Z-Wave devices are doing that in the first place -- I'll consider this for the future. In the meantime, the code that does this should be an easy hardcoded edit for anyone who wants to try.
Argh - you would not believe how many times I read the documentation and the instructions in the app before I suggested this.
My interpretation of the wording "Refresh before running report" made me believe it sends to all inactive that are ticked.
I'll know more tomorrow, I only ticked a couple things yesterday and the DAC reports today were showing last activity ~9am yesterday (last time DW ran). So now all the devices that I KNOW respond to refresh are ticked - plus I changed to 25 hour inactivity - I suspect tomorrow will look really good.
Hmm, that could maybe be phrased differently, like "generating," though I'm not sure if that's clearer. I do have this in the note below the option:
Note: If any devices need to be refreshed (only devices deemed inactive will be), ...
In the Note... yep, I didn't see that or realize it does what I wanted. Maybe reword slightly:
Note: Any selected devices deemed inactive at execution will be sent a refresh before the report is generated. The report will then be delayed ...
And put the Note above the drop-down selection.
Again, just thoughts. Another question - does opening the report page trigger execution? or does it just return results from the last time it ran?
I'm not sure of the specific question here. The report will evaluate Last Activity At every time it is opened. It will only refresh if you do so manually (button at the bottom; this isn't automatic like it is for notifications since I think most would find waiting to be awkward). The report, as it suggests on the main page, is intended to be useful for getting a current view of your devices with respect to your settings. Hopefully that's what you were looking for!
11 posts were split to a new topic: Notifications
3 posts were split to a new topic: HASS Community discussion
A post was merged into an existing topic: HASS Community discussion
I was looking into why I wasn't receiving email from Device Activity Check sending notification through @kahn-hubitat sendmail driver, and found the reason to be RFC non-compliance:
In parse - 552 5.2.0 Message contains bare LF and is violating 822.bis section 2.
As far as I know, this is only an issue sending email from this particular app. I do notice in Device Activity Check, the last changes were
- 2.4.1 (2024-04-25) - Add line break before (optional) appended notification text
- 2.4 (2024-04-24) - Add option to append text to notifications (e.g., Pushover users who want cloud report link)
It could be that this stopped working for me that long ago and I didn't notice it. Not sure if this is something that is best fixed in the DAC app, or checking for in sendmail, or maybe even some change to telnet broke it.
It does appear that DAC is sending a bare LF in the content to the notification device.
While evidently not a problem for other notification devices, a bare LF upsets SMTP. This wasn't an issue some time ago, so it may be the mail transfer agent I use only now started enforcing this.
For my purposes, I made a change in my copy of the code to add a CR with it, and that solved it for me. May be that would break somebody else, but it allowed notifications to be sent with sendmail and made no visible difference to notifications to Hubitat app.
1 Like
