Textual vs. Ui driven configuration

Hey all,

I started to set up my complete openHAB2.5 setup on a freshly new setup RPi4 switching to OH3. Now that the system is configured, I wonder whether still to use the textual configuration further (which I liked a lot during all these years) or whether to switch also to the Ui driven way? Is there a benefit using UI driven with respect to the future?

My focus is:
Using habapp for rules
Hugh setup
Coding using VS Code
Backup using raspiBackup.sh

Of course I read the advantages and disadvantages in the documentation but that directed more into UI driven which i could not understand.

Would like to hear your words on how you have chosen to go forward and the reasons why. Especially the ones how have used openHAB2 for a long time.

Thanks in advance
Patrick

I personally continued with textual configuration when switching to OH3.
Reasons have been

  • I had it already (i.e. laziness :wink: )
  • For me it provides a better overview
  • With the VS Code OH plugin comes a lot of cool features, e.g. checking the states on Items in the editor
  • It’s easy to do search/replace changes
  • All in all it’s faster if you are used to code editors, e.g. having Items and Rules in two editor tabs
    There might be a lot of good reasons for the UI, but the text based configuration is my choice.
    Cheers,
    Jens
2 Likes

I’m the same as @JensD, for pretty much the same reasons.

Kai has also confirmed that textual configuration is not going anywhere.

The downside is that some bindings may be difficult to use (I think ZWave is one of those), and all the new UI stuff can only be configured through the UI, despite it being YAML under the hood.

One thing is for sure, if you are a long time user of OH2 who has used files to configure or write rules, and it all works and you understand it, then using your existing file based system in OH3 is the easiest path to getting your system running on OH3.
I’ve seen a few glitches from people just plugging in their entire file based setup straight away, but many more who have reported doing so without any problems whatsoever. You can get a complex OH2 install running in OH3 and have all the benefits of the new version and explore the new features over time

Guys, that already helped me. That helps me to step ahead.

I think I have a classical FOMO.

If there are further replies I would be glad.
Thanks

I keep going back and forth. When I set up OH3, I imported most of my items into the UI, but left some trickier ones in text files. However, I never got around to finishing the job, because I’m not sure that I want to commit to UI items.

I think that all new users should use the UI so that their formative experiences are based on that paradigm and they get invested in the semantic model. However, my system is set up for very minimal interaction through screens, so the semantic model doesn’t offer much benefit for me at this point in time (that could always change).

This being the case, I sometimes think that it would be better to revert to having my items in text files. I enjoy the convenience of being able to add a new item by just copying and editing an existing item, which you can’t do in the UI (unless I’ve missed seeing an obvious “clone” button). But more than that, I just like being able to group my items in different files/clusters, instead of having a very long list on a single page.

I think this is key. If you’re not used to code editors, then text-based config is very difficult to wrap your head around, and the UI will feel much friendlier. If you’re used to code editors, the UI is likely going to feel slow due to the extra clicks and screens that make it friendlier.

Textual every time for me. Biggest reason is that it’s easy and secure to backup. I’ve had to rebuilt from OpenHabian a few times and each time, the file configured stuff has been back on line in minutes.

That said, I usually use the UI to get new things and items going and once I’ve fiddled with the configuration, I replicate the parameters into the .thing file.

2 Likes

Textual for me as well.

I really wanted to go UI, when I migrated, so I tried it, but felt it was too much manual overhead, took so much of my time, so in the end I went back to my file setup. I also prefer copy/paste for new items, and easy batch management in my preferred editor (geany). I feel I have better control of everything this way.

But I also think that if you don’t have a lot of rules, and items, or are new with oh, maybe UI managed setup is easier.

You can back up using this command:
sudo openhab-cli backup ~/openhab3-WIP-good-so-far.zip

I use only the UI. I used to use files but why bother trying to work out the syntax etc.
The UI is pretty good.
Yes I love my vim editor but the UI is how I am doing it now.
I also dropped DSL and all my rules are JavaScript.

A hybrid solution

Since OH 3.0, I am using a hybrid of file-based and UI configuration.

The file based part

