Recommendation for Binding configuration, edit or Paper UI?

Setup, Configuration and Use Items & Sitemaps
1

Is there any reason why Binding documentation show the configuration by editing files for Binding, Things, Items, etc and not using Paper UI?
Is it for future upgrade compatibility better not to use Paper UI or does it make no difference? What will be the recommendation for configuring Bindings, Things, etc., is it file or Paper UI?

2

PaperUI is disappearing in the next major release: openHAB 3. Something else will replace it.

It is easier to share textual configurations, than show screenshots of user interfaces.

Also a lot easier to copy and paste!

Here is a guide to what is ‘recommended’: https://www.openhab.org/docs/configuration/#versatility

Different bindings will recommend different methods, as they’re made by different people. And users have their own preferences too!

1 Like
3

Thank you, that makes it clear. I haven’t found this guide, because I haven’t looked at this section. After I have moved every MQTT 1.x stuff to Paper UI, I now better move it back to textual form. Is there any place I can copy it from.

4

I don’t think you have to move it. PaperUI saves into an openHAB database, which the new OH3 user interface will presumably be able to read and edit (or upgrade to whatever the latest schema might be, if relevant).

(Data from the configuration text files are also eventually funneled into the openHAB database, so ultimately everything is stored in the same place, irrespective of configuration method)

5

If it is this way it will save a lot of work. So I’m looking forward to the unique storage space and do nothing to transfer anything right now. You have saved me a lot of hours. Thank you again.

6

The official docs recommend Thing be done through PaperUI/REST API/Karaf Console and configure everything else using textual configs. This is because:

  • you can’t do automatic discovery of Things with textual configs
  • the syntax isn’t always well documented and with PaperUI created Thing the syntax is always right
  • sometime bindings need to be restarted in order to properly pick up changes in .things files
  • some features are just not possible with .things files, such as changing device settings through the Zwave binding

In OH 3, the ability to share configs will be addresses by an import/export function which will render the Things/Items/Rules as YAML for posting to the forum and such. And with OH 2.5, one can pull the JSON if it’s really needed and post that.

correct

Incorrect. OH first loads everything from the JSONDB into memory. Then it loads everything from the textual configs into memory (potentially overwriting what was loaded from the JSONDB). The only place they are combined in in memory.

Having said that, there is an import function built into the replacement for PaperUI that will import .items files into the JSONDB.

So ultimately there are two sources of truth.

7

Ah, perhaps I was conflating the two. I’ll amend my post to remove errors.

8

Your answers helped me a lot. For me I summarize that I should use Paper UI for installation of Add-ons e.g. Binding and configuration of associated Things, Services etc. . That means in general I don’t have any .things file to edit.
Items and their attributes (label, group, icon) are set by editing .items file(s).
That takes me to the question if a connection from an Item to a Thing will be done with a Paper UI link or a textual assignment like e.g. a channel statement?

9

Your choice!

Personally I do everything in files, so my vote would be to use the channel= configuration in your Items file. Keeps all Item stuff in one place!