OH3 pages textual configuration

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 - pages
  • ui:widget - personal widgets
  • system:sitemap - UI-defined aka. “managed” sitemaps
  • habpanel: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:page endpoint? (GET gives 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

openHAB is NOT diverging from the path to use textual configuration. There are no plans for such.

Not having a possibility to configure pages via text files just means, nobody has developed this feature. So if you have such a strong demand for it, feel free to contribute.

On the other hand, BasicUI is still there and will remain, so like in openHAB 2.5.x, you can define a UI via text config.

As you see, nobody took away key features/options, but new possibilities have been added, which will evolve in the future.

I can confirm that statement. I have been migrating from 2.5 to ver. 3 recently and I can develop Basic UI over the web interface in text form. However…
I still do not know how to tell openhabian he should take the .sitemap file from sitemaps folder. :frowning:
I did not find explanation in the documentation on that.
Any suggestion?

I don’t understand your question. If using the official apps, all sitemaps in your sitemap folder should be listed and selectable.

Hi,
I have created new sitemap within OH3 official interface. This sitemap is not being located in /sitemaps folder → this i understood. Can debate on the forum about concept but it makes no sense. OpenHab developers had to really think about the concept and I trust them in this what they do.
Nevertheless, me as probably many other older users have habits. We definitely need more time to switch :slight_smile:

From some reasons my sitemap does not support dynamic parameters like visibility or valuecolors (see my recent question in already closed post)
So naturally, to solve my problem I was trying the “old way” and created new sitemap I could test and check if it is working as in 2.5 or not.
This is the reason I am looking for possibility to tell OH3 to use another sitemap page, defined in the file and located in sitemap folder.

In 2.5 it was possible with Paer UI → Configuration …to attach the .sitemap file.

PaperUI never used sitemaps, only BasiUI and deprecated ClassicUI.

As I wrote, you can select the sitemap within openHABs official apps, or you can call BasicUI within your browser giving the correct sitemap as parameter :

http://hostname:8080/basicui/app?sitemap=sitemapname

Sitemaps in your filesystem will not show up under pages, as they cannot be edited.

1 Like

Sorry maybe I was not precise enough.
I meant this kind of BasicUI configuration page.

It means there is no possibility to link to the file based sitemap in the \openhabian\openHAB-conf\sitemaps folder, right?

Just for me to be sure I understood. In this case I will have to write separate post asking for help on how to run dynamic parameters because it does not work for me at all.
Secondly, if this is not going to work why we have the same folder structures like in OH2?

Did you check
Settings
Other Services
BasicUI
Last param : default sitemap

Yes. I have only these sitemaps visible, they were created with official pages creation.
Trying to type the name of the sitemap from the file does not work.

It definitely works, tried it here before posting.
Please show us one of your textual sitemaps.

Please note that it can lead to issues if using both, GUI and textual sitemaps at the same time. This had already been mentioned with items and things.

I am aware of it. I will not have multiple sites. I need to understand where do I make mistakes.

My textual site saved under \openhabian\openHAB-conf\sitemaps\wesiory3.sitemap looks similar to the created in a new way of OH3.

sitemap mainSitemap label="Wesiory2" {
    Frame label="System Info" {
        Default icon="settings" item=Systeminfo_Storage_UsedPercent label="Storage used"
        Default icon="settings" item=Systeminfo_Storage_AvailablePercent label="Storage avialable"
        Default icon="settings" item=Systeminfo_IPAddress label="IP Address"
        Default icon="temperature" item=Systeminfo_CPUTemperature label="CPU Temperature"
        Text icon="time" label="Uptime formated" item=SystemUptimeFormated
        Default icon="time" label="Uptime" item=Systeminfo_SystemUptime
    }
    Frame label="Network" {
        Text icon="network" item=PingJaceksiPhone_Online label="Jacek's iPhone"
        Text icon="network" item=PingableJaceksGalaxy8_Online label="Jacek's Galaxy 8"
        Text icon="network" label="Gosia's SONY" item=PingableGosiasPhone_Online
    }
    Frame icon="garage" label="Garage" {
        Default icon="temperature" label="Temperature" item=AEOTECMultisensor6_Sensortemperature
        Default icon="humidity" label="Humidity" item=AEOTECMultisensor6_Sensorrelativehumidity
        Default icon="sun" label="UV" item=AEOTECMultisensor6_Sensorultraviolet
        Default icon="sun_clouds" label="Luminance" item=AEOTECMultisensor6_Sensorluminance
        Switch icon="motion" label="Motion Alarm" item=AEOTECMultisensor6_MotionAlarm mappings=[ON="ALARM!",OFF="OK"]
        Text icon="motion" label="Motion Alarm" item=AEOTECMultisensor6_MotionAlarm mappings=[ON="ALARM!",OFF="OK"]
    }
}

That‘s the issue, your sitemap file needs to be named

mainSitemap.sitemap

See
https://www.openhab.org/docs/ui/sitemaps.html#special-element-sitemap

WORKS! Now I understand.
Thanks. Now i can refer to the page defined in the sitemaps folder.

1 Like