OpenHAB 3 Term Differences?

[TechFocus (Mugen)]

I like the Semantic Modeling concept of the openHAB (a lot), but as a new user, I am encountering a bit confusion myself.

For Items,

1. Type
2. Category
3. Semantic Class

For example, I have Lutron light switch. So I set followings:

Type: Switch
Category: Light
Semantic Class: WallSwitch

On the Main UI, I see under Equipment, this shows up as WallSwitch. This makes sense as Main UI is using Semantic class.

It makes sense to me that Items can be an end point i.e. Point vs. Group (such as location, equipment). However, why can’t that be replace type & category? I can potentially see a use of something outside of Semantic class as we can only choose one Semantic class currently for a given Item, but I thought Non-Semantic Tags is good for that?

When should I use them over/in addition to Semantic Class?

For Things,

1. Location

I see Location but this is separate from Item Group Location. This makes some design sense as Thing is above the Items. But I don’t see setting Location on THING have no effect on items created from it. I thought it would make sense to put the items created from the Thing to go under the Location Group.

For Items & Things,

Identifier on Thing. Name on Items.

Both appears to be non-editable after the first setup, which I assume used behind the scene for coding. In which case, why do we have separate names? Why can’t both be Identifier and even for Items it gets filled with somewhat cryptic code by default so as a user we do not have to worry too much about it unless for very specific reason.

Am I missing some specific difference between the two?

Thank you very much,

[rossko57]

The original use of ‘category’ was interchangeable with ‘icon’, i.e. show this Switch type Item with a lightbulb icon; show that Switch type Item with a fan icon.

[TechFocus (Mugen)]

@rossko57

The original use of ‘category’ was interchangeable with ‘icon’

Thank you. I see. Being able to assign own icon sounds like a good feature. It would perhaps be more intuitive, it actually said icons. Then maybe default pick based on Semantic Class if user does not select anything?

[rlkoshak (Rich Koshak)]

First a clarification. For Point Items you have the option to supply a second Properties tag. And most of the time you should supply a Property tag on these Items.

For example, a smoke alarm might be tagged with “Alarm” and “Smoke”. A leak detector might be tagged with “Alarm” and “Water”. A light switch Point Item might be tagged with “Switch” and “Light” and a light sensor might be tagged with “Measurement” and “Light”.

It’s only Equipment and Locations that are limited to one tag.

While not required, based on my experience, one should only use Group Items for Equipment. If, for example, you have a light switch that just has one Switch Item associated with it, you could just apply the Equipment WallSwitch tag to that Switch Item. However, when you get a second wall switch that maybe reports the amount of power being used then that same Switch Item will be tagged with Switch,Light and be a member of a WallSwitch Equipment Group. instead and it will be rendered completely differently in the overview pages as a result. In fact, the WallSwitch tagged Switch won’t even show up under the Lights category because there is nothing telling OH that it’s controlling a light.

@TechFocus

When should I use them over/in addition to Semantic Class?

In short, you should use 1 and 2 all the time and 3 only when using the model.

The Item’s type is always required and it determines what sort of states and commands the Item can receive. Usually the binding will dictate the Item type.

The category is optional and as rossko57 said, determines the icon that is used next to the Item in MainUI’s Items settings page, is searchable, and is used as the default icon used in sitemaps for that Item.

The Semantic Class is an optional tag on an Item to provide additional information that is used by MainUI’s Overview page and by HABot. The semantic model is both new and optional. Given that, I don’t think it makes sense to use the semantic tags to select the category.

@TechFocus

I see Location but this is separate from Item Group Location. This makes some design sense as Thing is above the Items. But I don’t see setting Location on THING have no effect on items created from it. I thought it would make sense to put the items created from the Thing to go under the Location Group.

This is a hold over from OH 2 and is not used in OH 3. It’s retained for backwards compatibility for now until and unless a use for it is determined or the devs decide to remove it. Things have nothing to do with the semantic model.

@TechFocus

Identifier on Thing. Name on Items.

The Thing ID and Item’s name are the unique identifiers for those entities. There must be something unique so that one can reference them in the UI, in rules, and persistence. Once created, these ID cannot be changed short of deleting the Thing or Item and recreating them with a new ID/Name.

However, there are many times where you as a human need to use the Thing ID and Item Name. For example, if you want to send a Telegram message in response to an event you need the Thing ID of the Telegram Thing to send the message. If you want to turn on a light when a motion sensor triggers, you need the Name of the Item to trigger the rule and to send the command to. Consequently, being able to define your own Names for Items means you don’t have to do some look up for some random string of characters every time you need to read/modify/edit a rule. The name you gave it makes it clear which Item/Thing you are working with.

In short, you as a user have to worry about it so make sure to choose meaningful names and Thing IDs where appropriate.

[TechFocus (Mugen)]

Thank you very much for very detailed explanation/clarification. I will have to read a few times, here but this seems to clarify point of confusions I had. Again, thank you.