@bobbyD Could we get the "last activity at" to update even when there isn't a state change for the following drivers
Generic zigbee outlet
Nue zigbee switch
Samsung presence sensor
Tuya zigbee scene switch
Using @bptworld s device watchdog, these drivers don't update the activity attribute so always show up on the report
Just to add to this, would be nice to have a method we could call to update the last activity without having to update an attribute which in tern can bloat the database if we are doing this to monitor device activity.
Something simple like "device.setLastActivity(now())".
I agree, and to add to it, I think all drivers should in some way update the last activity when doing a refresh. This would also fix the watchdog apps as they try to refresh devices that appear inactive.
The trick to this for it to REALLY work though, is to ONLY send an event IF the device actually responds. The Zooz drivers I maintain originally would send an event just by calling refresh, even if the device did not respond. And then sometimes when the device did respond it was not sending the events to prevent duplicate events being logged.
I have in my dev branch (not posted to main yet), where it will always send the event but still suppresses the logging if it is not changing the actual state. So the event is invisible to the user but updates the last activity if you call refresh and the device responds. It also should not be sending events unless the device replies so this way you truly know if the device is offline for some reason.
IMO this is the ideal implementation.
I use to have in my drivers, updating an attribute with a sendevent in the parse command. But found this created a lot of extra events that increased the size of the database. I then tried to store it in a state variable but found that an app has no access to this for "monitoring" so now I store a lastActivity in the device data section as it can be read by a monitoring app and doesn't create extra events in the database. This has been working nicely so far.
Its not doing it in parse, I just have the normal events always sending the event which is what a lot of drivers do already. When you call a refresh, it requests the state of the switch and if the device replies the event gets sent no matter what but only sends the log.info if the state is changing.
There are some state variables also which just carried over from the ST DTH I ported, not sure if they have a use at all?
As long as you do not specify “isStateChange: true”, the platform will not create a new event if the value has not changed. But, it will update the lastActivityAt field.
I do it in parse for mine. I figure if parse is getting called it's because the device said something. So to me it's alive.
I tried that in the past and it only updated the last activity when the actual state was forced to update. I'll have to recheck that.
Either way I still prefer using the data. The good thing is with the new libraries feature I can easily change it for all my driver's by editing a couple lines of code.
Don't want to derail the debate, but the feature request was to update the stock drivers
Yeah sorry, my original intention was to just point out the way I had found to handle it in a custom driver and state that I agree all the stock drivers should be doing something similar. Not sure how it is handled in any of the stock drivers where it does work correctly since we cant see the code. For all I know it may not even verify the device is alive in the stock drivers. I usually avoid the stock drivers since I cant see the code to debug any issues that come up.
I agree. All drivers should always issue a sendEvent() when parse() is called, even if the attribute value has not changed. The platform will then sort out any duplicates on its own, and still keep the lastActivity field updated.
Tagging @mike.maxwell and @bcopeland from Hubitat as they maintain most all of the built-in drivers.
Send event and last activity should be completely decoupled. If parse is called last activity should update irrespective of event generation.
That we can look into.
The only thing I miss from ST Hub is the Offline and Online device status then I don't even need DeviceWatchDog, I can just do, if offline in WebCore
Currently, my watchdog lists every outlet I have as they are rarely changed as they are mainly for repeating.
This is still an issue, I recently got a zigbee outlet and am now searching for a generic custom driver that will properly update the last activity when you refresh the device and it responds.
Update: I think I found a workaround for my plug at least. I enabled power reporting and now the refresh updates the activity I think because it is requesting a power update. I dont really need the power reporting but it fixes the issue.
I was looking at this issue just this morning so I came on the forums to have a look. In my case it the Generic Zwave Plus Switch driver that I am using. Refresh of the device(s) does not update the Last Activity and it is only when the switch is turned on and off that it will change, even though the Refresh is clearly in the logs. Is this something that is being considered to be changed? @mike.maxwell @bcopeland
Some Zigbee devices use to periodically send an 'Application Version' report as a way to check in or announce they are alive. So a possibility HE drivers to change the LastActivity timestamp will be very beneficial is such cases.
Any update on looking into this
Look into what?
Hi Mike, getting the "Last Activity At" to update with a refresh not only on/off. In my case it's the Generic Zwave Plus Switch Driver as shown in a couple posts back. Ther appears to be quite a few more drivers that don't do this.
A few more posts before that, it was likely that you nice folks were going to have a look into it for us.
Was a while ago
Yep, A long time ago. Probably just fell off the plate, but I bet a lot of people would appreciate this, it would tie in nicely with the Device Watchdog App that many of us use.
Download the Hubitat app
