Design Pattern: Time of Last Update

[JHC (Jens)]

You mean, you want to know when one of a Group of Items last updated?

No, I didn’t need it as an Openhab Group.

I have things with multiple items / channels and would like a last update at the thing level.
Wildcard would be a second option, based on the example above:

DateTime Pumprum_LastUpdate
    "Pumprum [%1$tF %1$tR]"  <battery> (gTimestamps)
    {channel="mqtt:topic:mybroker:pumprum:*" [profile="timestamp-update"]}

It is possible to add several channels to one timestamp Item, each configured with a timestamp profile as per the original post.

That would be enough for me. How can I link more than one channel?
Simply connect with a comma?

[rossko57]

@JHC

I have things with multiple items / channels and would like a last update at the thing level.

That would be a task of the binding then. you can always request an enhancement to add a last-update state channel, or any-update event channel.

@JHC

How can I link more than one channel?
Simply connect with a comma?

Yes, this is in the docs.

DateTime general_LastUpdate "Pumprum [%1$tF %1$tR]"  
    {channel="aa:bb:cc" [profile="timestamp-update"], channel="xx:yy:zz" [profile="timestamp-update"]}

@JHC

No, I didn’t need it as an Openhab Group .

It’s not about needing it, it’s about using it as a tool to achieve what you wanted, in a scalable and easily managed way
You can also choose if you want to record changes or updates.

Group mySensors // group for timestamp function

DateTime lastSensorUpdate  "Update of any sensor"

Switch someSensor "blah" (mySensors) {channel="xx:yy:zz"}
Switch otherSensor "bleh" (mySensors) {channel="aa:bb:cc"}

rule "timestamping"
when
   Member of mySensors received update
//   Member of mySensors changed - alternative
then
   lastSensorUpdate.postUpdate(new DateTimeType()) // defaults to now
end

[JHC (Jens)]

DateTime general_LastUpdate "Pumprum [%1$tF %1$tR]"  
    {channel="aa:bb:cc" [profile="timestamp-update"], channel="xx:yy:zz" [profile="timestamp-update"]}

With one parameter, it works as expected. As soon as I add a second or third, I have hundreds of update lines in the log …

Update: Seems to be the problem of the binding, with others it works without problems.

[rossko57]

Bindings are allowed to make lots of updates. Why do you think it is some problem?

I’ve already shown how to trap changes instead of updates, if that helps your situation.

[JHC (Jens)]

The sensor only reports every 15-x minutes … Nevertheless, I have hundreds of log entries for some channels per second. No matter whether update or change.

[rossko57]

If you want help with that, you might give some details.

[JHC (Jens)]

I have the following problems - tested with avmfritz and the mihome binding:
The connected sensors / actuators only connect when necessary or less frequently if no data is changed.

Example items:

Number   Sensor_Temperature "Temperatur [%.1f °C]"          <temperature> 
         (gRoom,gEGTemp) { channel="a:b:c:d:temperature" }
Number   Sensor_Humidity    "Luftfeuchtigkeit [%d %%]"      <humidity>    
         (gRoom,gEGHumi) { channel="a:b:c:d:humidity" }
Number   Sensor_Battery     "Battery MiHT"                  <battery>     
         (gRoom,gEGBatt) { channel="a:b:c:d:batteryLevel" }
DateTimeSensor_LastUpdate  "[%1$tY-%1$tm-%1$td  %1$tH:%1$tM]" <clock>       
         (gRoom)         { channel="a:b:c:d:temperature" [profile="timestamp-update"] } 

Log:

2020-07-01 13:21:56.275 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from NULL to 2020-07-01T12:59:27.605+0000
2020-07-01 13:21:56.280 [.ItemChannelLinkAddedEvent] - Link 'Sensor_LastUpdate-a:b:c:d:temperature' has been added.
2020-07-01 13:23:05.511 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T12:59:27.605+0000 to 2020-07-01T13:23:05.507+0000
2020-07-01 13:23:05.511 [vent.ItemStateChangedEvent] - Sensor_Temperature changed from 25.47 to 25.5
2020-07-01 13:23:05.523 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:23:05.507+0000 to 2020-07-01T13:23:05.519+0000

Now I try to use more than one trigger for the LastUpdate:

DateTime Sensor_LastUpdate  "[%1$tY-%1$tm-%1$td  %1$tH:%1$tM]" <clock>       
         (gRoom)         { channel="a:b:c:d:humidity" [profile="timestamp-update"], channel="a:b:c:d:battery" [profile="timestamp-update"], channel="a:b:c:d:temperature" [profile="timestamp-update"] } 

