Please Expose %lastActivity% Device Property

[Busthead]

It would useful to be able to reference Last Activity via %lastActivity% for Devices.

I saw and read the following posts but they are dashboard focused:

Attribute Template Selection for Last Activity

It would be nice if the Attribute Template could add access to the "Last Activity" attribute of the given driver. It already has "Last Update" available (for what reason someone would like to know the last update of the driver on their dashboard I don't know). However, Last Activity (which would indicate the last time a battery operated device updated it's status) would be very useful.

Dashboard for last activity

Here is a screenshot of my motion dashboard. I built it to track the last used mainly to help catch false reports (spot the detectors that need their sensitivity tweaked). [image] Here is the rule: [image] Create local variables to store the data and create connectors to use in the dashboard: [image] As of this writing there is a bug in 2.2.4 where only global variables are updating the dashboard, and not local - this being specific to number variables. A global number variable will upda…

[FriedCheese2006]

You, more or less, can already do that with a local variable.

[Busthead]

The example rule I provided was intended to test if the %lastActivity% and %lastUpdated% Device properties were already available and not indicative of my intended use.

[FriedCheese2006]

Then what is your intended use?

[Busthead]

I am requesting the use %lastActivity% in a Log or Notification from any App, not just Rules triggering on a Device change.

For example, the Notifications App Battery Level Text Notification.

My existing Notification contains %device% and %value%. I would like to add %lastActivity%.

[bravenel]

I will look into this.

[FriedCheese2006]

Everything is event based though. Inherently, the last activity time for the event you're monitoring would be the event time. %time% is already available for event time. That event time will be the last activity time...in that moment at least. For example, the notifications app for battery level goes like this:

1. Device sends battery report event.
2. Notification App instance is subscribed to that event as the trigger. The device report triggers the rule.
3. Notification is pushed.

This all happens in fractions of a second. So %time% would be equal (with a fraction second margin of error) to Last Activity. I suppose you could have issues if you have a rule trigger for device A and you wanted to see last activity for device B, but that's a different ball of wax.

[ogiewon]

@FriedCheese2006

Inherently, the last activity time for the event you're monitoring would be the event time. %time% is already available for event time.

Not always... "Last Activity" should be the last time the device's parse() routine was called (at least IMHO ) Just calling parse() does NOT always result in a new Event being generated. Without a new Event, Rule Machine and any other subscribed Apps will not be called.

So, if a device transmits its status periodically, whether or not the status has changed, then the Last Activity of that device 'should' be updated, IMHO. Only new status values, however, will result in a new Event being generated. The Hubitat Platform typically performs this deduplication, unless specified otherwise by the driver's programmer. Some devices, like Buttons, need an event generated every time there is a status update, as the user might push the same button number multiple times in a row.

[bravenel]

@ogiewon

Not always... "Last Activity" should be the last time the device's parse() routine was called

But with respect to the OP's request, where a notification is going to be sent, that's going to happen in response to an event on this device, so that will be it's Last Activity, as @FriedCheese2006 points out. Both RM and Notifier only send notifications for the last triggering device, not any other device. So there will only be milliseconds of difference between %time% and %lastActivity%, and hence this as a feature makes no sense.

In a custom app there are certainly situations where looking at lastActivity for some other device makes perfect sense.

[Busthead]

Understood, thank you.