Hi all !
I wonder if it is recommended to config OH2 by using only config files?
Or should we try to use as much GUI config as possible via PaperUI?
It is somewhat personal preference. People here generally advise AGAINST using Simple mode in the Paper UI.
I generally have the bindings automatically define the Things and use files for Items, Rules, & Sitemaps.
Sitemaps for the BasicUI are always files anyway, even if using Home Builder.
By the way, 2.5 stable has now been released.
1 Like
You’re sure to get a lot of different responses on that topic, so I’ll try to keep mine brief, as someone that’s still fairly new (started around Q2 this year), I’m regretting not going forward with config files from the start.
The long and short of it is that while I believe that PaperUI can and will be very powerful down the line, and certainly the best option for a lot of people, if you are willing to learn, config files are just so much easier to get help with, I find.
Almost all documentation gives examples with config files, if you search for some odd configuration or solution to an issue, there’s a very good chance that you’ll find out how it can be done via config files, but you’ll then have to figure out how to translate that solution into the paperUI configuration. The forums have so many current working solutions to so many different and odd things, you’re unlikely to get no results if you go searching, but adapting the solution to work in PaperUI can often be a frustrating experience.
Additionally, as it stands, you can’t copy items, or things in PaperUI, so if you have, say 5 Sonoff devices you need to setup, you’ll need to mindlessly do the same steps for things, items and channels 5 times. With config files, you can literally just copy and paste the same line, and edit maybe 1 or 2 things about it. There’s also no easy way I know of to rename items, so if you make a typo, or later decide on a specific naming scheme, you’ll have to go through, deleting and creating items again.
Personally, I’m slowly transitioning to config files.
1 Like
Yep, that’s the way to go. Avoid defining things with text file. It is very prone to errors.
1 Like
Configuration | openHAB outlines the various options you have available to you, their advantages and disadvantages, and the general recommendation (Things managed through PaperUI, text configs for everything else).
This can and should be done through the REST API.
- Create 1 Thing using PaperUI.
- Query for that Thing using the REST API Docs
- Copy and edit that JSON for your additional Things.
- Post the edited JSON to create the modified Things using the REST API Docs.
As mentioned above, text configs for Items is the recommendation already. The vast majority of bindings will automatically discover devices and create the Things for you. It’s only a few exceptions, like the MQTT binding, where you will need to manually create more than one Thing.
I spend almost no time supporting people who create Things using PaperUI. I spend hours of my time supporting people who insist on only using .things files. And why would you not want to take advantage of the fact that openHAB will do most of the work for you most of the time (i.e. discover and create the Things)? It’s a waste of your time, and when you run into trouble it becomes a burden on our time as well.
That’s a new use case. What I would do, if I had all my Items in JSONDB already:
- Stop openHAB
- Backup the JSONDB Items file.
- Change open the file and change the names as desired.
- Save and open the JSONDB Links file
- Repeat
Instead of step 4 and 5, I might just wipe out the Links file and relink the Items though the REST API or PaperUI.
It’s worth noting that the next version of OH will be 3.0 and it will feature a ground up reimplementation replacement for PaperUI which should address some of those limitations of PaperUI.
1 Like
That’s a fair response, and certainly news to me that it can be done.
I undertstand that using config files is more difficult, and will most likely result in more questions asked, but I’d still consider it the better option right now, as config files have many years worth of posts, not only form yourself, but from a lot of smart people solving a myriad of issues, you have a decent shot of finding a solution almost done for you ready to go if you look for it.
As for my example, I guess that’s colored by my environment relying heavily on MQTT, so I don’t get to enjoy many of the auto discovery aspects.
Looking forward to those changes in 3.0 tho, as soon as 2.5.0.1 gets to play nice for me 
1 Like
Except for Things. If you let the bindings find and create the Things for your it’s:
- guaranteed to be syntactically correct
- guaranteed to be complete
- take far less time to create
- relatively self documenting, all the options are there and documented in the UI itself.
Many of those advantages also apply for manually created Things as well.
There actually is a dearth of .things file examples for most bindings and many of those examples you will find are old and may or may not be currently supported. And you don’t find as many PaperUI examples because it just works. Examples are not really needed.
This is why the official recommendation is what it is.
2 Likes
I’m just arguing from my experience with it, I respect what you’re saying, but for me, even though I’m a tech literate person, I’ve found myself scratching my head a lot when it came to how things had to be set up in paperUI, because of a lack of explanations.
I’m sure, if I had started out with config files, I’d have scratched my head a lot as well, but now, after getting my head around the core concepts, I’m quite fine with using config files.
2 Likes