Wow, thanks Rich, for this great teaching lesson.
Needed to read it twice to fully understand all your comments.
Very interesting!
I had a look at your rules where you checked this.event in the “But only if” section.
What I don’t understand why this code in the “But only if” section is not working
if(this.event === undefined){
console.log("Rule aborted");
false;
} else {
console.log("Rule ok");
true;
}
The script is always executed.
How is the rule triggered?
When a rule is triggered manually, the conditions are never applied (which could be a problem with the edited the rule use case now that I think of it). It’s a work around so I don’t imagine it’s ever going to cover all the cases.
I see. I started the rule manually and thought that “But only if” gets executed. Obviously that’s not the case. Would have been a great option because the original code would remain unchanged.
Anyway. I like this.event approach and will now change my rules accordingly.
I need to install this software:
and not this one:
correct?
We don’t usually recommend Oracle Java because of their onerous licensing but in general the “correct” one is going to be what ever Java 17 implementation will run on your CPU (ARM, Intel, AMD, etc.) and operating system. To run 64-bit Java you must have a 64-bit processor and 64-bit OS.
I wanted to do some test like Stefan did.
Assume that I will choose the correct package for my CPU and architecture, I just wanted to double check I choose the correct jdk package (GraalVM JDK17 vs. JDK17).
To do that test you’ll need an RPi and at least two SD cards or two RPis. The problem is most pronounced on RPis.
One will need to have a 32-bit Raspberry Pi OS installed with, of course, a 32-bit JDK. The other will have the 64-bit Raspberry Pi OS installed and then there’s two tests, one with just a 64-bit JDK of any variety and one with GraalVM which only comes in 64-bit flavors.
Oliver, I use sdkman on my RPI (as Rich mentioned, it is a 64bit version of openhabian) to install and switch between the installed sdks.
In general you use
sdk list java
to view all possible versions you can install.
This is how you can list your installed sdks and see which ones I used:
sdk list java | grep install
| >>> | 17.0.7 | graalce | installed | 17.0.7-graalce
| | 17.0.7 | zulu | installed | 17.0.7-zulu
You can then just do
sdk install java 17.0.7-graalce
and as Rich said: Don’t use Oracle due to the license implications.
Hope that helps a bit.
I have been switching from openHABian 32Bit to 64bit and imported my backup (Openhabian 4.03 @ Raspberry Pi 4B 8GB)
Unfortunately, there is no change in behaviour. My simple rules for switching and dimming light through a Zigbee Device are delayed by roughly 10 seconds on first execution and after some hours of not executing. Is there any other solution yet?
So far the only solutions are to run with a 63-bit OpenJDK or GraalVM. Are you sure you installed a 64-bit Java?
If I understand the context correctly, and the explanation given previously in this thread (lots of disclaimers here 
), to get better performance you would need to replace OpenJDK with GraalVM. And GraalVM only supports 64 bit. So just running OpenJDK 64 bit will not improve anything.
Based on the experiments run thus far, 64-bit OpenJDK shows similar if not better improvement than GraalVM.
That’s good news! Thanks for testing and reporting that.
Did I forget to configure something when porting from 32bit to 64bit? Because on my installation, there is not really any improvement noticeable when running simple blockly scripts first time.
Well, I did say experiments thus far. Maybe there is something else going on causing problems. I do know it’s very sensitive to running out of RAM and high system loads.
Did someone find a solution to this? Running 4.1.1 64bit, still first execution of java-based and blockly scripts is taking ca. 30 seconds…
Up to this point the slow running of rules have had two potential causes:
running 32-bit
not enough RAM leading to high system loads and use of swap
If you are running in 64-bit OS and 64-bit Java check your system resources using top. If your system loads are greater than 1 and/or you are using any amount of swap, you do not have enough RAM to run everything you have running on that machine. You need more RAM or need to move stuff to a different machine.
If you are running 64-bit OS and 64-bit Java and your system loads are less than one and you are not using any swap then open a new thread. There is something unique about your configuration that needs investigation.
Oh, I see.
Thanks Rich for the valuable response. I guess my rules and items mass got out of control and my Little raspberry friend can’t handle it anymore with loads >2. How silly I was.
Sorry for the dumb question and thanks again, moving to a new, more powerful system…
Best,
Matthias
Sadly, probably what happened was the move to 64-bit. Unfortunately 64-bit requires significantly more RAM than 32-bit does. So you are stuck in a catch-22 with the only way out being moving to a machine with more RAM.
