OH2: near/mid term future?

Setup, Configuration and Use Beginners
,
#1

I am a OH1 user… and eventually… through quite extensive support from the community (I will be forever grateful) managed to get a simple, though large system to work in OH1.

In August 2017 I took the plunge, bought a rPi3 and installed openHabian… beautiful installation script/work… and ended up on a web page which said something like: Select habmin, ClassiUI, PaperUI, some other interface, some other interface… and this is where this new experience ended.

I could not make a decision on the spot, and subsequent reading on the forum ended with frustration, due to descriptions like (and I am only paraphrasing) if you migrate from 1 to 2 use this interface, but then you can’t manage things; and some things (or whatever their name) need text config, and when you use text config, some other interface does not work, and you need to use another interface. – What?!

As life has it: I went back to work in September, until yesterday, when I quit my job :slight_smile: Hence, I have time again to look my OH environment. Well, work did not help that cause, as I have forgotten most of it due to inactivity in reading and configuring my OH1 system.

And here eventually my query: Has, since the release of OH2, been a development of sort, which allows for a single way (interface) to set-up OH2 and manage its configuration?

I am happy to start fresh, but only want to learn one interface, or one way of doing things. Is this now possible? Maybe 3 months (since August), did not change much. Or is there a plan to consolidate the interfaces into one; or should I wait some time for this consolidation to occur? Is it planned at all?
Where could I find a roadmap for OH2 development?

Any hints appreciated. Thanks.

#2

I’m a fairly new user, but not new to open source linux projects of various types, so I sort of know the drill. Openhab has been similar to others with a steep learning curve, lack of concise info, confusing information, big holes in the documentation, etc.

Best I can tell, it’s not quote there yet if you want a gui front end. Some things you can do in paperUI, some things must be done in habmin, and still others must be done by editing files. I think that’s just the nature of these kinds of projects, but I am hopeful eventually you will be able to do everything from PaperUI.

Take this advice for what it’s worth: (-)not too much experience with open hab yet, so I don’t have all the answers. (+)Still new enough that I can relate to your frustrations. I think those that have been around the project for a long time will lose some sense of perspective, while gaining valuable experience.

I would suggest going with the openhabianpi build and choosing the PaperUI. From the paper UI it’s easy to load habmin, and anything else needed that paperui can’t do yet. I’m really hopeful that PaperUI will soon be the only tool needed… but not yet.

Maybe I should put all of this in a wiki while it’s still fresh in my mind. I even got alexa controls working, but what a huge messy pain that was.

1 Like
#3

It depends on what what you want to do. You have a freedom of choice to learn many things, but you don’t have to.

If you want to use openHAB with ClassicUI / BasicUI, PaperUI is enough (+ some OH1 addons, which require file configuration). I have no idea how Habmin or Habpanel works, or whatever additional interfaces are existing.

My suggestion is, use PaperUI to install and configure addons and discover your things. All the basic stuff is quite easy.
Then define your items via text files. (I define also most of my things via files, but i wouldn’t suggest that as a start.)

I think, you should also look into the migration tutorial, you may copy most of your OH1 stuff over to OH2, but i never did that. I started with OH2.

#4

Well, for auto discovery you need either Paper UI or HABmin, though you could use it even through API or karaf console (but who wants to do that?)
When configuring zwave, as far as i know there is only one way yet, namely HABmin (but as I don’t own any zwave devices…)
When using OH1 bindings, the only way to configure is through text files, as openHAB2 is as much as possible compatible to OH1.
If upgrading from OH1 to OH2, the recommended way is, first only to upgrade and reuse all text files (with slight changes in rules), then, little by little, changing from legacy OH1 bindings to the new OH2 bindings. Maybe you want to use auto discovery, then use Paper UI or HABmin, maybe you want to have the textual version, then use .things files to configure Things and Bridges.

In question of end user UI: If using Classic or Basic UI (or HABdroid, iOS app) you have to use .sitemap files, so there is no way to omit the textual configuration.

But of course you can do things here and there, the only thing is, not to mix configuration for the same Thing or Item. (If setting up a Thing through file, it will be read only in Paper UI, if setting up a thing through Paper UI, you won’t see it in the txt file).

1 Like
#5

Unfortunately, as with most of OH, the answer is “it depends”. It you will be using any 1.x version bindings then the answer is a definite “no”. If you will be using only 2.x version bindings the answer is “yes, use PaperUI”.

Given there are several highly used bindings that do not yet have a 2.x version binding including: MQTT, HTTP, and Expire, most users will likely have to use a hybrid approach.

