Upgrade 3.4 to 4, but how?

Dear all,
i am running a medium sized Openhab 3.4.2 smart home on a RPI 3b+.
I did the installation with openhabian.
Now i want to update to Openhab 4, but i am afraid to break something.
I read a lot about upgrade problems with Java Version, etc.
What would be the best approach to update the system?

  • Trying to upgrade my current system?
  • Fresh installation using openhabian and integration of a backup?
  • Fresh installation using docker and integration of a backup?

Is it even possible to integrate a Openhab 3.4.2 backup (sudo openhabian-config) to Openhab 4?
Do i have to change a lot in the configuration of things, item, rules (i read some stuff about item units).

I think it would be recommended to backup the complete SD card before upgrade, right?
Is the RPI 3b+ even capable running Openhab 4?
Sorry about the basic question but there a so many threads about this topic with different information, maybe there is a good guideline where you can point me to?

I would prefer doing a fresh installation with docker and the backup migration, what do you think?

Thank you alot!

2 Likes

Yes but the amount of work may vary depending on how you’ve created your config.

It depends on how you’ve created your config. If you are using managed configs (i.e. done through the UI) once you restore you’ll run the upgradeTool and it will do a lot of the upgrades for you.

If file based configs you’ll need to do everything manually.

Always do this before making a major change of any variety.

Yes but RAM will likely be a problem. It’s going to depend on your specific configuration and whether you are running other stuff (e.g. InfluxDB) on the same machine.

Docker is going to require even more RAM than running as apt installed. If you are looking to use an RPi 3, I cannot recommend Docker. It exacerbates an already existing problem, lack or RAM.

There is one post that shows the steps for restoring a 3.4 backup to a 4.0 instance. I can’t seem to find it at the moment. But the steps were

1, install OH 4
2. restore the backup
3. run the upgradeTool
4. start OH
5. fix all the breaking changes.

Well, as always… it depends…
Which version of OS is installed? get the information from the output of

cat /etc/os-release | grep CODENAME

which should give one line of information like that:

openhabian@openhabianpi:~ $ cat /etc/os-release | grep CODENAME
VERSION_CODENAME=bullseye

If it’s bullseye, you’re good to go for a simple update.
If it’s buster, you will have to first upgrade the OS, which is not that hard, but there may be some obstacles to circumvent
If it’s older than buster, don’t waste your time to up-up-update your OS.

Simple update: go install Java 17 (use openhabian-config → 40 → 45). Then do openhabian-config 02. Please ensure that you’re using the recommended version of openhabian-config (title shows [openHAB]{2023-09-18T13:49:51+02:00}(4651ad4)) You can alter the openHABian version with option 01, chose “release” here)

Well, that’s always a good idea. Best practice would be to copy the SD card, then do the upgrade with the new one.

Yes, absolutely, but please don’t use the 64 Bit Image.

A good option, too. But be aware that openHAB with docker is a little bit different to openHABian, as openHABian does much more than only installing a naked openHAB :slight_smile: so you would have to install more docker containers to get the same behavior (i.e. get samba shares for text configuration, get frontail for logging to a browser window, get a mosquitto container instead of installing it via openhabian-config and so on)
If you’re familiar with docker, go for it, openHABian is really nice, but also it’s at least “for dummies” :wink: and therefor there might be something which you want to do in another way…
As openHAB does rely on multicast (at least for some parts of Autodiscovery), you will need to use the host mode for network. If using real hardware you have to configure additional things for the container to be allowed to use the hardware.

1 Like

Also a thread that could be helpful : openhab-4-migration-faq

1 Like

Just as a point of reference, I am 0 for 4 attempts in successfully upgrading an RPi in place from bullseye to bookworm. In the end the networking always gets messed up and since these are headless it ends up being less work in the long run to start over from scratch. I have good backups and ansible playbooks so rebuilding from scratch only takes running the playbook and about 30 minutes.

I wonder if that should be in the Tutorials and Solutions category…

Thank you for your answers!

Terminal says “buster”.
I think its best to perform a fresh openhabian installation. Question is to first install V3.4.2, integrate the backup and then upgrade to V4 or directly upgrade to V4 and try to integrate the V3.4.2.
I think give the second option a try :slight_smile:

I do not have any comparison if my install is small or large…
My two main instances run on a VM and my backup instance on RPi, it was also a 3b and I decided to buy a new one (4 with 4GB). So I was able to do a fresh installation with openhabian 4.0.3. Then configured the bindings and did a restore from the 3.4 instance. I had ZERO issues and all worked as before.
Once it run for a couple days with careful log monitoring, did an upgrade of the 3.4 incl. buster to bullseye to bookworm. Took a few days to complete. However I have a rather complex network setup with instances taking over from each other if one dives. For me it was worth doing it, others might be faster with a clean new install.
From my point of view: buy a new RPi and configure it, so you have not just software but also hardware redundancy in the future and doing upgrades is easier going forward. And in case of failure and for the time of upgrade, your old system runs. For me it would be a desaster without OH

The Raspberry Pi Imager openhabian installation image is still from August 2023 and seems to be based on buster. Where do I find a bullseye image?

I dont know (in case the question was for me ;D ). But this is sad because i hoped to have a ready-to-go system after a fresh openhabian installation.

You can find the link under “Downloads” above.

No, it’s not.
It’s bullseye since Nov 9, 2021 (1.7 alpha release) respectively Dec 1, 2021 (1.7 official release)

There is still no official bookworm image, though.
Yes, finally (Oct 10, 2023) bookworm arrived in Raspberry Pi OS.

