OHv2: Do I need things at all?

I am in the process of migrating from OHv1 to v2… basic install; then copied all item, sitemap, rules files. Have a Fritzbox; and the Fritzbox items seem to work.

Then I started picking an easy one: sysinfo, rewriting the items:

Group gSystem

Number cpuLoadAverage1min		"Load avg. 1min [%.1f]"		(gSystem)	{ channel="systeminfo:computer:work:cpu#load1" }
Number cpuLoadAverage5min		"Load avg. 5min [%.1f]"		(gSystem)	{ channel="systeminfo:computer:work:cpu#load5" }
Number cpuLoadAverage15min		"Load avg. 15min [%.1f]"	(gSystem)	{ channel="systeminfo:computer:work:cpu#load15" }

Number memFreePercentPeriod
Number memFreePercent		    "Mem free [%.1f %%]"	    (gSystem)	{ channel="systeminfo:computer:work:memory#availablePercent" }
Number memUsed		        	"Mem used [%.1f MB]"		(gSystem)	{ channel="systeminfo:computer:work:memory#used" }
Number memUsedPercent	    	"Mem used [%.1f %%]"		(gSystem)	{ channel="systeminfo:computer:work:memory#usedPercent" }

Number memTotal	    	    	"Mem total [%.1f MB]"		(gSystem)	{ channel="systeminfo:computer:work:memory#total" }

These are on the sitemap, but nothing happens, as in, these items are not updated.

In fact I am getting an error:

[ERROR] [ore.common.registry.AbstractRegistry] - Could not inform the listener 'org.openhab.core.items.internal.ItemUIRegistryDelegate@f589c4' about the 'ADDED' event: org/openhab/core/compat1x/internal/ItemMapper

What am I missing?
Do I need things? … at all, when migrating and wanting a pure text-based config?
(I have no things at present.)

The question to ask is: Will you be using any “modern” (2.x) Binding?

If the answer is: Yes (most likely): Then, you will need to configure Things (either using PaperUI and/or using *.things flat text files)

If you stay with only legacy (1.x) Bindings, then you will not use the new 2.x concepts (Things, Channels, etc)

In your example, you are already using the systeminfo addon, which is a 2.x Binding, so you will need Things.
Note: There is also the legacy version (1.x) of : https://www.openhab.org/addons/bindings/systeminfo1/ but you should use the newer (2.x) one

Did you create Things for this binding using PaperUI? Check the Channel UID from PaperUI to make sure it is correct. If you have no Things defined for the systeminfo addon: then the Items will not be linked to any Channel (of a Thing) and will get no updates.

I have to check this one… I don’t remember its root-cause atm.
edit: check: AbstractRegistry raises Exception about ADDED event!: null

@rlkoshak invested alot of time to type up this: https://www.openhab.org/docs/configuration/migration/#new-concepts-things-and-channels. Check it out.

2 Likes

I’d like to elaborate a bit on Dim’s response, which is spot on.

In the OH 1.x world you are used to, pretty much everything is defined on the Item between those two curly brackets.

In an OH 2.x world, all the stuff that used to go between those two curly brackets are not created as a Thing with Channels. You MUST create a Thing. The Thing will have one or more Channels. Then you Link one or more of those Channels to your Item using the syntax you have above.

I’ve never seen that error either, but I would not be surprised if that isn’t the error one gets when trying to Link and Item to a Thing that doesn’t exist.

1 Like

Thanks for the quick reply :slight_smile:

Looks I am not ‘getting’ this ‘thing’ thing.
Had a look at the docu… oh dear; docu is fine, I am not.

I tried:

systeminfo:computer:work [interval_high=3, interval_medium=60]

which I found in the docu, and it worked.

But how am I supposed to know that I have to type systeminfo:computer:work?
And why is there a definition for interval_high and interval_medium?
I see that values can be assigned. OK.
… but where do I specify either one?

Huh… Rich… thanks :slight_smile:

I think I need to rename all my files (I had copied from OHv1 to become invalid, hence not loaded) and then do one bit (for a better word) after the other :frowning:

It looks like the sitemap can stay the same.

