I use text files personally, except for Things & UI.
The same as Text files you need to backup these files
Using the cli to backup you sudo openhab-cli backup
Note it tells you where this backup is made. You can backup however often you like.
The default jsondb backup is 5 and this way copies your backup folder.
It also saves all your persistence data.
It dose not save your TXT config files.
You can change where these backups are stored.
1 Like
I’ll give this a try, thanks!
It would still be nice to have the possibility to config the pages via openhab-config pages files besides the config via gui.
So my experience about this:
I am using OH3 with docker → till now I only have to mount the openhab-conf volume and thats it.
Additionally mounting the userdata would not be a big problem either, so I could also directly access the files I am additionally interested in e.g. users.json, uicomponents_ui_page.json, openhabcloud/secret and uuid
But using the backup is more complicated:
I am using docker-compose to start all services needed by openhab too. e.g. influxdb and mosquitto.
I was very satisfied with this setup, because it’s pretty simple and all dependencies and the data to persist are shown in the compose file.
Have to use the backup call will break the simplicity of my setup!
openhab-cli isn’t even provided inside the container and exec into my docker (I have to find out how to call backup without openhab-cli) with an external task is also kind of an overkill in my opinion.
Then I have to mount the backup dir and so on. The configuration is getting more and more complicated.
In my opinion it would be a huge improvement if there would be a possibility to configure users, pages and openhabcloud via openhab-conf files and handle it as readonly in the gui if configured via files just like its done with things and items.
I will always prefere KISS! For the users keep it simple stupid and standardize the possible configurations.
Thats why I personally dislike mixing things up.
1 Like
There is just one point missing:
It was always recommended to backup your userdata folder, as it holds information provided by some bindings, Z-Wave e.g., and your uuid and secret. This has not changed and I don‘t think it will ever change.
So if you follow that recommendation, and I am shure you will find help for your docker issue if using the forum search, then you have backed up your pages as well.
Yes thanks to your help I am now capable of finding the correct files to handle it the way I want to handle it.
I can now just build my own image on top of the provided one and copy the files into the userdata directory pre openhab start.
But in my opinion there should still be the possibility to keep the configuration inside the openhab-conf dir.
And sometimes things can be improved and do not have to stay the same because some bindings handled it that way and did not differ config and userdata.
I mount the conf, addons, & userdata volumes ad instructed on Docker hub. Im addition. I mount localtime as read-only. This is from the docs ans similar to what I do.
docker run \
--name openhab \
--net=host \
-v /etc/localtime:/etc/localtime:ro \
-v /etc/timezone:/etc/timezone:ro \
-v openhab_addons:/openhab/addons \
-v openhab_conf:/openhab/conf \
-v openhab_userdata:/openhab/userdata \
-e "EXTRA_JAVA_OPTS=-Duser.timezone=Europe/Berlin" \
-d \
--restart=always \
openhab/openhab:3.0.0
Things in text files are too error-prone, especially for z-wave.
As long as you have the thing id of the controller ( it is in the Item links) you can easily add the controller giving it the old ID, discover your devices and be back in operation again.
Thanks bruce 
I’m aware of that.
Working good for my configuration with: mqtt, max, http, fronius…
And don’t get me wrong I am not saying anything about the current main-ui gui configuration → anything configured from within the browser does clearly belong inside the userdata directory just like its implemented!
But I miss the possibility to add configured default pages from conf.
I thought this forum is about technical discussion?
It’s not about “good old days”, as I mentioned ealier it’s rather about mixing things up.
2 Likes
It’s also about having some fun 
2 Likes
I agree. I also do not understand why others want to discuss wishes.
To bring this topic up again. I would have a kind of textual configuration for pages too.
I deploy my openhab installation with ansible, which is great for templating textfiles in a very easy way. So I have the benefit to have all my needed configuration in one git repository to start from scratch if something went wrong (which often occurs, cause I’m not a openhab pro)
For the configuration of my “things” I switched from pure textual configuration to use the rest api to approve discovered things from inbox. This was a great thing, cause now I’m able to change configuration options for zwave devices through UI.
Back to topic I hoped to use the rest api to do the same way with pages. But it seems there is no rest endpoint for that, which I do not understand, cause there is the possibility to inject yaml based configuration via UI. There should be an rest endpoint for this, but it is possibly not exposed???
1 Like
To add my two cents:
I also deploy OpenHAB via ansible, by plopping down my textual config files and spinning up a docker image pointing at them. This is very beneficial both for reproducibility and for change management.
I currently configure ZWave device and Lifx bulb items without any difficulty at all via textual config. Extremely easy. The “things” are mostly automatic once the bindings are installed, and thus my items definitions simply refer to the channel=“lifx:colorlight:MAC_ADDR:CHANNEL”, or channel=“zwave:device:controller:nodeX:CHANNEL”, and all items are matched to their things perfectly easily.
I’d love to be able to drop the “pages” into a folder as .yaml files and have them loaded. I’d love to know what the reasoning behind not providing this is at least, maybe there’s just some issues that can be worked through?
3 Likes
You can use the /rest/ui/components/{namespace} endpoints. Look under UI in the API Explorer. Except for the GET operations they need authorization i.e. a token, and they accept/output JSON, not YAML.
The namespaces are:
ui:page- pagesui:widget- personal widgetssystem:sitemap- UI-defined aka. “managed” sitemapshabpanel:panel- HABPanel panel configurations
Also they are stored in userdata/jsondb/uicomponents_{namespace}.json (the colon being replaced with an underscore i.e. uicomponents_ui_page.json, uicomponents_system_sitemap.json etc.
3 Likes
I’ve been trying to use the API to orchestrate my setup:
curl -X GET "http://openhab.imagilan/rest/ui/components/ui:page" > /srv/salt_local/salt/openhab-server/files/ui/page/pages.json
curl -X GET "http://openhab.imagilan/rest/ui/components/ui:widget" > /srv/salt_local/salt/openhab-server/files/ui/widget/widgets.json
both grab the files fine. However posting back fails and I’m wondering if anyone else has managed to do this successfully or how I go about debugging the error:
[ERROR] [rg.apache.cxf.jaxrs.utils.JAXRSUtils] - No message body reader has been found for class org.openhab.core.ui.components.RootUIComponent, ContentType: */*
I’ve tried different forms of the following curl command (based on the API explorer documentation/examples.
curl -X POST "http://openhab.imagilan/rest/ui/components/ui:page" \
--user simon \
-H "accept: application/json" \
-H "Content-Type: */*" \
-d @/srv/salt_local/salt/openhab-server/files/ui/page/pages.json
Questions:
- should it be possible to post all pages back to the
ui:pageendpoint? (GETgives me them all so I’m assuming it’s possible) - Am I passing the right headers?
I’d like to avoid copying files into the database directly and going via the API to setup a new system seems like the best approach.
Incase this is useful, following up on my own post, it seems like it’s not possible to write to: http://<openhab-server>/rest/ui/components/ui:page but that individual pages can be updated like
http://openhab.imagilan/rest/ui/components/ui:page/BathroomGuest.
Also it looks like this is a case of PUT instead of POST.
And to follow up even more incase this is useful … I wanted one json file from
curl -X GET "http://openhab-server/rest/ui/components/ui:page"
but since we can’t post back to that url, I extract each page from the json using jq and post back accordingly
#!/bin/sh
for individualPage in $(jq -r '.[]| .uid' pages.json); do
echo $individualPage ;
jq '.[] | select(.uid=="'$individualPage'") | .' pages.json | \
curl -X PUT "http://openhab.imagilan/rest/ui/components/ui:page/$individualPage" \
--user apiuser:apipassword \
--header "Content-Type: application/json" \
--header "Accept: application/json" \
-d @-
done
Hopefully this is useful to someone.
1 Like
Hi Community,
I am searching for hints to deal with textual deployment too.
I totally agree with Lars statements. Depend on the knowledge of the “user” with openhab, generally IT experience and the smart home stuff too, the focus is quite different.
In my case, i think I am a “openhab power user”. I am originally a trained electrician and studied later on. Today am working as an IT administrator and with lot of experience in working with different large installations. Therefore installation, deployment and testing is a big topic for a stable production environment. A smart home in my point of view is a “production environment”.
The big challenge for a “smart home” is a stable running and a good usability for the “normal” user. A normal user is a resident of the house. But keep an eye on guest too.
However, i see 3 main reason to use “textual configuration” furthermore:
ONE - test new bindings
Like Lars said, I preferred to test new bindings and the corresponding settings in an extra installation. For some “gambling” stuff, I use a docker on my mac too. Than i use an extra PI for the new function. I configure all elements (things, items, a extra sitemap, etc.) in text files. With copy from the “software depot” to the test system, i can concentrate on these special new function – e.g. squeezebox.
TWO – migration from old to new OH versions
I start working with OH since 1.8. Since that I am familiar with the “textual” configuration. I update step by step until 2.4. Because of my LCN bus with the corresponding binding, the switch to OH 3.x became a big challenge. With OH 2.5 in my test environment, I began to switch over the things configuration for all bindings. Today with OH 3.x i migrated all bindings step by step. Sometimes separately and sometimes together, because of interaction belongs to some rules.
THREE – deployment for many customer
I earn my money in the IT. But when I think about an electrician, who has some customer with an openhab installation I have to support, I like to have a “default” setup which I can use for an initial deploy. Than I have to individualize the installation. This save time and money for the installation. But later when something happend, I like to have many customers with a default installation.
Therefore, I appreciate a way to deploy the new OH3 elements like pages, flourplans, layout, views eg. via textual configuration.
Best regards
Ralf
3 Likes
Hi community and sorry for bringing this topic back to life, I’m fully supporting @rayb.
I’ve been running OH for past several years.
I’m sorry, that I wasn’t contributing too much and had several accounts (for some of those I don’t have access anymore) due to personal reasons.
Last couple of years, I had my OH2 running on Kubernetes cluster with a proper defined failovers/automation.
While having OH2 running on Kubernetes cluster, where I could treat any workload except DB’s for persistence and graphs as a cattle, not a pet, as well as a-la Production/Staging/Development environments - all defined by the text configs, requiring not a single user action, if, for example, I would completely delete the openhab workload and recreate it automatically (in case of questions - Terraform, Kubernetes Secrets, Google’s KMS, Google’s Secret Manager and Flux, but you can contact me directly in case of questions).
From my experience, as Cloud/DevOps architect, all operations/deployments should have the possibility to be repeatable and completable without any human actions and my IMO, it’s a pity, that OH3 diverges from that path
1 Like