Blockly rules after upgrade to OH 4.0.1 very slow on the first run

I’m not sure but on my system the rules working and then after a while some rules stay in running mode and openhab crash.

It start with a false info and then all other bindings can’t connect and get timeouts…

2023-08-11 21:24:57.768 [INFO ] [tomation.script.ui.Schlafzimmerlicht] - false
2023-08-11 21:29:29.441 [WARN ] [ab.core.internal.events.EventHandler] - Dispatching event to subscriber ‘org.openhab.core.thing.internal.CommunicationManager@1bb03ee’ takes more than 5000ms.
2023-08-11 21:29:29.442 [WARN ] [ab.core.internal.events.EventHandler] - Dispatching event to subscriber ‘org.openhab.core.internal.items.ItemUpdater@be8e28’ takes more than 5000ms.

Open a new thread so this situation can be analyzed in detail. This behavior has nothing to do with Blockly. Something is running amok on your machine consuming resources and forcing OH to have to wait.

1 Like

@florian-h05 i just want to inform you that after the update to OH4.0.2-1, the delay is still there.
To make it sure i restarted OH twice and also uninstalled and installed the JS addon.

as i said already, i can live with that, because i ported all my rules already and i know that it’s just on the first run.

Fully disagree. Try to develop a new rule.
My Wife told me that rules they must be fired before are slow after a while. That happens with 4.0.1. If 4.0.2 didn’t fix it then that will not be satisfied for me.

As discussed above, there are 2 problems. Slow execution which happens the first time a rule is run and what you are seeing. That’s why I asked you to open a separate thread.

It’s open Openhab 4.0.1 unstable - #21 by Wikibear

Is the delay time the same? What’s your platform?

The delay is exactly the same as before, around 12 to 17 seconds, only on the first run.

Log on first run

==> /var/log/openhab/openhab.log <==
2023-08-19 12:38:26.347 [DEBUG] [.internal.OpenhabGraalJSScriptEngine] - Initializing GraalJS script engine...
2023-08-19 12:38:26.375 [DEBUG] [.internal.OpenhabGraalJSScriptEngine] - Injecting ThreadsafeTimers into the JS runtime...
2023-08-19 12:38:26.377 [DEBUG] [.internal.OpenhabGraalJSScriptEngine] - Evaluating cached global script...
2023-08-19 12:38:26.380 [DEBUG] [.internal.OpenhabGraalJSScriptEngine] - Evaluating cached openhab-js injection...

==> /var/log/openhab/openhab.log <==
2023-08-19 12:38:41.084 [DEBUG] [.internal.OpenhabGraalJSScriptEngine] - Successfully initialized GraalJS script engine.
2023-08-19 12:38:41.104 [INFO ] [org.openhab.automation.script.ui.AA ] - ASSUMPTION_DAY
2023-08-19 12:38:41.107 [INFO ] [org.openhab.automation.script.ui.AA ] - NATIONAL_DAY
2023-08-19 12:38:41.110 [INFO ] [org.openhab.automation.script.ui.AA ] - 128
2023-08-19 12:38:41.112 [INFO ] [org.openhab.automation.script.ui.AA ] - NATIONAL_DAY

Log on second run with a time trigger at 12:41

2023-08-19 12:41:00.367 [INFO ] [org.openhab.automation.script.ui.AA ] - ASSUMPTION_DAY
2023-08-19 12:41:00.373 [INFO ] [org.openhab.automation.script.ui.AA ] - NATIONAL_DAY
2023-08-19 12:41:00.379 [INFO ] [org.openhab.automation.script.ui.AA ] - 128
2023-08-19 12:41:00.383 [INFO ] [org.openhab.automation.script.ui.AA ] - NATIONAL_DAY

Release = Raspbian GNU/Linux 11 (bullseye)
Kernel = Linux 6.1.21-v8+
Platform = Raspberry Pi 4 Model B Rev 1.2
openHAB = 4.0.2 - Release Build

System runs absolutely stable!!

Same situation as you, I can confirm that with 4.0.2 the delay issue is still there.

It also happens every time you open a Blockly rule without saving it

2 Likes

I can confirm, that now after 4.0.2-1 upgrade, rules run very slow.
Normal it takes to send a mail and a WhatApp a couple of secounds.
Now it takes 55 sec. (55 sec the rule itself shows the icon “running”)

It’s not important for me if I get the notification that rain started or something else
happend, like power off from a charger, but compared to 3.4.4 it seems a problem.
This only happens on my testsystem with this configuration:

Release = Raspbian GNU/Linux 11 (bullseye)
##    Kernel = Linux 6.1.21-v7+
##  Platform = Raspberry Pi 3 Model B Plus Rev 1.3
##    Uptime = 17 day(s). 14:44:0
## CPU Usage = 2.01% avg over 4 cpu(s) (4 core(s) x 1 socket(s))
##  CPU Load = 1m: 2.14, 5m: 2.36, 15m: 1.75
##    Memory = Free: 0.00GB (1%), Used: 0.93GB (99%), Total: 0.94GB
##      Swap = Free: 2.33GB (78%), Used: 0.66GB (22%), Total: 2.99GB
##      Root = Free: 20.09GB (72%), Used: 7.67GB (28%), Total: 28.98GB
##   Updates = 0 apt updates available.
##  Sessions = 1 session(s)
## Processes = 125 running processes of 32768 maximum processes

The production System, works very well with:

 Release = Raspbian GNU/Linux 11 (bullseye)
