OH2: PaperUI | items -> very long list... how can I manage this better?

I am setting up OHv2 and wonder about a lot of things…

One thing is: the list of items in PaperUI is very long, due to me having some 600 items. Can I stick with item files and not having to use PaperUI at all?
Is there even any reason I must use this tool?

I noticed that bindings can be loaded via the addon.cfg (I like that) :slight_smile:

I read elsewhere:
Warning: Changes made in the configs via the Karaf console
will not be recorded in your /etc/openhab2/ config files
and these files will be re-read by OH2 at startup,
overwriting the OH2 stored config parameters.

… another reason not to use a UI.

I think I a missing a few things; in fact I may not understand OHv2 at all, being on OHv1 for a few years.

[Later edit: I did not pick a ‘solution’ as the conversation gained and garnered a range of very good replies, in particular useful if you are new to OHv2 or thinking of taking the plunge to migrate from OHv1.]

Yes, you can stick with *.items files. You don’t need to use PaperUI to manage your Items since you have them manually defined in files.

You will use PaperUI for 4 main reasons: Configure OH2 System parameters + Install addons + Configure Things/Channels + play with the new rule engine.

Yes :slight_smile: (one less reason to use PaperUI)

here: HowTo: Manage OpenHab 2 configurations

that sentence is referring to config changes performed from the OH2 console (not PaperUI) and applies in the case that the *.cfg files include these parameters.

Most of the config changes that you will do on PaperUI will be related to the OH2 System parameters and these are permanent (will not be lost after a restart).


I appreciate your enthusiasm to help me out.
I also acknowledge:
a) that I maybe past my expiry date for these things :slight_smile:
b) may not get the v2 conceptually.

… and yes, it was your post; and yes it is the console… I am all that worried, because I installed addons through the console, and then learned that because my addons.cfg does not have these listed it happily uninstalled the bindings I loaded at the console. :slight_smile:

Can I ask: do I need things at all, or will v2 work with items, rules and sitemaps alone (apart from the bindings I would load via addon.cfg).

If the answer is yes, I would not need any UI, other than BasicUI to display the sitemap on display units (iPads) around the house.

[And just to add: I am not denigrating the work done by many; I am very much in simplification and consistency… as such I rather use textual config than tools that do parts of it.]

What also worries me at present (it it may well be due to my current limited understanding) that some config goes into some database and once it is in there, it does not update the file where the config came from… leaving me stranded to understand, whether a config comes from the text file or the database. (Similar to the addons.cfg and PaperUI-selected bindings).

It looks like I have to go through my set-up, as in running up all on QHv2, and see where it falls over, as in where I make fundamental mistakes. Once the learnings take place I can start over from scratch properly.

Again, thanks for your support.

Rich just answered some of my ‘concerns’ here:

If you use a “modern” binding (2.x) you will need Things.
The legacy (1.x) bindings do not use the Things concept.

Most of the v2 bindings allow textual configuration of Things also (in *.things files) so in this case, you can skip PaperUI also.

This is true… it’s not easy to identify all sources and destinations of config options. I am reading various material on this topic for the past year and I am still finding out new stuff every day :slight_smile:

I believe that OH2 is still in “transition” and the final destination is: managed configurations = less flat text files, more UI based configs with jsonDB type of storage in the back-end (that you won’t have to interact with manually).

I believe that this will happen when all addons will be v2 (if feasible). Till then, we will live in a “hybrid” environment with v1 text and v2 UI based configs (for addons, items, things, etc, etc)

Also, imho, UIs are the future of OH2 for configurations (not text files)… but we still have lots of ground to cover till then :slight_smile: maybe we will have OH3 by then :stuck_out_tongue:

1 Like

Thank you for this clarification; it helps to make sense of it all… but raises the question for me again: do I really need to migrate off OHv1?! My main reason for migrating off was a nicer UI for the room tablets. given it took me years to get where I am today, I am quite happy with OHv1 as it is currently running.

[Later edit: it was a tongue and cheek comment; like an old car, it works and is in great condition, but can no longer be serviced or kept up, becomes to costly (time, money and safety-wise)].

Well… Yes…
As an indicator: look at the activity statistics on v1 & v2 below (this is just for the addons… not the core)
v2 is the future with all it’s new stuff like HABPanel, HABot, Voice, etc, etc :slight_smile:


comparison: https://www.openhub.net/p/_compare?project_0=openhab1-addons&project_1=openhab2-addons

1 Like

Thanks for the encouragement… I do get it that I have move on (As in adopt OHv2)
Interesting sites and stats (12m, 30d)… 124 man years OHv1, 85 man years n OHv2 already… impressive. :slight_smile:

The current recommendation from most of us is to use PaperUI to:

  • install and configure bindings
  • discover, create, and manage Things

Items, Rules, Sitemaps, Persistence config, and configuration of most 1.x version bindings remain in text files like you are used to.

You are not required to use PaperUI, but for some bindings (zwave, zigbee, knx, etc) it will be far less work and far less for you to lean if you let them be auto-discovered or created through PaperUI.

Though I should not that auto-discovery can be managed through the Karaf Console.

Another reason to be consistent in how you create and manage any particular category of config. For example, if you create some Items in PaperUI, you are better off creating all of your items that way.