Mihome Binding: With the first update, my log is bombarded with thousands of entries …

2020-07-01 13:30:55.015 [.ItemChannelLinkAddedEvent] - Link 'Sensor_LastUpdate-a:b:c:d:temperature' has been added.
2020-07-01 13:30:55.016 [.ItemChannelLinkAddedEvent] - Link 'Sensor_LastUpdate-a:b:c:d:humidity' has been added.
2020-07-01 13:30:55.018 [.ItemChannelLinkAddedEvent] - Link 'Sensor_LastUpdate-a:b:c:d:batteryLevel' has been added.

2020-07-01 13:31:00.528 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:29:02.969+0000 to 2020-07-01T13:31:00.506+0000
2020-07-01 13:31:00.572 [vent.ItemStateChangedEvent] - Sensor_Temperature changed from 25.5 to 25.48
2020-07-01 13:31:00.582 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.506+0000 to 2020-07-01T13:31:00.520+0000
2020-07-01 13:31:00.603 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.520+0000 to 2020-07-01T13:31:00.521+0000
2020-07-01 13:31:00.623 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.521+0000 to 2020-07-01T13:31:00.522+0000
2020-07-01 13:31:00.642 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.522+0000 to 2020-07-01T13:31:00.528+0000
2020-07-01 13:31:00.645 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.528+0000 to 2020-07-01T13:31:00.540+0000
2020-07-01 13:31:00.666 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.540+0000 to 2020-07-01T13:31:00.547+0000
2020-07-01 13:31:00.683 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.547+0000 to 2020-07-01T13:31:00.553+0000
2020-07-01 13:31:00.702 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.553+0000 to 2020-07-01T13:31:00.562+0000
2020-07-01 13:31:00.705 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.562+0000 to 2020-07-01T13:31:00.571+0000
2020-07-01 13:31:00.731 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.571+0000 to 2020-07-01T13:31:00.596+0000
2020-07-01 13:31:00.733 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.596+0000 to 2020-07-01T13:31:00.603+0000
2020-07-01 13:31:00.758 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.603+0000 to 2020-07-01T13:31:00.617+0000
2020-07-01 13:31:00.774 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.617+0000 to 2020-07-01T13:31:00.623+0000
2020-07-01 13:31:00.787 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.623+0000 to 2020-07-01T13:31:00.636+0000
2020-07-01 13:31:00.800 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.636+0000 to 2020-07-01T13:31:00.642+0000
2020-07-01 13:31:00.813 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.642+0000 to 2020-07-01T13:31:00.660+0000
2020-07-01 13:31:00.815 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.660+0000 to 2020-07-01T13:31:00.666+0000
2020-07-01 13:31:00.837 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.666+0000 to 2020-07-01T13:31:00.683+0000
2020-07-01 13:31:00.857 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.683+0000 to 2020-07-01T13:31:00.703+0000
2020-07-01 13:31:00.875 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.703+0000 to 2020-07-01T13:31:00.723+0000
2020-07-01 13:31:00.911 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.723+0000 to 2020-07-01T13:31:00.731+0000
2020-07-01 13:31:00.928 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.731+0000 to 2020-07-01T13:31:00.751+0000
2020-07-01 13:31:00.929 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.751+0000 to 2020-07-01T13:31:00.758+0000
2020-07-01 13:31:00.958 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.758+0000 to 2020-07-01T13:31:00.774+0000
2020-07-01 13:31:00.966 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.774+0000 to 2020-07-01T13:31:00.786+0000
2020-07-01 13:31:00.973 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.786+0000 to 2020-07-01T13:31:00.800+0000
2020-07-01 13:31:00.981 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.800+0000 to 2020-07-01T13:31:00.813+0000
2020-07-01 13:31:00.989 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.813+0000 to 2020-07-01T13:31:00.830+0000
2020-07-01 13:31:00.996 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.830+0000 to 2020-07-01T13:31:00.837+0000
2020-07-01 13:31:01.003 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.837+0000 to 2020-07-01T13:31:00.856+0000
2020-07-01 13:31:01.010 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:31:00.856+0000 to 2020-07-01T13:31:00.875+0000

AVMFritz! Binding: Here the flooding of the log file starts directly with the saving of the item configuration.