There is a beta ( ? ) version openhabian based on bookworm available.
Not all functions are tested yet ( Bookworm readyness · Issue #1788 · openhab/openhabian · GitHub )

I did a fresh openhabian installation now and restored my 3.4.2 backup.
I am now running openhab 4.0.4.
Also installed mosquitto mqtt and zigbee2mqtt using openhabian config.
Then i performed the recommended way to update my blockly rules: Rules Blockly | openHAB

But by re-saving some of the rules i am getting log errors:

2023-11-08 11:30:30.847 [ERROR] [automation.internal.RuleRegistryImpl] - The rule '4d741a5a40' is not updated, the new version is invalid
java.lang.IllegalArgumentException: The rule '4d741a5a40' has incorrect configurations
	at org.openhab.core.automation.internal.RuleRegistryImpl.resolveConfigurations(RuleRegistryImpl.java:487) ~[?:?]
	at org.openhab.core.automation.internal.RuleRegistryImpl.resolveRuleByTemplate(RuleRegistryImpl.java:364) ~[?:?]
	at org.openhab.core.automation.internal.RuleRegistryImpl.updated(RuleRegistryImpl.java:433) ~[?:?]
	at org.openhab.core.automation.internal.RuleRegistryImpl.updated(RuleRegistryImpl.java:1) ~[?:?]
	at org.openhab.core.common.registry.AbstractRegistry.updated(AbstractRegistry.java:1) ~[?:?]
	at org.openhab.core.common.registry.AbstractProvider.notifyListeners(AbstractProvider.java:66) ~[?:?]
	at org.openhab.core.common.registry.AbstractProvider.notifyListenersAboutUpdatedElement(AbstractProvider.java:91) ~[?:?]
	at org.openhab.core.common.registry.AbstractManagedProvider.update(AbstractManagedProvider.java:118) ~[?:?]
	at org.openhab.core.common.registry.AbstractRegistry.update(AbstractRegistry.java:361) ~[?:?]
	at org.openhab.core.automation.rest.internal.RuleResource.update(RuleResource.java:292) ~[?:?]
	at jdk.internal.reflect.GeneratedMethodAccessor54.invoke(Unknown Source) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
	at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:179) ~[bundleFile:3.4.5]
	at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) ~[bundleFile:3.4.5]
	at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:201) ~[bundleFile:3.4.5]
	at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:104) ~[bundleFile:3.4.5]
	at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) ~[bundleFile:3.4.5]
	at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96) ~[bundleFile:3.4.5]
	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:225) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:298) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPut(AbstractHTTPServlet.java:234) ~[bundleFile:3.4.5]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:520) ~[bundleFile:4.0.4]
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:273) ~[bundleFile:3.4.5]
	at org.ops4j.pax.web.service.spi.servlet.OsgiInitializedServlet.service(OsgiInitializedServlet.java:102) ~[bundleFile:?]
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1656) ~[bundleFile:9.4.50.v20221201]
	at org.ops4j.pax.web.service.spi.servlet.OsgiFilterChain.doFilter(OsgiFilterChain.java:100) ~[bundleFile:?]
	at org.ops4j.pax.web.service.jetty.internal.PaxWebServletHandler.doHandle(PaxWebServletHandler.java:310) ~[bundleFile:?]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:600) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:234) ~[bundleFile:9.4.50.v20221201]
	at org.ops4j.pax.web.service.jetty.internal.PrioritizedHandlerCollection.handle(PrioritizedHandlerCollection.java:96) ~[bundleFile:?]
	at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:722) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.Server.handle(Server.java:516) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034) ~[bundleFile:9.4.50.v20221201]
	at java.lang.Thread.run(Thread.java:833) ~[?:?]
Caused by: java.lang.IllegalArgumentException: Required configuration property missing: "group"!
	at org.openhab.core.automation.internal.RuleRegistryImpl.processValue(RuleRegistryImpl.java:577) ~[?:?]
	at org.openhab.core.automation.internal.RuleRegistryImpl.validateConfiguration(RuleRegistryImpl.java:517) ~[?:?]
	at org.openhab.core.automation.internal.RuleRegistryImpl.resolveConfigurations(RuleRegistryImpl.java:483) ~[?:?]
	... 67 more
==> /var/log/openhab/events.log <==
2023-11-08 11:30:30.904 [INFO ] [openhab.event.RuleUpdatedEvent      ] - Rule '4d741a5a40' has been updated.

and

2023-11-08 11:29:12.897 [ERROR] [automation.internal.RuleRegistryImpl] - The rule '36f9aeef3a' is not updated, the new version is invalid
java.lang.IllegalArgumentException: The rule '36f9aeef3a' has incorrect configurations
	at org.openhab.core.automation.internal.RuleRegistryImpl.resolveConfigurations(RuleRegistryImpl.java:487) ~[?:?]
	at org.openhab.core.automation.internal.RuleRegistryImpl.resolveRuleByTemplate(RuleRegistryImpl.java:364) ~[?:?]
	at org.openhab.core.automation.internal.RuleRegistryImpl.updated(RuleRegistryImpl.java:433) ~[?:?]
	at org.openhab.core.automation.internal.RuleRegistryImpl.updated(RuleRegistryImpl.java:1) ~[?:?]
	at org.openhab.core.common.registry.AbstractRegistry.updated(AbstractRegistry.java:1) ~[?:?]
	at org.openhab.core.common.registry.AbstractProvider.notifyListeners(AbstractProvider.java:66) ~[?:?]
	at org.openhab.core.common.registry.AbstractProvider.notifyListenersAboutUpdatedElement(AbstractProvider.java:91) ~[?:?]
	at org.openhab.core.common.registry.AbstractManagedProvider.update(AbstractManagedProvider.java:118) ~[?:?]
	at org.openhab.core.common.registry.AbstractRegistry.update(AbstractRegistry.java:361) ~[?:?]
	at org.openhab.core.automation.rest.internal.RuleResource.update(RuleResource.java:292) ~[?:?]
	at jdk.internal.reflect.GeneratedMethodAccessor54.invoke(Unknown Source) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
	at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:179) ~[bundleFile:3.4.5]
	at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) ~[bundleFile:3.4.5]
	at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:201) ~[bundleFile:3.4.5]
	at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:104) ~[bundleFile:3.4.5]
	at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) ~[bundleFile:3.4.5]
	at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96) ~[bundleFile:3.4.5]
	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:225) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:298) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPut(AbstractHTTPServlet.java:234) ~[bundleFile:3.4.5]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:520) ~[bundleFile:4.0.4]
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:273) ~[bundleFile:3.4.5]
	at org.ops4j.pax.web.service.spi.servlet.OsgiInitializedServlet.service(OsgiInitializedServlet.java:102) ~[bundleFile:?]
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1656) ~[bundleFile:9.4.50.v20221201]
	at org.ops4j.pax.web.service.spi.servlet.OsgiFilterChain.doFilter(OsgiFilterChain.java:100) ~[bundleFile:?]
	at org.ops4j.pax.web.service.jetty.internal.PaxWebServletHandler.doHandle(PaxWebServletHandler.java:310) ~[bundleFile:?]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:600) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:234) ~[bundleFile:9.4.50.v20221201]
	at org.ops4j.pax.web.service.jetty.internal.PrioritizedHandlerCollection.handle(PrioritizedHandlerCollection.java:96) ~[bundleFile:?]
	at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:722) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.Server.handle(Server.java:516) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034) ~[bundleFile:9.4.50.v20221201]
	at java.lang.Thread.run(Thread.java:833) ~[?:?]
