[OH3] high cpu load, unresponsive OH

Hi all,

Since I’ve migrated to the stable version of OH3 in a docker on my Pi 3B+, the system (only OH3 container) becomes unresponsive after a few hours or if I do a lot of editing rules (part of the migration I move the text based rules to the new NGRE).

Also in the log I get time-outs of bindings (like iCloud or Unifi) and this message:
Dispatching event to subscriber 'org.openhab.core.internal.items.ItemUpdater@a79b69' takes more than 5000ms
I can’t access the MainUI, only restarting the docker container helps.

I found on the form a different posts, but they are either about OH2 or the beta’s/milestones of OH3.

Anyone experiencing the same?


I’m experiencing the same! The lowest I cant get to on a RPi 3 B+ is a load average of 2 and above…

Rules load extremely slow (5min for a simple jython rule file with one rule).
Even when I let it calm down it won’t get better. Karaf console is also super unresponisve - I set karaf to DEBUG output but I don’t see much…

Here’s my /var/lib/openhab/config/org/openhab/addons.config:

[19:36:28] openhabian@openHABianPi:~$ cat /var/lib/openhab/config/org/openhab/addons.config

And shell:threads --list gives the top 20:

Id	Name	State	CPU time	Usr time
57	Dir Watcher	WAITING	159391	153480
14	Start Level: Equinox Container: 00b4dd77-4602-46bc-988a-67011f40d03e	WAITING	157955	154240
385	OH-scriptwatcher-1	TIMED_WAITING	65349	62220
293	OH-thingHandler-2	TIMED_WAITING	65164	59370
299	OH-thingHandler-4	TIMED_WAITING	63814	57410
267	OH-thingHandler-1	WAITING	62848	57000
296	OH-thingHandler-3	TIMED_WAITING	62341	56460
302	OH-thingHandler-5	TIMED_WAITING	61254	55300
97	features-3-thread-1	WAITING	60262	57610
387	OH-rulesRefresher-1	WAITING	51348	48620
110	SocketListener(openHABianPi-fritz-box.local.)	RUNNABLE	49647	47030
114	OH-eventexecutor-1	WAITING	43551	39870
4884	OH-rule-set-1-1	WAITING	36990	35920
240	OH-usb-serial-discovery-linux-sysfs-1	TIMED_WAITING	24182	16920
61	OH-OSGiEventManager	TIMED_WAITING	23337	20950
237	pool-14-thread-1	TIMED_WAITING	16872	14570
111	JmDNS(openHABianPi-fritz-box.local.).Timer	TIMED_WAITING	15490	13470
5518	OH-rule-temp-1-1	WAITING	13142	12860
128	upnp-main-2	RUNNABLE	12675	11330
3605	qtp15820476-3605	RUNNABLE	11882	11460
424	RXTXPortMonitor(/dev/ttyAMA0)	RUNNABLE	11310	5300
4866	OH-rule-roborock-1-1	WAITING	11046	10720
3598	qtp15820476-3598	RUNNABLE	10718	10100
4869	OH-rule-garden-6-1	WAITING	10509	10250
371	pool-21-thread-1	RUNNABLE	9719	8940

I have started deactivating bindings that I supect, but no luck so far…

Any advice would be welcome!

Thank you so much!

Edit: @ljsquare can you check if you also get this line when setting karaf to debug:

[DEBUG] [core.karaf.internal.FeatureInstaller] - Running scheduled sync job

I get it every minute and don’t know if that is normal…

I haven’t checked yet, but I found another post that describes my/our exact problem:

Thanks for the link!

I might have found a solution:
First of all, after stopping openhab, i overwrote the addons.config with the addons.cfg where only package=standard was defined. So the addons.config is now clear of any packages (it still had some 1.x bindings in the beginning).
Secondly, i found a file named:


Which i renamed openhab-addons-3.0.0.bak.
Then I cleaned the cache: openhab-cli clean-cache
After restarting openhab all your bindings will be gone, but I re-added them all and now it seems to be running smoothely.

My unqualified guess: Openhab got the addons from two sides at the same time, the kar file and the config file.


I’ve got the same problem.
I did a clean install with the Openhabian v1.6.2 on a RPI4B.
I didn’t import anything and just starting from scratch.
The system becomes slower and even unresponsive after a few hours.

I read on an other thread that this issue was also found on the M2 and M3 builds.
The problem might be in the Rules, the seem to be parsed every time the run (don’t no if this is the case).
This could explane why a rule is taking a ‘long’ time when it is triggered.
I’ve seen that a simple rule can take 5 seconds.

I turned off my rules for now, for testing the effect.

I’ll post my findings later.

Best regards,

Do you have your rules defined in the UI or via text files?

I’ve created everything with the new MainUI, also the rules.
Only the sitemap with a textfile because some options were not supported yet with the UI.

It seems that there’s a problem with DSL rules created in the UI:

Depending on how many rules you have you could try to put them in text files instead. Just until it’s fixed.

1 Like


To confirm what was expected.
After I turned off the Rules in the UI, the system load stays 's low and resonsive.

I hope the Rule problem is getting a fix soon, for now I will be using my old rules files again.

Best Regards,


I have the same issue. After a fresh install of OH with etcher & the openhabian image, with everything fresh inputted, all through UI, CPU load is at 100% (RPI).
However, disabling the rules I have, did not reduce the load.


I still see this problem on my side too. Is there a solution meantime?
Fresh install on a RPI3, all items/rules/… are created over mainUI.
CPU is used 100% .

When I reboot the device than it works for some days and we see that cpu load is low.

best regards,

Are there any timers in your rules?

I ran into the same issue after using timers (all created in main UI).
had to reboot daily.

After removing those timers my system is running without higher loads so far :crossed_fingers:

Edit: after a few days high load & unresponsive OH returned and keeps returning in a 3 days interval

1 Like

More useful than “me too” would be try out the latest fix relating to UI entered rules.

1 Like

Hello! I have the same problem and really want to test this fix. But I’m not shure how. Could you writedown the instructions, or send the link of them.

The easiest way would be to install a Milestone development version.

Hi ! I’ve setting up a new Openhabian 3.1 Instance on a Raspi3+ and had the same issue. Now i could solve the problem for me. I’ve migrated text based rules from OH 2.5 and one statement in a rule causes the the unresponsive OH after a few hours.
The rule switches only a few lights, but when it’s fired a storm of event’s are looping and flooding the log. This was caused by a “postupdate” command for a item enabled for the openhab smart home skill, to control with the amazon echo’s (text based item defined as “switchable”. The “postupdate” for this item makes OH running wild and causes the high cpu load.

Hey Guys,

I have a similar problem. But I can connect without any problem/delay with Basic UI or openHAB App.
Is ist necessary ti cancel the rules is it enough to deactivated it?


same issue on my fresh installation. CPU goes to 100% after some days but i don’t have a memory leak.
No rules are active.