Understanding "selfmade" timeseries: states not changing for future persisted states

Setup, Configuration and Use Scripts & Rules
1

running OH5.0.1 on docker

I’d like to understand, if I’m pertaining an item myself (meaning it’s not connected to a binding), which I feed some input like so:

      items.getItem("EMS_TibberPreisInterval").persistence.persist(futureTimestamp, "3");

I was under the impression, that if said “futureTimestamp” was reached, the item would automatically change the state to that value (here: 3)?
The corresponding chart looks like this:

image
image953×805 31.6 KB

but the item itself still has some state given to it (via postUpdate without the persist-stuff) a long time ago? It still has the value 5 despite having the chart telling me it should have 3…

Do I need to configure something or doesn’t it work that way?

2

currently I’m running a rule, which regularly updates the state at the start of an interval (luckily the interval is known beforehand: every 15 minutes - dynamic spot prices). But is there something I could do, so a non-thing timeseries-item will update itself automatically?

3

I’m thinking that is a Bug (or at least a “missing feature”), so I opened an issue. I’m thinking the state of a “timeseries-item” will only be updated, because the binding told it to. As I’m using non-thing items, that mechanism isn’t in place…?
https://github.com/openhab/openhab-addons/issues/19510

4

I bumped in this recently and what I ended up doing is systematically postUpdate(‘NULL’) to the state if it is changing to non NULL (e.g. restart)… this way NULL does not get persisted and the item value does not pollute my graphs.

I only update the persistency of the item in the past because I have access to the value only with a delay so I need to “fix the past”.

Not sure if it helps or not, but thought I’d share.

5

There are a few things that need to be in place for time series updates to work, most notably that the Item need to have forecast persistence strategy configured.

If you have that, have you tried creating a TimeSeries object in the rule and postUpdate that to the Item instead of using the persist action?

6

If it was for me! :wink:
Yes, of course the item is in the forecast strategy as are all my other binding-bouond items (like Tibber or ForecastSolar).

I’m not aware of a syntax for writing an object to a item, can you point me to the correct documentation for that? On the other hand, I’m wondering, what difference it would make to write a batch of timestamp-value objects instead writing everything seperate? But I can certainly try!

7

From what I can see it seems it’s not supported natively in jsscripting, so would have to be done by accessing the raw java types. I know jruby have support for TimeSeries, so if you would want to test it out quickly that might be easier.

9

perhaps I’m confused right now… :wink:
JS Scripting has support for Timeseries (see my code), but only for one timestamp at a time I think and not for posting a batch of 24hours at once.
What I think is missing is a backend functionality or process, which automatically changes states according to a timeseries, if that makes sense.

10

There is a specific TimeSeries class that bindings use to update channels with TimeSeries. For rules there is a sendTimeSeries function that can be used, but not sure if/how the helper libraries have implemented those.

1 Like
11

ok, that way you’ll send a Map with States/Timestamps, and that would cover the creation part. I’m pretty sure, that would not apply states once those timestamps have been reached. My “one sendCommand per timestamp method” basically does the same thing. the ‘sendTimeSeries’ does the exact same, but as a batch update.
What’s missing is still, that if a once “future” timestamp is finally reached to change the state of that item.

12

In your script snippet you use persistence to store the value, which is different from updating the item. Not sure that’s what makes a difference, but sending TimeSeries from bindings work with updating the item at the correct time, so my hypothesis is that the way it is persisted makes a difference.

Your method

State --> persistence --> DB

Vs

States --> TimeSeries --> Item update --> event bus --> persistence --> DB

There are a few events that are skipped when you write directly to persistence that may be important to ensure the forecast item update mechanism works. Again, just a hypothesis, but it could be the cause.

1 Like
13

I’ll set up a test for this. If I remember correctly, there’s also an binding-specific log-entry at the change-timestamps (if set to DEBUG), but I’ll test.

14

Thanks for that. It really did the trick! :wink:
as I know nothing about JRuby, I just copy/pasted together this silly script:

min1 = Time.now + 1.minute
min2 = Time.now + 2.minute
min3 = Time.now + 3.minute

# create and populate a TimeSeries object
ts_data = TimeSeries.new
                    .add(min1, DecimalType.new(1))
                    .add(min2, DecimalType.new(2))
                    .add(min3, DecimalType.new(3))

# Send it to the item
testTimeSeries.time_series = ts_data

logger.info "timeSeries sent"

and got this in the logs:

2025-11-10 20:14:07.466 [INFO ] [ion.jrubyscripting.script.testSeries] - timeSeries sent
...
2025-11-10 20:14:07.509 [INFO ] [hab.event.ItemTimeSeriesUpdatedEvent] - Item 'testTimeSeries' updated timeseries with 3 values.
2025-11-10 20:15:07.477 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'testTimeSeries' changed from NULL to 1
2025-11-10 20:15:07.499 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'testTimeSeries' changed from NULL to 1
2025-11-10 20:16:07.474 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'testTimeSeries' changed from 1 to 2.0
2025-11-10 20:17:07.487 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'testTimeSeries' changed from 2 to 3

just a bit curious, why it is “2.0” but “1” and “3”…
and => how to invoke the sendTimeSeries via JS Scripting, cause I don’t know JRuby… :wink:

JS Scripting: sending a TimeSeries to an item