That was not my point. Just updating openHAB will usually bring no benefit, you need to use the new features. Things need to be recreated, triggeringItem need to put in rules, same goes for MemberOf.
So, unless, the person doing the upgrade to the framework is also capable of applying the changes to the custom application of rules, sitemaps etc. you won’t get a benefit of the framework update.
Webview element to display url stored on String item.
That’s exactly some of the information i am looking for. 
If i remember correctly, at least the UI of the rules engine was something like that (dropdown for each bulletpoint):
This would be too simplified for my taste. Maybe for everybody who is able to write a script. If it is possible to write similar complex rules like the current one i am all for it. But if the direction is “one item, one trigger, one action”, I’d rather stay with the current one.
There is a + for each bullet point that lets you create multiple Items, multiple triggers, scripts, conditions, etc. for each. You are not limited to just one for each.
There is also the addition of a when clause that lets you set conditions under which the Rule executes (i.e. the much requested and in the Rule trigger). That is the “but only if…” section. I’ve added two to each field in the screenshot above. You can also see that you can have multiple actions for a given Rule as well.
The whole thing will be saved in JSON (see https://www.eclipse.org/smarthome/documentation/features/rules.html) so you will not be forced to use PaperUI to write rules if you don’t want to.
It does appear that JavaScript is the only language currently supported but I remember talk of all of the JSR223 languages being an option at some point (i.e. Jython and Groovy as well).
The Experimental Rules Engine has not yet reached parity with the Rules DSL in capabilities (it is called experimental for a reason) but I can already see that it will be a great improvement of the Rules DSL in the not too distant future.
Thanks for the info.
This excerpt from eclipse smarthome makes me shudder:
Concept
In general this rule engine aims to support rules defined with syntax similar to:
ON item_id state changed IF item_id.state == desired_value THEN item_id2.state = desired_value2
Not many of my rules are like that, just the simple ones. This type of logic is quite often directly inside my devices (e.g. heating, window contacts & temperatures).
I mostly need openHAB rules for special cases, when standard functionality is not sufficient. This would be most likely somewhere inside “a given script”. If the “given script” will be restricted to the above standard case (or a limited number of additional others), i will be not that impressed.
I usually need some string concatenation or splitting, calculation, conditional logic based on that as well. I could replace that with a mass of proxy items and transformations, but i am already well above 1500 items, i would not enjoy that.
I don’t care which language that will be, I am at least a bit familiar with all common languages, even the current language would be fine (the most unusual i’ve seen in a long time).
If you are editing your jsondb, what tools do you use? VS Code or some scripting language?
There are no such restrictions in the scripts. That concept section is describing the overall structure of a rule, not the sum total of what can be achieved with rules. A rule will have one or more triggers, zero or more conditions, and one or more actions that take place when the trigger occurs and the conditions evaluate to true. One cool thing that may not be apparent is you can write a whole JavaScript script as a condition which can give you the ability to have very complex conditions.
The Experimental Rules Engine as it exists today has no such restrictions. The only reason I’ve not experimented with it much yet is I don’t think it yet supports Timers, though I mostly use Expire timers these days so maybe it is time to start playing with it.
The script will support anything that can be done in JavaScript. I don’t know if it will be possible to import JavaScript libraries so you might be limited to just the core of JavaScript, but there is nothing you mention that cannot be easily done using just core JavaScript.
I rarely directly edit my JSONDB. On occasion, I’ll open it and fix something quickly using vim. Mostly, if I need to do much more than that I’ll go through the REST API. But the vast majority of the time I let Automatic Discovery do its thing and I just accept the discovered Things from the Inbox either through PaperUI or the Karaf Console.
I reviewed the experimental rule engine, just to know what i am talking about. Overall, having such a feature, is an improvement. No need to think of syntax, except for the code body. And that being javascript is also more common than what we have now.
The whole structure is (technically) the same as what we have now, not a change of approach like a graphical editor. People who are afraid of text editors may enjoy using it.
So far, so good. People who are used to editors like VS code will seriously hate it. A simple Web-Text-Input widget is not state of the art. The item dropdowns are horrible, if many items are involved. This is a problem throughout the whole PaperUI, so i do not know if this will ever be changed.
Since the apporach is the same as now, it’s easily possible to add an import function to load/reload the files into Jsondb. But if the direction of openHAB is that file usage is a bad approach, i doubt it will be done.
May i ask how many things and items you are using approximately?
I am running about 130 devices and between 1500 and 1800 items. All the large changes in the pipe are aimed to support smaller installations or support less technical users, while may making maintaining of larger installations more difficult. I understand, this is the majority of installations, but the openHAB core is able to support both easily, it’s just a matter of different input methods.
Sorry for bothering you with questions, but i am currently thinking about either staying with openHAB and becoming a member or switching to something else (long term). The current state is fine, the outlook may be even finer, but some details in the implementation trends make me fear if i will be happy in 2 years as well.
I think overall you are looking at things are they are now and projecting into the future that things will just as they are now.
OH is constantly growing and changing and migrating. It is unreasonable to expect that the Experimental Rules Engine will continue to use “A simple Web-Text-Input widget” in the long term. You are looking at a work in progress and saying “well, this doesn’t help me now” and projecting that into the future.
I’ll say it again.
Many of the maintainers run very large systems as well. I doubt they will make any changes that make maintaining their systems harder.
If you are basing your decision to stay with OH or not based solely on the state of the experimental and in progress parts of OH as they stand now, you do yourself a disservice and it reflects a lack of trust in the maintainers. No one is going to remove anything from OH until there is something in place that works just as well for both “regular” users with modest technical skills and smallish systems and “power” users with massive deployments.
Software does not spring fully formed from Zues’s head like Athena. It takes time to develop. So developers can either wait until their software is fully built and capable (and never release anything), or release changes and features as the become capable enough.
I will not be surprised that all developers continue using config files and Visual Code extension rather than Paper UI for their own HA system. Of course I hope this feature will never disappear, I think it is the best option for advanced users.
I would like to add to the list:
1.) Editable datetime on the sitemap.
2.) Built-in delayed rules startup. If my rules start before my bindings, I sometimes get a lot of errors.
Right now I am delaying my rules startup with a combination of Thread::sleep and “when System Started.” For each rule, I have an if statement that checks if the system is done starting.
