[RELEASE] Device Watchdog

@bptworld and @SuperDupe I 've also noticed that the Generic Zigbee Outlet driver doesn't update "Last Activity At" unless the outlet state is actually changed.

As a result of this my outlets show very old dates and sending a refresh command doesn't cause an update either.

I also know for a fact that my outlet does send a roughly hourly ping to say that it's still alive as I've seen it in the logs.

So I'm wondering are the drivers supposed to update the "Last Activity At" whenever they get an update from the device in which case the Hubitat developers should change the drivers?

Or is the "Last Activity At" meant to be updated only when there is an actual change in the state (i.e. the outlet either turns on or off) in which case it will be difficult to monitor if these devices have dropped off until we visually notice an automation failing in which case it's not a great end user experience

Several months ago, 3 outlets using the Generic Zigbee Outlet driver began showing on my daily Device Watchdog report as no activity. These 3 are all in always-on, so no change in status. I've been using DW on my C4 for more than a year with these outlets using the Generic Zigbee Outlet driver all along. After showing up on the report, they all still operate from the menu and often show up as repeaters on the Route Table.

This past week, I wondered if these 3 were all the same model. Yep, Sylvania 72922 SmartPlugs by Ledvance. Research here in this thread and others pointed to a driver issue. In another thread, someone posted that using the Generic Zigbee Switch driver would work. 3 days ago, I changed the driver on two of them as a test and now Device Watchdog no longer lists them as inactive without a status change. I was going to post this asking @mike.maxwell to check and this seems like a good place.

@alexandruy2k @rcjordan

I started looking at the generic Zigbee drivers for my devices today and noticed although I could change between drivers, when I selected the Generic Zigbee Outlet driver, I was not able to change preferences. Weirdly, the update issue was only affecting about 80% of my Zigbee outlets when I used that driver. It didn't matter the manufacturer (I have three different) but basically 5-6 were working as they were supposed to, with the other 30+ not... I would say its an issue with the built in Zigbee Outlet driver, but I'm not qualified to say that...

I did some research and found this community driver. I'm currently trying it on all my Zigbee outlets. Both wall mount and wall wart style... I'm going to give it a day or so to see what happens...

@SuperDupe Markus' drivers will likely fix the issue, but as they are no longer supported I personally wouldn't use them.
The person is no longer a member in this community, and even in the other forum he's no longer maintaining drivers (I've had an issue with one of his Xiaomi drivers and no reply from him at all)
So personally I'd rather make the effort to work with the community here and with the staff to get any necessary fixes in the official drivers which will be supported longer term. (There's other community drivers where the developer has left the community and now because of changes to hubitat the drivers are generating errors in the logs)

@rcjordan I've made the change as well from the Generic Zigbee Outlet to the Generic Zigbee Switch driver and will keep an eye on them.
If the 2 of us can pinpoint to some difference between the 2 we'll have a good chance of one of the staff engineers fixing it.
(If changing to Generic Zigbee Switch is a good workaround the I think it's just a workaround as by default the other driver is chosen after pairing and while it's easy for us to change drivers for any newbees it will be nice if it works straight out of the box for them)

1 Like

@alexandruy2k
This issue has been around for a while. I found it when Bryan first put the refresh option in. I have been using the switch drivers for both zigbee and z-wave. Thats why I have a few different community posts askinng which driver is best to use with an outlet. Resoundingly, I have been told to use the outlet drivers although no one has really given me a reason why....

Recently, I decided I was going to try outlet drivers again and switched all of my outlets both z-wave and zigbee, over.

Its refreshing to see I am not the only one who has experienced this issue. Maybe you will get more traction with your questions. :slight_smile:

BTW, it looks like something in the last month or two has fixed it on the z-wave side. I have switched all my z-wave outlets over to the generic z-wave driver and Bryan's refresh is now working for them.

@mike.maxwell or @bcopeland
I've done a good bit of reading on the forums and some debugging on my side and I think I have enough information gathered to report what I think could be a small bug with the Generic Zigbee Outlet driver.
The bug is that even though in the logs I can see updates sent by the device, the "Last Activity At" timestamp is not updated. A lot of us use Device Watchdog to monitor that our devices weren't turned off at the wall, and it uses the "Last Activity At" to check that.

The logs showing that the device is sending updates

And the Last Activity At doesn't get updated when using the Generic Zigbee Outlet Driver

When manually changing to the Generic Zigbee Switch the Last Activity At does get updated as expected.

Also to note that the Refresh command in the device page does generate a new log, and similarly the Last Activity At is only updated with the Generic Zigbee Switch and not the Outlet Driver

I would appreciate it as the Outlet Driver is the one used by default if one of the staff members could have a look at the differences between them and see if it can be changed.

If this isn't deemed to be a bug may I ask according to Hubitat what are the cases when "Last Activity At" should get updated?

Thank you very much

Can you check the actual device event times, as opposed to the live logs?

If you are trying to see if the outlet was turned off, wouldn't you be better off using a rule triggered by the off event?

1 Like

Hi Mike,

I don't think I explained myself clearly. The issue is for outlets (or similar devices) that are either left on or off for long durations of time (days and weeks at a time). As a result the last activity at shows the last time the status was actually changed from one state to another and similarly if looking at the device events.

The problem becomes when looking at a device with the last activity having a date of for example 1 week ago. You can't tell if that's OK or if someone unplugged it and you only find out when an automation fails when you eventually want to change the state of the device.

The Zigbee Switch driver works as we would like in that when the device sends data to the hub, the driver updates the last activity at even though the status didn't change and the outlet is still in the same state. In this case nothing appears in the event list.
The Zigbee outlet driver which is the default driver doesn't behave the same way and I'm not sure of a way to know if the device was physically unplugged and therefore will not work until it's powered again.

To put it another way the request is to treat state updates sent by the device similarly to how battery updates get treated. If I understood correctly a device sending a battery update will update the last activity at even if the battery level has not changed compared to the previous reported value.

Thanks

edit: tagging @mike.maxwell in case you haven't seen my reply

2 Likes

@alexandruy2k - Separate to following up with Mike on the functioning of the driver, in terms of getting the outcome you want with watchdog, could you use the refresh option in device watchdog to trigger a refresh before compiling the activity report?

Just on that...

@bptworld - I've just started playing with the app, great job as always (by you, not me for setting it up :slight_smile: ). I have used the refresh option I mentioned above to confirm some outside lights I rarely use are still online. I did notice it took a few runs of the activity report for them to all update and no longer appear in the report. I'm suspecting this could be either a simple delay in the refresh completing or was wondering whether it could be that watchdog is on my C-4 hub and the lights are paired to my C-7 and shared via Hub Mesh. Do you think it would be worthwhile and possible to add some kind of delay into the generation of the report when device refreshes are needed, to allow for any delays in device details syncing across hubs? Happy to do some more debugging if you would prefer to confirm the root cause.

Thanks,
Simon

@sburke781 a refresh in the device page when using the generic zigbee outlet doesn't actually update the last activity, so I wouldn't expect doing it from device watchdog would update it either.
I've resolved the issue by swapping to the generic zigbee switch driver which is updated as expected.
So for me the issue is resolved, but I'm trying to get an understanding of how things are meant to get and hopefully get a change done for the default outlet driver so that others in the future don't encounter this issue.

@mike.maxwell Sorry to bother you again. Any comments on my reply 2 messages up?

1 Like

Sure

New version on GitHub...

2.3.8 - 02/14/21 - Added a delay option to Refresh

1 Like

Hey Bryan,

Getting this error when I hit the activity report after the update.

Unexpected Error
An unexpected error has occurred trying to load the app. Check Logs for more information.
Error: No signature of method: com.hubitat.hub.executor.AppExecutor.sleep() is applicable for argument types: (null) values: [null] Possible solutions: sleep(long), sleep(long, groovy.lang.Closure), grep(), grep(java.lang.Object), dump(), every()

***Edit: I went in and basically re-saved my settings in the various reports and the errors went away... It initially showed up on all three hubs.

I got the same problem and re-saved as you suggested. thanks!

LOVE the Device Watchdog - it is great for identifying devices that have gone offline and need attention. Just upgraded and found the Refresh Option added since my last version. This appears really handy because it is only sending refreshes to devices that have not checked in. Previously I had two rule machine rules to "poll everything" that really bogged down my networks for several minutes while everything was reporting.

Question on the functionality of the Refresh Option - from observed behavior if I run the Watchdog once a day and look for no activity in 24 hours - I do get a few alerts, but then they are gone the next day. I assume when it is triggered anything that IS inactive > 24 hours gets reported THEN gets refreshed? And what is the ideal relationship between hours to be considered inactive and hours before sending refresh?

Thanks for mentioning this. I hadn't noticed it either. :slight_smile:

Time to play.........

1 Like

Thanks!

When the report runs the 'refresh' looks for anything over the set time, it then tries to 'Refresh' them and runs the report again.

Hi, really like this Device Watchdog appreciate the work put into it. I would like to know a little more about the refresh myself. It appears I have some devices, namely some Sonoff S31 Plugs and Zooz Zen23 switches that keep showing up on my Activity list for non activity >24 hours. Which is entirely true, they haven't been turned on, but they are reporting in the logs if I do a manual refresh from the specific device page. However this does not update the activity date, I need a physical on or off command to change that. I guess what I am asking is how does the refresh work in the App, when switches or plugs are not updating the actual activity date, or should it be updating it?

Each device is controlled by a driver. That driver determines when it updates the 'last activity'. If a certain device isn't working as expected, you would need to contact the driver author.

The devices work great! No issues whatsoever for on and off. So, if I hit refresh in the specific device page that should update the last activity to the time I refreshed it?

Again, depends on the driver.

1 Like