I ll just do it here for now.
I have some multifunction zwave sensors that also report temperature. Apparently hubitat hub discards temperature reports that show the same temperature as the last one (i totally disagree with this but whatever) if you click on triple dot on the device in a dashboard and then history it often shows that the device did not report in a long time and only going to logs you see that the device is actually working properly. Quite confusing.
By default, Hubitat's Architecture is to only generate new events when data/status has changed from the previous event. Thus, it sounds like everything is working as designed. There is a way to force the creation of new events every time data is received from a device, however this also increases database writes with duplicate data, and it will cause any Apps that are subscribed to those events to wake up and process the 'event'. This can have unforeseen consequences. To force an event to be created for every device status update, one does have to run their own customer driver, as a code change is required.
4 Likes
You are probably right that changing the behavior now is too late as many existing setups's behavior could change. However the initial design is questinable. Hub+driver decide whether the consumer is interested in a hardware event, which is funadamentally incorrect and causes some applications behave abnormally. Device Watchdog for example reports a device as stale when in fact it is online. In fact it makes it impossible to correctly monitor a device.
This is Z-Link water sensor with the stock Zlink Water Leak and Temperature Sensor driver. See the Logs are updated every minute but since the temperature did not change Device Watchog misreports the last activity.
Very interesting... Tagging @bptworld as he is the developer of Device Watchdog. He may have some clues as to what might be going on...
At the bottom of each device page, you can find the 'Last Activity At'. This is where DW gets the data from. It's up to each device driver to determine when this gets updated, not DW.
3 Likes
I would leave out Device Watchdog as it is just an external application that operates on the data that is available. However I do not think that delegating the last activity functionality to the device driver is a sound decision. How is it supposed to remember its state ? How to make the behaviour consistent among all possible devices ? It is all trivial on the hub level but messy and error prone on the individual device level.
Obviously you are entitled to your opinion, and should definitely make a feature request for things you want.
That said, I disagree with you. The driver is the only sane place to do it. The hub can't possibly know what is a real/good update unless the driver processes the event and registers it.
Not every update is an activity, and the hub has no way of knowing that across hundreds of device types. That's where the handling behavior in the driver comes into play, as it knows what each message from the device means.
8 Likes
Mind sharing which device you have?
I have some multifunction devices and my results vary, but I also agree with others that it makes sense to me that the Driver/Hardware vendor is defining meaningful events.
Of course every update is activity ! Not every activity is update. No matter how you formulate this the current design makes is impossible to reliably monitor the devices.
We'll agree to disagree.
I think it was clear in what I said that it is my opinion that not every update is a meaningful update that should increment the activity timestamp.
Your opinion is obviously different. And that's fine.
2 Likes
This truly is how the Hubitat system is architected. As you can see in the below screenshots, I have a garage door that has not been opened since yesterday...
Here are the latest EVENTS, the last of which was yesterday.
Yet, here is the device details page that shows the Last Activity field being updated today. This is because this device sends an update even though nothing has changed to ensure the hub always has recent data.
In this case, the driver for this device creates an event and allows the hub to decide whether or not the 'event' is new or not. If the value hasn't changed, NO new event is written to the database and apps that are subscribed are NOT notified. However, the Last Activity field is still properly updated.
This is how the platform was architected and should be used, IMHO. Unfortunately, not all driver developers adhere to this approach.
If the "Zlink Water Leak and Temperature Sensor" driver you're using was written by Hubitat, then either @mike.maxwell or @bcopeland probably wrote that driver. Perhaps they could take a quick look to see if they are checking to see of the attribute changed, rather then letting the platform make that decision? If so, the fix should be fairly easy for them to implement.
4 Likes
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.
In drivers I write, I filter out duplicate events
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.
2 Likes
Yea.. TBH.. Hadn’t thought about it until this thread
It's not a huge deal to me. Just an observation.
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.
This was actually part of the 2.2.4 Release:
1 Like
Except where it doesn't - like the Ring Range Extender driver. 
1 Like
Sounds like a bug...
