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.
Assumptions
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
Load
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ā.
Dump
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.
Conclusion
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
worked my way through this thread - still sane i think
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
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.
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.
