OH 3.2 new JS scripting - time to leave Rule DSL?

Setup, Configuration and Use Scripts & Rules
21

HI,

My reasons to stick with file based config:

  • I’m software developer for last 40 years
  • use of VSCODE editor
  • using vertical select & replace
  • github file versioning & change tracking
  • simple rename and management of items at once (search & replace across multiple files)
  • preserving comments in remarks in scripts and item definitions

While is important and nice to support not so skilled (in sw. development!) people, is also important to let more skilled people to use tools and approaches, that they use in every day life as developers. For my opinion simple configuration with files and normal scripting (DSL) possibility was critical for commiting to OpenHab years ago. And while learning new programing language, is in my experience ‘not a big deal’, being forced to click through config in mouse repeating tasks is ‘big deal’.

Regards
/Sas

13 Likes
22

What JS engine is used under the hood? What the performance expectations. I tried to load a couple npm modules to use in a JS rule, and ran into some issues. Just loading the npm modules resulted in java heap space issues, so I gave it more memory. But still, executing a function from one of the packages that takes about 300ms in a node vm, takes 20+ seconds in a JS rule.

23

OH has a lot of users that are also software developers. From all that I’ve read so far, there is no plan to change any of the existing file based stuff. That would be a major incompatibility change that I doubt the OH developers have appetite for.

2 Likes
24

I’d say expectations are 2-3 times slower than V8:

That 20+ seconds, is it that slow every time you run it? With repeated execution I’d hope for HotSpot optimization.

25

openhab-cli backup and restore works regardless how OH is configured. Furthermore, all the Items and everything else configured through the UI or rest API are stored in text JSON formatted files in $OH_USERDATA/jsondb.

As long as you are on the same version of OH, you can migrate these jsondb configs as easily as text file configs, since it’s all text files.

The key thing is to realize the following:

  • it’s mostly the same
  • the triggers are defined separately
  • if you have any “global” variables (commonly used for timers) you’ll need to switch to using Blockly or JSScripting for the language or keep them in .rules files
  • give a close look at Blockly which may be more powerful and easier to use than even Rules DSL, given it’s graphical nature.

You’ll basically define the triggers separately from the stuff between the “then” and “end” which will go in a Script Action (i.e. “run a script” option).

I’m not here to convince anyone to change from using file based configs. I’m just not motivated to spend a lot of time helping debug syntax errors or using the wrong semantic tag or not knowing all the options or any similar problems that simply do not occur when using the UI. I’ve measured the time, and mostly the time lost to dealing with those problems dwarfs the time lost to using the UI or REST API.

If you get some other benefits from using text files, that’s great. But in my experience, it’s going to cost you in time and effort.

This can be done with the JSONDB files too. They are just text files after all. Order is preserved so they are quite suitable for source control.

This is a misnomer and actually a source of problems when using. items files. It is impossible to rename an Item. The names are the unique id for the item. What happens with .items files is every time it’s reloaded, all the items defined in that file are deleted and then recreated based on the new contents of the file.

But if you are not careful, you can end up with orphaned links which causes all sorts of problems. It also causes a lot of churn.

The worst you can do is mix .items files and managed items as there are known issues, particularly with the semantic model.

And I’m not arguing against people choosing to use text config files. I never have and never will. I just won’t help people solve problems that simply do not occur when using the UI or REST API. It’s a time sink and I don’t have that much time too spare. If you want to use text files, you should know what you’re are getting into and not expect the same sort of self documenting and self describing interface. You’ll be spending a lot of time with reference docs up on one screen and your editor up on the other and fighting syntax errors. If you are ok with that, great! OH has you covered. I’d prefer to spend my time elsewhere, helping people with their home automation problems rather than solving syntax problems.

GraalVM. I can’t address any of the issues you experienced and recommend opening a new thread.

The way it currently works, at least with UI rules, it’s not even hotspot optimization. The script actions are reused from one run to the next. This causes it’s own problems, such as an inability to use let or const, but it’s super effecient.

Personally I’ve found no performance problems this far but I don’t use many npm libraries.

But the way it currently works well probably change because not being able to use let and const in UI rules really isn’t acceptable.

2 Likes
26

What does that mean, Graal native? And why the const/let limitations?

27

In MainUI rules, the script action is instantiated the first time it’s run. Then for subsequent runs the same script action is reused. Because it’s reused, if you use let or const you’ll get errors complaining that the variable already exists.