Caused by: java.lang.IllegalArgumentException: Required configuration property missing: "sceneController"!
	at org.openhab.core.automation.internal.RuleRegistryImpl.processValue(RuleRegistryImpl.java:577) ~[?:?]
	at org.openhab.core.automation.internal.RuleRegistryImpl.validateConfiguration(RuleRegistryImpl.java:517) ~[?:?]
	at org.openhab.core.automation.internal.RuleRegistryImpl.resolveConfigurations(RuleRegistryImpl.java:483) ~[?:?]
	... 67 more
==> /var/log/openhab/events.log <==
2023-11-08 11:29:12.937 [INFO ] [openhab.event.RuleUpdatedEvent      ] - Rule '36f9aeef3a' has been updated.

The code of the rules looks the following:

configuration: {}
triggers:
  - id: "1"
    configuration:
      itemName: Steckdose_Gosund_4_Steckdose_Gosund_4_Power
    type: core.ItemStateChangeTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      blockSource: <xml
        xmlns="https://developers.google.com/blockly/xml"><variables><variable
        id="mypZ$K`tW=E{1N-cfu8Z">HOleistung</variable></variables><block
        type="variables_set" id="z6sDTB01J06{k5x1Fw(l" x="160" y="127"><field
        name="VAR" id="mypZ$K`tW=E{1N-cfu8Z">HOleistung</field><value
        name="VALUE"><block type="oh_getitem_state"
        id="1!@lj)qr)}-uq+~]3e+V"><value name="itemName"><shadow type="oh_item"
        id="*xvwXacdp-[+Y-^+xqOe"><mutation
        itemName="Steckdose_Gosund_4_Steckdose_Gosund_4_Power"
        itemLabel="HomeOffice Leistung"></mutation><field
        name="itemName">Steckdose_Gosund_4_Steckdose_Gosund_4_Power</field></shadow></value></block></value><next><block
        type="controls_if" id="RHksCA}Zl6@h,t|WbHpo"><mutation
        else="1"></mutation><value name="IF0"><block type="logic_compare"
        id="q8H$Z`PWPfX,k)~Apr:."><field name="OP">GT</field><value
        name="A"><block type="variables_get" id="|b^1MJ{A(vm}0;CsuPw1"><field
        name="VAR"
        id="mypZ$K`tW=E{1N-cfu8Z">HOleistung</field></block></value><value
        name="B"><block type="math_number" id="^Q,PmT`#=2l[n~p72=U_"><field
        name="NUM">50</field></block></value></block></value><statement
        name="DO0"><block type="oh_event" id="Ac-*}A{jH0qKGSK}Pfzg"><field
        name="eventType">sendCommand</field><value name="value"><shadow
        type="text" id="s;^4wfzWcy(nymhY1S^/"><field
        name="TEXT">80</field></shadow></value><value name="itemName"><shadow
        type="oh_item" id="%]V-fh5,Mv@Q8%9l`dXx"><mutation
        itemName="Monitorlicht_GlobalBrightness" itemLabel="Monitorlicht
        Helligkeit "></mutation><field
        name="itemName">Monitorlicht_GlobalBrightness</field></shadow></value><next><block
        type="oh_event" id="`LuziCuSJ^y:q}Do((oN"><field
        name="eventType">sendCommand</field><value name="value"><shadow
        type="text" id="M22TrH~1Xd._;6^8jU)d"><field
        name="TEXT">ON</field></shadow></value><value name="itemName"><shadow
        type="oh_item" id="5|DKnx(Endu:M.*C|w)a"><mutation
        itemName="Kolbenlampe_Schalter" itemLabel="Schalter"></mutation><field
        name="itemName">Kolbenlampe_Schalter</field></shadow></value></block></next></block></statement><statement
        name="ELSE"><block type="oh_event" id="WJhKm.(1U[mlp*SscV9U"><field
        name="eventType">sendCommand</field><value name="value"><shadow
        type="text" id="ke+s#4T])d1-=iFYHp0U"><field
        name="TEXT">OFF</field></shadow></value><value name="itemName"><shadow
        type="oh_item" id="W;yxpeA!6}b*e#EzYaHh"><mutation
        itemName="Kolbenlampe_Schalter" itemLabel="Schalter"></mutation><field
        name="itemName">Kolbenlampe_Schalter</field></shadow></value><next><block
        type="oh_event" id="TOBOWwh%6STj/%@0]5^1"><field
        name="eventType">sendCommand</field><value name="value"><shadow
        type="text" id="0=~pS4y*AEV^6+7IO_2B"><field
        name="TEXT">0</field></shadow></value><value name="itemName"><shadow
        type="oh_item" id="AdF?n!GMByBmMlw3xy=)"><mutation
        itemName="Monitorlicht_GlobalBrightness" itemLabel="Monitorlicht
        Helligkeit "></mutation><field
        name="itemName">Monitorlicht_GlobalBrightness</field></shadow></value></block></next></block></statement></block></next></block></xml>
      type: application/javascript
      script: >
        var HOleistung;



        HOleistung = items.getItem('Steckdose_Gosund_4_Steckdose_Gosund_4_Power').state;

        if (HOleistung > 50) {
          items.getItem('Monitorlicht_GlobalBrightness').sendCommand('80');
          items.getItem('Kolbenlampe_Schalter').sendCommand('ON');
        } else {
          items.getItem('Kolbenlampe_Schalter').sendCommand('OFF');
          items.getItem('Monitorlicht_GlobalBrightness').sendCommand('0');
        }
    type: script.ScriptAction

and

configuration: {}
triggers:
  - id: "2"
    configuration:
      cronExpression: 0 0/8 * * * ? *
    type: timer.GenericCronTrigger
