Configuration of openHAB

IMO, it’s looking pretty good! :wink:

@rule("hello world")
@when("Item my1stItem received command")
def helloWorld(event): 
    events.sendCommand("my2ndItem", "Hello World")
3 Likes

Removing text file based configuration will be a huge turn off. More advanced users with hundreds of things/items file will find a ui-only approach tedious. We should try to accommodate as much as possible all types of users, the same way most schools and institutions are required to provide different methods of teaching…

May I suggest a more live discussion such as gitter or something similar.

2 Likes

So, basically everything i use will be removed. :smiley:

Go ahead, but please do it in openHAB 3.x. I will stay on 2.x until i find a replacement.

1 Like

Come on, the name will stay :grinning:

1 Like

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.

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.

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.

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.

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.

2 Likes

That was just another claim of @David_Graeff he hasn’t even repeated as an argument why we should get rid of Xtend. And @wborn to contradict right in the next post.


I don’t recall him stating Rules DSL is going to be deprecated. Just that NGRE is the future default (or words to that effect).
And I think that differentiation is key to this whole discussion.

Noone is against next-gen improvements/additions such as MQTT2, NGRE and PaperUI-NG.
But David wants to remove the current, widely used functionality pendants for no good reason which is where we all oppose.
Now everybody seems to agree (even David I believe if I got his latest statement right) that there
needs to be or will anyway be a longish transition phase.
That means we anyway have to get OH into a state where current and new methods of configuring (+programming) things/rules coexist flawlessly.

And this is the point where I’m asking myself:
Why the heck should we remove the working+used stuff at all?

Have a look at the release notes: https://www.eclipse.org/Xtext/releasenotes.html

Java 9 was possible since last May, so only two years after Java 9 was released and Java 11 is still not supported although the current long term stability release. Xtend is slowing us down.

Not “removing”, but moving into a bundle that people like me can disable easily. Of course it will rot more and more because nobody will maintain it anymore as soon as it is out of the core. But yeah I couldn’t care less. But this is open source so everybody can participate and keep it alive.

1 Like

First thing to hit the eye when I hit your link is “Java 11 preparation”. So it is going to work with Java 11 some day (probably soon if not already today albeit with a couple of warnings maybe).
Oh, and as we need to keep Xtend and a Java to support it for the longish transition phase anyway, your argumentation is flawed.

OK folks, I’ve been remiss here. I knew this whole discussion is really premature but I participated anyway.

As should be clear, this thread is primarily driven by one developer’s vision and many user’s concerns with that vision. It may or may not be shared by other developers/maintainers of OH but the process is not yet in place to decide if what David is proposing is the direction that OH will choose to go. We need the Architectural Council (AC) for that and it has not yet been established. Hopefully soon.

We have had a great discussion here. Lots of concerns have been raised and this thread (and the other threads too) and they will be here for review and discussion by the AC. And I’m certain the AC process will include community input as well which will allow everyone to express their concerns again, hopefully in a more structured manner than a 200 posting long argument like we have here.

Why don’t we all calm down for a bit. Nothing is decided. We don’t know where OH is going to go re config files. David has presented his vision. Everyone else has presented their arguments against that vision. All of these I’m sure will be taken into consideration by the AC. But the AC will be who makes the decision about where OH will go in this regard. It is clearly an architectural issue.

We can all blame them when we don’t like what they decide. :wink:

I propose we end the discussion here. We seem to be saying the same thing over and over anyway. Then let’s see what the AC process becomes and based on that we can have a more structured discussion there with the understanding that the AC will actually decide the future direction of OH.

3 Likes

Who came up with that name, nice one.

Oops, I added the “al”. I can already see this is going to be a problem for me.

Kai mentioned it in his ESH Merge announcement and named it the “Architecture Council”. See https://www.openhab.org/docs/developer/contributing/governance.html#architecture-council

Ah true, I read about it and forgot the source again.

I want to thank him again at this point.
I saw many complains last days, but only rare visions about a possible future.
I saw many people arguing against one person.
And to be honest:
If i would have been in Davids situation, i would not have lasted that long.
Some parts of this decision had a real bad attitude.
Sorry folks, but that was not the friendly and helpful community i usually find here.
That disappointed me a bit.

Fully agree.
I didn’t participate much (or at lest only reading) last days, because we repeated each X Messages.

6 Likes

Physical text files are not required though.

There was a poll, where most people said they want GUI & Text.
You turn that into: physical files are not needed.

I and many others have said we use a source control system.
That does work with physical files.

Multiple import/export trigger mechanisms could be implemented.

It looks like you only want that for things/items.
For me it would need that on sitemap (or its replacement) and on rules too.

I’m sorry but this shows your absolute inability to read.
The sitemap change was approved by Kai

So far Kai has not been in this discussion and I was not aware this was already approved.
and when.

In every discussion, I only see you(David) as a developer calling the shots.
it could be that you are the spokesperson, yet that was not (still is not) clear for me.
At first I thought I was just ill informed, now I see moderators also not knowing this.

I did not expect Kai to intervene in these discussions the whole moving away from eclipse seems a higher priority right now.

I can understand we need a new way for the sitemap, yet also there I would like a way to configure that outside the gui.
That seems not to have been discussed.

You are so much against change, that’s unbelievable. And you do not even think of a solution (that works!) yourself. Unbelievable. Really.

That’s not true. @Spaceman_Spiff (and others) have done a few proposals. You disagree on the feasibility, yet you can’t claim he is against any change.

I see many people asking for certain functionality to stay.
I see many people making proposals.

