OpenHAB2 Setup recommendations

Hi there,
I’m pretty new to the smart home topic and - HOLY *****- there are too many possibilities to get started! :open_mouth:
First tried Domoticz, but after I watched I switch to openHAB2 :slight_smile:

First seconds were easy, but then it was confusing. And I’m still a bit confused :blush:
I’m wondering what is the right way to use the text config files.
Starting at item level or at sitemap level?

And is there a way to get my current installed addons as a text file config - regarding automated updates?

But in total I’m very impressed

HI Christian,

OH2 does a lot of discovery for you, so you don’t need to manually edit the text files. You best bet is to go a change out the tutorials and see if it all makes sense.

Starting at item level or at sitemap level? - The SITEMAP is built from ITEMS, so you should always start with creating items from all of the things you want in the HA setup. Does that make sense?

Good luck with your adventure, I’ve been using openHAB for the past few months and have found that it’s able to do more than most of the other open source offerings. With it also being module based you can build your own solution as you go and don’t have to fit your HA solution into the original developers ideas to solve their own problem.

You can specify which addings get installed so you don’t have to reinstall them on an update by putting them into services/addons.cfg.

As @Maximo said, you should start with Items and build up from there. But I recommend starting small with one or two Items and get it working end-to-end (Thing -> Channel -> Item -> Sitemap, Persistence, and Rules). Then grow from there.

I was wondering whether it makes really sense recommending to start with OH2 for a newbie considering the state of maturity of OH2.

Many binding contain serious bugs,
using paper UI as the method for discovering items is flawed because the unlaying data base may not survive the next update and then item names used in rules may be different and so on…

Maybe in half a year or so, OH2 maybe mature enough. I have tried two times to “upgrade” to OH2 but it was simply not possible because functions critical for me did not work.

So I would recommend starting with OH1 and then later update after the first release.

From my personal experience :wink:
If you want to build robust solution - go with OH1
If you want to play around and learn - you will be good with OH2.

To be honest, as a *nix veteran, I prefer to keep all my configs as text files. I can keep them under git, version them, etc. OH2 has less steep learning curve, but it’s not stable enough (as mentioned above)

I very much disagree with you both.

If you use OH2 with textual configuration and the 1.x bindings that you also use in OH1, it is as stable as OH1.
Nobody forces you to use any of the new OH2 features (and yes, they are still under development and not left untouched for years, so they indeed aren’t stable yet and rather “to play around”).

But I don’t see many reasons why you wouldn’t want to replace the OH1 runtime by the OH2 runtime. If you have such reasons, you should file issues and not sit and wait for a year to hope that they miraculously disappear. Your help is needed!

I’ll second @kai’s assessment. The core of OH 2 is rock solid and it has backwards compatibility so you can use the 1.x bindings. And you do not have to use PaperUI or Habmin if you don’t want to. Everything can be done through text files (with the exception of zwave Things which is mainly lacking full documentation but I believe they are working on a way to autogenerate that). And if you stick to 1.x bindings everything can be configured in text files.

If you follow the Migration tutorial through section 5 that is pretty much were you will be, running the 1.x bindings on the OH 2 core. You can then migrate (or not) to the 2.0 bindings or the other new stuff at your leisure.

Personally (and this is my own opinion probably shared by few) I think having PaperUI be the default first thing presented after installing OH is causing as many if not more problems than it is solving. Many people get the impression that PaperUI is the only or the preferred way to do everything and it is not yet ready for that. Of course this is just a feeling. I don’t have any insight into how many people are successfully using PaperUI without complaint. I only see those who have had trouble and posted here.

Thanks for the responses.

Sorry wasn’t fully clear.

I’m using PaperUI for:

  • Installing any Plugin, Extension, Binding
  • for device discovery
  • creating simple items
  • for connecting things to items

I’m using the text config files for

  • creating “virtual” items
  • creating items with more tags (like mappings)
  • creating rules
  • creating sitemaps

So I use items in my sitemap which are defined in the PaperUI not in text files.
Same for Rules.

Is this ok to do so, or should I move completely to text files for now?

If not:

  • Is there a way to read out the items stored in PaperUI?

  • Or even an “export to text file” script?

  • the item discovery is just so nice :slight_smile:

Thanks again
not using Zwave yet, but so far I don’t have any stability issue
(but only using the harmony and hue binding)

I’d say this is ok - imho the only issue with settings that are done through the Paper UI currently is that we do not yet have a good procedure for updating to a recent snapshot without the risk to lose that data again. This leads me to your next question:

Is there a way to read out the items stored in PaperUI?

They are currently stored in binary form in the mapdb database. No human-readable export possible right now.

Or even an “export to text file” script?

There were many discussion on how to resolve this “backup” problem and probably the best way forward is to replace the mapdb storage by a json database. I hope to soon find the time to review and merge this PR from @chris.

the item discovery is just so nice

Thanks, I also think that it provides quite some value as you do not have to struggle with finding the right syntax for your config from the wiki pages as in the past…


I don’t think there is any “proper” way. Use what works for you.

I personally use PaperUI for binding installation and autodiscovery of Things and setting up OH core (e.g. default persistence). I use text files for everything else. I don’t like to maintain the same type of thing in two different ways so try to avoid creating Items in the UIs in addition to text files. I’d rather they were all in one place.

I can see nothing that helps you specifically but the smarthome:items list command will give you a list of the Items which you can copy and paste out and then reedit to be the right format. Once you have it in a text file you can remove it through the console with smarthome:items remove <item name>.

You can pipe the output of that command using:

ssh openhab@localhost -p 8101 'smarthome:items list` > items.txt

Ah this is helpfull! I’ll try that thx!