Hello in the round. I’m going to be migrating to v3 soon. In preparation I have been doing my due diligence to learn as much as possible and get it done the most efficient and pain free way, avoiding, or foreseeing whatever problems may arise, and have come across a couple of posts that, to me, question the Rules DSL in comparison to JavaScript.
Given that my only need right now is writing rules for OH, I’m not a programmer, is their any benefit to learning, and then converting, my rules to JavaScript? Ist it more efficient for OH? Does one offer more granularity/control/detail than the other?
There is benefit but whether or not that benefit matters to you is the question.
Do you need to access Item metadata in a rule? Do you plan on migrating your rules to the UI instead of .rules files? Do you want to use libraries in your rules or break free from some of the constraints of Rules DSL? If so there might be some benefit in moving because there are some things that JavaScript (or Python or Groovy) can do that Rules DSL cannot.
However, if you are OK with continuing on the way you have until now then do that. There is enough other new stuff to learn in OH 3 to add one more thing. At best, I’d say complete your migration and then if and only if you see some compelling reason to change (e.g. you want to be able to write rules in the UI) then consider a change and do so gradually.
Here is a quick comparison chart off the top of my head (i.e. don’t consider it to be comprehensive, or necessarily completely accurate).
| Feature | Rules DSL | JavaScript |
|---|---|---|
| Create rules in the UI | Supported with some limitations | Supported |
| Create rules in text files | Supported | Supported but without the Helper Libraries can be verbose |
| Define variables that can be shared by multiple rules | Only in .rules files | Only in .js files |
| Define a variable that persists across multiple runs of the rule in the UI | Not supported | Supported: this.myvar = (this.myvar === undefined) ? null : this.myvar;
|
| Import a library | Not supported | Supported |
| Access Item Metadata | Not supported | Supported |
| Access the Rules Registry | Not supported | Supported |
| Access the Things Registry | Supported? | Supported |
| Access the Item Registry | Supported | Supported |
2 Likes
Thanks Rich, my plan is to keep with text files for the rules but to use the UI for everything else. One factor that lead me to consider JavaScript was the impact on OH itself. Is JS less CPU intensive? But I can worry about that later. Migrate first.
As far as migration is concerned, my plan for my items is to download copies of the .items files to my local machine, delete them from my openHAB machine, upgrade to v3, then do the bulk entry using the copy/paste feature in the UI. I’m assuming that openHAB will properly associate the items to the correct thing.
CPU is almost never the limiting factor, RAM is. I doubt there is a measurable difference in ram usage between the two
Only if:
- the Links are defined in the. items files
- the Things have the exact same ids
To close the loop on this, my upgrade went flawlessly. I deleted the .items files and, after the upgrade, bulk added them via the UI. Afterwards it was a matter of adding tags and such as I built my semantic model.
I’m still reading and learning about all the capabilities of v3 and so far it is impressive.