I am not sure about .rules files, but i think .items files (and their way to configure stuff) should be kept.
It is known for long term users and i think a parser and corresponding maintenance can be handled, even when there should be a “modern replacement”.
.rules files can be very complicated and i can make no statemant about the work that would have to be done for a parser.
I have slightly differnt opinion on .things files:
I try to avoid them, where possible and user Paper UI instead.
For me, it is useless time to learn “the next way of writing thing files”.
Yes, the Paper UI could be improved here and currently you have many clicks to do for thing and channel configuration.
But if there would be improvements for this and the ability to select and edit multible things/channels/items in a row, i would like the idea of having a “standardized/consistent” way of handling things.
If i have to learn the things style for a specific addon anyway, i see no benefit in doing this on a textual basis.
I would guess that using the same and consistent “Future UI” in the addon specific way would be faster, as long as this UI provides not a “fancy” but useful interface for doing this.
Also i don’t would have to learn the addon specific keywords, since they are provided by the text addon through the UI.
My (personal) conclusion:
If there would be a powerful UI, that
can handle things properly and supports textual configuration in an extended way (i would call that vscode-like for now) and parallel editings,
i would love to keep already proved and widely used ways of configuring
(at least .items, .rules when possible and maintainable) with a parser
and get rid of stuff that is not consistent (.things files and its countless possible variations)
and try to improve those to a more common way of configuring different stuff on thing level.
Surly I could probably reduce my items quite a lot. There are some I only need for rules and I created quite some items for communication objects of my KNX actuators, which I currently do not use, just in case. I would have to guess, but probably more than 50% of my current items would still remain.
Today I added 30 items, again some „just in case“ . Using sed to duplicate existing lines in the things & items definition and search & replace after that made this very fast.
I like VSCode a lot and use it very often, and I could imagine using it in a web interface, when at home. But I surly would miss the ability to use sed, awk & grep.
But a web based editor, regardless of the functionality would not be sufficient for me. While I am not at home I quite often (but certainly not daily, admtted) use my iPhone to edit my config using joe in a ssh shell. I can not imagine that a web based interface would work over a sometimes very slow internet connection and on such a small screen, but maybe I am wrong.
I am developing software for more than 30 years. I can not count how may times I heard, that the new shiny GUI would make tool xyz superfluous and would be much easier to use. In some cases this was correct, but I a lot of cases it was not. There is a reason why people, myself included, still use makefiles and text bases tools, this is all because of the efficiency they bring. In quite a few cases I started using some graphical tool in the first place and switched to the old way after I came proficient.
I do not have tp use the new. shiny tool, just because it‘s new, if it provides significant advantages people will convert to it without beeing pushed.
Let me just briefly chime in here - I see there’s a lot of interest and enthusiasm in this discussion here and I agree it is an important one for defining the future direction for openHAB. I think we all agree that there there are good reasons for text & GUIs and that different people will always find themselves at different places in this range - and openHAB should do its best supporting both sides in a decent way.
I am also aware that there’s a lot room for improvement both for text & GUI configuration, so we should discuss the best way forward. My wish right now would be to delay this discussion just for a little time as some bigger technical changes are likely ahead and I’d like to introduce some clearer governance along with that - because discussing ideas is worth nothing as long as we do not know how to take a decision. I’ll have some news within the next two weeks on that, so please be patient and bear with me - thanks!
Yes, I have no objections whatsoever against an import that I have to start explicitly. In fact, for may workflow, I would see advantages in this, as I could change multiple files in place and start the import after everything is changed and fits together.
As already discussed, this import could be triggered via the rest interface, than it could be started from the shell too.
I agree, I find the GUI’s and Text file editing just fine once you’ve got a base setup and that there are more pressing issues that should be addresses before attention is diverted to these types of issues.
stability, erronuous errors, zwave enhancements/stability, improvements in troubleshooting or at least making it easier to determine why things break are in my view are far more pressing and help the usability far more than making the changes suggested in this thread to UI’s and methods of editing.
And with a new improved Paper UI, usage of text files will gradually die out. That’s simple a fact gathered by observation. Most new people are only using text files because of copy/paste, tag support. Not a problem in the future. It is really just the “stubborn” don’t-take-away-what-I-already-know OH1 folks, that don’t try to find a compromise here.
I started with OpenHab 2 and I choose to use the text files.
It is really just the “stubborn” don’t-take-away-what-I-already-know OH1 folks, that don’t try to find a compromise here.
I (and I think others as wel) have been trying to find a compromise.
I understand you want to remove the current file system.
That’s fine for me. Under the condition that I have a new way to configure everything text based.
And I do think that for openhab to stay healthy, you need an automatic conversion from the current file system to the new one.
That is the fastest way to convince people.
I agree. I suggest the Import/Export pattern. A file format that is readable/writable/has many tooling (yaml, toml, xml, json, eno-lang, …). And a (command-line?) import tool for current .thing/.item files including comments and file association.
But if I understand correctly we can’t have both. The syntax for Things, Items, et al is defined in Xtend. If we keep the current formats we keep Xtend.
Whose was it or was it just something that happened? IMHO this was the biggest mistake for how the MQTT 2.4 binding rolled out. Many many hours were lost by users and support on this forum from this one decision and I would like to prevent that when other highly used bindings get a 2.x version, HTTP in particular.
To play devil’s advocate. What is being offered to the “stubborn” OH1 folks to aid in their transition? Many have many thousands of hours invested in their home automation and no transition path is on offer here to help ease the pain of transitioning to something new. They may be looking at many man weeks worth of effort just to stay where they are.
They are not being stubborn. They are recognizing that the loss of their current configuration is going to require a tremendous amount of work on their part, work that will provide no advancement to their home automation at all. The concern is real and shouldn’t just be dismissed.
If it can’t be supported, at least provide aides to migrate. Ease the burden and while there will still be complaints and grumbling, it will likely leave fewer people behind. When it comes down to it, if I looked at an upgrade to OH that will require too many hours just to achieve parity with my old version, I might look somewhere else instead of upgrading. At least with a new system I’ll be learning something rather then spending hours with point/click/copy/paste/save over and over again.
This is what a lot of the “stubborn” users on the forum are telling you.
And there will be users who indeed, never will be happy with the change. You can’t please them all. But you can’t abandon every old timer because of the few who will never be satisfied.
Can we explore this a little more. Under what circumstances would this occur? Let’s make the problem simpler and assume we only have one admin user mucking with the config at any one time. Under what circumstances would a user accidentally overwrite something OH just wrote?
Wouldn’t something simple like most cmd line text editors provide like “this file has changed on disk, are you sure you want to save” suffice to mitigate that?
It’s already being done. That is what the Experiment Next Gen Rules Engine (NGRE) is and will be. And based on statements made by kai and others it will replace the Rules DSL as the default Rules Engine. Before everyone freaks out, there will be a transition path made available that will let existing Rules DSL Rules to run on the NGRE.
But what Things did for automatic discovery the NGRE will do for Rules. They are going to be different. We will have to think differently about how we construct Rules and optimizations and such. I’m guessing about half of the Design Patterns will become deprecated. But it means we can create NodeRed type Rule builders which will be a huge boon to new/less technical users.
But to bring me back to my earlier point, there will be a transition path. We will not just shut down the Rules DSL and replace it with NGRE and good luck to you transitioning.
I don’t think this is feasible.
Many times the same things you like about .items files are needed for Things as well
We have already reached the point where .items syntax isn’t able to keep up as new features get added like Metadata tags needed for HABot
One of the things that is keeping us back on Java 8 (if I understand correctly) is the Xtend libraries and the syntax for .items and .things are defined using those libraries
We have no way to write back out to these file formats meaning we have no way for users to transition from one approach (e.g. all PaperUI) to another (e.g. all text based). Right now if a user wants to switch from one to another they have to essentially start over from scratch with their definitions.
So you’ve hand coded Simple Mode? Or are you doing something more involved?
I don’t want to blame anyone, all I can say is that it wasn’t me
Read my post just above yours. An one-time import tool for .things/.item files would be part of such a new solution. Provided as a separate java application, for example.
I don’t want to blame anyone either. I want to open a discussion with them so we can prevent or at least mitigate the problems that occurred when the MQTT 1 binding disappeared for so many users when HTTP gets replaced. I’m fine with a PM. I really just want to make upgrades like this a little less painful.
I don’t remember that exactly but as far as i know this happens automatically when a binding becomes legacy by introducing a OH2 version, which wasn’t there before.
If yes, then it could be discussed if this makes sense all times or if there should be a mechanism to catch this eventually.
I noticed that early on because I implemented this behavior with the docs pages on the website, if there’s a “foo” binding it automatically deprecates any “foo1” binding if it exists (meaning it won’t appear in the menus etc.), put a banner on the old binding’s page and so on.
To be honest while I wouldn’t have minded too much for any other binding, for MQTT I immediately thought “uh-uh”
And it will happen once again with the HTTP binding too. That’s why I want to get ahead of the problem.
I figured this was an automatic thing that happened and it impacted the less technical users the most because these are the users who are most likely to have “Show Legacy 1.x Bindings” disabled and less likely to know and understand they need to enable this to get the MQTT1 binding back.
For many of them the assumption was “Well, MQTT1 is gone, now I have all this work to learn and move to a new version that is totally different. Thanks openHAB! ”
There wasn’t even a mention that this might happen in the release notes.
I want things to go more smoothly in the future, even if all we do is enhance the release notes to really inform the users what they are in for.
My guess is, nobody remembered it would happen and it took everyone by surprise
Then I’ll as go as far as to say (it’s just an honest question): do we really need to replace all 1.x bindings, and do we really need a new 2.x HTTP binding?
I mean, if I get it right, we’ll have to define some “HTTP things”, whatever they are, just for the sake of it, link channels and so on, while I just want the state of my item to follow some HTTP response… is it really necessary? Could we not agree the “old” 1.x way of linking items to bindings is still a thing (no pun intended)?
Yes. As soon as OH1 support is removed from the core every OH1 binding stops to work.
On top of that, there is already a working OH2 http binding in review process.
Doubles the maintenance of developers. You could just use OH1 if you don’t like Things/Channels?
I understand the developer POV, but I also chose openHAB 2 years ago because it had an Epson Projector binding. This binding might or might not get an upgrade to 2.x. If nobody does it and 1.x support is dropped just because, openHAB will lose a lot of appeal to me.
”