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.