Thing, Channel, Item semantics is difficult to understand

[timo12357 (Timo)]

I have been on the OpenHAB journey for a couple of months now. I have built a heat pump control system based upon @masipila’s code and also added some light bulbs I can control and room temperature sensors that I can read. So far so good.

However, even after quite some considerable reading of this forum and the documentation I find the semantics used utterly confusing and difficult to understand. For some reason I am unable to grasp the concept of things, channels, and items and create a clear architectural picture in my mind of how they relate to each other. Hence, I find myself spending a lot of time trying to configure my new devices with trial and error, even after RTFM, which is very time consuming and not very inspiring.

As far as I understand a significant part of OpenHAB development and innovation happens in Germany? Could my semantic confusion be related the differences between German and English languages, perhaps? My German is not good enough to understand the subtle differences in “Dinge” and “things” or “Artikeln” and “items”. On top of this neither language is my first language.

Therefore I have started suspecting that the key to understand the semantics might in fact be in understanding the German language semantics of items, things and channels? It would be extremely interesting if some native German speaker could explain the German semantics of these words. I suspect that could help understanding what this all is about?

[masipila (Markus Sipilä)]

I’m not able to explain you the German semantics but I had the exact same struggle that you’re going through.

The description we have in the official docs are quite abstract description of abstract concepts. So let’s start with a couple of concrete examples.

Lets’ say I have a Nibe heatpump. That is a real-world Thing.

Let’s then say I want to build an openHAB user interface that has a switch that can be used to toggle the heat pump’s compressor block on / off. This switch is an Item.

The Item is from our software world whereas the Thing is from a physical real world.

The software switch (Item) obviously does nothing unless it is somehow connected to physical Thing. My openHAB instance cannot control your heatpump unless it is somehow connected to your pump. To bridge the gap between the physical world and the software world we need a Channel.

There can be many different ways you connect to your real world Thing. The Channel uses a Binding that provides the capability to connect the software world (Item) to the physical world (Thing). In my case it’s the GPIO Binding.

Hope this helps.

[masipila (Markus Sipilä)]

Continuing on the example. I also have a Mitsubishi air-to-air heatpump. It has a wifi capability and it can be connected to Mitsubishi MelCloud service .

So here my Mitsubishi hatpump is the Thing. I have several Items for it such as

• power on/off
• fan speed
• mode (heat, cool, auto, etc)
• set temperature
• current temperature

All these software Items must be again connected to the real world Thing. There is a Channel for each Item and the Channels use the Melcloud Binding, which let my openHAB log in to the Melcloud service on my behalf to control the device.

[JustinG]

Maybe this will help a little:

openHAB Glossary

Perhaps it is just my years of experience teaching a vocabulary heavy subject, but it seems to me that many of the beginner questions that show up on the forums (and even some of the more advanced ones) result from struggles with all the terminology. Many beginning users stumble when attempting to use docs and even users who have read the help docs sometimes come away with only partial understanding unless they are already fully steeped in the language of openHAB. With the goal of alleviating …

[rlkoshak (Rich Koshak)]

I don’t think it has to do with semantics in German nor in English. It is just that OH choose some very generic terms to redefine and give a specific OH meaning. Just go ahead and pretend they don’t even represent a real word because there really is no connection between the English meaning for “thing”, “channel” and “item” and the OH terms Thing, Channel, and Item (note I and many others always capitalize the OH term to make it clear which we mean.

I’ll try to remember to come back here and drop in a “real” drawing but for now perhaps a quick and dirty asci art diagram can help.

Physical                                Channel 1 <--> Link <--> Switch Item
Light    <--> Binding  <--> Thing <-->  Channel 2 <--> Link <--> Dimmer Item
Bulb                                    Channel 3 <--> Link <--> Color Item

The physical device is a light bulb. It has a zero or more things you can ask it to do (actuators) and things it will tell you (sensors).

The Binding is software that knows how to interact with the physical device’s API in order to command the actuators and receive the sensor readings. The binding represents each physical device as a Thing in openHAB.

The Thing is a normalized representation of the physical device in openHAB itself. It may have properties you can set or other stuff in it that is specific to the technology being connected to.

Each actuator and sensor that a Thing supports is represented by a Channel. Some Channels can have complicated configuration options (e.g. MQTT) which most of the time they just show what the data type of the Channel is and what it represents.

Channels are connected to Items through Links. The only reason why mentioning Links is worth mentioning at this level is because one can apply Profiles on Links to transform the data coming from the Channel before it gets to the Item and vice versa.

Items are the base concept in openHAB. Almost everything else in OH operates with or on Items. Items are the basic abstraction of actuators and sensors. There is a limited set of types of Items and, for example, a Switch behaves like a Switch no matter what end device it might be connected to or perhaps not connected to anything at all.

And I’ll just mention here that the Semantic Model is an optional way to tag and organize your Items.

Each of these is a layer of abstraction that go from a very specific interface defined by a hardware device’s vendor and a normalized representation that everything in OH knows how to work with. It is these layers of abstraction that make OH able to bridge 350+ different technologies in a way that they can all work together without forcing you, the OH admin, from knowing and understanding the intricacies of each and every technology you want to use.

I imagine I’ve mostly just restated the definitions in @JustinG’s glossary above but can’t stand posting a picture without the text to go with it.

If you are still confused, it might help to ask us some specific questions which might help us clear up specifics.