##    Kernel = Linux 6.1.21-v8+
##  Platform = Raspberry Pi 4 Model B Rev 1.1
##    Uptime = 14 day(s). 5:11:40
## CPU Usage = 22.44% avg over 4 cpu(s) (4 core(s) x 1 socket(s))
##  CPU Load = 1m: 0.35, 5m: 0.45, 15m: 0.43
##    Memory = Free: 0.80GB (21%), Used: 2.94GB (79%), Total: 3.75GB
##      Swap = Free: 2.99GB (100%), Used: 0.00GB (0%), Total: 2.99GB
##      Root = Free: 20.21GB (72%), Used: 7.55GB (28%), Total: 28.98GB
##   Updates = 1 apt updates available.
##  Sessions = 1 session(s)
## Processes = 132 running processes of 32768 maximum processes

Yep… Just try to develop a new rule… That drives me total crazy if you hit run and then you change something small. Oh, forget something and hit again run and wait…

As you can see memory usage is 100% and swap usage is 10%, which indicates that the system does not have enough memory. Using swap instead of memory can heavily affect overall performance.

I think @rlkoshak wrote a more extensive post about this topic, but I cannot find it currently …

Ok, this mean, more or less, that the “old PI3” can not more used for an default installation with 4.02 to get a propper UI performance and a quick tasking from the rules. So a clear recommentation for a PI4!

Thanks!

As with most things it depends. If all you are running is OH 3 with a modest configuration an RPi 3 is probably fine. If you have ZRAM configured and running InfluxDB, Mosquitto, and NodeRed an RPi 3 is probably not enough.

1 Like

Thanks Rick :slight_smile: I only recommend this to the Users which maybe not have it on their
shopping list, that when they upgrade from a OH 3.4x System to an OH 4.0x which was running on an
PI3, that they shall order an PI4, that is running smoove again as was in past …
Order already done for me…

Some update:

New HW has arreived:
Funny thing ist, that I have a 1:1 copy from my configuration. The production system and a testsystem.
Different is only the on the testsystem all rules a deactivated.
On the production (with the new HW) the rules are slower that on 4.0.2 and the testsystem (with the current used hw for pro) the rules are much, much slower ~ feeling ~3 times.

So for me it seems, that from 3.4.4 to 4.0.3 something has been changed in this way, that ist blocking a fast run from the rules. Also the hint from open,edit,close, and run the rule is NOT making the rule faster.

Here the config:
New Prodsystem:

###############################################################################
###############  openhabian  ##################################################
###############################################################################
##        Ip = 192.168.xxx.xxx
##   Release = Raspbian GNU/Linux 11 (bullseye)
##    Kernel = Linux 6.1.21-v8+
##  Platform = Raspberry Pi 4 Model B Rev 1.1
##    Uptime = 0 day(s). 0:43:18
## CPU Usage = 2.27% avg over 4 cpu(s) (4 core(s) x 1 socket(s))
##  CPU Load = 1m: 0.15, 5m: 0.30, 15m: 0.31
##    Memory = Free: 1.62GB (43%), Used: 2.13GB (57%), Total: 3.75GB
##      Swap = Free: 2.99GB (100%), Used: 0.00GB (0%), Total: 2.99GB
##      Root = Free: 20.20GB (72%), Used: 7.55GB (28%), Total: 28.98GB
##   Updates = 5 apt updates available.
##  Sessions = 1 session(s)
## Processes = 132 running processes of 32768 maximum processes
###############################################################################

Testsystem:

###############################################################################
###############  openhabian  ##################################################
###############################################################################
##        Ip = 192.168.xxx.xxx
##   Release = Raspbian GNU/Linux 11 (bullseye)
##    Kernel = Linux 6.1.21-v8+
##  Platform = Raspberry Pi 4 Model B Rev 1.1
##    Uptime = 0 day(s). 12:1:8
## CPU Usage = 12% avg over 4 cpu(s) (4 core(s) x 1 socket(s))
##  CPU Load = 1m: 0.68, 5m: 0.49, 15m: 0.42
##    Memory = Free: 1.33GB (36%), Used: 2.41GB (64%), Total: 3.75GB
##      Swap = Free: 2.99GB (100%), Used: 0.00GB (0%), Total: 2.99GB
##      Root = Free: 20.10GB (72%), Used: 7.66GB (28%), Total: 28.98GB
##   Updates = 0 apt updates available.
##  Sessions = 1 session(s)
## Processes = 130 running processes of 32768 maximum processes
###############################################################################

But nothing in JS Scripting has changed from 4.0.2 to 4.0.3.

Could you please check if the performance is better with „Use Included Library“ disabled?

Hello florian-h05

I’m not talking about a issue in performace between 4.0.3 and 4.0.2
Rich says it’s the old HW (Pi3), so I orderd a new one Pi4 and still have the issue,
that rules that where running in 3.4.4 are now much slower in my prod system, and much much much slower in my testsystem. As told, it’s an 1:1 image copy and only the rules are disabled all on the testsystem.

I disabeld, the „Use Included Library“ in the JavaScript Scripting Binding settings.
Restarted OH, and the speed is the same was ist was. Not real a good performance.

I noticed that GraalVM is slow on first run rule after start system or edit rule, but NashornJS is fast, but Nashorn is deprecated (

Important changes:

  • Java 17 instead of Java 11
  • GraalVM instead of Nashorn

You could try to install the Nashorn addon and run your Rules with it, so you could compare the speed.