Configuration of openHAB

(Sebastian) #81

I am not talking about external reference but rather custom classes which do load and merge the other files.
This is fundamental and why this concept works.
!!load_from_file items.yaml is not an external referance but a class that gets constructed with the external filename. It is then used to merge the manually created configuration with the automatically created one.
The class gets serialized to !!load_from_file items.yaml with a custom resolver but actually does contain the file contents because these get loaded in the constructor.

I am fully aware that the files on the disk are always just a serialized copy of in-memory state.
But this is no problem.

Let’s play a load and a dump through.


  • openhab does serialize to/from openhab.yml and it contains a gui-configured thing “GuiThing”
  • a custom thing “ManualThing” is defined in mything.yml
  • in openhab.yml there is a class registered to load mything.yml
  • there is a file-watcher in place for openhab.yml
  • if there was a dump to openhab.yml the consequent file events will be ignored

Openhab.yml is loaded. Custom class with external files is constructed and loads configuration for ManualThing. Configuration is then merged in memory and contains configuration for “GuiThing” and “ManualThing”.

Since all things/items/etc. have unique names dumping is easy, too.
First, check if changed thing is in the custom class. If yes, don’t serialize these changes and show warning message. This step is optional.
Serialize data to openhab.yml.
The external, manual files get serialized to !!load_from_file mything.yml so there is no need to know about file boundaries.

It is possible to create configuration through the GUI, but a manual configuration will always have more priority then a configuration through the GUI. There is only one source of truth. Automatic loading and dumping still works.

(David Graeff) #82

You suggest to change half of the core. Please go for it, you know where the source code is.

(Sebastian) #83

Good - so we agree that this approach is valid and possible.

Tbh I only think this would affect configuration and serialization.
But this is the development section and we’re here to discuss concepts. And when introducing new concepts I expect that there are changes to be made.

While these changes may not be “low hanging fruits” they solve the problem of two truths while providing the possibility to configure through GUI and textual files. And this is the consens how everyone here wants to configure openhab.

(David Graeff) #84

openHAB is prepared to use different storage providers. That is the easy part to switch to yaml.
But everything after that means a lot of work. Things would need to remember their storage association etc. Because the storage service doesn’t know any meta data about the objects its going to serialize.

But as I said, have a look at the code. Personally I’m happy with the internal state database as it is so will not do anything in this regard. I’m more interested in a fast start-up and a good UI. And currently .thing/.items files are parsed via XTend/XText which pulls in a gigantic 3prd party library that is slow and evolves slow (we can’t update to newer java versions at the moment because of that) and I just want to get rid of that mess and instability that it inflicts.

(Sebastian) #85

I was under the impression we are talking about configuration not about storage of items/things.
It is perfectly fine to have only one way of doing so ( and this is the status quo as you keep mentioning that everything gets loaded from jsondb).

Nobody wants the keep .thing/.items files nor the XTend libraries. The only dependency here is the yaml-parser and configuration would be done using the yaml syntax.

(David Graeff) #86

And I was under the impression that you want to replace jsondb with yamldb. Because that is the only way to archive a single source of truth.

(Sebastian) #87

No - I want a consistent, logical and flexible way to configure things and I provided a concept how it can be done.
If that means to get rid of jsondb it’s fine with me.

(YvesHanoulle) #88

here’s a actual good UI nobody will ever ask for textual files again. Pretty sure.

You keep saying that, yet many times people have said that it’s not true.

I chose OpenHab because of textual configuration.
yes, I do believe there are powerusers who prefer GUI configuration, just as there are beginners who prefer text.

In the poll on this page most people selected both interfaces.

I’m not against a great GUI, I am pro also text configuration.

(YvesHanoulle) #89

I think David’s point is you cannot have static read only text configs and automatic discovery of Things.

The discussion on how the handle the automatic discovery is happening, so I’m ignoring that part here.

For me I don’t use automatic discovery from things.(especially because i use the same configuration on two openhabs instances that swap between production and test)

