- Platform information:
- Hardware: Raspberry 4B
- openHAB version: 3.0.1
I believe I have a good understanding of the semantic model, however I am confused with the usage of the basic types while configuring items.
These ones seems to be totally out of the model scope and allowed definition to irrelevant semantic classes.
For instance it is possible to define as Basic Type “location” with a Semantic Class “Switch” and a Semantic Property of “Light”; strange isn’t it.
Focusing on the semantic model, the only relevant usage of the basic types that I see is “Group” giving access of Semantic classes such as Location, Equipment and Points.
Is it possible to give me a better explanation / recommendation about usage of “basic types”.
Thanks in advance
While starting with the semantic model I had a similar struggle. I believed, that the type if equipment a assigned to an item would somehow influence the way it is displayed or it behaves.
But as I understand it now, the model does not have any impact on these things. It is just a way of logical structuring the items, e.g. for creating the UI.
Where do you see “basic type”? Are you referring to “Members Base Type” on Group Items?
- Not all Items need to be a part of the model.
- Therefore not all Groups need to be a part of the model.
- Groups have other uses beyond just defining a location or equipment membership. For example:
- they a can be used to trigger a rule when any one of it’s members receive an event
- they can summarize and aggregate all the values of it’s members into one value (e.g. the max value of all it’s members)
- a command sent to a Group will be forwarded to all of it’s members
In order for 3 to work, you have to tell OH what type of Item the Group should be treated as. So a Group with a “Members Base Type” of Switch can be treated like a Switch Item. You can send it ON and OFF commands. You can test in a rule to see if the Group is ON or OFF.
You can further define the “Aggregation Function” which will tell OH how to summarize all the states of it’s members into one state. For example, “All ON then ON else OFF” means that if all the members of the Group are ON, the Group’s state will be ON.
None of this has anything to do with the model.
Unfortunately there are some words like “Location” and “Switch” which are both semantic model tags and Item Types. In this case the “Member’s Base Type” is an Item type, not a semantic tag. See Items | openHAB for the list of all Item types. You will see that list exactly corresponds with the list under “Members Base Type.”
tl;dr: “Member Base Type” has nothing to do with the semantic model.
No I am talking about “Basic Type” and “Numbers with Dimensions” see picture below
As you see even if it has nothing to do with the semantic model, semantic class and property can be added.
- I don’t understand the usage of it (including Numbers and Dimensions)
- When and how should I used it concurrently with the Semantic Model (or what is the impact of this).
Perhaps is this some kind of reminiscence of OH1 or OH2 for compatibility?
That type you marked is the basicmost property of an Item - the item type.
That’s the data type openHAB uses for this.
Dimensions are optional, see UoM (Units of Measurement) for their use.
Any item need not but may have a semantic class and property, and very much in a broad sense so.
An item of type “switch” with semantic settings like you show does not necessarily represent a physical light switch. It can but it can as well represent a GUI-only virtual switch that has a virtual function i.e. isn’t mapped to any physical device, location or function.
The nature of this broadness of uses is that you must not restrict semantic assignments for a specific item type because you cannot know upfront the item’s use. That’s why there intentionally are no restrictions so you can assign anything. Whether it makes sense is another question and to answer that is up to you, the user.
Your picture shows a misunderstanding of yours. Rich already answered that but let me restate what he was trying to tell: you are confusing the item type “location” with the semantic property that by chance has the same name.
Through the light of your explanation I have made some different items configurations, and the usage of the basic types is becoming now clear for me.
I’m glad you are understanding. Just to provide one more bit of explanation/summarization for other readers (if you were confused others will be too):
For all the old timers out there, the Type of the Item is the same old thing you’ve always defined when creating an Item. In a .items file, it’s the first word of the entry for an Item. It defines what sort of state and what sort of commands the Item can receive.
Unfortunately there are a couple of Item Types whose name has been reused in the model, namely Location and Switch. This was unfortunate and couldn’t be helped as the model is based on a third party ontology (Bricks for the curious). But even though they appear in both parts of OH, they have nothing to do with each other. A Location type Item indicates that the Item stores a latitude, longitude coordinate. A Location tag in the model is a way to indicate that a specific Group type Item represents a “location” in the model (building, floor, room, etc.).
The model is optional (though highly recommended); types are not. Not all Items are expected to be a part of the model also. You will have (or at least should have) a number of Items and Group that you need for various reasons (e.g. to drive or be used in rules only). In my personal configuration only about 60% of my Items appear in the model. The rest are not semantically tagged.
The model is constructed through Groups with tags and Items with tags. A Group with a Location tag (semantic tag, not type) represents a location in the model. A Group or Item with an Equipment tag represents a piece of equipment. That Group Item is made a member of a Location Group to “place” the Equipment into that Location. Typically a non-Group type Item is a Point/Property. These Items represent the sensors and actuators of a piece of Equipment and are made a part of the Equipment by making them a member of the group. The Point tag tells the model what sort of sensor or actuator it represents (Switch, Measurement, Alarm, etc.) and the second tells the model what it’s measuring or controlling (Humidity, Light, etc.). So all the model is is tags and a structured set of Group memberships. Nothing more.
Usually, when an Item is linked to a Thing’s Channel, the Channel dictates what type of Item is required. When you create equipment from Thing on the Model page, the Item’s Type will be decided by the Thing Channel.