Great topic Oliver!
At first I didn’t get your thread title, you are asking if you personally should migrate away from DSL rules, not suggesting openHAB itself should dump DSL right?
I see you’ve been around for almost two years so you’ve witnessed some of the changes in openHAB. The rule language situation in openHAB is one of the few things that really remains in flux right now. I think Rich did (as ever) a terrific job of summing up the current situation.
It is at this point I would like stand up and applaud what a great project this is. openHAB advertises itself as being ‘hardware agnostic’ . Well I’d like to add that it also is pretty dog gone ‘language agnostic’. In other words, when it comes to writing automations, you have a lot of choices. This is because there are a awful lot of very talented people who have contributed to the project, talented programmers who used their expertise and talent to make openHAB better and more capable.
You would need a crystal ball to make a better choice then Rich’s advise provides. All our contributors are volunteers and unfortunately for myraid reasons come and go. With them, again unfortunately, often goes the maintenance of some very good ideas.
So… in response to your request for comments in reference to the blog post, Dan also introduced the newly merged jRuby option and Yannik and Stefan’s recent enhancements to the Blockly languages
Lots of horses for courses
As far as DSL going away… not to worry… not to worry DSL isn’t going anywhere any time soon IMHO
I migrated all my rules from “Rules DSL” to “ECMA script”, after upgrading to OH 3.
Now after reading this thread, I am confused.
Are my rules in the outdated “Nashorn ECMA script”?
Do I have to migrate again from “ECMA script” to “JS scripting”?
I am currently on OH 3.1 and upgrade to 3.2 is planned for next week…
Regards
Bernd
No. Both versions coexist. You can continue with Nashorn ECMA script 5.1 for now.
Migrating should be feasible as code gets easier.
Please re-read Rich‘s section - everything is in there
Yes
Eventually. There is no big hurry but eventually you’ll need to. But it could be as simple as adding one line to the top off the script.
Can you use “Blockly” to generate “JS scripting” code? I found it quite useful in OH 3.0 to use Blockly and look at the generated ECMA script code…
Hi all
I will just write my thoghts about this. I’m pretty much a poser or wannabe, that lacks experience in coding and just got addictive to homeautomation. I’ve no hard feelings of learning some’ new skills but going to java seems like a huge learning curve.
With that beeing said is there a risk that unexperienced users will choose any other platform?
And is there any good place to start learning java scripts? I just recently started playing around with blockly and watched the code and that doesn’t look like java as mentioned above. On the downside it all felt like you need a dsl rule to trigger blocklyscripts and blocklyscrips can’t be added to textual scripts atleast not in my VS code.
Maybe there’s a better way to trigger rules, and yes I prefer having my config as text so I can edit them easily.
Cheers y’all
I agree, that looks for me confusing as well (trigger by regular rule and do the rest in blockly).
(By the way, I am a wannabe as well 
I tried once NodeRed, because I liked the “visual approach” this is what’s interesting on Blockly.
However, I was not able to replace all my DSL code with NodeRed, so I wonder if this will be possible with Blockly.
And: if there will be an option to create a trigger “block” in OH blockly soon as well (like if item XY changed to ZZ)
Blockly is now pretty complete and way easier to use and learn than even Rules DSL.
Perhaps but I don’t see how that can be helped. But it’s worth noticing that we now have a rules language even more beginner and non-technical user friendly than Rules DSL in Blockly. We also have rule templates and blockly libraries in the Marketplace so most of these users may not even need to write rules at all eventually.
And as I said, there are no plans to remove Rules DSL. But we don’t own the upstream Xtend project upon which Rules DSL is based. When the upstream drops support, we will have no choice but to drop support too. There really isn’t any other option. But it’s not going to be our choice when/if that happens.
Do not confuse Java and JavaScript. They are completely different programming languages. Also note that the JavaScript that the Blockly blocks convert to is going to be more complex and hard to read than code you would write yourself. So it’s perhaps not the best comparison.
Currently it also converts to Nashorn JavaScript, not JSScripting. And with the helper library that comes with JSScripting, the code will look significantly different too.
Blockly only exists in MainUI. You cannot easily define them outside of MainUI. So you will configure a rule, choose “Run a Script” as the Action and code your Blockly there. If you want to stick to files, Blockly isn’t for you, nor are custom MainUI Widgets.
This is probably going to be controversial and the opinions expressed are my own.
-
Most of the objections against using the UI are bogus. I fully agree there are some cases where sticking to text files for configs is absolutely required. In all other cases it pretty much boils down to “because I want to” is the reason. That’s fine and well on it’s own. However…
-
There are compromises that come into play when choosing files or the UI for configs. Some of those compromises are covered in the Getting Started Tutorial but they can entirely be boiled down to the following: you get no help in text file configs; you will have to fight syntax errors and spend lots of time looking stuff up.
-
Given 2 inexperienced users and non-technical users have no business trying to use text based configs. It’s going to be a waist of their time and it’s going to be a waist of our time supporting them. There is a whole world of mistakes that are simply impossible to make in the UI. Much (not all) of the config in the UI is self descriptive and self documenting; there is no need to look stuff up.
If you are “pretty much a poser or wannabe, that lacks experience in coding” and just getting started with OH, IMO you have no business messing with text configs in OH. It’d be like trying to win a bike race with flat tires.
Since you @Marcus_Carlsson already have started with text files it may not be worth the effort to try to convert. But ultimately choosing to do everything in text configs is a choice that comes with a cost and compromises and I don’t have a lot of sympathy when those costs and compromises come due. It’s up to you to decide if the costs and pain of dealing with text configs are less than what ever benefit you perceive to get from using them.
Navigate to Settings → Rules in MainUI.
Click the + icon.
Fill in the metadata (UID, name, description, etc).
Add triggers as desired.
Click add Action under “then” and choose “Run Script”. Choose Blockly as the language and code what you want the rule to do.
As of 3.2 it should be possible.
This is really kind of nonsense.
Blokly only exists in UI rules. In UI rules there are three sections: triggers, actions, and conditions.
- Triggers are where you define the events that trigger the rule. There is no code here at all in UI rules. Compared to Rules DSL, this is what goes between the line that starts with
ruleand ends withthen. - Actions are where you define what the rule does when it triggers. Compared to Rules DSL, this is what goes between the
thenandend. - Conditions are unique to UI rules. This is where you can define under what conditions the rule will execute (e.g. only run when MyItem > 20 °C). This is the equivalent to Rules DSL rules that start with an
if(MyItem.state <= 20 | °C) return;. Separating out the conditions from the actions is a very powerful capability.
NOTE: There might be a confusion between the Rules section and the Scripts sections of MainUI. Rules are fully capable rules with triggers, actions, and conditions. In very simple cases there may be no code at all in these. In more complex cases you’ll have a Script Action (“Run script” chosen as the Action) and sometimes a Script Condition (the last line of a Script Condition needs to evaluate to a boolean). Scripts are a special type of rule that consists only of a single Script Action without triggers or conditions.
Blockly can be used in both Scripts and Rules.
That’s possibly true and my impression about this comes from NodeRed, where everythig was visible in the graphical view (like item xx changed).
Now that you explained it your way, it totally makes sense (to create the code itself between then and end with blockly (only).
I will play around with the mainUI possibilities to get a better idea.
Thanks, @rlkoshak
Actually I would love to switch from DSL to ECMA 11.
But for sure I started with something simple, that had to fail 
.
SendNotification does not work in my OH env conditions (no openhab-cloud).
JavaScript Scripting - Automation | openHAB
What I don’t like is the dependency to OH external stuff (npm), while with Rules DSL everything is part of it and known where to be found (but that’s because of I would need to get used to). And as @rlkoshak stated there is a lot of stuff and examples for the old Rules DSL, while there is room for improvement on documentation of JavaScript stuff.
hmm. Normally you do not have to care about as it is installed with the binding -if I got you right.
I have not only decided to move from DSL rules to JSscripting - I am also moving from text based files to UI scripts.
I think once you have successfully migrated one rule, the rest can be migrated easier.
npm is an option, not required. Everything you need to interact with OH is built into the add-on including the helper library. The reference docs for the helper library that comes with the add-on is at JavaScript Scripting - Automation | openHAB. Be sure to click through the links which will lead you to more detailed reference docs and eventually to the actual code if desired.
By default, all of the helper library stuff is imported into your rules by default so you don’t even need to import it manually. For those who do want to use npm and external libraries and such that flag can be turned off to avoid naming conflicts where necessary. I think this is a good compromise between the ECMA Script experts out there and most of the rest of us who just want to write rules for OH.
One final note about npm though. This is going to be a really powerful and easy way for people to distribute additional rules libraries and even perhaps rule sets. Instead of 1. clone the github repo, 2. copy the files you want to the right folder, 3. test that it’s working, 4. repeat we will have 1. navigate to $OH_CONF/automation/js, 2. run npm install openhab_rules_tools. With the former not only do you get the library but you get everything that library depends upon as well.
I’m not expecting this to replace the Marketplace and I’ll still push to get support for libraries in the Markteplace, but for now it’s a much better experience than what we used to have.
This addresses two different things. As reference docs, I find JS Scripting’s docs to actually be far superior to what we have for Rules DSL. They are more comprehensive, complete, and you can actually get down to the actual source code where needed. Furthermore, because it’s almost fully standard ECMA 11, there are way more resources out on the wider Internet and hundreds of books to help you learn the language. But that’s just the reference docs.
Where Rules DSL excels is that it has nearly a decade’s head start when it comes to examples specific to openHAB. There really isn’t a whole lot that can be done about that except give some time for more and more people to post tutorials and examples.
While I cannot promise timeliness, I would ask anyone who is struggling to convert a rule to post a new thread, tag me in it, and I’ll do my best to show you what it should look like in JS Scripting. But note that I’m far from an ECMAScript coder and my code is likely riddles with anti-patterns and poor practices so what I post may not be the best, but it should at least work.
However, I’m strictly using UI rules these days. My primary goal is to write rule templates which are only supportable in the UI. So I won’t be much help in creating rules in .js files, but I can help with the actions part.
Rich, from a learning curve’s perspective, I think it makes sense if we had one subforum for JSscripting so that all users who start with or move over to JSscripting have all they need at one place.
It is painful to find JS examples (even NashornJS). Sure, there are tags available but those are not consistent nor are they maintained.
If we create one for JS Scripting we’d need to create one for Groocy, Jython, jRuby, Rules DSL, JScript, and any new ones that come along. What about HABApp and Node Red? This forum already has too many categories and this will create a whole new set.
And even if there is a category, I guarantee you it won’t be used any better than the tags are. So I don’t see how adding new categories is any better than using the tags that already exist.
Hi
Thanks for alot of input, my reason for having textual co figuration as a favorite is in somehow related to my start with Openhab for several years ago in version 1.8 if i recall correctly.
Textual has been my safe metod to easily restore old config on new setup across windows or linux os. Maybe there is a way that I don’t know about to easily backup and restore config across different plattforms.
I am now cliking around in the ui designs and can figure some of it out but not all yet. I might get it soon and woukd really like to learn how to convert my rules and I have no regrets for learning new stuff I’m eager too learn new stuff. I’m no educated programmer but have a big interest and have coded basic, html, power query and read a cojple of css and java books.
And a least I will say that everybody in the community is really helpfull and there is alot of examplecode to get an idea from or reuse it as is .
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
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.
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.
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.