But this is not going away, there is just an import/export trigger mechanism on top of what there is now. Just from the technical aspect: You cannot have two sources of truth, that always leads to a disaster.
Because you don’t use the UI, you probably just haven’t seen all those 409-conflict errors that occur because of that exact problem.
I kind of like that you, in the mentioned post, absolutely dislike the one huge json db file while @Spaceman_Spiff suggests one big yaml file. Funny.
See, if you could give people confidence in that statement, I belive many of us would be happy and wait and see what you come up with. But with statements like “nobody will ever ask for textual files again” you trigger alarm signs. I don’t want to wake up one day and see a pull request merged that breaks things “that nobody will ever ask again”. Not even intentionally removing something but breaking because you consider it “not to be important anyway”. Your statements after the MQTT binding are what have left a conflicting taste, even though the software itself is a nice piece of engineering.
We did not meet in person, so allow me to state this via forum. And maybe someday over a beer. I do have 25 years of experience in building complex IT systems in the Telco and Financial industries. Systems a little bit more complex than our itty bitty openHAB installations. I do know many a thing about multiple sources of truth and resulting chaos.
Sorry, but you again assume too much. Yes, I use the UI too. Yes, I know about the 409 conflicts. And they are there for a reason. I know.
I commit right from VS Code once I’m happy with the change. My commits are typically pretty granular (a few lines) unless I’m adding something entirely new, in which case it could be several to many dozen lines across multiple files.
I like to provoke although I sometimes share the same opinion. For widening the discussion and idea flow and to find more alternatives to problems. We are on the same side though as I get from your last post.
Hm ok. I really don’t know how to make you happy in that case Everything in openHAB core must go through the jsondb, that is our runtime database. For compatibility reasons the old .thing and .items files were kept when OH 2 was released, but all Things and Items are specially marked and are basically not editable from any of the newer means of OH like the console or REST API (for UIs and Apps). So those files and the file watcher really need to go, there is no way around it.
What we need to make you happy as well is to extend the VS extension to automatically trigger the import as soon as you push your changes (equals: you are happy with changes).
You see, it’s not just not just items and things. Everything in my conf directory is under version control – html, icons, items, persistence, rules, scripts, services, sitemaps, sounds, things, transforms. I have three installations, so keeping track of all the changes to the configs becomes really important.
I assume that quite a lot users are using some sort of version control system for their configuration. That’ s one of the reasons why I started to use text files for my item definitions some weeks ago. I even store the JSONDB in git.
But some sort of version control could also be implemented in a graphical environment. Maybe even using git in the backend.
After following the discussion for some time I have the feeling that it goes round in circles and will not come to any conclusion (it reminds me a bit of the BREXIT discussion in Britain).
I think we can agree that most of us have the following requirements (in addition to generally improved graphical UI):
some sort of version control for all definitions
backup/restore function for all relevant definitions
export/import option to make it easy to copy definitions to other OH installations
copy/paste of definitions plus the support of “mass changes”
efficient editing especially for large installations with hundreds of items
I can understand @David_Graeff 's arguments (at least partially ). If you want to implement new configuration options it is in most cases easier to add new options to a GUI than to “invent” some sort of syntax for a textual representation. If you look at the item definitions and all the different types of brackets, then we already have a syntax that is not so easy to understand.
I don’t know whether it is possible to implement all required functions in a GUI that satisfies both new and experienced users. But we should a least try to.
Indeed, runtime. I’m not interested in the runtime configuration. I don’t even see the need to store it to disk. My source of truth are the configuration files that I write that are under my control. From security perspective it would even be good if openHAB didn’t have write access to them.
Each time I start openHAB I want to be sure that it uses my configuraton, not some automagically updated config hidden in an unreadable format (I know its JSON but that doesn’t make it readable).
But I guess this is where we have a fundamentally different opinion on what the source of truth should be. In your opinion it should be the JSONDB, in mine the text configuration files.
Personally I don’t care how it works. I’m a fairly new user and my needs are simple, I’m comfortable with text file and once I figured out that Items and rules beliong in text files and things belong in PaperUI I did fine setting up what I needed to please my wife.
But, if you expect this product to grow, you need to make it so my wife can make changes which means it all has to be through a GUI. The way it is now and if you keep requiring text files, 99 of every 100 people who come here will move on.
Making text files an option so that the people stretching the edges can keep stretching makes perfect sense, but home automation should be for everyone and openHAB needs to realize that or something else will come along.
How it works underneath should not be a concern of the users because if it works, the majority of the users will not know or care. If you think it matters, become a developer and show the team a better way, isn’t that what open source is about.
Hm but that is how OH2 is build internally, it allows multiple ways to access the internal database (jsondb), but that has to happen in a structured way. The console and the rest interface are using the correct interface. And the next logic step is to make the file inputs also use that interface. Please accept that technical fact.
You are probably just used to the OH1 way of thinking. But this is OH2.
This topic is turning into the same conversation like in the other discussion. There’s a poll in the beginning, saying that 90% of people like GUI and textual ways.
6% GUI only and the rest textual only.
The poll unfortunately doesn’t differentiate between people who want a textual interface for copy/paste, search/replace, cloning or real text files.
Nonetheless. OH and also the developer environment must become more newby friendly (but stay powerful of course). Please ask yourself what compromises you are willing to offer for that goal.
I think you are still not understanding what I am proposing. The yaml file is a drop in replacement for the jsondb. But with the yaml file structure it is possible to move configurations into another yaml file or while it still can be used with the yaml parser. This provides the flexibility for proper configuration.
Openhab does auto discovery and detects a z-wave device and links some items. This is what gets created
Note that the openhab.yaml is still valid and can still be written to by the parser.
Openhab registers the file changes and loads everything back.
A part of the gui configuration became now manual configuration.
–> Benefit of db & gui but still allows full manual configuration
With a good concept there is no compromise needed!
I think David’s point is you cannot have static read only text configs and automatic discovery of Things. That is a hard break. Since removal of automatic discovery of Things is not up for discussion we require OH to be able to write this information to disk.
This is the choice. Either get rid of automatic discovery, in which case you may as well go back to OH 1.8, or come up with a more reasonable way to handle the fact that configuration information can come from both the user and OH itself.
See the Hue binding. You configure just the bridge, and for the light and control Things, auto-discovery works just peachy. I believe this would also hold true for MQTT things via the Homie convention. So, in my mind, it is possible to find proper sweet spots between all-text and all-GUI. This is also the way I would expect my dream HA system to work.
The “static read only text configs” provide only just the minimum necessary for the rest of the system to work. Which does not preclude us die-hard greybeards from fully defining all attributes of the Things ourselves, of course
And where do those automatically discovered Things get saved? The binding doesn’t go out and rediscover the Things every time OH restarts. It discovers them, you accept them out of the inbox, and they get saved.
Unless you are wanting to have all the Things be rediscovered every time, in which case that makes it impossible to set any configuration parameters on discovered Things because there is nowhere for those parameters to get saved.