Design Pattern: Time of Last Update

Really Cool thing! Thanks a lot!

Is it work on 2.5M5.

Trying to use it in this way

Contact   DoorEntrance 
    "Door Entrance Contact [%s]" 

DateTime  DoorEntranceLastChange 
    "Door Entrance Last Change [%1$td.%1$tm.%1$tY %1$tH:%1$tM:%1$tS]" 
    {mqtt="<[mosquitto:zigbee2mqtt/0x00158d00044b228e:state:JS(getZigbeeContact.js)]" [profile="timestamp-update"]}

But it do not updates item(((

This is error i get

2019-12-05 18:58:25.600 [WARN ] [] - given new state is NULL, couldn't post update for 'DoorEntranceLastChange'

Profiles work with channels. You have no channel. Profiles do not work with 1.x binding version.

One more reason to migrate to mqtt 2 )))

Any idea when this was introduced? I’m on 2.5M1 and this doesn’t seem to work…

Doesn’t sound right to me. The “latest” release is 2.4. 2.5 is not released (so it cannot be latest by definition), and Milestones are not releases.

So “latest” would be 2.4. When 2.5 is released, ‘latest’ would be 2.5. Until then you have no way of telling what ‘latest’ means. could be 2.5M1, M2, M6 who knows?

Labeling things “latest” or “new” is meaningless, everyone interprets this differently. the only way to be clear would be to use an explicit value (like 2.5M6). of course the question then would be if 2.5M6 is a release, is 2.5M1 as well? and if so why is it not in the list?

Anyone know when this was introduced? 2.5M1? M6? it’s not helpful unless this information is included somewhere.

Functionality, line 4


So the answer is this functionality was introduced in 2.5M2 and above.

Sorry, but it’s not my idea. Read again what i wrote please. If you look at doc, there is a switch, where Latest means - Latest testing bulid. If you switch to 2.4 ther is no timestamp-update so it was introduced in 2.5.

Thank you for this function and pattern.

Is there a way to trigger this at thing level? Or to consider several items?

Background: I have sensors with multiple channels that report very rarely and always only transmit the changed value.

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

It is possible to add several channels to one timestamp Item, each configured with a timestamp profile as per the original post. But it’s likely to become unwieldy when you get past two or three.

I’d be inclined to gather your Items into a Group, trigger a rule from Member of group, changed or updated as you wish.

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?

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.

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"]}

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"
   Member of mySensors received update
//   Member of mySensors changed - alternative
   lastSensorUpdate.postUpdate(new DateTimeType()) // defaults to now
1 Like
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.

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.

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.

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

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"] } 


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).

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"
   Item Sensor_Humidity received update // should be linked same channel
   logInfo("diag", "update for " +

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.

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

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.

1 Like