Because openHAB internally uses a json based database and that is not going away any soon as it is not even two years old by now. And people don’t like that json file at all, why do you think they like yaml better. There is a longer heated discussion about this topic existing.
Please see that mentioned discussion with a lot of technical background why that is a bad idea.
I’ll chime in here…
In my case, I have multiple openHAB installations that share some of the same technologies. As a consequence, I often copy snippets of things, items, rules, sitemaps, services, transforms, etc. files between the installations. And, I like the fact that I can track/manage all my changes using VS Code and Git.
But you have read about the import/export functionality that I mentioned above? In contrast to the status quo you would need to trigger an import/export, everything else is really like now. Please also read the mentioned discussion, because we are repeating ourselves here.
Sorry, I was simply responding to your recent post that suggests you still don’t see value in textual files.
Yes, I did. From my perspective, those are just extra steps that I don’t have today.
But when do you push your changed item/thing files? Isn’t that done manually or by a cron trigger or so. You would just need to add a openhab-cli export command. Is that really much more?
Keeping things compartementalized. And migration between deployments. And development. Basically what I already said at Next generation design : Ideas & Discussions - #7 by hakan on January 6th
Yes, I did. And it did more to convince me even more that text configurability is a sine qua non. I’ll comment my reasonings about it on that thread.
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).
That’s what I was afraid of. 
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):
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.
FYI: I have updated my design study with a UI for cron expressions.
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.
Is always the jsondb for openHAB. .things/.items files are creating a second source of truth here.
A configuration file in contrast is read once at start-up. .thing/.items files are not configuration files at the moment, they are like a 2nd backend/database.
If you would have to have your .things/.items as the one and only source of truth, the implication would be that openHAB writes back on any changes like discovered and accepted things on the UI etc.
'Nuff said…
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.
Ira
Absolutely!!
Amen to that
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.
Cheers
I will always and forever want text configuration.