Configuration of openHAB

The others also haven’t denied what I’m saying. Think about it.

Partly correct yes. All shortcomings of OH can be worked around. You can of course always just use the UDP, TCP and EXEC binding to do your stuff. Start time is slow? Just create one rule that loads the other rules in one by one after a given time. Problem solved.

But really that’s not how it should be. The core should be stable and each core bundle would only provide one way to do a thing (like the UNIX philosophy) and workarounds should not be necessary. .thing/.item files are contradicting this goal.

But I really don’t know why you fight against this improvement. You will barely notice if your .thing files are read in by the core-xtend or by a separate service io-thing-files.

Correct me if I’m wrong but you’re the only developer taking part in these discussions. Dunno if anyone else is even reading (if so, please step up).
The rest to discuss is users, and most of them oppose. They only don’t ‘deny’ because they don’t have the code insight it would require to discuss on par with you. But that does not mean they agree.

I’m not fighting the GUI improvements you propose. I like them, please keep up the good work (really, no pun intended).
But I’m fighting your push to remove proven, working functionality that is in widespread use.

The unfortunate and I believe unnecessary thing you’re doing is to tie those together by repeatedly claiming GUI and speed improvements can’t be done without removing Xtend.
It can be done. You can implement an alternate parser, you can even choose to ignore that - start time is annoying but in fact negligible if users don’t ever have to restart (which I hope you agree is another OH vision albeit one that has become reality). It’s both alternative solutions that you just don’t want.
And you’re putting the wrong priorities here. There’s also other problems to affect performance even more that your changes won’t help against such as unnecessary rule re-processing. These make up for the major part of OH slowness and annoyance in real operations.
You for yourself identified Xtend to be the culprit of everything so you want to kill it and you’re unwilling to think into any other direction which may e.g. result in coexistence of Xtend based file input and GUI improvements.

No, and that’s another thing you totally underestimate because you have the developer’s view only.
All users will notice and will need to act upon whenever the interface changes.
Examples and responses on the forum become invalid, proven configs stop working, questions answered will be raised again and need to be answered again. Tutorials need to be rewritten.
Users will turn away from OH because changes like yours broke their setup.
Just for a moment, try to imagine the amount of work your changes would inflict on all OH users with an EXISTING OH installation it’ll take to move from their current Xtend based input format to say GUI based definition or also any changed but still textual format such as YAML. And remind you they’re not power users as all of us to discuss here are.
I’m a forum member to help people with their setup questions. Do you now understand what your push would mean to me and my contribution to OH ?

That’s what you fail to understand your vision results in. I said it on a couple of occasions already but
feel I need to raise this again: you only think of this as a developer. But the vast majority of people is not developers but users, and those don’t care about many of the things you’re interested in such as to remove Xtend. But they are afraid of the work and following outages it’ll take them to migrate config when they’re forced to because the interface changes.

3 Likes

Another idea to find a middle ground: @David_Graeff keeps insisting that the majority of the users are GUI-and-GUI-only users.

So, how about, having one release where we remove the Eclipse Smarthome stuff, keeping the guys at Eclipse happy. In the same release, every Thing (and maybe Item) that has been configured via xtend-files shows a big friendly warning that tells the user “User dearest, we want to remove xtend, so consider moving to our new system of Paper UI config”. Of course, we would need a setting that persistenly tells the system “YES, I KNOW, I READ THAT” :grinning:

In the next release, David can fully kill the xtend core, telling all the users that they have been told that they had 6 months / one year of time to upgrade their configuration.

Maybe this would keep the flood of questions in the forum a bit in check. And David and “the other developers”, who kept silent in the many permutations of this discussion, can reach their goal of killing xtend, albeit a bit later than desired.

The last thing I would like to see is people (and ideas) moving away from openHAB because they feel that this thing is breaking everything on every release (our latest Pearl Harbour being the unfortunate timing of the introduction of MQTT 2 just before 2.4)

Or, even worse, people feeling that the commercial walled garden setups are much better than that unreliable Open Source Crap :sob:

2 Likes

I really don’t see it that way. He invests his time to help new openhab useres with a good GUI - as a programmer he also could just made a parser for himself.

I also see him trying to get you onboard with his IO Service. I don’t see why this wouldn’t - read no technical argument why it would not work.

1 Like

PaperUI-NG is basically a separate track and does not have much to do with the configuration changes that he wants make.

David wants to get rid of Xtend in openHAB. He does not want to write a parser for the current Xtend based configuration files such as the .things and .items. There will be a new format incompatible with the current format based on e.g. YAML (the IO Service could support more formats so YAML is not written in stone).
Markus’ point is that this will render all the current examples and solutions in the forum and documentation usesless as these will no longer be valid.

Removing Xtend from openHAB will also obsolete any DSL based rules that people have written. In my opinion this will be the biggest pain point for most current users.

1 Like

They are just “imports” and not a source of truth anymore. If an import conflicts with a database entry, it will not be imported.

