Yeah, I meant it answers whether he made any progress yet 
I reinstalled on a ssd and use as max RAM as possible. I can double check the values when back from holiday. Itās now ok, maybe on same level as in OH 3 before.
So it is not a real solution but more a technical work around via hw. Especially as the same hw was dramatically faster on OH 3, I wonder a lot.
I figured it out. When a JS rule fails, it seems to reload all the rules. Reloading all rules takes a long time and consumes lots of CPU, at least on my system. After fixing the rule, everything seems to be performing ok again. Note that Iām still running on Raspberry Pi 2 Model B Rev 1.1, OH 4.1.
My last problem is the scratchpad, which is almost unusable for trying things out, because it also leads to full reload. I wonder if I can run this somehow on the old Nashorn Engine, as reloading is very fast on it.
All that said, Iām not so sure anymore if Iām talking about the same root cause as you @Matthias_Kaufmann. Btw, enjoy your holidays 
Edit: My Memory Settings: -Xms192m -Xmx450m
Edit2: Just tested Groovy binding for the first time and itās blazing fast. So scratchpad issue solved for me. Maybe Iāll start rewriting my JS rules to Groovy, but need to see more of the API firstā¦
Really? What is indicating that a rules are reloaded, and can you please try to describe how to reproduce that?
You can install the Nashorn automation add-on from the add-on store and select that as script type in the scratchpad.
JS has much better docs and a helper library that covers most interaction with openHAB, IMO Groovy documentation is āa bitā short.
In case you want to move away from JS, consider jRuby as an alternative, it also has a nice helper library. Iāve read that jRuby performs better than JS, but especially on older Pis, it also requires some compilation time.
FYI: The compilation time in JS Scripting is mostly caused by the helper library code being evaluated, if you disable the helper library injection, it is also very fast, but I guess we all want to use the helper library.
1 Like
Meanwhile, I think itās wrong. What led me to that conclusion was CPU metrics and some thread dump data. What actually happened was multiple JS rules were failing, because they were not written against JS helper lib but called in periodic fashion. Each time the failing rules got executed, the whole ācompilingā process started from scratch. I wish I had these rules written in a statically typed language, as all errors could have been catched by type checker way before execution and above all, all at the very same time.
@florian-h05 Thanks for your suggestions regarding automation alternatives. ATM the most promising solution to me seems to be GitHub - seaside1/jrule: openHAB Java Rules Engine. They claim that you can just deploy Java bytecode to openhab, which means the whole compilation/developing process can be done outside the board where openhab is running. Also, one can pick any JVM language of choice, which is Scala for me. If that thing does what it promises, Iāll come out happier out of these JS issues than ever
Fine. I already wondered what happened at your system, because rules are independent from other rules.
You can write file-based rules with JS scripting.
Install the openhab library from npm and add // @ts-check to the top of your JS files. This enables type checking as in TypeScript for your JS files. The openHAB library provides type definitions for the full API.
JRule works with Scala, Iāve already replaced some JS rules. That way I can write openhab rules using one of the most advanced type systems in the world. On top of that, I can use outstanding libs like GitHub - typelevel/cats-effect: The pure asynchronous runtime for Scala. Loading/Executing rules is faster than ever before, no matter how many libs I use. Iāll probably never look back
1 Like