Clearly … no. Speak for yourself, but it’s foo nonsense that power-users=text-users.
Diversity. Nobody stops you from leaving openHAB and start using Home Assistant 
You are really here just because of ZWave. Sigh.
Now I get you. Please use proper terms. I was talking about Next generation design: Paper UI design study, so the maintenance GUI. And you are talking about Habpanel. Please contribute to Habpanel then with your ideas, this is the wrong topic.
foo? Do you mean true?
Not all… I use the paperUI exclusively to manage my things. It’s pretty much error proof and you can’t mess up the syntax. Once a thing is created and online there is no need to fiddle with it so it’s a one time job.
I, of course use text for items and rules because there are no real alternatives yet.
In every thread about UI there are users with many items which ask for textual configuration.
So let’s just be different just for the sake of being different?
I would have at least expected some logical or technical reasons.
Because our documentation ONLY shows textual configuration because Paper UI was a total mess. If there’s a actual good UI nobody will ever ask for textual files again. Pretty sure.
No you misunderstood. OH decided to do it like it is doing it now, and it would be a huge effort to turn that around. And just for the sake of HA uses it that we should use YAML as well is also not exactly fruitful. They have their own problems with YAML if you skim through the developer forum.
If you have to manage multiple openhab instances and have transfer things/items from one to another without transferring the whole config textual is still the way to go.
Textual configuration provides flexibility because it can be distributed and modified very easy.
Everything can created without the need for the openhab instance.
That was never the reason nor the intention. It is a possible (future) solution to the given problem and I think a good one. It provides flexibility and everything discussed so far can achieved with it.
Except new users are demanding it. Despite the “Experimental” in the name, new users are using it. The demand for this is high.
But it won’t be fine at the expense of JSR223. It will become the new default replacement for Rules DSL.
We already have this and it is used by some. OpenHABian will install NodeRed and there is a fully functional NodeRed node for openHAB. But I think outsourcing something as vital as Rules would be very much to the detriment of OH. We’re I starting fresh, I pick something else besides OH if it required instalation and configuration of since other service to implement automatons.
If you read the thread I linked to above you will see that is pretty much the consensus. Except instead of watching the file have a manual trigger to import or export so we have more contril over how they get loaded.
Also don’t forget that we need a migration path so users can switch from GUI to text and back without starting over.
Right, for now we have PaperUI for configuration and administration and for display we have sitemap based UIs, habpanal, and Habot. It sounds like you are proposing what we already have.
So e should ignore me users and less technically skilled users?
I can concur. Many of not most of the most active contrubutors on the forum use the UIs almost exclusively due Things. I’d use it for Items too if the UI were complete. And when the NGRE matures I’ll use the UIs for Rules.
But nowhere are we saying that we don’t want to accomodate those who prefer text.
I don’t know about that much. There are reasons such as source control that will make some users airways want the option. As discussed on that other thread, if the db file changes the order when it saves things the history will become mangled and unusable.
Yeah true. I came to the conclusion that the internal JsonDB is not suitable for backups. I imagine to have a backup service in OH3 that exports to yaml (or whatever we have settled for by then) with a stable order, suitable for revision control. And that is also used for to trigger imports and restores.
No - since there is no possibility to freely create complex layouts in the sitemaps and there is no possibility to create custom widgets. This is what I was trying to say with my HomeAssistant example:
Users can create, use and configure widgets using the existing configuration syntax.
It may not be intentionally but It sure feels that way since openhab2.
I never said that. I acknowledge and support gui based configuration if everything that is available in the gui is possible through some clean, textual configuration.
So why the need for the import/export and not serialize directly from/into the files?
I had two far openhab instances running which synced their configuration through my cloud service. It was nice and easy to configure and run them from my machine at home. I hat no access to the gui or the machine but once it was set up it still worked flawlessly. There should be at least the option to watch for file changes (and may it only be in the central config file).
Really? Could we at least agree to disagree?
Hm, why do you need textual files? I mean real files on a filesystem. You probably have seen the Paper UI design study already. If you assume that would be the status quo.
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 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).