2020-07-01 13:51:08.166 [.ItemChannelLinkAddedEvent] - Link 'Sensor_LastUpdate-a:b:c:d:temperature' has been added.
2020-07-01 13:51:08.167 [.ItemChannelLinkAddedEvent] - Link 'Sensor_LastUpdate-a:b:c:d:radiator_mode' has been added.
2020-07-01 13:51:08.167 [.ItemChannelLinkAddedEvent] - Link 'Sensor_LastUpdate-a:b:c:d:battery_level' has been added.
2020-07-01 13:51:08.738 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T10:12:18.237+0000 to 2020-07-01T13:51:08.700+0000
2020-07-01 13:51:08.757 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:51:08.700+0000 to 2020-07-01T13:51:08.702+0000
2020-07-01 13:51:08.767 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:51:08.702+0000 to 2020-07-01T13:51:08.712+0000
2020-07-01 13:51:08.776 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:51:08.712+0000 to 2020-07-01T13:51:08.729+0000
2020-07-01 13:51:08.786 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:51:08.729+0000 to 2020-07-01T13:51:08.738+0000
2020-07-01 13:51:08.795 [vent.ItemStateChangedEvent] - Sensor_LastUpdate changed from 2020-07-01T13:51:08.738+0000 to 2020-07-01T13:51:08.748+0000

Did I chain the channels incorrectly? Or does the function not work?
Update or change makes no difference.

I’m using the official Openhab docker Version 2.5.6 (Build 1st July 2020).

[rossko57]

Simplify your problem to begin with. Reduce your timestamp Item to just one of the secret channels.

DateTime Sensor_LastUpdate  "[%1$tY-%1$tm-%1$td  %1$tH:%1$tM]" { channel="a:b:c:d:humidity" [profile="timestamp-update"] }

It’s really unlikely, but not impossible, for the mystery binding to be issuing lots of updates. They don’t get logged normally, unless a change is caused.
You can check for unlogged updates with a rule -

rule "update diag"
when
   Item Sensor_Humidity received update // should be linked same channel
then
   logInfo("diag", "update for " + triggeringItem.name)
end

although it does sound like some curious feedback effect, let’s make sure what is going on.
Channels are bi-directional, the binding can listen for state updates of the Item. Most don’t (listening only for commands) but there are exceptions. Or the profile itself might react to state updates incorrectly.

EDIT - yep, profile is the culprit. More experimenting to do, but it appears the profile tries to force the Item state to what it wants continuously. i.e. if you postUpdate the Item, it will immediately set it back to last channel update.
With two channels/profiles, they begin an endless war …

I will create a bug report when I’ve found the simplest example.

[JHC (Jens)]

@rossko57 Thanks for your effort, I can only wait and see, right? Or go back to my old update rules.

[rossko57]

timestamp profile is currently broken for multiple channel use.
As they’re not doing any further changes to openHAB core, expect no fix for OH2.x
Use rule based techniques for now.

[profiles] timestamp-update channel profile forces Item state

[aspork42 (James O'Gorman)]

I just implemented this for some battery sensors. I’m using the design pattern and tying it to one of the five things reported by the sensor (in the case; battery level). Then, I go into Paper UI and link the other four channels to the ‘[…]_lastUpdate’ item I created in the .items file. Now I have a master “last updated” which is tied to all the five things reported by the sensor.

[patrik_gfeller]

@martin1

The DateTime item uses the same channel as the original item, but with the addition of the [profile… ] part. The profile can be either timestamp-update or timestamp-change.

I would like to use the “timestamp-change” profile in OH3 with MainUI, but can not select the profile:

Is this wrong place to look or is this not possible with MainUI.

[rossko57]

You have to go about it the other way.
Create your free-standing DateTime Item first, then link that to the channel.

[patrik_gfeller]

Thank you - this worked.

[airmax (Andreas)]

My motion sensor reports to a contact item. Can I have the last OPEN state with this design pattern? I guess I cannot use timestamp-update, as the motion sensor sends it’s state in regular intervals, even without change.

[trumee]

I am trying to use this design pattern for my sensor battery similar to OP. The channel is linked to the item (Battery_LastUpdate) as shown below,

You would notice that the item shows an ‘Err’ above and also does the same in Model. I dont understand this since in ‘Items’ it shows the correct date,

The item is defined like so,

[ubeaut (Greg)]

Maybe this may help?

Showing timestamp of item value update in a mainUI card?

Create a secondary item like JustinG said: [image] Select Timestamp on update or Timestamp on change. Also if you want the time to be displayed for example like this: 2021-05-31 08:17:45 Go to the item and then add metadata: [image] Add the state description: and put this in for example: %1$tY-%1$tm-%1$td %1$tH:%1$tM:%1tS [image] Then in the main UI card the code to display the formatted date for example is: =items.Doorgarage_Doorgaragelastupdate.displayState [image] [image] It wi…

[trumee]

Thanks, that did the trick.

[ubeaut (Greg)]

It is much easier with picture examples that you can adapt.
Glad it worked for you. Thanks for the like!