Im in the same situation as Thomas.
Going from DSL to something else feels like starting all over trying to learn a new langauge. It may be fun, and it may also be better ind the long run. But I suspect its also rather time consuming.
And that is where the problem starts.
BLOCKLY is the most ineffective way I have ever seen when it comes to programming.
Installing JS is not possible as it is not advertised in the “AddOn Store”, in fact, nothing is advertised there anymore, all I can do is uninstall the addons I have installed so far.
(no scrollbars on this page).
I redesigned this page some time back. I hadn’t considered this particular scenario with the sidebar not visible.
You’d need to pin the sidebar/menu so you can see the submenus, where you can see “Automation” to install JSScripting.
Alternatively you can type “jsscripting” in the search bar.
I’ll make some changes to accommodate this screen when the sidebar menu is not visible.
Yup, added by me, 3 weeks ago, so it would only be in 5.0
Can you please direct me to the “docs” for JS?
(Beside this JavaScript Scripting - Automation | openHAB
as it is useless, there is no entry point.
It tells me to store the “rules” in “openHAB-conf\automation\js”, but not with what ending.
Also the syntax is not clear,
When I write a rule, it can have several 100 lines of code (optimized PV charging for the house battery, the car, the heating, the hot tub and a number of additional “consumers” as an example.
DSL is a bad and complicate choice altogether, but I do not see hjow JS would make it any easier.
A generice “at 5 turn on the light at the balcony” is not a useful example.
When learning a programming language, I would expect a tutorial on how to start and how to call functions.
https://openhab.github.io/openhab-js/
The link is located here:
BTW, if you’d like to get more help on scripting, please open a new topic and keep this one about “new features wishlist”.
You should try jruby too. It is my preferred scripting language. It makes many tasks and operations simpler. For the most part, you will no longer be struggling with type casting. Instead you can focus on doing what you want to do. The downside is that less people are currently using it so you’ll probably get less people to help, but I’ll be happy to help.
@jimtng has written a page (I can’t seem to find it) showing the same rule wirtten in most of the supported languages) which is an excellent resource. The JSR223 page also has a bunch of examples in most of the languages. Most of the Design Pattern postings here on the forum also have equivalent versions of the same rule or at least the same code in multiple languages for comparison.
For the most part, it’s not that as much work as you might think. You need to spend a little bit of time with a 101 level tutorial for the language you are using (not required but it can help) to get a feel for the language itself. But after that, all the concepts you already know still apply. You still have rules and rules have a fixed set of triggers and a body where you get the states from Items or the event that triggered the rule, calculate some stuff and send commands or updates to Items. So you just need to look up in the docs for how to get the syntax right for that.
For example, in JS you might ask yourself:
- How to I start a rule and/or what is the overall syntax of a rule?JSRule or Rule Builder
- How do I define a trigger for a JSRule? JSRule
- How do I define a trigger for Rule Bulder? Rule Builder Triggers
- How do I get the name of the Item that triggered the rule? UI Rules, JS Rule or Rule Builder
- How do I access and work with Items (send commands, post updates, get the state and other properties, persistence, etc.)? Items
- How do I create and manage timers? Timeouts and Intervals or openHAB Timers
- How do I send a notification? Notification Builder
- How do I work with date times? Time note this is far easier in JS and jRuby than Rules DSL
- How do I work with Quantities? [Quantity] (JavaScript Scripting - Automation | openHAB) again this is far easier in JS and jRuby than Rules DSL
You should be able to go line-by-line in a Rules DSL Rule and ask “how do I do that in X” and the docs for X should have a section that tells you exactly how to do it. As you go along you might find that there are new opportunities to condence things and simplify things. For example:
- conditions in UI rules, JS Rule Builder, and jRuby
- full support for classes, functions, and libraries to centralize repeated code
- ability for rules to call each other and pass data
- etc.
But you don’t have to mess with those. To start, I recommend just reproducing what you have or what you want to do in the new language and over time you’ll learn.
But I also want to stress again, you do not need to nor do I recommend rewriting your existing rules. Maybe pick one or two rules to rewrite to help you learn the new langauge and how to work in it but do not feel overwhelmed and feel like you need to rewrite everything. You don’t and you shouldn’t unless that’s something you really want to do.
The link you have there is a reference to the helper library. This is going to be your interface to openHAB. But to learn the generic syntax for any of the languages you have any one of hundreds of books, tutorials, online classes, etc.
Without the code I couldn’t say. If you want you can open a new thread and I can show what it would look like in JS and you can judge for yourself. In my experience, the JS equivalent would usually be roughly half as many lines of code with a whole lot less casting and converting between types. There’s also support for libraries so it could be the case where it makes things simpler to centralize the code but split the rule into multiple rules.
More than year ago I wrote thing file parser which is free of xtext dependency:
It takes much less memory and resources than xtext as it is much simpler. I have also a prototype of item file parser but its not complete yet.
So xtext is not a must to keep things. For rules its another story.
Here’s two features that I don’t think have been mentioned, that would make my openHAB life sweet:
-
Allow any directory structure for file-based configuration. Currently
.itemsfiles have to be in theitemsdirectory etc. What this means is that my HVAC things, items, rules, and transforms are spread across 4 directories and they’re mixed up with my lighting things, items, rules and transforms. And my extractor fans and heated towel rails, weather… all mixed up. I can’t imagine there’s a technical reason why the current directory structure is necessary; it seems like a relatively simple change that’s completely backwards-compatible, to care only about the file extensions, not the directory. -
Calculated Items. It would be soooo powerful to be able to define an Item as a calculation of other items. For example
Light_On = (We're_Entertaining or Light_Switch) and not Daytime. Sure, it can be done with rules or group aggregations, but that’s more work, less maintainable and less understandable because the item is effectively defined over two files or screens. Maybe this could be implemented as a profile - I’m sure it would be a popular one. But I think the challenge would be that (according to ChatGPT) profiles can’t access arbitrary item values - except via the API.
There are at least three places I can think of where the .js extension might be used and it has different meaning in all four places:
- automation/js : a JS Scripting rule
- automation/js/node_modules: a node.js module, not to be loaded or used as a source for rules
- automation/jsr223: a Nashorn JS rule file
- transform: a JS Scripting or Nashorn JS transformation
- html: a JS to be included on a web page served from this directory
This is more complicated than it might seem, but not impossible.
I don’t see how creating a new Item type changes this. It’s still depending on the states of other Items, and those Items will still be defined elsewhere.
A Script profile can.
(function(data) {
return (data == "ON" && items.MyItem1.state == "ON" && items.MyItem2.state == "OFF") ? "ON" : "OFF"
})(input)
Or if you want it to be an inline so you don’t need to define it somewhere else:
JS: | (data == "ON" && items.MyItem1.state == "ON" && items.MyItem2.state == "OFF") ? "ON" : "OFF"
The gotcha is how to you invoke this as a profile? Profiles only exist on the ItemChannelLink. Which Link do you apply it to? Or do you apply it to all of them?
It’s a matter of syntax.
In Jruby you could write it as a rule like this
changed(Entertaining, Light_Switch, Daytime) { Light << (Entertaining.on? || Light_Switch.on?) && Daytime.off? }
But yes it is a bit more complex than your version. Interesting idea but it’s kinda limited. What happens when you want something more complex? You’d have to expand the syntax and eventually have to end up with some sort of scripting language. Then it will be a new can of worms.
So it might end up easier to just learn one of the scripting languages, or use the UI rule definition. Maybe we need to add Boolean logic to it?
I can see in my Git history that I finished migration of my first real productive rule from DSL to JavaScript 16.12.2022. And my very last DSL rule was deleted 21.12.2024 which finally completed my mission after two years.
My approch was to not migrate 1:1, but rather to take one rule at a time, think it through, and consider how to refactor it, also taking into consideration transformations, semantic tags, timers etc. to reduce/eliminate duplications and also make them more reliable. Some of my DSL rules were also the first ones I ever wrote, and I wouldn’t have written them that way again at the time when I started migrating to JavaScript. I went from ~200 rules to ~150, but in the two year period quite some new automations were also added, so my estimate is that I cut half of the rules.
For me, this process of rewriting all my rules and refactoring them completely at the same time, was mostly fun. Sometimes I didn’t migrate anything for months, so really only did something when I felt for it. I’m sure they could all have been rewritten 1:1 in a weekend or so, but that wouldn’t have been fun, and for sure the outcome would have been… well, still screaming for refactoring. 
This is just to say - there is no rush, and you should do it at your own pace and with your own approach. But the sooner you decide which scripting language you might like best, you could already start getting your hands on that and adding new rules in that language. That would put an end to adding new DSL rules, and the work you probably have to go through eventually will no longer accumulate. Instead you could start migrating a rule here and there as you get more proficient with the new language.
As long as you know JavaScript or Java, using JS Scripting should be pretty straightforward with the docs. Teaching JS is out of scope for our add-on docs, there should be enough details only.
If you don’t know a programming language, it’s a pretty good way to start programming and I even allows you to learn the syntax of the language it generates to (JS).
Thx, Flo,
I am a software developer for more than 35 years now, I know JS as I am earning my money with that language and several others.
What makes no sense without explanation is “Rule Builders” and similar stuff
Also, it is not explained what the rule files should be named?
Should it be .rule like for other rules in OH or should it be.js as in other environments?
And still, BLOCKLY is the most ineffectiv way for a software developer to write software.
The docs are pretty extensive about that:
There is an introduction about it, then there are all methods you can call listed and at the end there are examples.
Ultimately, you can make use of the type definitions (see JavaScript Scripting - Automation | openHAB) to let your IDE show the available methods.
Good point, I though it was in the docs but it is .js
For a software developer that might be true, but calling it the most ineffective way of programming for everyone is wrong. We have users that are no software developers or don’t want to learn the API, those can use Blockly.
And BTW: It’s not Flo, it’s Florian.
I’ve just added this into jruby’s docs because it wasn’t specifically stated there either! 
I would like to have the option of deactivating a Thing in the MainUI that I only need temporarily, such as a socket for Christmas lights. When this is packed away again, I always see a red mark in the interface for the rest of the year. If I delete it, I also have to at least comment out parts in the rules.