conditions:
  - inputs: {}
    id: "1"
    configuration:
      itemName: Steckdose_Gosund_2
      state: ON
      operator: =
    type: core.ItemStateCondition
  - inputs: {}
    id: "3"
    configuration:
      startTime: 07:00
      endTime: 23:00
    type: core.TimeOfDayCondition
actions:
  - inputs: {}
    id: "4"
    configuration:
      blockSource: <xml xmlns="https://developers.google.com/blockly/xml"><block
        type="oh_event" id="1(,pqS}vg+5SN.,#%%Y/" x="267" y="362"><field
        name="eventType">sendCommand</field><value name="value"><shadow
        type="text" id="qpNW,%)Oc]grCWGC;.7("><field name="TEXT">Ă–ffne My Page
        und starte Seite 3</field></shadow></value><value
        name="itemName"><shadow type="oh_item"
        id="/x+)eFc28^?ICYh+?n}:"><mutation itemName="EchoBuro_Befehl"
        itemLabel="BĂĽro Befehl"></mutation><field
        name="itemName">EchoBuro_Befehl</field></shadow></value></block></xml>
      type: application/javascript
      script: >
        items.getItem('EchoBuro_Befehl').sendCommand('Ă–ffne My Page und starte
        Seite 3');
    type: script.ScriptAction

However, when i run the blockly script manually it works …

Also i do have this in the log:

2023-11-08 11:56:41.130 [WARN ] [rnal.defaultscope.ScriptBusEventImpl] - State '544.6-196' cannot be parsed for item 'Hausverbrauch_Leistung'.
2023-11-08 11:56:41.136 [WARN ] [rnal.defaultscope.ScriptBusEventImpl] - State '544.6-196' cannot be parsed for item 'Solar_Eigenverbrauch'.
2023-11-08 11:56:41.141 [WARN ] [rnal.defaultscope.ScriptBusEventImpl] - State 'NaN' cannot be parsed for item 'Solar_Eigenverbrauch_prozent'.
2023-11-08 11:56:41.146 [WARN ] [rnal.defaultscope.ScriptBusEventImpl] - State 'NaN' cannot be parsed for item 'Solar_quote'.
2023-11-08 11:56:41.151 [WARN ] [rnal.defaultscope.ScriptBusEventImpl] - State 'NaN' cannot be parsed for item 'Hausverbrauch_Openhasb_Background'.

Seems like a unit mismatch (?).
However i set all the item units in the item state description.
Dont know what to do…
edit: I managed to fix the one above by putting Quantity conversion in blockly all over the place …

Maybe one of you can help me :slight_smile: Thanks!

edit: Also i am getting so many “item updated to …” logs even if nothing changed on the item value.

2023-11-08 14:36:55.130 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Network_simon_phone_online' updated to ON
2023-11-08 14:36:55.532 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Network_simon_phone_online' updated to ON
2023-11-08 14:37:55.795 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Network_simon_phone_online' updated to ON
2023-11-08 14:37:55.917 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Network_simon_phone_online' updated to ON
2023-11-08 14:38:56.179 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Network_simon_phone_online' updated to ON
2023-11-08 14:38:56.304 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Network_simon_phone_online' updated to ON
2023-11-08 14:39:57.830 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Network_simon_phone_online' updated to ON
2023-11-08 14:41:01.961 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Network_simon_phone_online' updated to ON
2023-11-08 14:41:02.261 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Network_simon_phone_online' updated to ON
2023-11-08 14:42:02.449 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Network_simon_phone_online' updated to ON
2023-11-08 14:42:02.669 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Network_simon_phone_online' updated to ON
2023-11-08 14:43:02.751 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Network_simon_phone_online' updated to ON
2023-11-08 14:43:03.079 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Network_simon_phone_online' updated to ON
2023-11-08 14:44:03.376 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Network_simon_phone_online' updated to ON
2023-11-08 14:44:04.416 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Network_simon_phone_online' updated to ON
2023-11-08 14:45:04.658 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Network_simon_phone_online' updated to ON
2023-11-08 14:45:04.832 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Network_simon_phone_online' updated to ON

This was not the case in Openhab 3 log. I am getting spammed in the log file. Really hard to solve the issues like this … Is this normal in Openhab 4?

Also my main UI keeps crashing from time to time. Log is still alive but main UI just doenst responde anymore. Have to reboot to get it back alive. CPU load is very minor (~1-5%) but RAM is ~50-80%. I am really confused about the amount of “item updated to …” in the log.

Despite the error it looks like something updated. The generated code looks reasonable. It appears the conversion to JS Scripting worked.

Do you see this error every time you save these rules or just that first time?

Note:

This is unlikely to work the way you think it will. The .state is a String and you are comparing a String with a Number. Change that first block to the “get [name] of item” block and select “numeric state” for the property to get. That will get the state as a number so the comparison will work as expected.

What type of Item is this? If it’s a Number, well 544.6-196 isn’t a number so it’s going to complain. If you are updating this Item from a rule, I suspect that you are having a similar String/Number issue as described above.

NaN is what JS creates when you attempt to do math with something that you cannot do math with or attempted an invalid math operation (e.g. divide by 0). It stands for “Not a Number”. Obviously that can’t be parsed into a Number either and I suspect the same root cause as above, you are using the .state as a number when in fact it’s a String.

Nashorn JS was more forgiving of this sort of operation but GraalVM is more strict about types.

Yes, if you are working with Items with units in rules, you need to use the “get [quantity state] from item” block and do the math using the blocks in the Units of Measurement menu.

Or use the “get [numeric state] from item” and do the math without units.

When you restored your backup it overwrote $OH_USERDATA/etc/log4j2.xml. You are missing two lines.

                <Logger level="ERROR" name="openhab.event.ItemStateUpdatedEvent"/>
                <Logger level="ERROR" name="openhab.event.GroupStateUpdatedEvent"/>

I’ve not seen any reports of the UI crashing. If it’s truly crashing it might be a client side problem instead of a server side problem. The fact that the logs continue supports that.

Are you using Firefox? There have been reported problems with Firefox. Those problems are not that it crashes but maybe the reported problems are exacerbating a different problem.

Wow thank you for the detailed answer. The get numeric state should be the key. In openhab 3 i always saved item states to variables to do math. But this was really a pain! I will try your suggestions and report!

Thank you. That did the trick. Much better now :slight_smile:

I am using google chrome … i am not sure. Sometime the frontend doesnt response after deleting some items, things, etc … But i can not reproduce the issue. I will observe it.

Now i am getting some “from time to time” errors for some rules.
Strange things is that they often run without a problem and also can be run manually.
But i am getting error in the log from time to time.
For example:

2023-11-08 19:41:34.817 [ERROR] [e.automation.internal.RuleEngineImpl] - Failed to execute rule '55c8b7abce': Failed to execute action: 3(Multi threaded access requested by thread Thread[OH-rule-55c8b7abce-1,5,main] but is not allowed for language(s) js.)
2023-11-08 19:34:58.409 [ERROR] [b.automation.script.javascript.stack] - Failed to execute script:
org.graalvm.polyglot.PolyglotException: ReferenceError: "itemRegistry" is not defined
	at <js>.:program(<eval>:40) ~[?:?]
	at org.graalvm.polyglot.Context.eval(Context.java:399) ~[?:?]
	at com.oracle.truffle.js.scriptengine.GraalJSScriptEngine.eval(GraalJSScriptEngine.java:458) ~[?:?]
	at com.oracle.truffle.js.scriptengine.GraalJSScriptEngine.eval(GraalJSScriptEngine.java:426) ~[?:?]
	at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:262) ~[java.scripting:?]
	at org.openhab.automation.jsscripting.internal.scriptengine.DelegatingScriptEngineWithInvocableAndAutocloseable.eval(DelegatingScriptEngineWithInvocableAndAutocloseable.java:53) ~[?:?]
	at org.openhab.automation.jsscripting.internal.scriptengine.InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.eval(InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.java:78) ~[?:?]
	at org.openhab.automation.jsscripting.internal.scriptengine.DelegatingScriptEngineWithInvocableAndAutocloseable.eval(DelegatingScriptEngineWithInvocableAndAutocloseable.java:53) ~[?:?]
	at org.openhab.automation.jsscripting.internal.scriptengine.InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.eval(InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.java:78) ~[?:?]
	at org.openhab.core.automation.module.script.internal.handler.ScriptActionHandler.lambda$0(ScriptActionHandler.java:71) ~[?:?]
	at java.util.Optional.ifPresent(Optional.java:178) ~[?:?]
	at org.openhab.core.automation.module.script.internal.handler.ScriptActionHandler.execute(ScriptActionHandler.java:68) ~[?:?]
	at org.openhab.core.automation.internal.RuleEngineImpl.executeActions(RuleEngineImpl.java:1188) ~[?:?]
	at org.openhab.core.automation.internal.RuleEngineImpl.runRule(RuleEngineImpl.java:997) ~[?:?]
	at org.openhab.core.automation.internal.TriggerHandlerCallbackImpl$TriggerData.run(TriggerHandlerCallbackImpl.java:87) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]
	at java.lang.Thread.run(Thread.java:833) ~[?:?]