I can understand the need for a single truth.
I understand if you have people working with the gui, they prefer that the import is turned of
as I don’t intend to use the GUI for configuration, I hope I can turn this feature of.
I want the config file to be the single truth and thus overrule whatever happens in the gui that I did not specify.

4 Likes

This exaclty.

1 Like

Very interesting discussion
The configuration methods are an important piece of the puzzle and the subject of this thread, but an interesting aspect provoked by the discussion is the performance aspect of the system. David has identified one shortcoming of the equation and created a variant which eliminates the bottleneck. The solution for configuration is not yet at hand but will be found with so many bright individuals working on it.

  • exaggerated start times on RPis (dozens of minutes or more)

I understand that, and I don’t like it, yet might be ok for some if that is the only way to stay with configs, that is only once every x days/weeks.

  • rules start triggering before the system is ready, giving strange errors like “no such symbol OFF”

That should indeed be turned of until the openhab system is ready.

slow load times causes reloads of config files as they are being edited to get queued up to the point that OH can become unresponsive for hours

that is indeed a bad thing, another reason why I do my changes in source control and load them all together, yet I do notice that indeed sometimes it seems to load the files twice. No idea why, I guess an order for certain config files should be set for loading.

Really, how often do you need to restart openHAB? It should be running 24/7/365. A reboot every now and then shouldn’t be a big problem if it takes a little longer.
Let’s put things in perspective here, we’re talking about a home automation solution.

The main, “productive” Installation which must not break lest the family kills me? only if I buy new hardware (which is far too often, but this is another topic :grin: )

The “test” installations where I debug new bindings, or develop some new stuff? multiple times daily, but only on the weekends when I have time to play with stuff.

All my deployments are as hands-off as possible. Should something happen to the server, I want to be able to switch some spare Pi on, pull the docker image and be good to go. When replacement hardware is bought, the same game, in the opposite direction. Kill the Pi, restart everything on production, and hopefully no one will notice :stuck_out_tongue:

1 Like

But I guess you’re not doing this on a Pi, right? This problem seems to be an issue only on the Pi. If you do your development on a laptop/desktop then it is far less noticeable.

To upgrade the production server you first need to contact the Change Control Board and get approval for the nightly maintenance window. At least it seems for some the end of the world when openHAB isn’t running for like 30 minutes, so I guess that is what they need to do :slight_smile:

Maybe it would help to get a link or a short statment of the current state?

Text files are the truth files for?
all things, items, channels and rules defined in it?

  • but these are also serialized into the jsondb ?

The jsondb files are the source of truth for anything else and features like discovery, persistence,…?

No.

I want to repeat my question:

Hacking is being done on my main dev boxen. “production” is an Intel NUC that lives in the basement with all the other networking stuff. And a Pi ist mainly a backup if and when the NUC dies, and should be preferrably be replaced as soon as Amazon gives me a fresh box.

For us, it’s the properly automated operation of the window blinds. The lights are managed by a Hue controller, I don’t dare breaking stuff there :grin:

1 Like

Both are valid points.
There would be a need for a conversion script to migrate the existing configuration to the new format and I will happily provide a python script that does all the work.
I really think it is possible to migrate configuration to a new format but for rules I definitely agree with you. There is no way that users have to throw away their tested and maybe even complex rules so we well have to keep Xtend at least for the rule engine.

Every time in this thread you write about the runtime “database” it is the reason something does not work or will not work in the future anymore. Maybe it is time to rethink this whole database thing?

Without going into too much detail, but this is the core of how openHAB 2 on top of OSGI operates. The architecture was developed on purpose like it is by Kai and all the other project initiators.

Home Assistant does it different. And as a result you need to restart it after configuration changes.

I really ask you to support the fact that there is an untouchable runtime-database in the background, which happens to be human-readable (and might as well serialize into different files in yaml format in the future). If you want to restore your OH setup to the last bit (including session tokes, passwords and whatever), you would just restore those files.

And additionally there will be an IO-service that can import/export .thing/.item files in whatever format, trigger based. It will use the official ways of OH to manage things/items, not like the current Xtend solution which bypasses those.

Not true. There is an option to reload configuration during runtime in the GUI.
It just happens to reload the config files on startup, too.

But how can I support it if it only seems to have negative impacts. It seemingly doesn’t support such simple things like a configuration file.

Would be fine with me if I could specify passwords in the config files. That’s where they belong actually.
It really seems this “runtime database” is a bad mixture of cache and configuration and maybe this is why things seem so difficult right now.
Maybe there has to be a stronger differentiation between cache and configuration.

I’ll try to translate:
support it > believe it that this is the current state

1 Like

Very short sighted, probably because you don’t use auto-discovery. openHAB can negotiate session tokens with services via auto-discovery and you will never see those “passwords”. That’s how oAuth based services, ikea Tradfri or the Hue bridges work. Except if you want to create the tokens yourself and enter them in your config files each time.

Yes it is a mixture of cache + configuration + runtime data. And that is the correct and wanted behavior. And the reason why your vision of jsondb->yaml-config-files cannot work straight away. But it does work with a dedicated IO service.