I run as follows (note, I run in Docker so have some use cases that drive some of these decisions):

  • Use addons.cfg to manage add-on installation and removal
  • Use PaperUI to manage autodiscovery and management of Things
  • Use .items files for all my items
  • Use .rules files for my rules (i.e. not using the Experimental Rules Engine).
  • Use Habmin to send commands and parameter updates to zwave devices

This is not the only approach. Some people avoid the UIs completely and use the Karaf console and/or REST API to work with the Things Inbox and such. Others do not use automatic discovery at all and define all their Things manually.

Were to start over from scratch or were not using Docker, I would probably manage installation of my add-ons through PaperUI as well.

Given the nature of OH development, I don’t think there is that sort of roadmap. There will likely never be just one UI chosen and the rest removed. ALL the UIs are optional choices. PaperUI is probably the closest to being “the official” administration UI, but I don’t see Habmin ever going away unless chris decides to abandon it.

Pay attention to that word “administration”. PaperUI and Habmin are admin UIs and not necessarily intended to be User’s Interfaces (Habmin has some features that, if they mature, could make it a very good User’s Interface as well). The other UIs, BasicUI, ClassicUI, HABPanel, etc. are User’s Interfaces, interfaces that you configure and present to the users of your home.

1 Like
#6

ZWave devices can be readily configured via Paper UI without having to use (or even install) HABmin.

#7

I appreciate the input! :slight_smile:

It looks like my 4 months absence from any ‘behind the scenes’ OH has resulted in a total blank in my grey matter box…

It is this conundrum where I want a stable environment… built up skills in OH1, run a system with lots of items.
… then OH2 comes along… I did not follow it at first, because it was under the dev.
… asking OH1 questions led to mixed messages answered in OH1 and OH2 speak.
I then conceded it must be time to move to OH2
Install it all, and get stuck at which interface to use.

Maybe I have to do more reading, but it confuses the heck out of me…
Why so many interfaces?
Is there no desire to settle on one?
Auto-discovery… what does it discover?

I have a network of Arduinos via Ethernet doing all sorts of things; mostly sensors and actuators, door bell, tank levels, air vents. Everything talks MQTT. They have no config file; other than .items, a bunch of .rules, and a .sitemap.

The addons I am using are:
org.openhab.action.mail-1.8.3.jar
org.openhab.action.mqtt-1.8.3.jar
org.openhab.binding.astro-1.8.3.jar
org.openhab.binding.comfoair-1.8.3.jar
org.openhab.binding.exec-1.8.3.jar
org.openhab.binding.expire-1.10.0-SNAPSHOT.jar
org.openhab.binding.fritzboxtr064-1.9.0-SNAPSHOT.jar
org.openhab.binding.http-1.8.3.jar
org.openhab.binding.mqtt-1.8.3.jar
org.openhab.binding.networkhealth-1.8.3.jar
org.openhab.binding.ntp-1.8.3.jar
org.openhab.binding.systeminfo-1.8.3.jar
org.openhab.binding.weather-1.9.0.jar
org.openhab.persistence.mapdb-1.8.3.jar
org.openhab.persistence.mqtt-1.8.3.jar
org.openhab.persistence.rrd4j-1.8.3.jar

So if I were to say I want to run this on QH2, I suspect I do not need auto discovery?! I have neither z-wave products, nor other HA products; other than a ComfoAir interface I have not used yet.

I can migrate or start from scratch, but which way to go is till a mystery.
Should I wait? Until ‘what’ needs to fall in place?

[One thing I find attractive is the graphing part; but I haven’t even looked at how this can be realised.]

So, my focus is on should I move to OH2 with the set-up I have got?

#8

You mentioned August 2017. Between then and now, all questions you posted have already been answered. Looking at your bindings, you may not need any changes to your items and rules files.

Why so many interfaces?

  • Because you may not like what I like
    Is there no desire to settle on one?
  • Because we don’t and shouldn’t have to. If you want a single interface, just buy Apple products.
    Auto-discovery… what does it discover?
  • Again, if you read enough, you’d know this by now.

No one can tell you which UI you’d like. Have you even tried them? If not, I suggest you start there first

#9

Hmm, I sort of get it… if OH wants to be boutique your answers suffice…
I don’t think I need to explain why I am not using an Apple product…

I am almost certain that the OH community wants a consolidated approach, avoiding to many ‘forks’ of the same thing.

One reason for my post was to save me lots of time; with others having already figured out a best way forward. I was absent, things have changed; maybe a response would have been; yes, interface A seems to do most of what you want… or the stuff I’ve got does not need auto-discovery anyway… I mean, one sentence, 30 seconds for some, would save me the effort of hours to make sense of disjointed responses.

