OH3: to use or not to use JS (ECMAscript 2021)

  • openHABian 3.3.0 on rPi4 with 4GB

I recently migrated to OH3.
Now I am snooping around and see how things work and what is new.

I always struggled with the DSL rules; hence, when I saw ECMAscript2021 it grabbed my interest.
Looking at some of the docs and rules, it seems doable to me.

While I read rule DSL is here to stay, this ECMAscript2021 JS seems to be a permanent feature in OH, able to replace the rule DSL.

Here a few questions for those who are using ECMAscript2021, or have migrated to it.

  1. Does it do what DSL does; e.g. is a full replacement?
  2. in case you where new to JS, was it relatively easy to pick up? May you had a go at rule DSL and then opted for JS.
  3. Any other insights, suggestions, recommendations you may have?

Thank you.

[edit 1] Does it have longevity? It is part of OH’s core?

Lots of horses for courses these days
Consider Jruby for instance, I love it!

While openHAB supports all of the scripting engines that get accepted as official addons, The JS Scripting (ECMAscript2021) is by far the most supported and useable alternative to DSL rules (especially out of the box). I considered this as the primary scripting engine that most users will migrate too, and indeed is the successor to the DSL rules engine. But again, if another rule engine fits your needs better, like ruby, python or java, those choices are available as well.

1 Like

It is not about my needs and other special circumstances.

I prefer to jump onto something that has a future.

What you said makes sense; hence, is the way to go.

C is a language I am familiar with; any other I have to learn (hence, it is neither here not there what the language is).

General comment; where many struggle with openHAB rules is about grasping the event-driven environment, the differences between command and state, update and change, etc. Rules language choices do not change that.

Further lurking around, and I found this Youtube channel: https://www.youtube.com/@_openHAB/videos

Amongst these vides I found ( Blockly Rules with Stefan Höhn | Blockly Features Interview):

… a series of three videos.

One of the interesting bits was that rules can be created in Blockly, with the underlying code generated being JavaScript… brilliant. This means, if I fail to write a rules, I can build (at least) a skeleton and see what the code needs to look like.

Well, this seems to have answered my question. :slight_smile:

Syntax had been the problem for me, more than anything else.

Blockly still generates ECMAScript 5.1 code so some tweaks may be necessary to run that code with the JS Scripting (ECMAscript2021) add-on, see:

1 Like

Rules DSL is well supported in VSCode with the openHAB extension.

I’m writing my first ECMAscript2021 scripts. I wonder why it takes almost 15s for executing the script for the first time on my Raspberry3 once I have done changes to the script? Is there something like a Just-In-Time Compiler which is very slow?

As already pointed out, Blockly generates old ECMAScript 5.1 code and without usage of any helper libraries which leads to not the cleanest code.
But: Work is ongoing to make Blockly generate ECMAScript 2021/JS Scripting code.

That was normal until a few days ago, because the injection of the openHAB JavaScript library, that provides easy access to openHAB APIs, takes some time due to its relatively large codebase.
I have implemented a caching mechanism to improve injection speed (13 seconds without caching and 2 seconds with caching on my Pi 3), see [jsscripting] Cache openhab-js injection to improve performance by florian-h05 · Pull Request #14135 · openhab/openhab-addons · GitHub. This enhancement is coming with openHAB 4.


Thanks for the info. Is there something like a language specification, where functions like parseFloat() are described?

Hi Florian,

and on Github you wrote

the code needs to be evaluated once before it is cached.

what does that mean in detail? Is it your code which needs to be evaluated to be cached or is it our rule that needs to be evaluated to be cached?
The performance increase you measured was done on a freshly started oh-instance?

See JavaScript | MDN or JavaScript Tutorial.

The injection of the openHAB JavaScript library is cached by default (you can disable this to use a version from the node_modules folder). As a user, you don’t have to do anything to have the caching work.
When openHAB starts, the library code is loaded and then it‘s injection is evaluated once by the first JS script to run. All JS scripts that run after this initial run take advantage of the cached version, but the very first run after an openHAB start will take longer than the subsequent ones.

The performance increased I measured was on two dev systems, that were started at some time and then I performed the tests. As already mentioned, the first script to run after openHAB or addon Start takes a bit longer than the following ones because the cache is not initialized yet.

1 Like

Ok. This means we better create a „startup“ rule with zero content to force the injection being evaluated to avoid the first rule being delayed?

Yes, would be an option.
I don’t know how long the first evaluation takes on your system and whether that’s something annoying for the first rule to run, but if you want to create a „startup“ rule, I would recommend to put a .js file inside automation/js with e.g. console.log(„JS Scripting cache initialised“); as content.

I have updated today to OH3.4.1 and also updated JS scripting (openhabian-config → Openhab related → Install openhab-js). Now compilation takes even almost one minute on my Pi3. This is too much. Can I do anything about it? Can I downgrade?

2023-01-09 14:28:29.036 [INFO ] [openhab.event.RuleUpdatedEvent      ] - Rule '517365d010' has been updated.
2023-01-09 14:29:24.649 [ERROR] [b.automation.script.javascript.stack] - Failed to execute script:

Why have you upgrade openhab-js? I guess that’s the reason why compilation time increased, because the version in the file system is in a different format than the included version.
I’d recommend to run the openHABian-config → openHAB related → Uninstall openhab-js option.

I need previousStateTimestamp() what is missing in OH3.4. Is there workaround not to use previousStateTimestamp ?


This is what I have done now, but compilation time is still about 50s. Can it be caused by OH3.4.1 ?
I’m getting this error message again, as previousStateTimestamp() is not available now. Any proposal? Thanks!

org.graalvm.polyglot.PolyglotException: TypeError: itemEnergyReading.history.previousStateTimestamp is not a function