As I haven’t seriously developed in Java, I on purposely have not proposed what to do.
I prefer uses say what they need, and developers decide on the how

you as a developer want to decide on the what and you also want user to come up with how. Both are the world upside down for me.
And yes I’m well aware,in opensource stuff is a little more mixed, still I do think that users have a right or better a duty to state what they need.

It seems on top you want a big bang, that really scares me.

We had problems with a too fast move for MQTT.
For MQTT, there still was/is version 1.0 yet the upgrade got screwed up.
There is no one too blame for that, yet we should learn and offer options.

from a developer point I understand that moving, rules, items, sitemaps things all at once is easier.
yet it will make things harder for support, for people to make the move

I have helped many teams over the last 15 years to make smaller upgrades, yet development was harder, yet because teh better support, everyone of the users always moved along. If everything from Openhab 1.x was converted, we would only need to support 2.x
Now you risk that with 3.x you need to upgrade 1.x and 2.x users all at the same time, in a big bang.
As long as people have not moved, you need to manual to stay online and thus also maintain. you have people on the forums that need to know all 3 versions.
That is a support nightmare and that on a forum that does not want to be called support.

You claim that everyone will gladly move and OH3.X will have a lot more users.
yet what I have learned from crossing the chasm theory for IT projects, is that the early and late majority look a lot to the early adopters on what to do. If the early adopters move away because they feel no longer supported, there will be not early majority.

You claim that many in this discussion are against change, yet early adopters, are known to embrace change. If they challenge things, it’s because they fight for a cause.

please get the message.

and yes, I know that right now, for what we are asking, it’s not clear how to do that .
that’s why we need to keep discussing to understand the boundaries of the needs.

I had hoped to go to fosdem and talk to some openhab people in person as it seems we are at the point some F2F discussions can help, unfortunately some family and coderdojo stuff got priority

2 Likes
  1. Because OH2 has suffered solutions for some bindings which I need.

What bindings are blocking you?

I’m working on 2.5 and I’m using 1.x bindings like anel hut, this combination works.
(I don’t know about the speed, I never worked on 1.x in this large configuration)

You were writing your reply while I was writing my post above. I made my post above to address just this very issue.

Indeed Kai is very busy right now trying to get the snapshot build working again. He reached out to me privately and asked me to add a little bit of context to these threads. I feel a little ashamed that I didn’t think to do it on my own and worse, I’ve contributed to the thread going off the rails without making sure the following is clear.

To address these statements, what David has presented here is his vision. He has a strong opinion and I think we can all agree there are merits to his vision. But even if everyone where in perfect agreement, it is still just David’s vision for OH.

Major architectural decisions like this will be the responsibility of the AC. We don’t know what that process will look like, who will be on the AC (I do know the AC will not be strictly made up of developers/maintainers, the users will have a say), or how the decisions will be made by that group yet. But they will be the ultimate arbiters of proposals like this.

Ultimately you don’t have to convince David and David doesn’t have to convince you. You both will have to convince the AC. I’m am positive that the process will let all of us make the cases for our desired direction of OH. I think everyone’s positions are stated clearly here and we will all have the opportunity to make your cases to the AC when the time comes as well.

Because some of the ideas are mutually exclusive, we all have to be prepared that we won’t get everything that we want. But I hope we can all at least feel that our side was fairly heard and considered and decisions are not being made arbitrarily.

This was a good discussion, if a little impassioned. A lot of concerns were raised and they will be preserved here and there will be opportunity to raise them again, hopefully in a more structured manner.

Let’s wait and see what the AC process becomes and then we can answer:

  • who speaks for the future direction of OH (the AC)
  • where to go to find the “road map”
  • how to adjudicate concerns like the ones raised in this thread.

The AC is a much needed by OH and I for one look forward to knowing who ship is steering this ship.

10 Likes

Hah… Now realized, there is an Issue with the Next generation Paper UI design (no offense! I’m aware that is a design study) it does actually not work with firefox :smiley: So indeed I missed about 90% of the functionallity… :blush: Maybe worth to mention, that one should use Chrome…

That’s really amazing and I’m pacified that there will be simplified ways to configure openHAB NG :slight_smile:

Really the whole code? Every snippet of code I saw until now, was blown up. This one is far more better to understand (at least for me…)

1 Like

One should note that JavaScript doesn’t have annotations like Python does so the rules in that language will be a little more verbose but not much more than Rules DSL. I don’t know what Groovy Rules look like.

One should also note that Rules defined through the UI and those fully text based can all work together and interact. No longer will we be faced with either/or choices for Rules development.

Well, I left off the imports, but they would be used by all rules in the script. Here’s a thread…

Note, ‘System started’ will work after this PR, but I’ll need to make an update first. Actually, I got Jython 2.7.1 working too, which will also require an update to the modules.

It does, but not in ES 5.1, which ships with JDK8. JDK9 has some of ES 6, but it does include support for classes. I recently got OSGI working in a JS script, but we’ll need classes for ScriptExtensions. I’ve been slowly migrating the Jython helper libraries to JS and Groovy, with the intention of putting them all in the OH-Jython-Scripters organization (after a rename)… preparing for the addition of Jython and Groovy to Paper UI from this PR. Hopefully soon, I will have some bundles for the installation of Jython and Groovy… possibly with the core helper libraries.

With Nashorn currently deprecated in JDK11, it’s doubtful we’ll see the @, which arrived in ES7. :slightly_frowning_face: But with GraalVM, there will be many more things supported. :slight_smile: