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.
Slightly off topic as the OP was for incorporating Last Activity change ability in all Zigbee device drivers, but . . . I am using Device Watchdog along with Hub Information driver to monitor whether my Zigbee devices are online. Since some of my devices (Sengled Zigbee Plug-in Outlets) did not report Last Updated changes unless they were turned on or off, I found that by using a RM rule that sent a Configure command thru the Custom Actions Actuator command each hour would change the Last Activity status whereas a Refresh did not appear to do so. If the Last Activity data is not within a set time (in my use case two cycles of the Configure schedule, then I receive a notice that the device is offline. The reason why I could not simply periodically recycle my devices on and off to check is that some of them trigger other alerts/sirens etc.
Again, sorry if this was slightly off topic from the OP. I just thought this might help some to get around some of the limitations in some of the drivers (given @chad.andrews comments regarding the Device Watchdog app).
@moh I think it's on topic, The Configure button in my situation doesn't work either to up date the last activity. This specifically with the Generic ZWave Plus Switch Driver in my case. I'll get a refresh called in the middle of the night, it's refreshed and it shows up in the logs that it's doing what it supposed to. But the Last Activity is days before that, if I haven't used the switch (actual send event). This is from one of the staff members, which makes me believe this is suppose to update as we expect it to. So I am not sure why it isn't. The guys who would know this are @bcopeland @mike.maxwell @bobbyD and they could already be looking into it.
Hi @chad.andrews,
Thanks for the heads up. I was not aware that the Configure button was not refreshing the Last Activity on devices using the Generic Z-Wave Plus Switch Driver. This is useful information and I will need to check this out on my Ecolink Z-wave Plus Firefighter device.
My only experience so far was using this method to get around the Generic Zigbee Outlet Driver limitations in my use case and the OP mentioned they were having problems with Zigbee devices.
As you stated, hopefully @bcopeland @mike.maxwell and @bobbyD are looking into this. Thanks for the info.
Download the Hubitat app