I am also not picky with interfaces; I do not care much what they might look like, as long as I get the job done.

In any case; thanks for your reply.

#10

You’re welcome

#11

Well. OH isn’t meant to be a boutique and in fact it isn’t that many interfaces to actually overlap.
On the user UI side, there’s ClassicUI and the more modern BasicUI, just select which one you like better, but essentially now that BasicUI is working reliably, ClassicUI is just still around for compatibility.
There’s also HABpanel, but it’s no all-device Web UI but it is specifically designed to be used on specific devices (tablets), just as are the Android and iOS apps.
On rules, there have always been text files, and there’s openHAB Designer (now called ESH designer), but few people like it and thanks to @kubawolanin the VS code extension has matured as an alternative so now it was declared to be the new standard starting with OH 2.2.
On items, there’s PaperUI and text files and on sitemaps (items, too), there’s the new homebuilder (since 2.2 as well).

On the admin side, there’s habmin and PaperUI. PaperUI is the recommended generic (cross-technology) admin UI while habmin is specific to ZWave (although it also provides quite comprehensive access to items, graphing/persisted data and more). Anyone to run ZWave can use any of these, exclusively or in combination. habmin still provide a little more of the advanced functions.

The main confusion likely is because there’s sort of an overlap of textual (old style you’re used to from OH1) and UI config (PaperUI, default in OH2).
The OH vision is to have PaperUI be applicable for all administration tasks and to do it (or at least offer to do it) visually.
Reality, though, is that it only works for OH2 native bindings and there’s still a number of bindings that aren’t natively available as OH2 versions thus not configurable through PaperUI - MQTT being among these (that one is almost there, though). You do can keep running any OH1 binding, though, with it’s OH1 items syntax config for as long as you like or need to.
On the question why to move, check out this thread, too, please (short summary from that one: start migrating asap so you won’t have to do it in a hurry).
You should follow Rich’s migration tutorial - and specifically for experienced users like you, we hope (or should I say expect?) you to take the opportunity to validate this tutorial and to help enhance it.
Migration also is where autodiscovery fits in … in OH1, there were no things and you had to explicitly configure every item. PaperUI and OH2 bindings offer to auto-create things and items (to the extent possible, depends on how the underlying technology works) to ease first time setup, but you don’t have to take that offer. Specifically when coming from a working OH1 installation, you can rework your items file as the basis for your migration and will not want to create any new items at all. Most users will want to use autodiscovery for things since they’re using a main basic HA system to address most of their devices such as KNX or ZWave, so OH reads and present as things what’s configured in the controller or gateway already, saving a lot of config work.
But quickly browsing your list of bindings, I see none where you could benefit from this kind of config accelerator so yes, feel free to ignore autodiscovery.

2 Likes
Best Practices for Adding Z-wave
#12

Don’t forget, there are also HABpanel and cometvisu (though they are to be configured in a very different way).

#13

@mstormi, thank you very much for this helpful post!
I can work with that!
… it provides perspective… what I was looking for.
I am sure others will benefit from your post as well.

What confused the heck out of me (back mid year) was, that one interface can some 50%, which overlaps with another tool that does 70%, and another tool that does what the others can’t do… and I thought: what a mess? how do I remember using which tool for what – and promptly bailed out of it, by putting a potential new start or migration on hold. :slight_smile:

1 Like
#14

Because it is an open source project and UIs are add-ons like bindings and actions so people have contributed multiple UIs. Further more each one has a different aesthetic and each individual has their own personal preference. Multiple UIs allows this. Finally, the administration UI almost necessarily needs to be a separate interface from the day to day user’s interface.

I’ve not seen any move in that direction and it would be somewhat counter to the open source ethos to remove options like this. This is especially the case for something as personal as as the interface to one’s home automation.

In OH 1, one binds an Item to a binding via a config string between the {}. Each binding has its own syntax and each needs to be individually configured.

In OH 2 there is the introduction of Things. Things encapsulate that binding config separately as a Thing. Then we link our Items in a standardized way. And now that it is separate, OH 2 can automatically discover and create the Things based on automatically finding them. For example, Things are created for all the devices paired to the Zwave controller. Things are created for each device on your network in the Network binding. Things are created automatically configured for your location using IP based geolocation. Etc.

I wrote the Migration Tutorial and still recommend migrating what you have now to the OH 2 core. This will require the minimum of changes to what you have now. Then as time and desire allows migrate from the legacy 1.x version bindings to the 2.x version of that binding and OH 2.

1 Like