But it will.. As this is the new standard
6 Likes
Gotcha. 
Good standard/decision in my opinion.
And I wasn't really trying to pick on your Ring driver. It was just an example.
2 Likes
No biggie.. I know it needs to be addressed now. 
2 Likes
Well if I realized it was actually a gap I would have reported it in a less cheeky way though. lol
4 Likes
I think this discussion just proves the original point. Device activity (not the device state) is something the hub should track not the device.
Then all concerns about writing device drivers according to the currently adopted standard are irrelevant.
Giving control over the activity to the device itself means letting the device to hide its activity or even report the activity that did not happen. The driver could have a bug where the last activity could be in the future for example.
The driver does not provide a time stamp for Last Activity. Only the Hubitat platform can update that field, and only if the driver creates and sends an ‘event’. It is then up to the platform to determine if a change in attribute value has occurred (unless forced true by the driver, as is necessary for button pushed, held, and released events). The Last Activity is always updated, I believe, as long as the driver sends the event to the platform.
I agree that it does make sense for the Last Activity field to be updated always. All developers of the drivers need to be held accountable for following the platform architecture. That means allowing the platform to process all events, and allow the built-in de-duplication to run. Hopefully this discussion will help all developers to adopt this approach. I am not certain Hubitat could modify the platform to improve upon this as not every driver even requires a parse() routine to be called. Some drivers simply query devices based on a polling mechanism, which does not result in parse() being called, but events are still created.
Thank you for the explanation, That looks better than I thought. I probably should have a look at the code before continuing the discussion but I am already looking at way more projects than I can comprehend.
With Hubitat I assume zwave requests from the device hardware are received by the hub first then delivered to the driver accoding to the device id. At that point why wouldnt the hub simply record the time instead of relying on the driver to create an event ?
That might work for Z-Wave and ZigBee devices, but possibly not other devices. I think the architecture is fine as-is, as long as developers adhere to it. I completely understand where you're coming from, though. I guess anytime the platform spins up a device's driver code, it could update the Last Activity field...but that would actually cause the opposite problem of believing a physical device was actually active when it might just be a scheduled timeout routine within the driver code (i.e. no real message from the device...) 
It's an interesting discussion, which I hope helps driver developers always send the events to the platform and allow it to make the right decisions.
2 Likes
I know zero about app/driver architecture and development. But on the face of it, it seems as if the Last Activity field should be updated anytime the driver receives something interpretable from the device.
And since it is the driver that does the interpretation, the role of updating that field should fall on the driver. From my limited experience with z-wave toolbo (and the debug function in the Hubitat driver), I have at least one Dome motion sensor that periodically sends out some packets that are not interpreted by the driver (the timing doesn't correspond to motion active/inactive), but apparently is received by the platform because it shows up in the logs.
I agree with you that it would be ideal if all developers followed the same model for key features of their drivers.
What if the user assigns a wrong driver to the device ? then you have the device activity which is not reported as the driver could not interpret it. The user may think the device is broken.
And generally: I have zero knowledge about hubitat architecture. But still many many years ( from the times of punch cards) of software designs, And my experience has been that anytime you rely on someone else to adhere to your rules you are making life harder both for yourself and for the developers who need to take extra steps in learning the details. And inevitably a new person comes and will make mistakes that could easily be avoided.
The best framework architecture is that sets up as little rule as possible. And those rules that are still have to be set must be enforced in the code.
No platform can compensate for user error. Nor should it.
1 Like
Then the device won't work anyway, so who cares what the last activity field shows?
2 Likes
I have some outlets that I don't turn on or off very regularly and as a result their "Last activity at" shows very old time stamps.
However if I look at the logs I can see that the outlet does send it's status on an hourly basis. For these outlets I use the Generic Zigbee Outlet driver
Does it make sense for the official drivers to be updating the "Last activity At" similar to how they do for battery updates since 2.2.4?
I think that if this was done in the official drivers it would be easier to find devices that have fallen off the network.
What do people think before I tag one of the staff members and make an "official" request
1 Like