2023-11-08 19:34:58.421 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'f79deb37fb' failed: org.graalvm.polyglot.PolyglotException: ReferenceError: "itemRegistry" is not defined
2023-11-08 19:29:34.827 [WARN ] [ore.internal.scheduler.SchedulerImpl] - Scheduled job 'MyTimer' failed and stopped
java.lang.IllegalStateException: Multi threaded access requested by thread Thread[OH-scheduler-328,5,main] but is not allowed for language(s) js.
	at com.oracle.truffle.polyglot.PolyglotEngineException.illegalState(PolyglotEngineException.java:129) ~[?:?]
	at com.oracle.truffle.polyglot.PolyglotContextImpl.throwDeniedThreadAccess(PolyglotContextImpl.java:1034) ~[?:?]
	at com.oracle.truffle.polyglot.PolyglotContextImpl.checkAllThreadAccesses(PolyglotContextImpl.java:893) ~[?:?]
	at com.oracle.truffle.polyglot.PolyglotContextImpl.enterThreadChanged(PolyglotContextImpl.java:723) ~[?:?]
	at com.oracle.truffle.polyglot.PolyglotEngineImpl.enterCached(PolyglotEngineImpl.java:1991) ~[?:?]
	at com.oracle.truffle.polyglot.HostToGuestRootNode.execute(HostToGuestRootNode.java:110) ~[?:?]
	at com.oracle.truffle.api.impl.DefaultCallTarget.callDirectOrIndirect(DefaultCallTarget.java:85) ~[?:?]
	at com.oracle.truffle.api.impl.DefaultCallTarget.call(DefaultCallTarget.java:102) ~[?:?]
	at com.oracle.truffle.polyglot.PolyglotFunctionProxyHandler.invoke(PolyglotFunctionProxyHandler.java:154) ~[?:?]
	at jdk.proxy1.$Proxy1116.run(Unknown Source) ~[?:?]
	at org.openhab.automation.jsscripting.internal.threading.ThreadsafeTimers.lambda$0(ThreadsafeTimers.java:85) ~[?:?]
	at org.openhab.core.internal.scheduler.SchedulerImpl.lambda$12(SchedulerImpl.java:189) ~[?:?]
	at org.openhab.core.internal.scheduler.SchedulerImpl.lambda$1(SchedulerImpl.java:88) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]
	at java.lang.Thread.run(Thread.java:833) ~[?:?]
Caused by: com.oracle.truffle.api.TruffleStackTrace$LazyStackTrace

Dont know how to fix this because i can not understand the error message and also dont know how to reproduce the issue…

What i also noticed: Running the script takes a strange long amount of time. Running a simple blockly script takes 10-20sec till i get a log answer (and its displayed “running” in the UI). This was not the case in openhab 3.

Is there a way to see what part / binding / script / … is consuming a lot RAM? I am afraid i do have a lot of unnecessary stuff. A lot of weather forecase items etc. But i dont want to delete them if they are not responsible for the RAM usage.

Still i am getting this error:

