fix state initialization in case of timeSeriesUpdated and currentState == UnDefType.NULL

[lo92fr]

fix item state Initialization in case of timeSeriesUpdated and currentState == UnDefType.NULL

description

This PR is a Bugfix around item state initialization and persistence.

When you send an update to a timeseries on an item which currentState==UnDefType.NULL, the currentState stay to null even if there is a value in the timeseries before the current timestamp.

When you restart your openhab instance, the persistant layer restore the last State before current timestamp as the current state of the item. This is done in PersistenceManagerImpl.restoreItemStateIfPossible. ligne 606 to line 629.

This current behaviour is inconsistent as value before / after restarting openhab is not the same.

This PR is a proposal to set the current item state (only if it's currently null) to the last state present in timeseries that is before the current timestamp.

Like this, current item state is consistent before / after restarting openhab.

Laurent.

[mherwege]

First, please link to the related issue which has much more discussion about why you want this: https://github.com/openhab/openhab-core/issues/4662

Second, I don't think a special treatment for NULL solves anything. Take this example:

• Item initial state NULL.
• You apply a time series with last value before now equal to let's say 10.
• With your proposed change, the item state is now 10.
• You apply a new time series with last value before now equal to 20 (and the timestamp of 20 is equal or after the timestamp of 10 in your previous time series).
• Your item state is still 10.
• You stop and restart OH.
• restoreOnStartup will restore the item state to 20.

Se we are incosistent again.

As I wrote in the linked issue, loading a time series alone should not automatically set the state of the item. If you want that, you should update the state explicitly at the same time you load the time series. If you do not want this updated state to be persisted with the current timestamp, don't define a persistence strategy for the item and solely rely on the time series in persistence. You can still use restoreOnStartup for the item.

[lolodomo]

@lo92fr : did you see the feedback from @mherwege ?

[lo92fr]

Hello @all,

Yes, I see the response from mark. As it said, there is many implications on this change that would not be consistent. So please, can you close / cancel this pull request

Laurent.