Difference of file based configuration approach and UI based configuration approach

Setup, Configuration and Use Migration
1

Hi there,

I started several approaches to think about how to migrate from my files based configuration to a UI based configuration without having so set up all from scratch.
While thinking (and reading :o) about this, I reagularily was wondering about one central point:

Why is this so much different?

When I was starting with OpenHAB I needed some time to understand why I was not able to do the config vice versa. Then i understood, there are two different persistence points:

  • filesystem and
  • database

Still I do not understand why this is needed (anymore).

While I do understand, that, if I start to change something in the UI this is not changing my files (because this would be a nonsense requirement with too much effort.) :slight_smile:

So I thought, it might could make sense to just start the question, why my text-files could not create/update the things (and items and rules) in db, as if I had done this in the UI, without any difference, so I would have the possibility to change them in the UI from now on as well, but if I do this will have no effect to my source file, which will remain untouched.
And if i decide to change the files again, this will update the target db object again with all consequenses: I might loose changes made to them via UI.

So, yes, i would need to be careful, but could have best of both worlds.

Maybe, your answers now will show me, what I am still missing in the details about the core of the different approaches. :slight_smile:

At least, I can learn another detail or two. Or, alternatively, there might be a chance … a way to change the future behavior of this. That would make me happy as well. :slight_smile:

1 Like
2

This exists for items. If you go to Settings → Items and click on the plus icon in the lower-right corner this not only gives you the option to create a single new item via the UI wizard but also gives you the option to bulk import items from a textual configuration file. This works exactly as you have mentioned; when you do this it creates new items in the UI managed item db and does not continue to reference the file used to create them.

This does not exist for things and rules. I do not know how difficult the technical limitations are, but I do know that the create of things is such a rare event relatively speaking (and the same goes for rules), that this isn’t a very pressing feature. It will take at most an hour or two for you to just recreate the things in the UI, and if you are careful to copy over your thing UIDs then all your item links will still be correct. With rules, the same applies. If you already have functioning DSL rules then it is a simple thing to set up the trigger using the UI and copy the body of the rule over to the UI script action.

That said, if you are migrating over an old installation, there are benefits to NOT just importing all your old things and items (setting up the semantic model, for example). It’s worth actually taking the time to consider whether you do just want to start from scratch. There are several features, such as the model page’s Create points from thing button that allow for very rapid creation of well structured item sets that might just be cleaner in the long run than a crufty old set of file-based item definitions.

Lastly, of course, there’s no need to move over to UI managed configurations if you have a comfortable file-based system. That will continue to work. For many users, the control of file-based configs outweighs the benefits of accessing the configurations though the UI. There’s nothing wrong with that.

2 Likes
3

Managed config (i.e. stored in database) is required to support any configuration through the UI. File based configs are somewhat legacy but also popular enough that they are maintained and expanded as needed so users have a choice in how they prefer to configure OH.

I can’t imagine something like this ever working. There are so many edge cases and weird rules required it would always be buggy and always result in surprises for end users. There will be much complaining as users lose work because they forget to include the changes they made in the UI to their text based files before updating.

Let’s say you created an Item in a .items file. Then you added a link to the Item through the UI, changed the category (i.e. icon) and the label. Now you decided to rename the Item so you open your .items file and change the name of the Item and nothing else. All those changes you made through the UI are now gone. Users will start to complain.

There must be only one source of truth. Trying to maintain two is a recipe for disaster. Any solution that results in “an idiot in a hurry” doing something natural and intuitive that results in the loss of data is a recipe for disaster. For those who source control their configurations, what to they source control? As a human looking at what’s in the REST API and in my text files, when there is a discrepancy how do i tell which one is the most current?

Unfortunately, we cannot have our cake and eat it to.

Things could probably be supported this way. Rules would probably not be supportable because so much of what makes a text file based rule a rule comes from the helper libraries and not core syntax.