And if I understand you correctly, with curly brackets moving from item to thing, I may have to create a few hundred things… maybe not, as the systeminfo thing has proven; it seems to apply to multiple items.

I reckon further reading and trial and error the config.

Is it correct to assume that a pure text file config is possible and no UI is required when using text-based config only?
What leads me to this approach is the problem with either UI not doing all, and some bindings need text config and others but not all get discovered. — And before I get shot in the foot with that, I rather stay away from auto-whatever.

If you use *.things files, you need to follow the docs examples.
By default, you are expected to use PaperUI to create your Things.

This is the configuration for the Thing. It affects the polling interval for each of the Channels priorities (low,med,high)

good question: the docs don’t explain how to change the default priority for each Channel :slight_smile:

1 Like

A tl;dr for the concepts, which are covered in the migration tutorial and the Concepts section of the docs are:

  • A Thing represents a Device or API. So I would expect the SystemInfo binding to have you create one Thing for a Computer.
  • A device can have one or more sensor readings or actuators that it supports. Each of those will be represented as a Channel on the Thing. So in cases like the SystemInfo binding, I can see one Thing with dozens of Channels.
  • You usually only have to define the Thing and the Channels are predefined on the Thing for you. So all you need to know is the ID for the Channel you care about. The easiest way to find the Channel ID is in PaperUI. Browse to the Thing and it will list all the Channels. There is a little two overlapping squares icon to press to copy the Channel ID to the clipboard. Copy that to your { } in your binding and you are good to go.
  • Things are really intended to be automatically discovered, in which case ALL you have to do is let the Thing be discovered and created and copy the Channel IDs to your Items.

I suppose you can also get the Channel ID from the Karaf console and you can for sure get them from the REST API. And the docs for the binding will list them as well.

Only for those Items that you are trying to migrate to the 2.x version bindings. All the ones still using the 1.x version bindings can remain unchanged.

Yes, but frankly, it is going to me more work, more fiddly, and more error prone. People seem to insist that defining all their Things in text config files is somehow better and saving them something or giving them some sort of advantage. I fail to see it myself. I’d rather let the computer do the work. It will save you a heck of a lot of time and effort in the long run.

What I do and what I mostly recommend is the following:

  • Install bindings using services/addons.cfg. This requires a little more attention to details because you need to know whether you are working with a 1.x version binding or a 2.x version binding to choose the right binding ID (e.g. MQTT 1.x version binding’s ID is “mqtt1” but the 2.x version is “mqtt”). This is not a strong recommendation and in my setup it is largely an artifact from when the Docker Image wouldn’t upgrade the bindings when you upgraded the container.

  • Configure 2.x version bindings in PaperUI. This is largely because not all 2.x version bindings adequately document how to configure them in .cfg files.

  • Configure all 1.x version bindings in .cfg files. Precious few 1.x version bindings can be configured in PaperUI. And the ultimate goal is to eventually have 2.x version bindings for ALL capabilities so this is really just a temporary (could be years) situation.

  • Create and configure ALL Things in PaperUI. I still have a few defined in .things files that I’m slowly moving to JSON DB as time permits. The freedom to not have to worry about formats and parameters and the like is more than worth giving up .things files.

  • Create and configure ALL Items in .items files. I still use a few 1.x version bindings and I use tags and will start to play with profiles soon, none of which are supported in PaperUI yet. So I manually create my Items in text configs.

  • Everything else is in text files as well, though I’m going to start migrating my Rules to the Experimental Next Gen Rules Engine soon as I continue the effort of documenting it and writing the tutorial for it. It is almost ready to drop “Experimental” from it’s name.

And lest you fall prey to the FUD out there about configuring using PaperUI…All the Things (and NGRE Rules) are saved in files in /var/lib/openhab2/jsondb. Should you want or need to, you can open these files and edit them by hand as they are just text files. Just about any other advantage people claim for using .things files over the JSONDB files are not true. There ARE reasons to choose .things files over the JSONDB files. But the ones usually sited are not true.

And the JSONDB actually gets automatically backed up unlike your .things files.

Let’s take a case in point.

