Openhab2 - starting out - really don't get it

So I’ve been using OH1 for about 5 months. Got quite comfortable with the concept of adding a item to the default.items and then adding the item to the default.sitemap.

Now I come to OH2…and are confronted with paperui, basicui, habpanel.

So a bunch of my items are still on an old OH1 system (on frodo), and most a mqtt based. I add the mqtt binding in oh2 expecting to be able to configure in in the paper ui (as my discovered chromecast is able to). Nope it didn’t seem to show up. Ok so I find there’s an mqtt.cfg file to play with - no worries I had a frodo broker, and a openhabianpi broker (this is another OH2 instance with a zwave sensor on it, publishing everything to the mqtt broker - should be a simple mqtt based item to add to my new system).

So I have the mqtt confgured, and have a look back in paper ui…and still see no reference to mqtt. Ok again, back to the terminal and jump into the items folder and paste my zwave items to a file - this feels familiar.

Back in paper ui I look at my configuration/items - oooooh there they are. But there I stop. How do I look at the value? How do I display it. There doesn’t seem to be a way to view it or add it to something. With my chromecast, it appeared in the inbox and I could click on it, or find some channel that if you select it, it showed up in the control part of paper ui. But with an item - I can’t see how to get a list of the channels, or add an item to to be viewable.

What am I missing? And it it something special about mqtt?

I just added the mqtt binding to my openhab2 testing enviroment. :slight_smile:
I noticed the lack of mqtt items in the paperUI, too. :frowning:

I guess its because there is no special binding for openhab2.

It looks like you need to create a sitemap, so you can use classic-ui or basic-ui.

This worked for me.
http://<server-ip>:8080/basicui/app?sitemap=mqtt#

and creating a sitemap is in the oh1 style, ie get into the sitemap folder and start hacking?

Seems weird that that fundamental part of the system is not part of paperui - or even just a pointer to say, “hey go edit in here as we haven’t got that feature yet”

Yes.
My sitemap looks just like this:

sitemap mqtt label="mqtt"
{
    Frame label="Sonoff01" {
        Switch        item=Sonoff01Switch
    }
}

Cheers so I’ve done that…but now I’ve got the situation were if you go to basic ui by itself, the discovered chromecasts show up, and only if I add the extra to the url can I get my hand written sitemap.

It seems very disjointed. It smart home designer, the discovered items don’t show up as items I can utilise, only the file based items do, and in the interface there doesn’t seem to be any link between runtime items (I believe that’s what the discovered ones are called) and file based

Am I missing something?

There are 2.0 version bindings and 1.x version bindings. PaperUI, Things, automatic discovery and other newfangled OH 2 capabilities ONLY work for 2.0 version bindings.

The MQTT binding is a 1.x version binding. Consequently it works almost identically to how it worked in OH 1. There is no autodiscovery. There are not Things. There are no Channels. PaperUI and Habmin cannot create Items for these bindings.

You must create your Items in a .items file like you have always done in OH 1.x and add those Items to a Sitemap (or Habpanel). PaperUI is not involved in any way.

Its a 1.x version binding so you can do nothing in PaperUI to configure or create Items bound to this binding. You must create Items like you always have in .items files.

This is a 2.0 version binding so is compatible with PaperUI.

PaperUI is an adminsitration UI, not a User UI. You need to create a sitemap like you did in OH 1.x and use a User UI like BasicUI or ClassicUI, or create a new UI using Habpanel.

Please see the Migration Tutorial. I think a lot of these confusions would be cleared up by following that.

There are new concepts that come into play with OH2, Things and Channels. These replace the stuff you used to put between the { } in your Item definitions and were created to support automatic discovery of devices like you experiences with the Chromecasts. But these only exist for 2.x version bindings. MQTT is a 1.x version binding so none of this exists. It woks like it always has with .items files. PaperUI does not work with 1.x verison bindings.

You can set the default sitemap in the BasicUI settings in PaperUI. Without setting the default sitemap it uses an autoamtaiclly genreate sitemap containing all of the Things that exist in your conmfig (and therefore nothing from your 1.x version bindings).

Discovered ones are Things. Things have Channels. Channles get linked to Items.

ESHD is only aware of and able to deal with Items that exist in .items files at this time.

Yes, please see the Migration Tutorial.

2 Likes

Does that mean that if the Matt binding is rewritten for version two, it will support discovery and use the new channel model?

And that eventually all the confusion over file based items and runtime items will go away?

There has been some work in that direction but there were some problems so I would hold my breath waiting for the 2.0 version of the MQTT binding. It will probably be quite awhile.

I can’t guarantee that the 2.0 version of the MQTT binding would support aurodiscovery but it definitely will utilize Things and Channels and work with the admin UIs.

I personally don’t think all the 1.x version bindings will ever be replaced for various reasons. Take exec for example. A lot of users consider the 2.0 version to be a big step backwards.

I guess the big problem I can foresee, is people stuck in this model of the nice gui experience for v2 based addons, and the OH1 experience of configuration for v1 type addons - as there’s no real connection between them at all.

I would have thought that if the v2 addons wrote themselves as items into the files based config (rather than use it’s own internal database) - that the experience would be slightly easier to grasp.

It would have but it would have greatly hampered OH 2’s progress on its roadmap. The decision would have been to either cut off OH 1 entirely (which would mean no support for MQTT at all right now) or greatly hamper if not completely preclude auto-discovery and some of the other new OH 2 capabilities, not to mention making the administration UIs much more difficult to write and therefore manage.

Eventually everything will catch up and it might work a little more consistently. But when you are dealing with an opensource volunteer driven activity I’m sure you will find that getting something out the door that mostly works trumps waiting months or years to have a wholly consistent product.

1 Like