Sure. It’s a normal property of a Thing/Item/etc that is (de)serialized to/from disk.
I do not have a better name for this service yet. Call it different if you like. Maybe IO-Import-Export service.
I do not have a better name for this service yet. Call it different if you like. Maybe IO-Import-Export service.
IO would indeed be better.
Backup is wrong as it 's a one way proces that starts from a configured system.
When I start from a text file, I would never look for a restore function to upload these text files.
For many people a backup is about the data, not about the configuration.
Yes correct my improper use of that word might have caused confusion. I’m sorry for that.
1 Like
I could be wrong but I’m pretty sure the import /export was not going to be strictly gui. I believe they’re was going to be something added to openhab-cli to initiate that.
1 Like
Could it be like:
If the configuration file changes I want an import to be triggered?
But why not use a simple file watcher? Why add more complexity?
If an import can triggered manually why not trigger the same import if one of the config files has changed?
Can we please do not focus on rules/items/things here? Textual configuration has not to be in any of these formats and there are many better alternatives.
Concerning your Paper UI NG:
Does it allow for grouping multiple configurations together? We could call a group of multiple configurations “file” and a group of that “folder”. 
But to get back to topic, I’ll try to summarize what has been going on and what we (hopefully) all can agree on.
- There is the need for configuration through GUI
- There is the need for configuration through files
- There is the need to migrate configuration through GUI to configuration through files
This has to be solved somehow.
Since I don’t believe that there will be any GUI that covers all the use-cases of configuration through files I think the only way this can be solved is if openhab will save the configuration in the same file format that is used for manual configuration.
Sure there will be a in memory copy but I still believe that the goals of both fractions can be achieved if a clever configuration syntax is used without the need to compromise.
I made a proposal here and imho it is still up for discussion:
Proposal
Example and further explanation
It allows to manually specify parts of the configuration in file and migrate from/to configuration through guy. As far as I can see everyone would be happy.
1 Like
And I explained already why that is not possible. The internal database format is a pure serialization of java objects. That will not change for performance reasons. So you need an additional IO service, like there is one right now (XTend for .thing / .item / .rules files).
Yes of course. Any trigger can be used. The developer of that service will provide one in an initial implementation though I guess and not dozens.
I think you really don’t understand. What we do right NOW is adding A LOT of complexity to the core, because it must virtually for every code path decide if it’s a manual configured thing/item/whatever or a “real” configured thing/item/whatever. All that complexity can be REMOVED and the startup time increases.
The semantic of those files change however. They are just “imports” and not a source of truth anymore. If an import conflicts with a database entry, it will not be imported. This basically inverts the priority of “.thing”/“.item” files versus the internal database state. For good.
Because at present, the way OH loads configs is horribly broken and it is caused at least in part by the file watcher.
I think some of the problems that are driving since of these discussions have not been fully enumerated nor appreciated. Just a few of these problems include:
- exaggerated start times on RPis (dozens of minutes or more)
- rules start triggering before the system is ready, giving strange errors like “no such symbol OFF”
- 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
It’s not just for sake of change that this approach is being recommended. OH is horribly broken.
And back. Migration needs to be both ways. There should not be two separate configs. There should be two ways to create the one config.
2 Likes
Even if I can understand some of the users need a GUI, I prefer myself setting up my system in textual files because all the advantages already mentioned in this topic. If the textual configuration was finally suppressed, this would be a major disappointment.
And I don’t want a move to JSON for textual files because it is largely less readable than the current syntax.
5 Likes
So what you are telling me is that an additional map lookup (name in manual config) takes too much performance? I highly doubt that.
Also the possible performance hit would only apply to users with manual configuration and only if configuration was changed. Therefore it is neglectable.
Sure there are code changes necessary but don’t we actually want to improve things?
What you are describing is a direct result of Xtext/Xtend and not a result of file watchers/configuration files. These points definitely need to be addressed but will automatically vanish if we finally get rid of Xtend.
Yaml is the way to go!
You are absolutely correct! The only way manual and automatic config can work if there are two ways to create one config. And this is only possible if the automatically created config is in the same format as the manual config. Otherwise there will always be differences and inconsistencies.
1 Like
Let me find my json db, converted to yaml. I think you can’t imagine the mess you are dealing with. openHAB is storing its entire runtime information in there, no matter if you could split things/items etc up in several files… there are so many runtime information in there.
Because currently it is a mixture of configuration and a cache of runtime information which are not mandatory for the proper function of openhab.
I understand that a cache can speed things up (e.g. startup) but a cache can and must never override configuration.
2 Likes
But this is the current state as i understood. So every proposal will create work on this current state. And going through all Objects sorting out configuration, runtime and cache data, would need to be done if this is going to be changed.
I mean it sounds great to have all sorted out - but if the two sources of truth are introducing more errors and issues i would start there.
1 Like
No. That’s wrong, at least on my system. The only entries in my jsondb are the auto-discovery things. Nothing else is in there.
Which is not contradicting with what I have said. If you do everything via the proper OH2 APIs (REST for UIs and console for command line users) then it will be in the jsondb including all runtime information (states, properties, api-tokens, passwords etc).
Textual configured things use a different code-path and that is what I’m aiming for removing from the core to reduce complexity, errors, slowness. This will be done via a separate, in the future also replaceable or extendable IO service that imports / exports based on custom triggers (like for example file system changes).
Same as me, I prefer textual configuration to understand what is going on. I was using Homeseer and after configuration became bigger I felt little confused.
Ok, i understand that. But why isn’t it simply possible to create the jsondb entries from the the current text files? On some kind of trigger the jsondb is updated with the text files contents.
OH2 has still a relatively large code base taken from OH1 where things were just different. There was no runtime database. Everything was files and OH build up its runtime state each time it started up, I guess. I never used OH1.
The vision for OH2 is different, but there are not enough developers to push everything at once to that vision. So subsystems got replaced one part after the other. It’s about time the .thing / .item file subsystem gets an OH2 replacement.
That’s probably part of the problem why you don’t want to see the benefit in keeping file based input as most long term users do.
Caution with generalized statements.
YOUR vision is different.
No, it’s about time the .thing / .item file subsystem gets an OH2 GUI complement.
Not a replacement.
7 Likes
That’s not my vision. Have you seen the codebase of OH2? Auto-discovery, REST API, new rule engine… it’s the vision of OH2.
Well, to date I have not seen any other developer second your statements, so for the time being it’s not more than yours.
And OH2 is way more than its codebase.
It’s also the users, community, set of solutions built based on accumulated knowledge, documentation and examples on the forum.
Most of which you’ll probably call legacy from a code point of view, but it’s in fact the present and basis of OH’s popularity.
3 Likes