This is key to what all you text file addicts out there do not understand:
There is no code in openHAB that can write config into Xtext format config files (the format of .things and .items files).
It has been like this since OH1.X and while there might have been a chance on that at times, nowadays noone will develop any such code any more.
One of various reasons for that is that you cannot map all 2.X and 3.X features to that format.
All GUI input is now stored in JSON format in the jsondb and while that is text too, you must not edit that because it is not an input file (it’s the live database).
Hi Markus
I do understand that it is not trivial to write code that would convert GU input to .things or .items.
I understand you should not edit the jsondb file, or others for that matter, because they are the live files.
However: it is only a matter of labelling whether you label the jsondb file as a database or as a config file. I know there are probably fundamental differences but to me they are the same: those files I need to put back into place when I want to restore my system to a set point. So let’s not call them config files then, but documentation of which files to restore to get stuff working again would be great. For me, idealy they should all, including the .things .itemes etc, resort in 1 directory I can easly backup and restore. The same holds true for e.g. the Habpanel file.
As indicated I do understand, and appriciate, the fact that you provided multiple off the shelf solutions in openhabian. Inbetween users, as there are many, would probably prefer a simple copy/paste option to create backups, providing some ilusion of control over one’s home automation system.
In my opinion, this would benefit the OH community by opening up to lesser experienced programmers.
That is about backup and restore.
That is something fundamentally different from input files - which is what this thread has been about.
Just use the openhab-cli tool to backup/restore ALL openHAB config files in one go.
Also available from within openhabian-config as menu options 50/51.
Absolutely not my prerogative to unilaterally decide which way to go - I only made the UI and tried to make it a viable (and hopefully for many, even appealing) option to configure your system. That somehow became presented as the “recommended” way to go in the docs, but I don’t think it was me who worded it that way when I wrote the pros & cons.
Whether the text based configuration will be deprecated because there’s a more capable UI now is a decision to be taken by the core runtime maintainers, and rest assured it’s clearly not on the roadmap, probably never will.
Are you changing them in the openhab2/* folder or the one for OH3?
Use the GUI to do everything. OH2 I used all text files and just decided to try and go all GUI you can use expert mode to enter in items in a more familiar way.
Don’t edit the json db while openHAB is running so for me I never will do it this way.
Main UI highlights errors before you try and load them into database.
Honestly I felt the exact same way it is hard to learn new things. Once you get the hang of things it hard to go back to not know how to do it and update the docks.
As there is more than one way of doing thing you have only 2 types of code. One that is not yet working and one that works.
Most of my help on here is looking at the question reading the docs and answering in a more detailed post. Some people are just not knowledgeable enough to read a doc and get it. Especially if the doc is written by someone who’s first language is different to English.
Yep more examples will make it easier for new users. Stick some in the doc’s
Pros
They can be edited with any text editor,
Cons
Syntax errors will make you loose hair.
It is and you have done excellent. It is better than some professional tools I have used. You are just 1 man changing the world one line a time and I am so thankful for all the effort you put in. I could write a whole list of things I want in the UI however I assume you they are already on your list.
One way would be to display them on the screen like in Expert mode in screenshot above to be copied. To me this would be a waste of time as we go forward and the norm becomes using the UI these features wont be needed.
I’m a bit reluctant to reply because I do not want to sound ungrateful for all of the work you and the other maintainers are putting in. Not only in the code itself but also in the community. I’m also aware of the openhabian menu options 50/51. I still want to reply because I think there are a lot of users out there that are facing similar problems.
I do not agree that my link to backup is off-topic. Aside from keeping a helicopter view on my system, one of the most important reasons for me to choose textual configuration is actually the fact that I’m very confident of what I’m doing when creating a backup copy.
This is not off-topic because, to me, the very fundamentals of reliability and therefore backup is that I can rebuild the setup from scratch almost instantly. The key being: from scratch and based on the knowledge and skills I have. Realy understanding what I’m doing when using openhabian 50/51 is not part of this. I’m okay, and as I mentioned before gratefull for the tools provided, with creating a blank copy using tools I’m not fully mastering. (e.g. linux, openhabian, … ) Your openhabian is a perfect example of an excelent tool to help novices. It’s great people created and provided these tools, even free of charge, and I’m confident that I wil be able to create a blank canvas for a long time to come.
However once I start customising this blank canvas to my individual needs I’m on my own and have to do with what I know. You could argue that it is time to dive into new stuff, but do not underestimate all the knowledge you might consider trivial but that I do not master. And I still want to have my fancy home automation now, that’s my focus. Being able to backup using simple copy-paste would be a great help.
I find that the documentation on how to backup key components such as the jsondb, habpanel, newRules, … is missing. Again, not pointing fingers just want to help with my insight and experience. And yes I’m willing to contribute: I’m currently keeping track of all the small steps I have to take to migrate to OH3 with the intention of charing it ones I’ve moved the majority.
The title of this thread is: “OH3 - Textual configuration still supported?” An interesting topic to me because textual configuration is to me very closely linked to creating backups of my system.
Since I really have no clue and look forward to the answer:
Is it feasible to create copies of jsondb, opehab etc config files and use these for backup purpose? It would be nice if the config folder would hold a “backup” subfolder with these files. Obviously, those files are not to be edited manually.
And just to make that clear. I don’t wanted to piss off or insult someone here with my questions. I do really appreciate the work of @mstormi and @ysc and all the other core developers!
I just wanted to get a clearer picture of how to go on with my openhab setup which contains hundreds of items and a switch from text to ui should be well thought through.
And by the way I don’t want a UI syncing back to my text files. The text configuration gets versioned and a sync back would also mean a commit done by the ui.
If you want a glimpse at how that feature really makes sense including sync back and VCS just look at the node red implementation. It does exactly that. You can do both there. Text files, UI configuration + VCS done by the UI. This is how it makes sense.
I don’t want to critizise your work an OH3. That was and for shure is awesome.
I don’t expect you to make a decision about text based configuration. You have been concentrating on the UI and that’s fine. I followed your online presentation the other day. What i saw was a dedicated developer, who is convinced of what he is doing. Great. Keep on!
What i want to emphasize on is, that now there are deficits on the text based side. This maybe because of time restrictions. Or lack of other resources or whatever.
.
.
The following is not directed to you but generally speaking:
Some people tell me: this is not true. My understanding is an other. And i come to the conclusion, that all this “txt is functional” talk is kind of marketing. “Do not scratch the freshly polished surface of openHAB!”
I don’t like this attitude at all. I don’t like evangelists either.
Because the reason for all this might be a lack of knowledge on my side, i’ll stop posting in this thread.
The expert mode is excellent.
I’m wondering about one feature that I think is currently not supported (and is a dealbreaker to me)
Can I have multiple jsondb files?
or let me rephrase:
I have a knx system, sureflap cat flap & squeezebox
I have my .items .things .rules organized such that I can switch on or off some part of the configuration by just changing the file extension. The squeezebox can be temperamental at times and while I’m experimenting I just create a copy of the squeez.items file for backup and start messing around. Since it is in a separate file there is no danger of messing up the knx items. (essential to WAF) The sureflap binding is not an official binding and requires a .jar file. As long as this is not part of OH3 I just omit the sureflap.things sureflap.itmes and sureflap.rules and all is well. The same holds true for rules: if have my stable ones in one file and the experimental ones in another. (experimental as in: do I want my system to behave as such? Does this generate race conditions between rules?)
Adding to this I can easily backup and know what I’m doing.
One of the biggest problems when helping someone is gauging the level of their knowledge and their failure to realise I am Australian. We joke at the most inappropriate times. The team look like they can take a bit of criticism and scratching the polish is all I am doing nowdays. I am defiant and running it on 64bit Java and os.
You only get one jsondb and you can disable things for example I will disable the moon
There are objectively deficits and textual configuration is definitely not on par with gui based configuration.
But every time this gets pointed out in this community the response is either “But look at the shiny new gui we built!” or “How about you go fix it yourself and don’t complain!”.
The new gui is awesome and an overhaul was long due but with all this focus on it sometimes it seems like the textual configuration part of the community somehow has been forgotten.
Ok, I can see that enabling and disabling things might be a step towards switching to the GUI.
Still not to keen on the suggested backup solution.
There is actually only a fine line between configuring and programming. Creating an extensive configuration shares a lot of best practices with creating code. You want to build up gradually and in case of errors, you want to break things up into chunks. A suitable backup and debug methodology, as in: what works for me, is step 1 of your configuration.
Disabling/enabling things and or rules is a first step forward, but lacks e.g. the possibility to copy a thing in order to be able to debug/revert to the previous version or use trial and error. (I know, not always the best method)
I’m currently using textual configuration because I can see the advantages of versioning etc. I can stick to the principles of versioning without having to use (and learn) a tool like git. Using git would mean putting my config out there or setting up a whole backup infrastructure. We are taking about kb of config files so having a lot of versions as separate files does not bother me. I can just use the same approach to backup as the one I’m using for family photo’s and files. For me, dumping the files into the correct folder will make sure there is a backup, both in the cloud as well as physical hardcopies.
When using the GUI I’m not sure on how to combine this with my general backup approach. Having (copies of) all config files in one folder would allow a more flexible approach to backing up ones system.
The backup method you describe is a manual one and if that works for you go for it. Its not for me, mine are all automated as I am super lazy.
In the future there may be automated git configuration syncing. As a user would you want this feature
This with Mirroring would be ultimate backup solution. Mirroring for when you have a hardware failure of SD card so the recovery time is the time it takes to change SD card an boot. You don’t even need to redownload the jar files or setup the mqtt broker again.
Git is for when the house burns down and you want to rebuild it exactly the same as you did before.
I believe in freedom of choice and if you want to do it that way it is not wrong.
“No” because it isn’t “feasible” to do any sort of DIY backup and restore of these files when you do not have enough knowledge of how the system works (as you said yourself).
It’s the straight road into disaster for many users.
That’s why it isn’t in the docs and also why I’ll never ever give a recommendation like that unless I’m convinced the addressee knows the prerequisites and consequences.
“Yes” because that’s what openhab-cli does. There already is a jsondb “backup” subfolder.
Leave implementation to the people that know how to do it. Use their tools and get them feedback to enhance them for everybody’s benefit.
As an overworked dev, you would want someone to build this feature.
There fixed it for you.
I am very aware that you asking for help dose not mean that it will be done. In fact I don’t think it worth the effort to build as the effort the team has put into Amanda and Mirroring is all that is needed. If someone wants it and takes it on then excellent go for it.
People don’t seam to understand that openhabian is not openHAB and both teams have put in a huge effort recently and you guys deserve some downtime.
