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

binderth · October 18, 2025, 10:17am

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:

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?

binderth · October 19, 2025, 6:55am

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?

binderth · October 20, 2025, 9:00am

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…?

github.com/openhab/openhab-addons

[timeseries] states not changing for a non-thing timeseries-item, but are shown in graph

opened 08:58AM - 20 Oct 25 UTC

binderth

bug

## Expected Behavior I'm using a timeseries-item and let future states persist o…n that item. The item is not linked to a thing. The graph is drawn as I told the persistence to: for past and future timestamps. I used a rule for that, something like that: ``` items.getItem("EMS_TibberPreisInterval").persistence.persist(futureTimestamp1, "3"); items.getItem("EMS_TibberPreisInterval").persistence.persist(futureTimestamp2, "4"); items.getItem("EMS_TibberPreisInterval").persistence.persist(futureTimestamp3, "1"); ... ``` I would expect the item to change state accordingly Example: * futureTimestamp1 is 15min in the future and different from current state * 15mins go by and item automatically changes to the futureTimestamp1 value * the graph is shown as the timeseries was built by the rule ## Current Behavior The item does not change the value, even if it has a timeseries, the standard persistence is `jdbc` and both the update is done via `jdbc` and persistence strategy for `jdbc` is `forecast` for that item. The state of the items stays at the latest `.postUpdate` I triggered (via API or rule). Example: * futureTimestamp1 is 15min in the future and different from current state * 15mins go by and item retains the "old" value * there is no change in state over time * but the graph is shown as "it should" see more/context: https://community.openhab.org/t/understanding-selfmade-timeseries-states-not-changing-for-future-persisted-states/166842 ## Possible Solution somehow bind either the standard persistence to an automatic use of timeseries, also for for non-thing items. or have some "special configuration" ready at item-level for those non-thing items. ## Steps to Reproduce (for Bugs) 1. create an item without a link to a binding 2. have a rule in place to update future states for specific timestamps for that item (in the standard persistence) 3. wait for future timestamps to go by 4. item states don't change ## Context I'm trying to use my own logic for future states to solve issues facing with known or predicted states of items, which are not in the control of a binding. I have two use cases: 1. the obvious "dynamic pricing" for energy. I want a self-defined "level of cost", which then triggers specific actions once the item is asked. I don't want to repeat the logic for said level everytime some rule/script asks for it. 2. the next thing on my list is to have a "consumption plan" ready, meaning, the future item states will represent actions I have planned for future timestamps like "starting the heating", "charging the EV", ... for both scenarios (and surely more) I need the non-thing items to change states based on my "predictions" or "plans". ## Your Environment * Version used: openHAB 5.0.1. * Environment name and version (e.g. Chrome 76, Java 8, Node.js 12.9, ...): current docker (openhab/openhab:latest) * Operating System and version (desktop or mobile, Windows 10, Raspbian Buster, ...): host is Linux Debian 12 (bookworm)

thefathefa · November 4, 2025, 10:51pm

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.

pacive · November 5, 2025, 7:08am

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?

binderth · November 5, 2025, 1:55pm

If it was for me!
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!

pacive · November 6, 2025, 6:08pm

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.