[profiles] timestamp-update channel profile forces Item state

[Rossko57]

Example Item, using channel profile timestamp-update -

DateTime testTime "testing" {channel="openweathermap:weather-and-forecast:api:foss:current#condition" [profile="timestamp-update"]}

Expectation - when that channel updates, the Item state will be updated with a timestamp. That works well enough -

2020-07-01 19:01:56.453 [vent.ItemStateChangedEvent] - testTime changed from 2020-07-01T17:41:27.007+0100 to 2020-07-01T19:01:56.368+0100`

But, postUpdating the Item with some other value somehow causes the profile to immediately overwrite the state with a completely new value of "now"

2020-07-01 19:35:22.903 [vent.ItemStateChangedEvent] - testTime changed from 2020-07-01T19:01:56.368+0100 to 2011-01-01T10:10:10.000+0000
2020-07-01 19:35:22.934 [vent.ItemStateChangedEvent] - testTime changed from 2011-01-01T10:10:10.000+0000 to 2020-07-01T19:35:22.910+0100

Expectation here is that profile does nothing until the next real update of the associated channel. It should not destroy any manually set value of the Item. It certainly should not "invent" a new timestamp unrelated to its channel activity.

A nastier consequence; it is reasonable to link more than one channel with timestamp profile to a single Item, say to record the most recent event for any one of a set of sensors.

DateTime testTime {channel="x:x:x:x" [profile="timestamp-update"], channel="z:z:z:z" [profile="timestamp-update"]}

This results in disaster, the two profiles enter a loop of warring updates every few milliseconds

2020-07-01 19:47:25.926 [.ItemChannelLinkAddedEvent] - Link 'testTime-openweathermap:weather-and-forecast:api:foss:current#condition-id' has been added.
2020-07-01 19:47:25.940 [vent.ItemStateChangedEvent] - testTime changed from 2020-07-01T19:44:47.686+0100 to 2020-07-01T19:47:25.924+0100
2020-07-01 19:47:25.950 [vent.ItemStateChangedEvent] - testTime changed from 2020-07-01T19:47:25.924+0100 to 2020-07-01T19:47:25.934+0100
2020-07-01 19:47:25.957 [vent.ItemStateChangedEvent] - testTime changed from 2020-07-01T19:47:25.934+0100 to 2020-07-01T19:47:25.949+0100
2020-07-01 19:47:25.966 [vent.ItemStateChangedEvent] - testTime changed from 2020-07-01T19:47:25.949+0100 to 2020-07-01T19:47:25.958+0100
2020-07-01 19:47:25.975 [vent.ItemStateChangedEvent] - testTime changed from 2020-07-01T19:47:25.958+0100 to 2020-07-01T19:47:25.965+0100

This presumably also affects timestamp-change, and potentially other profiles.

[candiesdoodle]

hello
is there any chance of looking into this issue, or is it by design? I also ran into this while i was trying to reset the value of a timestam-change item via a rule. It would just re-rest to the current time withount any update from the channel.
Pls, if you could look into this, that'd be great!

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/update-datetime-as-thing-receives-data/117367/6

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/timestamps-not-rendering-consistently-in-ui-3-0-2/121891/2

[Rossko57]

See https://community.openhab.org/t/timestamps-not-rendering-consistently-in-ui-3-0-2/121891/13

It seems this may be fixed by 3.0.2 or (less likely) only occurs with some channels.

[brianwarner]

@Rossko57 I'll run a manual backup and see if I can trigger the issue again later today or tonight.

[brianwarner]

Looks like the issue is still there.

I linked two Channels to the same Item with the "Timestamp on change" profile, and the log was filled with updates and the system basically ground to a halt. Deleting one of the links brought it back to normal. The log messages are formatting errors, but I can see the Timestamp is iterating every few milliseconds, so I'd assume the formatting errors are related to #2037 and are a coincidence.

Hope this helps!

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/oh3-no-offset-profile/120044/21

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/datetime-item-with-lastupdate-profile-doesnt-take-state-descriptions-and-i-get-some-interesting-log-messages/122025/2

[cweitkamp]

This is exactly the intended behavior of the timestamp-change and timestamp-update profiles. Even if I agree that there is some space for improvement to fix your issue.

From the JavaDoc of the classes

openhab-core/bundles/org.openhab.core.thing/src/main/java/org/openhab/core/thing/internal/profiles/TimestampChangeProfile.java

Lines 26 to 27 in aa48f59

	* This is the default implementation for a change timestamp profile.
	* The timestamp updates to now each time the channel or item state changes.

and

openhab-core/bundles/org.openhab.core.thing/src/main/java/org/openhab/core/thing/internal/profiles/TimestampUpdateProfile.java

Lines 27 to 28 in aa48f59

	* This is the default implementation for a state update timestamp profile.
	* The timestamp updates to now each time the channel or item state is updated.

you can see the implemented behavior. But the documentation tells us slightly different behavior.

timestamp-change:

This Profile will update a DateTime Item to track every change of the state of a given Channel.

timestap-update:

This Profile will update a DateTime Item to track every update of the state of a given Channel, whatever the state is.

I can offer to add a configuration to ignore updates from Items. This will keep the original behavior but adds a way to solve your issue.

[brianwarner]

@cweitkamp if it helps, I've only noticed an issue with having multiple Links with openweathermap. For Z-Wave devices, linking multiple timestamp-change and timestamp-update profiles to the same item works fine (setting aside the format error thing).

I wonder if there's something specific to the openweathermap binding that's causing it to update so frequently when multiple channels are linked?

[cweitkamp]

@brianwarner Thanks for helping. I cannot tell you if there are specific differences in both add-ons.

I submitted #2353 to solve this issue.

[Rossko57]

Why would anyone want a profile that updates an Item state when the same Item state is updated?
Maybe it's a partial or undocumented feature intended to update timestamp when some other Item updates. But then there's no way to usefully use that, because there is no channel to hang the profile onto when two Items are involved.

But yes please, let's have it behaving as per user docs and doing timestamps in response to channel activity (only).

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/how-to-get-notified-about-offline-non-communicating-z-wave-sensors/124281/12

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/profile-timestamps-not-updating/128080/4

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/datetime-format-with-oh3-items-not-working/130130/22