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.
I personally continued with textual configuration when switching to OH3.
Reasons have been
I had it already (i.e. laziness )
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
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
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.
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.
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.
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.
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).
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.
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.
Anyhow, where is a will there will be a solution!
Cheers,
Åukasz
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
)