But one of the purposes of openHAB is to abstract away the specifics of each of the hundreds of supported technologies and APIs so that a light switch is a light switch whether it's controlling a Hue light bulb, a KNX wall switch, or a custom DIY relay that speaks MQTT.
The semantic model, when set up correctly, will allow openHAB to turn all lights off in the kitchen when asked, as the framework can understand the kitchen location and what items are lights in that location.
Once created, a model allows one to use [Semantics Actions]({{base}}/configuration/actions.html#semantics) in Rules to e.g. determine the Location of an Item or the related Equipment.
This will help one create, generalize, and simplify Rules based on patterns and purpose.
- A Property is an additional tag on a Point Item that indicates what sort of point it is. For example, a thermometer might be a Point of type Measurement with a Property of type Temperature.
In addition to these relationships, there are restrictions.
- A Location can only be the direct member of zero or one Location Group.
- An Equipment can only be the direct member of zero or one Location, or the direct member of zero or one Equipment. Put another way, an Equipment can only be the direct member of one Group that has a semantic tag.
- A Point can only be the direct member of zero or one Location, or the direct member of zero of one Equipment. Put another way, a Point can only be the direct member of one Group that has a Location or Equipment tag.
Because the model represents the physical, it makes no sense to deviate from these restrictions.
An Equipment or Point cannot be in more than one location at the same time.
A Point cannot be a part of more than one Equipment at the same time.
In this example, the Rollershutter in the Living Room is a member of the `AllRollershutters` Group which could be used to determine if any are OPEN and send commands to all the rollershutters in the house at once.
But this functional cross cutting Group is not an Equipment nor is it a Location and it violates the restrictions of the model.
A typical installation may only have 60%-80% of all the Items in the model.
More about creating Items and Groups outside of the model is below.
Equipment are often mapped to Things, but not always.
You can represent a single Equipment with several Things.
For instance, a computer might have points to switch it on (send a wake-on-lan packet), off (shell command), determine if it is online (network polling), and how much power it consumes (Z-Wave wall plug).
All of these multiple Things from different bindings can be combined to model a single piece of Equipment.
Add your first item, a Group representing the ground floor.
Give it a name, but choose carefully as you cannot change it afterward.
Choose a label, a category (it mostly defines the default icon), and then specialize the item by choosing a more accurate semantic class than "Location".
Now let's add the kitchen. Make sure to select Ground Floor again and choose Add Location to add the third item (name: `Kitchen`, category: kitchen, semantic class: Kitchen).
The "Plant Sensor" Equipment has now been created under the Kitchen location, and all the selected Points represent the selected Channels of the Thing.
Go back to the Model by choosing Model in the sidebar and verify that the Equipment added to the model from the thing page is effectively there as well as, its Points.
There may be times where a user needs to add existing Items to their model.
Perhaps they are migrating from an older version of OH, they did not follow the advice above to start with the model to begin with, or they are following a tutorial or example that doesn't include the model.
In this case all is not lost.
Existing Items can be added to the model.
Browse to the Item in the Items settings, click on Edit and choose an appropriate Semantic Class and Semantic Property.
Then add the Point as a member of the appropriate Equipment or Location Group.
If the Equipment Group doesn't exist yet, create a Group and use the appropriate Equipment semantic tag first and add the Equipment to the appropriate Location Group.
This is a table describing the Equipment, Point and Property classes needed to enable the display of status and measurement badges on the location cards.
As discussed above, many Items and Groups are expected to be outside of the semantic model.
Perhaps they are only supporting Items only used for Rules.
Maybe they are the raw Items that feed a proxy Item or summarizing Group.
If they are a Group, perhaps they are functionally based instead of physically based, e.g. `AllLights`.
As discussed above, existing Items can be added to the model.
The reverse is also true, an Item can be removed from the model simply by removing their semantic tags by setting them to "None".
Note, when removing a Point/Property pair of tags, remove the Property first or else the Property tag will remain on the Item.
## Creating Non-semantic Items
Note that a Group is a special type of Item.
It can only be created from the Items Settings Page (when not created from the model), but the process to create a Group is the same as any other Item.
### From the Model Page
Selecting an existing Item and remove the sematic tags by clicking on "Edit" and setting the semantic tags to "None"..
This is particularly useful if one has created an Equipment from a Thing but only some of the Items created are to be a part of the model.
### From the Things's Page
Select a Things and click on the "Channels" tab.
Click on the Channel from which the Item is to be created.
Click on "Add Link to Item..." and select "Create new Item".
Fill out the information about the Item to be created, omitting the semantic tags.
Finally click on "Create Link".
### From the Items Settings Page
Under "Administration" click on "Settings" and then on "Items".
All the Items defined in the system are listed.
The list of Items can be filtered by using the search box at the top of the list.
One can search by Item name, Item Label, or Item type (e.g. show all the Switch Items).
At the bottom of this page there is a blue "+" icon which when clicked allows the creation of an Item.
Clicking on this offers two options: "Add Items from textual definition" which allows one to import one or more Items based on the [textual configuration syntax]({{base}}/configuration/items.html), and "Add Item" which allows the creation of the UI by filling in a form.
Again, leave out the semantic tags and the Item will not become a part of the model.
## Group Membership
Once a Group is created, other Items can be added as members of the Group.
Note that this process also works for semantically tagged Groups.
Navigate to or search for the Group on the Items Settings page and select the Group.
In the middle of the page will be a field labeled "Direct Group Members".
Click on "Change" and then "Members".
This brings up a searchable list of your Items.
Find and add a check next to those that should be a member of this Group.
Remove the check for those that should not be a member of the Group.
Click "close" when done and then click "Apply" to change the Group's members.
# Items Best Practices
- Only include Items in the model that make sense. Not all Items can nor should they be in the model.
- Use meaningful and unique labels for Items. If all the Temperature Items are just labeled "Temperature" there will be no way to tell which one is which when using the search on the Items settings page or in the UI.
- Use manually created Groups that are outside the model to create functional capabilities such as a way to send a command to all the lights in the house with one tap or see the maximum temperature in the house.
- Groups have the option to apply an aggregation function. One can semantically tag these Groups using a Point/Property tag and put the Group into an Equipment or Location. This can be useful in cases where a number of Items are logically controllable as one device, such as three smart bulbs in one lamp.