Items, things and sitemaps are completely configured via files, because I came from OH 2.5 and there was no good UI-based way of configuration. Personally, I like the files for easy search and renaming items and they are really easy to backup. Also, I can work offline on my openHAB configuration and upload it to the openHAB server later. In my opinion, the only drawback of the files is that loading them takes quite a while.
I have about 550 items and 53 things.

The hybrid part

Most of my rules are still file-based in .rules, but I am mirgrating them now to UI-based rules and scripts for better code-reuse.
The biggest disadvantage for me of the file-based .rules is, that I have many rules which do exactly the same with different items. I had to copy and paste them many times and I had to adjust the item names.
Now with the new UI-based scripts and rules I can easily reuse the code.
And UI-based rules and scripts have another big advantage: my rules and JavaScript scripts are extremely fast compared to the file-based rules.

Conclusion

When you come from openHAB 2.x, stay at your file-based configuration for items, things and sitemaps and maybe switch them over to UI-based later.
But you should really try it the UI-based rules and scripts for their speed.
When you are new to openHAB 3.x, personally I would completely go with the UI-based configuration as you don‘t have to learn much and it is very intuitive.

2 Likes

Is there a good way to extract the parameters from the UI, or are you just doing that for each item individually?

It isn’t automatic but looking at the ‘’’code’’’ tab in the thing definition in the UI shows the parameter names and values that you can replicate.

Similarly with items, you can use the ‘’’Channels’’’ tab to get the ‘’’channel=‘’’ string to link it to an item.

3 Likes

Guys, thanks a lot for all your inputs, that gives me a good starting point! Helped me a lot.

As written in my inital post i have massive amount of things and items currently configured file based in openHAB2.5. So i will proceed using the file based approach and will test the Ui step by step (and maybe use the semantic model).

Thanks
Patrick

For info, you don’t need the UI to generate the semantic model, though it is a bit friendlier.

1 Like

Nice. I didn’t upgrade to OH3 until February and missed seeing when you originally posted this. Thanks for mentioning it here.

I feel this problem. How to get clear overview of item metadata (e.g. expire) and how to compare many similar items / things easily to spot configuration errors.

Most of my items are bound to modbus and traditionally many use text for these. In the end I bit the bullet and built everything with UI. Semantic model was one the main reasons for me, but also syntax error free configuration.

I ended up doing a small python command line app (calling OH HTTP API) to split out details of things, items, links in a tabular format. I highlight unbound items that are probably result of configuration error. I know this is definitely not for everyone but for me it really worked and allowed me to identify issues in the config.

You can use the semantic model with text config. [OH3] Semantic Model setup via tags in configuration Items files

I am aware. But prefer the visuals to see the hiearchy…

I would say that the textual vs UI driver discussion will never end, cause both have their own advantages and disadvantages. What I would like to point, is that current way of handling textual configuration is based on xtext which is very specific to openHAB.
Over time we have seen a failed attempt to make an IDE around that syntax (anyone recall Eclipse SmartHome designer?). We also have community members who work pretty hard to add support for this syntax in modern tools to simplify people’s life. Yet, I believe, these do not solve a core issue of the xtext based approach. The issue is that you cant read, modify and write it back. Or there is no one in this community who knows, or want to learn, how to do it.
I recently wrote a new XML based configuration for persistence services (sample persistence.xml file) especially for that reason. Over time I hope to get a way to manage persistence over UI and write it back to configuration file when needed.
I am not sure if I will invest time to do same for things and items files, but I would welcome an alternative to jsondb (anyone who tried to edit json files knows how hard it is). A “read only” handling of user supplied files should be a switchable feature and not limitation imposed by the framework. For some reason openhab core is able to parse above definitions, create model elements out of it but it can’t synchronize it back to the disk. To me this is pretty artificial and should be marked as first to shoot in OH 4. :wink:

Anyhow, where is a will there will be a solution!
Cheers,
Łukasz

1 Like

Hello, can you post me some Javascript rules you
Implemented in your openhab setup. I’am a beginner and like to learn about rules and Javascript.
Greetings Peter