This is already identified an as a problem but a fix for it doesn’t yet exist. The creation of the cache is the first part of the fix though. The rest of the fix will require changes to OH core and might impact other rules languages.

1 Like
28

You are doing great work here providing help, support and examples for the whole community. I’m aware that sticking to file based config can cause many problems, I’m trying to resolve this by my self not bothering the Community.

This info (order is preserved) is very useful, now I’ll have change tracking for widgets and UI!

I’m only using file based definitions, all changes are made in files, no UI ‘driven’ model here. Meta data is very useful !!! Would be great having possibility for file based widgets and UI elements :wink: :sweat_smile:.

Any way: thank You for great work and providing help and support.

Regards
/Sas

29

Is there actually a way how I can see which version of the “openHAB Javascript Library” is currently installed? The version that comes with the addon “JavaScript Scripting” is probably also updated only with the half-yearly rhythm?

30

+1000!

31

If you don’t have the JS Scripting add-on installed you only have Nashorn ECMAScrpt 5.1 installed.

Nashorn comes with Java. It was deprecated in Java 11 so probably true last time it was updated was in Java 10. In any case it’s been years since Nashorn had been touched.

JS Scripting is an add-on like any other. As an add-on, it follows the same release versions and release cycle as OH itself. If you want more frequent updates, run the milestones it snapshot version of OH.

The current developer isn’t going to do it so someone has to volunteer to create all the stuff required to make that happen. No one has volunteered yet. It’s been a year now.

32

Thanks for the quick reply. However, I did not mean the Java version nor the add-on version, but the version of the openHAB Javascript Library. The current version is the 1.2.1. Is there any way to see which version is included in the JS Scripting add-on?

33

I’m not sure how @digitaldan is handling the version numbers for openhab-js. I suspect it will work like tracking the changes on any other binding. It’s all based on timing. What ever has been merged into the baseline before the release is part of the release. For SNAPSHOTS that can be as little as one day ago. For a milestone that’s as little as one day before the milestone was created. For releases that’s as little as one day before the release was created (most likely one week before the release).

If you want the absolute latest version of the library, or a specific version of the library, you can install it using npm i opebnhab from the $OH_CONF/automation/js folder.

NOTE: sometimes there will be changes made to the library that coincide with changes to openHAB core or the JS Scripting add-on so the latest library is not guaranteed to be compatible with older versions of the OH or the add-on.

35

I’m using a computationally expensive library for calculating the Hebrew calendar. Before JS rules, I had a separate node script that I would call to load the data for the day. The initialization of the library is actually the slowest part, as it build’s the calendar model for the full year. So instead of just an exec, I actually have a node service running that serves a JSON API to retrieve the data.

I wanted to ditch this service and bring the whole thing under JS rules, but just importing the library and its dependencies caused Java heap space issues. I increased the heap size but it was still incredibly slow. It could very well be that through hotspot optimization it would get faster, but I suspect that anything other than the smallest, simplest npm libraries might just be too much.

36

One of the current drawbacks of the Rule DSL is that rules cannot be tagged, meaning that there’s no way to make them show up in the schedule. Is that already possible with those new JS rules if they are file-based?

37

Yes. rules - Documentation. But if you are maintaining your rules in text files I’m not sure why it would matter how it shows up in MainUI. You can’t really do anything to the rules there.

38

I’m talking about the Schedule. It’s a nice feature even if I can’t make any changes from there. But it requires me to tag my rules with Schedule, and it doesn’t seem to work they way the documentation says.

rules.JSRule({
  name: "Schedule Test",
  description: "Test the Schedule",
  tags: ["Schedule"],
  triggers: [triggers.GenericCronTrigger("0 0 20 * * ? *")],
  execute: function(data) {
    console.log("JS rule test!");
  }
});

UI-Based rules show up just fine.

PS: I noticed a ruleGroup property under your link. What does it do? I couldn’t find anything about it.

39

First use the API docs to verify whether or not the rule actually has that tag.

If it does, it’s probably the case that file based rules cannot be shown in the Schedule view. I could see that being the case since the triggers and overall structure of the rules is different for UI rules and text based rules. I bet the Schedule page is unable to read and interpret the triggers from file based rules.

If not, file an issue on the openhab-js repo.

In general, if you want to take advantage of something in the UI, you are going to be best off managing your stuff through MainUI.