Make sure not to be mixing up terms. When we use the term Console, we mean https://www.openhab.org/docs/administration/console.html#the-console, not PaperUI.

All OH 2.x version bindings require Things. You cannot skip then and use the new bindings.

However, you CAN use the legacy 1.x version bindings and never have to deal with Things. But be aware, when a 1.x binding gets replaced with a 2.x version, usually development on the 1.x version stops. Essentially, this is what state your OH will be in half way through the migration tutorial. OH 2 core with all 1.x version bindings.

2.x bindings are a complete rewrite of their 1.x counterparts. The way they are configured and used are often radically different, and the fact that they all work through Things is only one of the ways they are different. This is why I structured the migration tutorial the way I did. It gets you up and fully running and let’s you explore and migrate to the new 2.x certain bindings at your leisure. It’s portentially a huge job otherwise.

But note, Things and Items are not exclusive. You still need the Items. Think of Things and Channels as replacements for the stuff that goes between the {} in your .items files. You still need the Items. You will just need looking your Items to a Channel on a Thing instead of configuring the connection to the binding at the Item.

Things and Items (and the experimental next gen rules engine) created through the REST API (e.g PaperUI) and Consol get saved to a JSONDB file in $OH_USERDATA. It’s a text file you can read or edit if you need to but it’s not very human friendly. Binding configs get saved to a config file in $OH_USERDATA/config whether they are made through PaperUI it cfg files. BUT, cfg files will always take precidence. In most areas, PaperUI won’t even allow you to make a change to something that is already being managed through config files.

But I’ll once again point to consistency. Be consistent and you won’t have problems.

Though many bindings do not document how to manually create Things in .things files so YMMV.

IIRC you are suffering from a memory leak on OH 1.x which prompted this latest look into OH 2.x. That will never be fixed in OH 1.x.

Many of the bindings you rely on now have ceased development as they are now doing bug fixes and updates only on the 2.x version binding.

Java 8 has reached end of life and OH 1.x will not run on the newer Javas (11 is the latest). At some point Java 8 will no longer be able to run on updated Raspbian. So if you plan on staying with OH 1.x realize you are also committing to not upgrade ANYTHING on that RPi because at some point there will be a change that will break OH or Java or something.

You have already reached the point where there is really no one left in this forum who can help with problems on OH 1.x.

Obviously the choice is yours but you will have to encase this system in amber, bugs, security issues, and all.

And of course you will be missing out on a lot of the enhancements. IMHO, the Member of Rule trigger and triggeringItem implicit variable alone are worth migrating for.

Indeed, I had no idea stats like that were available. In terms of the core of OH 2, I would not be surprised if they’re isn’t already more man years invested compared to OH 1.


Yes, I hear you loud and clear; agree with it all; updated my ‘trigger’ post… I won’t be staying on OHv1, as the downsides are obvious.
… and, of course, very much appreciate your effort with postings like this, which more often than not also help others to understand some of the quirks and philosophy…
I am sure I am not the only one who remained a happy chap and stuck with OH based on your input and support.

The good thing for me is, I can build a new system in parallel, by copying config files and ‘migrating’. In essence: I have no choice, given the life system which has to (must) continue to run until I can ‘switch’ over.

Another good thing would be to understand, whether some v1x binding are even required in OHv2. E.g. the Expire binding (can’t recall, whether I really read here that it may not be required in v2 due to new functionality). And I reckon it is up to the dev community to decide where the focus on ‘migrating’ code.

Is there a (dev) roadmap of sort?

There is no binding what-so-ever that is required in OH 2. You could run OH 2 without any add-ons. It wouldn’t do anything useful but it would run. Every user has their own set of add-ons and bindings that they use in their bespoke home automation system. But, if you use a 1.x bindings like Expire or HTTP (there is a 2.x version of the MQTT binding that is scheduled to be released in OH 2.4) you will have to continue to use that binding or find an alternative approach. For Expire you can use Timers in Rules, or continue to use the 1.x version binding until such time that an alternative is developed. There is another thread where a group of us are discussing just such an implementation for the experiment rules engine.

But this also points to Dim’s statement about OH being in a state of transition. OH 2 is essentially not done with whole swaths of features still stuck in the OH 1.x paradigm. Slowly features are being added to address this but it’s a ton of work and progress is relatively slow. But some of the awesome things coming down the line in the near future:

  • MQTT 2.x version binding with built in broker, no need for a separate Mosquitto server (available in the snapshots), support for some standardized MQTT topic structures like Homie, and automatic discovery of topics in some circumstances
  • HABot which provides a UI that lets us interact with OH more like a conversation using natural language (available in the snapshots) and UI elements that you can construct on an as needed basis (e.g. ask “what’s the temp” and it will show a thermostat widget)
  • Rule libraries; no longer will users need to copy and paste code from the forum
  • point and click Rule creation (work is started, hopefully to resume soon)
  • Rule and script editor built into PaperUI (available now but not super usable)

Yes but I don’t know where it is kept, outside of Kai’s head anyway. It is kind of hard to maintain a roadmap like that with an open source project because everyone pretty much works on what they want to when they want to.

1 Like