OH 1.x Zwave way of configuring an Item (IIRC):

  • Add the device to the controller by opening Habmin (or unplugging the dongle if it supports offline pairing) and entering inclusion mode
  • Create the Item
  • Look in the log to determine which Node it is you want to configure an Item for
  • Look in the Zwave database to figure out what command classes and what parameters the device supports (you may have been able to get this information from the .xml file automatically generated by the binding, I can’t remember)
  • Look on the wiki for figure out the correct format to bind an Item to the proper node and command class with the proper parameters
  • Watch the logs for the inevitable syntax errors
  • Put the Item on your sitemap to test it works (watch events.log if it is just a sensor
  • Repeat for each command class supported by the Node and for each Node on the controller

OH 2.x Zwave way of configuring an Item:

  • In PaperUI open the Inbox, click the scan button and choose zwave to enter inclusion mode. Include the new device.
  • In the Inbox the new device will be listed. Accept the new device. Enter in some metadata like where it is located and what it’s controlling so it can be easily identified later.
  • Create your Item
  • Copy and paste the Channel ID from PaperUI to the Item’s channel=" " between the { } (or create the Item in PaperUI and create the Link in PaperUI)
  • Test the Item by looking in the Control tab in PaperUI

OH 2.x Zwave way of configuring Item using .things files:

  • see the OH 1.x way of doing things, only the format and structure of the configuration string is WAY more complex and involved then it is for OH 1.x bindings.

By using PaperUI and automatic discovery I don’t need to learn a new syntax. I don’t need to look anything up. I don’t need to search across multiple files or locations to gather information needed to configure the device. There is not syntax to mess up. And unless you already know how to create Things by hand for that binding, it is going to be way faster even with all the point and click steps involved. And because it was done automatically there is no chance of the syntax being wrong.

3 Likes

Thank you kindly for this comprehensive reply.

Further reading on the forum in the interim confirmed the confusion with things (over the last two years), and what you referred as FUD about PaperUI.

I am happy to take your advice, and will use PaperUI. Should I delete the oneliner .things file I have created and let PaperUI discover it? Or will PaperUI find the file whack it in the JSON and delete the .things file?

Is PaperUI only ‘taking’ the things, or will it suck in other ‘stuff’ (e.g. items) inot its JSON DB?

I now get the difference between v1 and v2 bindings:

openhab-ui-paper                            │ 2.3.0            │ x        │ Started     │ openhab-addons-2.3.0        │ Paper UI
openhab-binding-exec                        │ 2.3.0            │ x        │ Started     │ openhab-addons-2.3.0        │ Exec Binding
openhab-binding-systeminfo                  │ 2.3.0            │ x        │ Started     │ openhab-addons-2.3.0        │ System Info Binding
openhab-action-mail                         │ 1.12.0           │ x        │ Started     │ openhab-addons-2.3.0        │ Mail Action
openhab-action-mqtt                         │ 1.12.0           │ x        │ Started     │ openhab-addons-2.3.0        │ MQTT Action
openhab-binding-expire1                     │ 1.12.0           │ x        │ Started     │ openhab-addons-2.3.0        │ Expire Binding
openhab-binding-fritzboxtr0641              │ 1.12.0           │ x        │ Started     │ openhab-addons-2.3.0        │ Fritzbox TR064 Binding
openhab-binding-http1                       │ 1.12.0           │ x        │ Started     │ openhab-addons-2.3.0        │ HTTP Binding
openhab-binding-mqtt1                       │ 1.12.0           │ x        │ Started     │ openhab-addons-2.3.0        │ MQTT Binding
openhab-binding-weather1                    │ 1.12.0           │ x        │ Started     │ openhab-addons-2.3.0        │ Weather Binding
openhab-persistence-rrd4j                   │ 1.12.0           │ x        │ Started     │ openhab-addons-2.3.0        │ RRD4j Persistence

This also explains why the Fritzbox items worked and he systeminfo items didn’t.

I do not have zWave devices; in fact I have no devices a binding could serve… all talks MQTT from Arduino type devices around the place.

[further update]

I deleted the .thing file I had created; when I scan, systeminfo comes up:

For what I am seeing, it creates a channel (is this the right terminology?) named systeminfo:computer:rpi3ohv2.
I suspect this then invalidates my item config as defined in previous posts, which read systeminfo:computer:work

Can I change the thing to systeminfo:computer:work?
It seems this is not possible in PaperUI.
I do not like the name, as it reflects the computer name: rPi3OHv2 … which may not be the case in the future, if I change computers to run OH on.

If I click on items, will PaperUI suck in convert my items configured in text files?
Unless someone can confirm, I won’t even dare to click on it.
:slight_smile:

Usually, you can’t change the auto discovered Thing names. You can change the label but not the name.
You can manually create a new Thing using PaperUI if you want and provide a specific name.
It seems that the systeminfo binding takes the hostname for naming the Thing.

In this case, it would be better to use a *.things files to create your Things.

Yes, it will :slight_smile: (but they will appear as read-only since you won’t be able to modify them using PaperUI)

maybe:

systeminfo:computer:localhost [interval_high=3, interval_medium=60]

(since work is not your hostname)

1 Like

Thanks again… :slight_smile:

I have deleted the thing in PaperUI and am now getting endless error messages, like these:

2018-12-24 19:26:47.925 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler SysteminfoHandler of thing systeminfo:computer:rpi3ohv2 tried checking if channel storage#available is linked although the handler was already disposed.

How can I fix this?

It is not the same message; it seems all properties of the channel are being listed… (ran through).

You need to first unlink the channels for that “thing”

I did not link anything…
Checked at the console:

openhab> links list
cpuLoadAverage1min -> systeminfo:computer:work:cpu#load1
cpuLoadAverage5min -> systeminfo:computer:work:cpu#load5
cpuLoadAverage15min -> systeminfo:computer:work:cpu#load15
memFreePercent -> systeminfo:computer:work:memory#availablePercent
memUsed -> systeminfo:computer:work:memory#used
memUsedPercent -> systeminfo:computer:work:memory#usedPercent
memActualFree -> systeminfo:computer:work:memory#available
memActualFreePercent -> systeminfo:computer:work:memory#availablePercent
memTotal -> systeminfo:computer:work:memory#total
openhab> things list
systeminfo:computer:work (Type=Thing, Status=ONLINE, Label=Systeminfo, Bridge=null)
openhab>

… it did not show links.

I restarted openhab2, and the errors (actually [WARN] were gone.

Still interested though, what I should have done to unlink the channels.
Wouldn’t like to do this with a production system, not even thinking about clogging the openhab.log.

The PaperUI way of doing that:

This shows a switch itemtype “Test_Linking_Switch” linked to the switch_binary channel of a Fibaro Relay:

Hit the recycle bin icon, you will get:

unlink

Confirm with “Unlink”, then delete the item, then delete the thing to get rid of everything.

1 Like

I see…

[I can’t remember what I was presented with in PaperUI, whether there were linked items; most like there was one, as I could see the channels listed after I had created the systeminfo thing.]

This seems to mean, while I only wanted to create the .thing file, PaperUI must have created the relevant items and established the links?!

Hmm… if I only want 5 channels, and the thing has twenty, and what I assume above is correct, all 20 would be created, despite not being needed?!

Only if you have “Simple Mode” enabled.

Yes, all available channels are created, but you only link items to channels which are needed.

This screenshot shows three channels from a thing, only one channel is linked to an item (the first one with the solid white dot):

channel_no_item

1 Like

BUT :grinning:
there are exceptions: as you are working with MQTT, with the new MQTT2 Binding you need to create each channel separately for manually added things:

2 Likes

Thanks… not there yet; ‘there’ meaning MQTT…

I am very very slowly working my way through the overall config…

1 Like

Check out this docs page, too.

1 Like

You need to delete the file. In general the text files will take precedence over what’s done in PaperUI and PaperUI is powerless to do anything with the text configs.

It doesn’t stuck in anything. JSONDB is just how Things, Items, Links, and soon Rules get saved when you create them through the REST API (e.g. through PaperUI). Nothing you define in text configs like .items files will appear there.

Notice in that list exec is also a 2.x version binding.

MQTT binding?

You can but it will be easier to copy the new Channel ID over to your Item. Some bindings give you the opportunity to change the Thing ID when you first create it. But not all bindings do. And once it is created it is best not to chafe the ID. Once it’s crated, you can edit the JSONDB by hand, just be sure to stop OH while modifying the JSONDB file manually. But you also have to make sure the links get updated also.

Also beware you should only modify the last segment of the Thing ID. The rest of the parts identify the binding and information needed by the binding to identify the device.

The Thing is supposed to represent a physical device. That sort of abstraction is intended to be handled by Items. So if you’re computer gets relplaced then you should create a new Thing and update your Links to the Channels on the Items.

No. It will show your Items but you won’t be able to modify them through PaperUI.

Unfortunately this approach is going to make this really long and frustrating for all of us. Trying things and seeing what happens is how most people learn best. If you are too afraid to try stuff how will you ever get the confidence to administer your own system?

As sihui indicated, only if you have simple mode inabled will this be the case. When simple mode is enabled items will be created and linked for all channels automatically. But you implied you have an Items menu in PaperUI. If you have that menu then you do not have simple mode enabled. If you followed the migration tutorial simple mode would not be enabled.

Channels are properties on a Thing. If the Thing can provide that sensor or actuator then there will be a Channel on the Thing. You may have a bit more freedom when you define Things in .things file but that is going to depend on the binding. Typically all possible Channels are going to exist as a property on the Thing.

Thanks; according to this table, textural config is the way to go; it provides all but auto-discovery.
… and since I have nothing to discover, textural is it.

What I take on the chin is that I have limited time… and it is not about “don’t we all?” I commute 200km per day, work 8+ hours, hence, am away from home for 12h. 8h sleep, and I have 4h left for other things. [I am also end of life, maybe another 10 years to live; time will be of the essence.]

As you know, I have started looking at v2 last year in August and got stuck when I was offered a bunch of Admin interfaces with varying capabilities. What I also take on the chin is that I get into it, and then have to stop, and by the time I get back to it, I forgot most of what I’d learned before; however, I do take notes, and I have a structured approach. One thing is, I want clean systems. And when I buggered up the Java install, and had to uninstall, and fix, and clear and what not, I rebuilt the system based on my notes… the further I progress, the less like I want to ‘destroy’ the system.

While I have no intention to ‘frustrate’ my fellow forum members, my aim is to look for a repeatable and reliable way forward to create the OH v2 system. One assumption is that my naming can stay the same; I have some 500 items, and now remember that creating or having these in PaperUI is a mess, as I end up with a list of 500 items I have to browse through. At present, these a logically grouped in ‘energy’, ‘water’, ‘light’, ‘astro’ and other groupings, with easy access via items file.

When I asked why we have multiple interfaces with disparate capabilities, I was told this is the freedom in Open Source, where people do what they like. Given my time constraint, I see no value in figuring out to use A for Z, and B for Y, in a changing environment. I am doing this now, and am looking for a way to easily transition form v1 to v2… based on what works ‘at this very moment in time’.

Having a thing created that names itself to blah:blah:rpi3ohv2, without me being able to edit it, also knowing there will be different hardware or other upgrades/progressions, is not really helpful. I get the part for non-local things, but for itself “thismachine” or “localhost” would have been better. [This would be in line with the astro binding, referencing ‘home’ for sun and moon.] But this is a very minor point. In this case, since I had mt items already defined and referencing one name, I was not prepared to change them to the new name. Hence, I deleted it, and ran into the problem of not having unlinked it. I am sorry for not being aware that PaperUI created links (I had to delete)… the issue here: I don’t know what I don’t know.

Anyway, what I wanted to say is, I have no intent to frustrate anyone; I consider myself lucky for having such a great response to my encountered problems, including explanations that help me understand the bigger picture.

What causes me problems seems to be directly related to my findings in August: multiple interfaces with different capabilities, rather than one that does it all. I have no intention to keep track which interface may develop new capabilities and change my approach accordingly. If it worth anything, I’d like to appeal to the community by saying: make sure whatever binding, thing you develop, that at the very least, textural configuration (thus not requiring any UI) is always possible. As such, UIs can develop or cease to develop, without affecting basic configuration, but rather ensuring that anything can be configured textually.

Merry Xmas to you all.