so having static read only without automatic discovery would work for me.
yes this means i need a way to set the all that config info also in the static files.
yet when I can do that, I’m ok with not being able to access the rest of the current state.

and yes I’m personally OK when that means that I’m limited to a reboot of openhab to do this.
My use of a source control system is more important then to have the current state of whatever openhab needs besides the configuration in files.

(Andrew Rowe) #90

just out of curiosity, what bindings do you use?

(Rich Koshak) #91

It’s not clear who you are replying to. I always try to tag the user or quote from their post just to make it clear.

I doubt it was me but just in case:

Actively use:

  • Bindings: zwave, astro, expire1, network, http1, mqtt1, mqtt, networkupstools1, nest, openweathermap,
  • UIs: paper, basic, habmin,
  • Persistence: mapdb, influxdb
  • Transformations: map, jsonpath, regex, javascript
  • Misc: openhabcloud, restdocs, market

Installed but not actively used, mainly legacy left overs or stuff I’m learning:

  • Bindings: zigbee
  • UI: habpanal, habot
  • Actions: mail
  • Transformations: xslt

(Andrew Rowe) #92

Sorry Rich, I was asking Yves
thanks anyhow… I believe you’ve told me your personal setup before

(YvesHanoulle) #93

binding = astro,exec,hue,mqtt1,netatmo,ntp,samsungtv,fronius,anel1,neato
hue and ntp not activly used at this moment.
anel1 is the biggest part.

ui = basic
persistence = influxdb
action = mail

all the bindings that need things are configured using .things

Why are you asking?

(Andrew Rowe) #94

Sorry… as stated… just curious
I’m new to OpenHAB, still learning. This is an amazing discussion. I’m watching the development of this platform and am in awe of the work you guys are doing. Your opinion on the configuration is important to this discussion and I wondered how you used the platform

(David Graeff) #95

An example of why .thing files are just super confusing for people:

And another one:

Doesn’t seem to be so hand-edit friendly the current .thing file syntax, is it? :wink:

(Markus Storm) #96

But that’s not because it is text as it seems you want to indicate. It is because of lack of documentation.
As .things were not part of OH1, unlike the well-known and well-working .items format, almost noone ever documented the .things syntax, at least not in a central place and generic form.

(Scott Rushworth) #97

Unmanaged zwave Things are also very troublesome, because you can’t configure them, although this applies to more than zwave. Hopefully, one day we can get this in place. But personally, I don’t mind managed Things… Items are a different story.

(Christian W) #98

worked my way through this thread - still sane i think :slight_smile:

And I still believe there is a way to make every one happy.

The new tablet guy, who wants todo everything with his UI. No idea what a backup is but wants his ‚undo‘ button.

The full control text only guy with partly distributed config over several systems - all productive versions surely resting inside a git

Hopefully respecting the work already done in the OH2 core :thinking:

Import/ Export ( aka Backup Restore) be available
through GUI and through commandline.

Now the new part.

There should be an option to configure a custom command after an backup. And a configuration when a backup should happen (on regular base/ on change of…).
This way you could always have an up to date text based backup file. To distribute edit an import on all systems you like even automatic.

The storage provider (jsondb as i understood)
should keep track of changes to the configuration. So when the serialization happen, the old db will be moved to a (rolling?) history. Or if git is fast enough it will do through git. Every serialazation a new commit? A diff Function could show changes between those ‚snapshots‘ in the ui.

It still is a lot of work but should much less then replacing current runtime storage concept.

What do you think?

(David Graeff) #99

The planned backup service will allow to run commands after an export and will on its own be able to backup to a git repository. But that’s not enough for the hardcore textual fraction. I don’t see a solution.

My idea is to make .thing/.item file support an installable service instead of being part of the core. Whoever want to stick to those files can do so. Everybody else can use the backup service.

(marcel_erkel) #100

Objection Honorable Moderator. There’s no proof that text users are only a fraction! :wink: