Next generation design : Ideas & Discussions

Unfortunately I can’t please Markus @mstormi in my proposal and let the current .thing / .item files stay as they are. XTend really needs to go. Starting up OH shouldn’t take half an hour for a decent setup.

I understand the need for removing XTend and I agree with that. I am also not opposed to change the file format, if this has benefits. ( so, not a total die hard old timer and btw. I just finished rewriting all of my rules in Jython). I just prefer having editable files in text format.

I agree with what rlkoshak wrote, some tools for making the migration easier would be needed, as nobody likes spending hours and hours, just to have I system with the exact same functionality as before.

What I would like to understand, just to get a better insight is, why there is such a big dependency between XTend and the current file syntax. Would it not be possible to rewrite the parser using one of the parser generators available? Of course this would leave the problem, that this solution would have to o be maintained by the openHAB developers.

That is possible. The grammar need to be written though. And there is still the problem that there is no tooling for our custom syntax. xTend is not the only problem. There is no file writer existing for exporting the internal openHAB state back to files. And if you read through the forum you will find especially newcomers to struggle with the syntax. It is not structured enough, to be honest. But you will find all of this discussed in this thread already.

I am completely new to OpenHAB, just installed a week ago. I tried to use PaperUI for about 2 hours, before I gave up on it and switched to edit files in /etc/openhab2 - not just because I have to use some v1 bindings, but because of the amount of clicks/interactions needed to add things/items and the fact that it does store the created objects in a different location than /etc.

If there was an editor in the browser UI which is editing the files in /etc, that supports syntax highlighting and is showing contextual help for the type of object I am currently editing, so I don’t have to open a browser window next to it, I would use it.

1 Like

It’s really Xtext I think which is the base language parser that is used to define the syntax for both. In short, we currently have the exact situation you describe with Xtext being the parser generator that was used for the config files. Xtend is a programming language whose parser was also generated using Xtext.

So moving to some other parser generator doesn’t really improve things all that much because we are still on the hook to maintain a custom grammar and reliant on a single source for the parser generator libraries.

And the parser generator only gives you half of the problem (reading). We still need to be able to write in order to have a migration path between text and UI configs.

In short, IMHO, moving to some other parser generator will be a lot of work for very little long term benefit.

Though I’m only halfway through the thread, as a user since 1.5, I would prefer a GUI solution. I’m on board with your solution.

My proposal is online: Next generation design: Paper UI design study

1 Like

When Paper UI arrived i started to use GUI for both things and items.
After a while i went back to text files depending on that i had to recreate many things when i updated different bindings- When i use text files i do not have to recreate things when updating.

I we can solve that issue i think it is best for general users (the ones that is not daily here :smile: ) to use gui for configuration.


1 Like

Yes that’s a known issue in the core that hopefully is resolved some day. In the meantime a simple “Recreate that Thing” action in the openhab-cli or via GUI would already be helpful.

1 Like

+1 yes would be really helpfull :slight_smile:

And perhaps (should be easy if the other thing can be done) „change thing type“.

Aren’t comments an issue with JSON currently? Does yaml allow comments?

Yaml supports line comments. Json doesn’t. However gson the json parser used by oh does support al kind of commennts. Reading is one thing, writing yaml or json removes all comments.

1 Like

I have put together a “roadmap” document and one point on it is to let Things/Items/Scheduled-Tasks have a generic comment/annotation. When presented in textual form to the user I thought about pulling that field out and put in front of the object, like so:

Database form:

  some: "value",
  annotation: "my little comment"

Textual form (yaml in this case):

# my little comment
   some: value


Looks good David. IMHO, I can’t remember what I did last week without comments in the files :slight_smile:

Not related to configuration storage…

I would like to see a less tight coupling between the add-on/bindings and the core.
Maybe using something like the package.json construct.
As it is now, I’ve ‘needed’ to opt for beta or even nightly build of the core to get hold of a version of a binding that I wanted.

Not necessarily. You can download the binding’s jar file and drop it into the addons folder. That is how lots of users run newer versions of bindings on older versions of the core.

Though sometimes there are changes to the core and/or the bindings that make newer bindings no longer compatible with older cores.

Ok, but I’d still prefer a standardized way for an add-on developer to be able to state
the requirements for the add-on to function. (This is new Generation Design…)
Also, running on an RBPi with only a console, it is not just drag’n drop :blush:

I do think the environment should aim for less fiddling and more ‘out-of-the-box’.
So I confess, I want all to be handeld through GUI. Even though I love vi as an editor.

Also, if ‘we’ opt for continued file editing, I think it should work out of the box with vscode (or similar)
If that is a pre configured webdav server presenting all config- (and log-) files so these things work out of the box.
Needing to learn how NFS (or SAMBA) works to turn on a light may hinder the masses from using OH.

I do not think that works from the command line vi ssh. :wink:
OpenHABian already has a Vim addon if you want that.

So, they use Windows then. Exchange those problems for another mass of surveillance.
If people choose to use Linux they need to learn how to use it. That is outside the scope of OH, in my opinion.

So you’re among those ~5% to prefer GUI over text. Given this sort of prepackaging you would like to see would adversely affect all of the remaining users, this sort of streamlining will not happen, at least not inside openHAB. Flexibility ever has been and still is among the top reasons to choose OH in the first place.

Editing and file management is out of scope of OH. You’re confusing things a little there.
For those who want some sort of standardized OH environment without willing to learn Linux, there’s openHABian, to provide a logviewer, vscode enabled editor and more (a complete server in fact).