2023-11-08 19:53:26.135 [ERROR] [automation.internal.RuleRegistryImpl] - The rule '4d741a5a40' is not updated, the new version is invalid
java.lang.IllegalArgumentException: The rule '4d741a5a40' has incorrect configurations
	at org.openhab.core.automation.internal.RuleRegistryImpl.resolveConfigurations(RuleRegistryImpl.java:487) ~[?:?]
	at org.openhab.core.automation.internal.RuleRegistryImpl.resolveRuleByTemplate(RuleRegistryImpl.java:364) ~[?:?]
	at org.openhab.core.automation.internal.RuleRegistryImpl.updated(RuleRegistryImpl.java:433) ~[?:?]
	at org.openhab.core.automation.internal.RuleRegistryImpl.updated(RuleRegistryImpl.java:1) ~[?:?]
	at org.openhab.core.common.registry.AbstractRegistry.updated(AbstractRegistry.java:1) ~[?:?]
	at org.openhab.core.common.registry.AbstractProvider.notifyListeners(AbstractProvider.java:66) ~[?:?]
	at org.openhab.core.common.registry.AbstractProvider.notifyListenersAboutUpdatedElement(AbstractProvider.java:91) ~[?:?]
	at org.openhab.core.common.registry.AbstractManagedProvider.update(AbstractManagedProvider.java:118) ~[?:?]
	at org.openhab.core.common.registry.AbstractRegistry.update(AbstractRegistry.java:361) ~[?:?]
	at org.openhab.core.automation.rest.internal.RuleResource.update(RuleResource.java:292) ~[?:?]
	at jdk.internal.reflect.GeneratedMethodAccessor58.invoke(Unknown Source) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
	at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:179) ~[bundleFile:3.4.5]
	at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) ~[bundleFile:3.4.5]
	at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:201) ~[bundleFile:3.4.5]
	at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:104) ~[bundleFile:3.4.5]
	at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) ~[bundleFile:3.4.5]
	at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96) ~[bundleFile:3.4.5]
	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:225) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:298) ~[bundleFile:3.4.5]
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPut(AbstractHTTPServlet.java:234) ~[bundleFile:3.4.5]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:520) ~[bundleFile:4.0.4]
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:273) ~[bundleFile:3.4.5]
	at org.ops4j.pax.web.service.spi.servlet.OsgiInitializedServlet.service(OsgiInitializedServlet.java:102) ~[bundleFile:?]
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1656) ~[bundleFile:9.4.50.v20221201]
	at org.ops4j.pax.web.service.spi.servlet.OsgiFilterChain.doFilter(OsgiFilterChain.java:100) ~[bundleFile:?]
	at org.ops4j.pax.web.service.jetty.internal.PaxWebServletHandler.doHandle(PaxWebServletHandler.java:310) ~[bundleFile:?]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:600) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:234) ~[bundleFile:9.4.50.v20221201]
	at org.ops4j.pax.web.service.jetty.internal.PrioritizedHandlerCollection.handle(PrioritizedHandlerCollection.java:96) ~[bundleFile:?]
	at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:722) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.Server.handle(Server.java:516) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883) ~[bundleFile:9.4.50.v20221201]
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034) ~[bundleFile:9.4.50.v20221201]
	at java.lang.Thread.run(Thread.java:833) ~[?:?]
Caused by: java.lang.IllegalArgumentException: Required configuration property missing: "group"!
	at org.openhab.core.automation.internal.RuleRegistryImpl.processValue(RuleRegistryImpl.java:577) ~[?:?]
	at org.openhab.core.automation.internal.RuleRegistryImpl.validateConfiguration(RuleRegistryImpl.java:517) ~[?:?]
	at org.openhab.core.automation.internal.RuleRegistryImpl.resolveConfigurations(RuleRegistryImpl.java:483) ~[?:?]
	... 67 more
==> /var/log/openhab/events.log <==
2023-11-08 19:53:26.184 [INFO ] [openhab.event.RuleUpdatedEvent      ] - Rule '4d741a5a40' has been updated.

I changed the blockly script to this:

configuration: {}
triggers:
  - id: "1"
    configuration:
      itemName: Steckdose_Gosund_4_Steckdose_Gosund_4_Power
    type: core.ItemStateChangeTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      blockSource: <xml xmlns="https://developers.google.com/blockly/xml"><block
        type="controls_if" id="RHksCA}Zl6@h,t|WbHpo" x="160" y="153"><mutation
        else="1"></mutation><value name="IF0"><block type="logic_compare"
        id="q8H$Z`PWPfX,k)~Apr:."><field name="OP">GT</field><value
        name="A"><block type="oh_getitem_attribute"
        id=",:4lSGU-XWoKRTH37pXN"><mutation
        attributeName="NumericState"></mutation><field
        name="attributeName">NumericState</field><value name="item"><shadow
        type="oh_getitem" id="SXWv`QJ`a(2DdAgGXE_8"><value
        name="itemName"><shadow type="oh_item"
        id="$2DU$+XgN|U@bRc,Pgq#"><mutation itemName="MyItem"
        itemLabel="MyItem"></mutation><field
        name="itemName">MyItem</field></shadow></value></shadow><block
        type="oh_getitem" id="zS~nKtG.%icn%hi[qh.e"><value
        name="itemName"><shadow type="oh_item"
        id="R=+)t_eehC_|o[lz$IKx"><mutation itemName="MyItem"
        itemLabel="MyItem"></mutation><field
        name="itemName">MyItem</field></shadow><block type="oh_item"
        id="=T[8:`~8:y$W.%)S~Bl#"><mutation
        itemName="Steckdose_Gosund_4_Steckdose_Gosund_4_Power"
        itemLabel="HomeOffice Leistung"></mutation><field
        name="itemName">Steckdose_Gosund_4_Steckdose_Gosund_4_Power</field></block></value></block></value></block></value><value
        name="B"><block type="math_number" id="^Q,PmT`#=2l[n~p72=U_"><field
        name="NUM">50</field></block></value></block></value><statement
        name="DO0"><block type="oh_event" id="Ac-*}A{jH0qKGSK}Pfzg"
        disabled="true"><field name="eventType">sendCommand</field><value
        name="value"><shadow type="text" id="s;^4wfzWcy(nymhY1S^/"><field
        name="TEXT">80</field></shadow></value><value name="itemName"><shadow
        type="oh_item" id="%]V-fh5,Mv@Q8%9l`dXx"><mutation
        itemName="Monitorlicht_GlobalBrightness" itemLabel="Monitorlicht
        Helligkeit "></mutation><field
        name="itemName">Monitorlicht_GlobalBrightness</field></shadow></value><next><block
        type="oh_event" id="`LuziCuSJ^y:q}Do((oN"><field
        name="eventType">sendCommand</field><value name="value"><shadow
        type="text" id="M22TrH~1Xd._;6^8jU)d"><field
        name="TEXT">ON</field></shadow></value><value name="itemName"><shadow
        type="oh_item" id="5|DKnx(Endu:M.*C|w)a"><mutation
        itemName="Kolbenlampe_Schalter" itemLabel="Schalter"></mutation><field
        name="itemName">Kolbenlampe_Schalter</field></shadow></value></block></next></block></statement><statement
        name="ELSE"><block type="oh_event" id="WJhKm.(1U[mlp*SscV9U"><field
        name="eventType">sendCommand</field><value name="value"><shadow
        type="text" id="ke+s#4T])d1-=iFYHp0U"><field
        name="TEXT">OFF</field></shadow></value><value name="itemName"><shadow
        type="oh_item" id="W;yxpeA!6}b*e#EzYaHh"><mutation
        itemName="Kolbenlampe_Schalter" itemLabel="Schalter"></mutation><field
        name="itemName">Kolbenlampe_Schalter</field></shadow></value><next><block
        type="oh_event" id="TOBOWwh%6STj/%@0]5^1" disabled="true"><field
        name="eventType">sendCommand</field><value name="value"><shadow
        type="text" id="0=~pS4y*AEV^6+7IO_2B"><field
        name="TEXT">0</field></shadow></value><value name="itemName"><shadow
        type="oh_item" id="AdF?n!GMByBmMlw3xy=)"><mutation
        itemName="Monitorlicht_GlobalBrightness" itemLabel="Monitorlicht
        Helligkeit "></mutation><field
        name="itemName">Monitorlicht_GlobalBrightness</field></shadow></value></block></next></block></statement></block></xml>
      type: application/javascript
      script: >
        if
        (items.getItem('Steckdose_Gosund_4_Steckdose_Gosund_4_Power').numericState
        > 50) {
          items.getItem('Kolbenlampe_Schalter').sendCommand('ON');
        } else {
          items.getItem('Kolbenlampe_Schalter').sendCommand('OFF');
        }
    type: script.ScriptAction

To be honest, its a little bit sad that so many stuff which took a lot of time to create in Openhab 3 in now not working anymore. I do understand that comparing units etc makes sense. But my setup in Openhab 3 worked for me … now i have to re-build so many stuff again :frowning:

There is a limitation where only one thread can access a rule’s context at a time. Given the context can be shared between Timers, and passed when rules call other rules an extensive set of locking mechanisms have been added to prevent that. However, when you have rules that call other rules or when you have a rule that gets triggered really fast the locking mechanism appear to fail and you’ll see this error.

This should only occur in rare cases. If it happens frequently additional exploration is required.

This points to a rule that is still written in Nashorn JS style and has not been edited to work with GraalVM JS. There is no itemRegistry in GraalVM JS (by default). Instead all access and manipulation of Items goes through the items class.

You can search for “f79deb37fb” to find the rule this error is coming from. In the future, when creating a rule be sure to give it a meaningful UID so it’s easier to map errors in the logs to a specific rule.

Given the nature of the Multithreaded error it might be challenging to identify exactly what’s going on. You can find the rule by search for the rule UID in the exception and then look at events.log to see what was going on when the rule was triggered. Techniques for avoiding these are highly dependent on context. I can give no generic “try this”.

There is an open issue that has received some attention but no resolution yet. The very first time a script is run after it’s loaded (which also includes after it’s edited) it can take an extended amount of time to inject the helper library and parse the script. Preliminary experimentation has shown that for some users running OH on 64-bit Java or on the GraalVM JRE gives a 10x improvement. It only seems to be a problem on ARM based CPUs like an RPi has and when running as 32-bit.

But there have also been a lot of people experiencing problems because OH 4 requires a bit more RAM than OH 3 and they’ve run out of room to run it on the machine they are using. Running htop on the machine will show you what’s going on. The most important thing to look at is the average system load. If it’s > 1 you have problems. Also look at swap. If you are using any you don’t have enough RAM.

Every time you save it?

I’ve never seen this error before.

As much as is possible, breaking changes to OH are limited to a major version upgrade. That means moving from OH 3.3 to 3.4 is going to be relatively painless. However, moving from OH 3.4 to 4.0 (or 4.X to 5.0 in the future) is always going to take some work on your part because those version changes include breaking changes.

Honestly, the number and nature of the breaking changes between 3.4 and 4.0 are tiny and mostly handled automatically compared to between 2.5 and 3.0 and between 1.8 and 2.0 were. In those cases there were huge fundamental changes to the underlying architecture and how end users interact with OH. 3.4 to 4.0 is mostly refinements to what is there in OH 3 and if you have managed configs a huge amount of the breaking changes were handled for you during the upgrade process.

I can reproduce this. Created a very simple rule, giving the starttime, save 1+1 in a variable and give the end time.
Starting the first time manually took 24 seconds to give results:

2023-11-09 07:59:09.708 [INFO ] [openhab.event.RuleUpdatedEvent      ] - Rule 'dc4e0a3be4' has been updated.
2023-11-09 07:59:33.865 [INFO ] [nhab.automation.script.ui.dc4e0a3be4] - Starttime: 2023-11-09 07:59:33
2023-11-09 07:59:33.884 [INFO ] [nhab.automation.script.ui.dc4e0a3be4] - Starttime: 2023-11-09 07:59:33

Then i added a cron trigger to run it every 30seconds, looks fine:

2023-11-09 08:05:37.278 [INFO ] [openhab.event.RuleUpdatedEvent      ] - Rule 'dc4e0a3be4' has been updated.
2023-11-09 08:06:20.605 [INFO ] [nhab.automation.script.ui.dc4e0a3be4] - Starttime: 2023-11-09 08:06:20
2023-11-09 08:06:20.621 [INFO ] [nhab.automation.script.ui.dc4e0a3be4] - Endtime: 2023-11-09 08:06:20
2023-11-09 08:06:30.309 [INFO ] [nhab.automation.script.ui.dc4e0a3be4] - Starttime: 2023-11-09 08:06:30
2023-11-09 08:06:30.339 [INFO ] [nhab.automation.script.ui.dc4e0a3be4] - Endtime: 2023-11-09 08:06:30
2023-11-09 08:07:00.310 [INFO ] [nhab.automation.script.ui.dc4e0a3be4] - Starttime: 2023-11-09 08:07:00
2023-11-09 08:07:00.343 [INFO ] [nhab.automation.script.ui.dc4e0a3be4] - Endtime: 2023-11-09 08:07:00
2023-11-09 08:07:30.308 [INFO ] [nhab.automation.script.ui.dc4e0a3be4] - Starttime: 2023-11-09 08:07:30
2023-11-09 08:07:30.337 [INFO ] [nhab.automation.script.ui.dc4e0a3be4] - Endtime: 2023-11-09 08:07:30
2023-11-09 08:08:00.309 [INFO ] [nhab.automation.script.ui.dc4e0a3be4] - Starttime: 2023-11-09 08:08:00
2023-11-09 08:08:00.339 [INFO ] [nhab.automation.script.ui.dc4e0a3be4] - Endtime: 2023-11-09 08:08:00

Then i just opened the blockly script, didnt change or save anything, again big delay:

2023-11-09 08:08:11.926 [INFO ] [openhab.event.RuleUpdatedEvent      ] - Rule 'dc4e0a3be4' has been updated.
2023-11-09 08:08:51.426 [INFO ] [nhab.automation.script.ui.dc4e0a3be4] - Starttime: 2023-11-09 08:08:51
2023-11-09 08:08:51.443 [INFO ] [nhab.automation.script.ui.dc4e0a3be4] - Endtime: 2023-11-09 08:08:51
2023-11-09 08:09:00.956 [INFO ] [nhab.automation.script.ui.dc4e0a3be4] - Starttime: 2023-11-09 08:09:00
2023-11-09 08:09:00.980 [INFO ] [nhab.automation.script.ui.dc4e0a3be4] - Endtime: 2023-11-09 08:09:00

Strange but this may be a root cause for the this error:

I think a lot of issues are coming from the number units. I didnt take care about this alot in the past and set everything up using the state description and just put the item to a number:category which seemed to be right. But this is now causing troubles. I think this will take some work to fix … :frowning:

However one rule is giving me some pain.
I am getting this WARN all over:

2023-11-09 09:44:33.931 [WARN ] [ab.core.internal.events.EventHandler] - Dispatching/filtering event for subscriber 'org.openhab.core.events.EventSubscriber' failed: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@3147ea[Not completed, task = java.util.concurrent.Executors$RunnableAdapter@3fd5d9[Wrapped task = org.openhab.core.automation.internal.TriggerHandlerCallbackImpl$TriggerData@13dda8a]] rejected from java.util.concurrent.ScheduledThreadPoolExecutor@1fb73eb[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@3147ea[Not completed, task = java.util.concurrent.Executors$RunnableAdapter@3fd5d9[Wrapped task = org.openhab.core.automation.internal.TriggerHandlerCallbackImpl$TriggerData@13dda8a]] rejected from java.util.concurrent.ScheduledThreadPoolExecutor@1fb73eb[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2065) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:833) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:340) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:562) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor.submit(ScheduledThreadPoolExecutor.java:715) ~[?:?]
	at java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:748) ~[?:?]
	at org.openhab.core.automation.internal.TriggerHandlerCallbackImpl.triggered(TriggerHandlerCallbackImpl.java:57) ~[?:?]
	at org.openhab.core.automation.internal.module.handler.ItemStateTriggerHandler.receive(ItemStateTriggerHandler.java:146) ~[?:?]
	at org.openhab.core.internal.events.EventHandler.lambda$2(EventHandler.java:168) ~[?:?]
	at java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]
	at java.lang.Thread.run(Thread.java:833) ~[?:?]

It is triggered every ~30seconds and looks like this:


Can you imaging where the WARN may come from?

This is how htop looks like on my RPI 3b+:

Is there a way to see which rules are triggered how often?
Maybe i am using too aggressive rule triggers which are not really needed.

There is a different issue open. Currently the mere act of opening a Script Action causes the rule to be reloaded. This is a bug and hopefully will get fixed. But you are seeing here the conjunction of two problems and not a root cause.

units has no impact on the multithreaded exception. This is all about when and how the rules are triggered and whether timers are involved.

It’s a warning so it might still be working. The error is coming from OH core. JS Scripting isn’t even in the call stack. I’ve never seen this warning before but stuff similar to these often indicate a lack of resources on the machine.

Do you see this warnign every time the rule runs?

It’s not even getting that far before the warning is thrown (or it’s occuring after the rule is finished) so I don’t think it’s relevant. But just in case, please click on the code tab of the rule and post the full text of the rule. It’s a lot easier to analyze the code that actually executes than the blockly version, particularly when it’s a pretty extensive rule like this.

Use code fences.

```
code goes here
```

OK, you are using swap but your system load is relatively low. That’s actually pretty unusual. Usually once swap starts being used your system load goes up because swap is really slow which leaves programs waiting around waiting for resources.

Try a reboot and then periodically monitor the swap. How long does it take before swap starts to be used? If it’s pretty fast (minutes to hours) it means you have too much running on this machine and need to move everything to one with more RAM or move something off this machine to another machine to free up some RAM (e.g. InfluxDB).

If it takes an extended amount of time (days) to start using swap we might be able to make it work in the RAM available given a few tweaks,

Also pay attention to openhab.log. Do the errors and warnings start to occur when swap starts to be used or even before that point?

You can watch the event stream in MainUI. Open the developer sidebar (alt-shift-d), click the second tab, set the filter to openhab/rules/*, and click “Stream Events”.

You can also add these events to events.log by changing the logging level of openhab.event.RuleStatusInfoEvent to INFO. This will show when Rules start running and when they return to IDLE. It’s kind of handy to have those events interleaved with the Item change events in events.log.

Either of these approaches will be useful. It would also be helpful to give your Timers a unique name when they are created. That will help map some of those multithreaded exceptions to a rule and timer.