It isn't 100% up to the platform, it also depends on the driver.
There are a number of in-box drivers that do not update activity time on ALL incoming events. The Ring Alarm Range Extender driver is another example. On mine activity hasn't changed since 12/14, but I'm pretty sure battery update events have been coming in since then...
Example, just did a REFRESH on this Ring Extender.
Hub log shows a message definitely came in from the device:
But Activity time didn't update (and, yes, I refreshed the page before taking the screenshot):
Should it have updated? Probably. Why didn't it? Don't know. Not sure I've ever seen it documented what specific driver activities cause that field to update (?). Maybe @bcopeland or @mike.maxwell know, but I don't.
That's what I assumed, thus my comment that it isn't up to the platform alone when last activity time is updated.
I will say that filtering out things that are likely to be redundant long term (like battery) does make the last activity time pretty useless in those devices.
Then there are other in-box drivers like the Ecolink Firefighter that go the opposite way and make the battery reports a state change every update. I prefer this for battery updates, actually, as some devices will stay at the same level for months.
The Ecolink firefighter below has been in service >12 months - still 100% on battery report. If it didn't report as state change, I don't know how far I would have to go back to see a battery status.
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.
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.
Good standard/decision in my opinion.
No biggie.. I know it needs to be addressed now. 
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.
