Items do not update state


sometime, actually out of a sudden my items are not updated anymore. in the Eventlog I see a lot of received command entries but not the changed entries. my openhab log doesn’t mention anything in this direction.

when I want to publish a new state to an item it simply does not update. It doesn’t matter if I do this via Habpanel, the Openhab console, a rule, etc.

I’m running 2.5, latest release, on Ubuntu. And I had comparable symptoms after my first upgrade approach. I did a downgrade back to 2.4 these days and tried after some time again, where it worked.

The rest on the machine looks good, memory, CPU, Load, disk IO, network, etc. I honestly have no idea how to continue.

Someone any good ideas and/or observed the same issue?



I found

openhab> shell:threads --list | grep -i item
202  │ items-1                                                                                        │ BLOCKED       │ 723      │ 460
203  │ items-2                                                                                        │ BLOCKED       │ 751      │ 470
204  │ items-3                                                                                        │ BLOCKED       │ 759      │ 430
226  │ items-4                                                                                        │ BLOCKED       │ 716      │ 450
227  │ items-5                                                                                        │ BLOCKED       │ 781      │ 490

honestly I have no idea what it means, but “blocked” doesn’t really sound good.
I remember I had also had to increase the concurrent rules, and thing handlers in the past.
Does anyone know, is there also a concurrency topic with items?
I have thousands of items with hundreds of rules, and also a high frequency of item updates. if openhab can only update them via 5 threads this could indeed limit me.


Do you have rules with while loops and/or sleep?
Especially if you have lots of rules, items and updates that can become problematic.

I remembet having seen others reporting changed behaviour related to concurrency after an update (can’t find them now…) and it is not unlikely that some minor code changes resulted in changes in timings that could ultimately result in this ‘side effect’.
Having said that, it is considered bad practice to keep a rule running for more than one second in an (asynchronous) event driven system like OH.

nope, I do not have any while loops and/or sleeps in my rules.

You may have already tried this when upgrading but after the upgrade restart OH 2 or 3 times and see if that helps. It took me 1 reboot and 2 restarts for everything to start working correctly. Since my upgrade if I need a restart it still requires doing it a few times to clear all isses.

Can we see that too?


right now it’s working again. I have not really done/changed anything.
My systems still seems to be a bit unstable, like longer time until something is switched on/off and sometimes some elements are not working at all, but I haven’t checked it yet.

with regards to the questions:

  • I actually had several reboots, also cleaned the cache and at some point it was working again, perhaps thats the current workaround for such issues… :slight_smile:
  • i can share some logs, but fundamentally you will just see me item names and received command next to them :slight_smile:


When having issues with OH cleaning the cache and restarting a few times is one of the first steps to try. Glad everything is working again.
Please mark the topic solved by click the square box on the post providing the solution.

Honestly I wouldn’t consider it as solved right now … It’s working again, but I have no idea about root cause and actually I cannot even say what to do if it’s happening again… rebooting it several times (until it gives up an works again :slight_smile: ) is in my opinion not a good solution.

therefore I’ll keep the thread open, perhaps someone has the same issues and/or can contribute something elese.


It sounds like your events bus grinds to a halt. That kind of thing has been seen before, but invariably associated with other system performance clues. Often persistence i/o related. But this -

rules out the usual approaches. Maybe you can review how/what you are checking for here.

I agree, it looked like openhab was not able to write the new states in the item states. as said, the received events were working, also rules triggered by received events were fired, but if in the rule an item state has been used the state was not correct/valid.

I’ll definitely look into this topic again, and will post updates here, I just need to find some spare time for this :slight_smile:

Let’s say they were announcing themselves in your log. That doesn’t mean they’re not just queued onto event bus.
Earlier you said commands, rather than events. For all I know, trigger channel events are handled differently to commands, maybe we could clarify (that events.log excerpt for example)

As above, what kind of triggers work may be relevant.

thats true, sorry, you’re right, I wasn’t precise enough. I meant received commands.
I’m not using any channels directly to fire a rule.
I only use received command/update or changed.
all my rules with received command were working, the changed not.
so it seems that the Eventbus delivered the new command to the item but did not properly update the state.

I do not know the inner workings here, but that does suggest the event bus is working and something we might call “item updater” is clagged up. I’d still be looking to blame something like persistence i/o (which ignores commands and triggers but is very interested in state updates)

could of course be the case, although all metrics I checked were fine and in their normal range
load average, cpu usage, memory consumtion, iops, wait time, .
I’m using InfluxDB to store my states. I actually store everything, which could of course be reduced, but since my system is usually more or less idle I never followed up and also think it’s not necessary…

perhaps I can find some time on the weekend to investigate a bit deeper…


quick update: unfortunately I had not really any time over the weekend to look into it deeper. However it just happend again; immediately after I updated (saved) an item files (added a new item). (via Visual Studio Code). Before the issue occurred I added some other items as well, without causing the issue, Also the item file was not broken or something like this, and for the sake of completeness, it was a string item, but I think this doesn’t really matter.

IT was the same situation as written above, my items did not change anymore, but they received commands, meaning rules fired by received command were working.
I had a look at my openhab console and started to restart bundles. item bundle, rules, etc. nothing changed anything but after I started my http binding it was working again.

Can it be that openhab updates the item state after the received command via the http binding through it’s REST interface? I have seen something like this in the debug logs earlier but I didn’t follow up on this closer.
In the past I had always issues with the http binding, especially since I have some devices polled via http and if the devices are not reachable (that can happen) openhab most likely slowed down and/or stopped working. But I have never seen any impacts on item states.

Perhaps someone know more how it works internally and/or can lead me to some documentation?

AND: also some tipps/suggestions around http binding configuration/tuning would be appreciated. Unfortunately I need it, and I cannot avoid that sooner or later some of my http target devices are not working/answering anymore.


Clearly the http binding shares underpinnings with everything else openHAB is doing with http - weather binding, UI updates.

Use timeouts. That’s about all we can say with the info provided.
Applies also to any http actions used in rules.


where can/should I configure them?
I of course have a timeout in my http.cfg;: and I’m note using any http post/get funktions in my rules (using execcommand issuing bash scripts running curl), but it might be in the bindings of course.

Then you’ve got timeouts,

And you’ve set timeouts on those, too?

sure, there is a timeout with the execcommand.
any my curls do not utilize the openhab http bundle.