Last Activity not updating

🛎️ Get Help
1

Hi,

I have a few devices that does not appear to be updating the "Last Activity" correctly if I understand last activity correctly. I have reports in the logs of communications with the devices but the last activity date does not update. All devices are working great when commanded. Only until I actually use the device will it update, is this how it it supposed to be? Doesn't sound right, if the hub is communicating with the device then it should be active right?

Here is one example, Its a Sonoff Zigbee plug using the generic Zigbee outlet driver, its constantly communicating with the hub but the last activity does reflect it.

Plug refresh
Plug refresh978×461 35 KB

Plugs Activity

Here is another, my Presence Sensor, a Smarthings V4, is always checking in with the hub but the activity does not reflect.

Prescence Device
Prescence Device1171×467 37.6 KB

Presence
Presence885×62 14.7 KB

My zooz switches Zen23 experience the same behavior. I've done some reading on here but there doesn't seem to be a clear answer. So everything works as it should just the last activity does not get updated. Should it?

2

Just to update this, I originally asked this question over in the Device Watchdog thread wondering how the refresh option worked in his App., he pointed out that not all drivers support Last Activity in this way. Another kind gentlemen also pointed out that Stock HE drivers don't do this, as well as the Generic Zigbee Outlet. Having read though many posts regarding this the answer wasn't that clear to me, but it is now. So if any of you folks experience the same behavior this is why.

3

I'm in the process of writing a driver for an automated valve. I am not a programmer so I end up learning by trying.
I mention this because I recently found that updating a state variable is not enough to cause an update of the Last Activity at.
I had to create a dummy Attribute and cause it to change for the Last Activity to be updated.

4

The Hubitat architecture would normally be to always update the attributes when new data comes in, even if the value has not changed. This allows the ‘platform’ to perform the deduplication routine, which prevents creating a new ‘event’. However, the Last Activity field does get updated.

This is why I believe drivers should not try to filter events. I always let the platform handle that task.

6 Likes
5

Good to know. However now I'm confused.

Goal: My valve controller does not send anything to the hub unless you tell it to do something (mostly to open or to close).

To allow me to have a comfort level that the controller is still connected I send out a BasicGet.
I don't want to exercise the valve mechanism, just get the controller to respond so I know its connected and still alive.

When I send the BasicGet, the controller returns the BasicReport, telling us the valve is open.
Receiving this does not update the "Last Activity at" shown on the device page.
From how I read your post, it should.

However if I add code to update an attribute, the "Last Activity as" is updated.

So I must be missing something. I'll do more testing.

Thanks.

My Parse Method:

def parse(String description) {
log.trace " incoming message (description): $description"
def cmd = zwave.parse(description)
    log.trace "(parse) $cmd"
    if (cmd) {
            return zwaveEvent(cmd)
    }
    log.debug "Could not parse message"
	    return null
} // --- parse ---
6

What does the output of the above log.trace statement look like?

7

It would be good if that was really the case, but I found that to not be the case even for some of the Hubitat drivers.
I came across this issue with a few drivers and also either the Generic Zigbee outlet or Generic zigbee switch. I even had one of the staff members tagged in it, but after initial interaction I couldn't get them to note that it is a problem.

Hopefully now that there's a new thread and more people are noticing the issue it will get staff attention and be fixed eventually

8

My understanding, which may be wrong of course but is based on some previous discussions with @mike.maxwell, is that the Last Activity field is only updated if an event is committed.

For an event to be committed, the data needs to have changed (else it is filtered out by the platform), or the event needs to have been sent with a forced isStateChange (for example to always send a button event even if it's the same value), or if an App exists that subscribes to the attribute with filterEvents set to false (which forces all events to be committed even if the data hasn't changed).

I think some changes have been mooted at some point to change the behaviour of Last Activity to always update based on ANY data received from the device ..... but I guess it's a low priority.

In the meantime Last Activity should probably be thought more of as "Last Event" from the device.

9

actually now that I'm reading your message closer, to fix the issue for the Generic Zigbee Outlet swap to the Generic Zigbee Switch and that will fix the last activity at

10

The output is/was: (parse) BasicReport(value:0, targetValue:0, duration:0)

However my testing showed that "BasicReport" does not update "Last Activity at"
But switchBinary does update "Last Active at"

switchBinaryV1.switchBinaryGet()

Apparently the hub doesn't thing BasicReport is eventful (pardon the pun)

John

1 Like
11

My testing performed today:

  1. My device is a water valve. BasicV1 and switchBinaryV1 are supported.
  2. none of my test included any changes in the valve state. Was always OPEN

Results:

  1. BasicV1 Report DID NOT update "Last Activity at"
  2. switchBinaryV1Report DID update "Last Activity at" even though the valve state did not change.
  3. None of my code includes the "isStateChange" option.
12

That's interesting, did an event get created on the Events page?

13

Oddly enough no events were entered to the devices event log as a result of switchBinaryV1 nor BasicV1.

Here are the results of my three tests:

  1. BasicV1 "no update to "Last Activity as" Event entry = no
  2. switchBinaryV1 updates "Last Activity as" Event entry = no
  3. custom attribute updates "Last Activity as" on change Event entry = yes
14

If an attribute is updated in a driver via a sendEvent() command, even if the value does not change, the lastActivity field will be updated. This is true even if “isStateChanged” is not supplied as a parameter in the sendEvent() call.

My HubDuino devices send updates to the hub even if the values haven’t changed, just to make certain that the hub is kept up to date (e.g. if the hub was powered down when a real change occurred.) As a result, my drivers make sendEvent() calls routinely, and their lastActivity is kept up to date.

15

The below suggests that not every event will update the "Last Activity At"

The basicV1 message:

void connectCheck(){
   sendToDevice(zwave.basicV1.basicGet().format())
}

results in: and NO change in "Last Activity at"

image
image951×105 4.86 KB

The switchBinaryV1 message:

void connectCheck(){
    sendToDevice(zwave.switchBinaryV1.switchBinaryGet().format())
}

results in: update of "Last Activity At"

image
image980×120 5.69 KB

If valve is closed the switchBinaryV1 logs are:

image
image971×75 5.53 KB

16

I don’t develop Z-wave drivers, so I don’t know what’s going on inside those calls. I do know that if you were to issue a sendEvent() call, for an existing attribute, the lastActivity field will be updated...even if the value is unchanged.

sendEvent(name: "valve", value: "open")

will cause the lastActivity to be updated, even if the current value of the “valve” attribute is “open”.

17

That has been my experience as well. I don't develop drivers either, just hacking this one together with the community help.

But before I realized the difference in Hub reaction between Basic and switchBinary I added a dummy attribute. As you said it would update the "last activity at".

I'll have to look at the

sendEvent(name: "valve", value: "open")

to learn how that constructions works. There is a lot of "object" items I've not sorted out in my head. I still hoping some day I'll have an epiphany :slight_smile:

18

Or an aneurysm. :exploding_head:

1 Like
19

Don't you need to include the isStateChange option in the sendEvent call or for an app to subscribe to changes in the attribute? Like @martyn relayed from a discussion with Mike earlier in this thread:

Simon

20

This is good reading, there appears to be some confusion as to how this actually works and what the expected result is. So far my take away is that it is a driver dependent function and not even all HE own drivers are coded the same it seems.