Configuration of openHAB

[rlkoshak (Rich Koshak)]

@Udo_Hartmann

How’s the JSR232/Jython/whatever preferred language looking?

For the UI based Rules in the future it will look something like

Only less complex as you would have a simple trigger, no intermediate, and a “send command to Item” Action.

In PaperUI right now it looks something like what is described in detail here.

Not great but even now users are ignoring the “Experimental” warning and using this GUI for Rules because it is so much easier than Rules DSL for simple use cases like this.

In JSR223 it would be a bit more complex as the user will need to create the Rule and triggers manually themselves in text. See Scott’s posting for a JSR223 Jython example.

Yes the syntax is different. But given the availability of libraries (which I’m pushing to become a standard part of Rules rather than something users need to download separately) it is really no more complex than Rules DSL. And we now have the opportunity to have GUIs built such that no code at all is required for a hello world case like that.

There is no functionality in Rules DSL that is not available in JSR223. There will be no functionality available in Rules DSL that will not be available in NGRE (i.e. GUI Rules). But besides being as simple as Rules DSL, there are some real improvements:

• the ability to import libraries of Rules written by others. This is the biggest improvement for users IMHO. No more copy and paste from some DP posting. If a user wants to use Time of Day or Heating Boilerplate, they can just “install” it and use it. No need for writing complex code in the first place.
• the ability to build Rules a la NodeRed for those who are more GUI oriented, very little need to actually “code” Rules for most simple cases. And for the complex cases, there may be a library that can be used.
• much faster to run and parse
• the ability to enable/disable Rules through Rules
• the concept of “but only if” which lets you define what state OH Items must be in to run the Rule (replaces all those if(MyItem.state == NULL) return; lines at the top of every Rule.

@Udo_Hartmann

How’s the JSR232/Jython/whatever preferred language looking? By the way: an easy to learn language like VisualBASIC would be very nice, at least for the execute part.

The languages supported must be supported by the Scripting for Java platform. I don’t know the full list of languages supported. I also know that not all listed languages are supportable by OH. There was some effort awhile back to support JRuby but there was something about OH or JRuby that made it not work even though JRuby is a language supported by Scripting for Java.

One thing to remember about writing Rules in this environment though is that if you use the GUIs, you really only need to learn the very basics of the language. If you want to use text only then you need to learn a little more but are not required to become an expert in the language by any means.

@Udo_Hartmann

I’m not a fan of GUIs when the GUI is “One field per parameter, One page per channel” and so on.
I’m ok with a GUI which provides a text-like configuration (like demonstrated by David far above…)

There has to be an option to do mass changing (like changing dozens of group membership for Items in an items file at once). In a text file, it’s so easy to change all appearances of a single word, let’s say I want to change the word “kitchen” to “Küche”. When defining a mass of similar items, in a text file I’ll do a copy&paste and change a detail of each item. PLEASE make it easy for users!

If you haven’t looked at https://davidgraeff.github.io/paperui-ng/index.html and Next generation design: A Paper UI replacement proposal you should do so. There are three views of Items (and Things and such). One of those views is essentially a text editor that allows all of those copy/paste/edit operations.

@5iver

As for the NGRE, it has obviously been merged, but there has not been any approval for the deprecation of the existing rules file format. There’s no foreseeable future in which such a breaking change would be approved.

And Kai stated at the last industry day (or whatever it was where the latest set of videos were recorded where among other things MQTT 2 and HABot were introduced) that Rules DSL would be deprecated and not the default but there will be a time at least where the two continue to live side by side. I believe he also mentioned that there would be some sort of migration path rather than just a big cutoff leaving users behind. Perhaps the conversion of most rules to Groovy would be that path. Perhaps allowing users to install Xtend and continue to use their existing Rules on JSR223 would be that path. I don’t know.

I was comforted by this. And I believe that will be how it has to happen. It won’t be really soon (too much work and too few developers) and despite what David stated, I don’t think it will be done without some transitional period and/or migration aides.

I haven’t seen any announcements about the new adjudication process yet so at this point all we can assume is that David is stating his desires. Any major structural changes will need to go through some sort of process. And while many or most of the proposed changes are approved in legacy (i.e. it was agreed to before bringing ESH back under the fold) how those changes get rolled out to the users would, IMHO still need to be adjudicated.

We cannot have another repeat of how disruptive the MQTT 2 roll out occurred. We lost users over that.

@job

So, basically everything i use will be removed.

Replaced

I don’t know why everyone is surprised by this. It’s been talked about replacing all of these file formats (and Rules DSL too) since before OH 2.0 was released. We are just now getting around to talking about what they get replaced with.