lastUpdate returns in fact lastChange value

[travnick]

Since in triggers there is a difference between update and change - it's even possible to set a trigger depending on change/update, then PersistenceExtensions.lastUpdate returns an invalid value. This value is in fact equal to what lastChange should return (but it does not exist).

Invalid value:

2022-09-29 13:22:45.459 [INFO ] [org.openhab.rule.water_volume_change] - Rtl433_consumed_water previous state:  JdbcItem [name=Rtl433_consumed_water, state=436.002, timestamp=2022-09-29T13:06:14.463+02:00[Europe/Warsaw]]
2022-09-29 13:22:45.459 [INFO ] [org.openhab.rule.water_volume_change] - Rtl433_consumed_water last update:     2022-09-29T13:06:14.463+02:00[Europe/Warsaw]
2022-09-29 13:22:45.460 [INFO ] [org.openhab.rule.water_volume_change] - Rtl433_consumed_water current state:   436.002 ㎥

It's possible to miss the issue when observing changing values

2022-09-29 13:22:45.463 [INFO ] [org.openhab.rule.water_volume_change] - Rtl433_time previous state:    JdbcItem [name=Rtl433_time, state=2022-09-29T13:22:18.000+0200, timestamp=2022-09-29T13:22:18.449+02:00[Europe/Warsaw]]
2022-09-29 13:22:45.463 [INFO ] [org.openhab.rule.water_volume_change] - Rtl433_time last update:       2022-09-29T13:22:45.432+02:00[Europe/Warsaw]
2022-09-29 13:22:45.464 [INFO ] [org.openhab.rule.water_volume_change] - Rtl433_time current state:     2022-09-29T13:22:45.000+0200
2022-09-29 13:22:45.465 [INFO ] [org.openhab.rule.water_volume_change] - 
2022-09-29 13:22:45.467 [INFO ] [org.openhab.rule.water_volume_change] - Rtl433_rssi previous state:    JdbcItem [name=Rtl433_rssi, state=-0.111423, timestamp=2022-09-29T13:22:45.436+02:00[Europe/Warsaw]]
2022-09-29 13:22:45.468 [INFO ] [org.openhab.rule.water_volume_change] - Rtl433_rssi last update:       2022-09-29T13:22:45.436+02:00[Europe/Warsaw]
2022-09-29 13:22:45.468 [INFO ] [org.openhab.rule.water_volume_change] - Rtl433_rssi current state:     -0.111423 dBm

[rkoshak]

It helps to understand what lastUpdate really does. This returns the timestamp of the most recent value stored in the database. That's it. Whether or not that makes sense in a given situation depends on how values are stored in the database. Any time you are using an everyX strategy (e.g. everyMinute) lastUpdate is probably going to be meaningless because there is no way to tell the difference between an entry made on the schedule or an entry made because the Item changed or was actively updated.

In other cases if you are using the everyUpdate strategy and the Item gets updated pretty frequently even when it's not changing, again lastUpdate is unlikely to be all that meaningful (though it might be).

Assuming that these two problems are not present, then all that lastUpdate should tell you is when the Item was last updated/changed to its current state (depending on whether you're using an everyUpdate or everyChange strategy), which is what you show.

I'm not seeing the problem here. It seems to be working as designed and documented. It's hard to interpret the second set of logs without knowing the strategy used to store values in the database, whether or not you've used the flag in the call to previous state to cause it to find the most recent value that is different from the current state or not, and whether a timing issue might be coming into play.

The value is saved to the database in parallel with the triggering of the rule. You cannot trust that the database is updated and correct when the rule is triggered. The timing may not work. This too is working as designed, or at least is a know limitation caused by the event based nature of the OH architecture.

[travnick]

I' using UI and there was not even a clue that this might behave this way (everyUpdate default strategy). There is not even notice that there are different strategies and one need to dig into documentation and configuration files to somehow prepare proper file.

Looking at documentation https://www.openhab.org/docs/configuration/persistence.html I'm not even sure what's the syntax of such configuration file, since files in /var/lib/openhab/config/org/openhab look very different.

Anyway, I guess I need some other tool to properly present data on charts.

[rkoshak]

If you have ideas where/how to make this apparent in the UI please file an issue on the webuis repo. Though, truth be told, if you want to use OH without ever referring to any docs, you're likely to be disappointed.

The fact that OH uses rrd4j by default and the default behavior is covered in the Getting Started Tutorial (note that it's everyChange, everyMinute, and restoreOnStartup, not everyUpdate). It's also covered in the docs for rrd4j as well as an explanation for how it works (and why it requires the everyMinute strategy). It is also covered in the first paragraph of the Persistence docs.

As for the syntax, the rrd4j docs has an example rrd4j.persist file. Both the Getting Started Docs and the Persistence Docs tell you where the file needs to be placed as well as two additional complete examples of a .persist file.

Persistence configuration is not supported through the UI yet so it must be configured (if the default is not suitable) using a text file which goes under $OH_CONF/persistence. Where that is depends on how you installed OH and on what operating system. On Linux that's usually /etc/openhab/persistence.

NOTE: everyMinute is required for rrd4j so if that's a problem and you can't use a work around (e.g. using perviousState to get the time of the last change) you'll need to use a different database.

[travnick]

I'm just about checking the easy of use for my PoC to choose a solution that requires as little effort as possible, so I'm playing with the UI first rather than (too much) documentation digging :)

Anyway, the conclusion of this issue is that it would be nice that the documentation of lastUpdate() says that it means a persistence update only, and highly depends on a Persistence strategy, so it's not the same update as item update (see everyUpdate explanation). In my opinion, method should be renamed to reflect its meaning: something like lastPestist()

[rkoshak]

In my opinion, method should be renamed to reflect its meaning: something like lastPestist()

I don't disagree but that would be a huge breaking change. It's been called lastUpdate() for at least a decade now. It's not so easy to make changes that breaks everyone's system.

[travnick]

So at least documentation update would be nice thing :)

Simply rename would be a hard way, it's possible to use deprecation mechanism or something. But this is not my decision, if and how it would be done.

[J-N-K]

See attached PR.