I’m getting the following warning in my openHAB logs:
Item 'Sensor_GF_Kitchen_ShellyTwoSignalStrength' (Point) has invalid semantic structure: It belongs to multiple equipments [Group_House_Sensors, Group_GF_Kitchen_Sensors]. A Point can only belong to at most one Equipment.
Group Group_House_Sensors "Gesamte Wohnung Sensoren" (Group_House) ["Sensor"]
Group Group_GF_Kitchen_Sensors "Kueche Sensoren" <window> (Group_GF_Kitchen) ["Sensor"]
From my understanding, both groups being tagged as ["Sensor"] might be treated as Equipment, which conflicts with the semantic model rule that a Point can belong to only one Equipment. Could someone confirm this and suggest the best practice here?
It seems to me that you should remove the sensor tag from both groups. Neither is a proper equipment. It seems that you meant to use those groups as groups of (multiple) equipment, thus they themselves aren’t equipment.
The semantic model is hierarchy of the physical layout of your home automation. You can’t have a physical device in more than one location at the same time. You can’t have a sensor or actuator that is a part of more than one location at the same time. It’s physically impossible, so the semantic model doesn’t support it.
You’d have the following hierarchy assuming you have one physical device that is providing all the sensors:
House (Location)
|_Kitchen (Location)
|_Kitchen_Sensors (Equipment)
|_Kitchen_Temperature (Point)
|_...
In the semantic model, you don’t need a House_Sensors because it’s already known that Kitchen_Temperature is in the House because it’s in the Kitchen which is in the house. We know the device is a sensor because Kitchen_Sensors is tagged as such.
If for some reason you need a functional Group of all the sensors in your house (e.g. to trigger a rule) you can still do that. But that Group needs to exist outside the semantic model (i.e. no semantic tag). So @jimtng is exactly right. Group_House_Sensors should not have a semantic tag and, unless Group_GF_Kitchen_Sensors represents a single physical device, this Group should not have a semantic tag either. But if Group_GF_Kitchen_Sensors does represent a physical device, it’s poorly named.
Correct. For example, if you have a smoke alarm, thermometer, and water leak sensor in the kitchen, each would be represented by a separate Equipment Group. But again, you can still have the Kitchen_Sensors Group, just remove the semantic tag.
That’s the intent. However, you have some flexibility here. If these three devices will only ever be used by OH and the users of your home as if they were a single device then certainly you can model them as if they were a single equipment.
You can also model them as an equipment of equipments.
Generally a Thing is represented as a single Equipment. There are some cases where that won’t be the case but most of the time one Thing will become one Equipment in the semantic model.
The semantic model only exists in Items. There is nothing in a .things file relevant to the semantic model (except in cases where you have fulkl control over the Things and Channels like MQTT and HTTP).
And I still say that unless you have a really compelling need for the semantic model, it’s hardly worth the effort if you are using .items files. When you are using the UI though, you can create the Equipment and all the Point Items for a Given thing in one go using “Add equipment to model” from the Thing’s page in MainUI. With changes comming in OH 5, the binding authors will even have recommended semantic tags to use.
Also note that this warning is just that - a warning. Depending on how you’re actually utilizing the semantic model, this may or may not be a problem. I personally have lots of things that violate this, like so:
Group eAirQualitySensor ["Sensor"]
Group eMiniSplit ["HVAC"]
Number:Temperature MyRoom_AmbTemp (eAirQualitySensor, eMiniSplit) ["Measurement", "Temperature"]
In reality, the ambient temperature is provided by my air quality sensor, because the Mini-Split only has a set point, and doesn’t expose a measurement of the current air temperature. But I still want to expose that as the temperature when exposing the mini split as a thermostat to say HomeKit. In reality, if I ask for the points of either eAirQualitySensor or eMiniSplit, they will both give me MyRoom_AmbTemp just fine. But if I ask for the equipment that MyRoom_AmbTemp belongs to (keeping in mind the semantic model is quite clear that a point is expected to only belong to one equipment), I don’t know which equipment it will give back (in practice it will be eAirQualitySensor, but that’s just a consequence of how group names and semantic actions are implemented, and not to be relied upon). It would get even “more” undefined if you were to ask which location the temperature item is in, since the equipments might be in different locations. But if you don’t run into any rules or UI constructs that need to reliably go from point to equipment or location for this item, and you have a good reason for a point to be in multiple equipments, again, it’s just a warning, and can be ignored. For me personally, if I ran into issues, I could resolve it by using a non-semantic-equipment group to define the HomeKit accessory. But it’s quite convenient to use the same group for both-- for now.
Right now I try to understand the semantic model and especially for what it is good…so I need to expose it but why do I need it that’s still unclear for me…
one way you can organize your Items hierarchically
it’s the only way there is enough information for HABot to work
it is the only way to populate the Overview Locations, Equipment, and Properties tabs of MainUI (these tabs are automatically built based on the semantic model)
there are some rule Actions which can be used to interrogate where an Item fits in the hierarchy (e.g. items.SomeItem.semantics.location will return the Location Group Item SomeItem belongs to in JS).
For a concrete example of the last point, I use these actions to find and use the status Item for an Equipment when the sensors for that Equipment stop reporting new values.
I use the name of the Item to figure out which one is the status Item but I could just as easily use the semantic tags. alertItem and isAlerting comes from Threshold Alert. This rule gets called from Threshold Alert when a sensor doesn’t report for a certain amount of time. I get the parent equipment for that sensor, find the status Item for that equipment and set it to ON or OFF based on the value if isAlerting. Because everything is grouped by equipment because they are in the semantic model, I can easily get at all the other Items that are also a part of this same equipment with just two lines of code. I don’t even need to do any tricks like making sure all the Items are named with the same pattern and using string manipulation to find the related Items.
If none of the points above is relevant to you, you don’t need the semantic model.
To me this is a pretty helpful structure as the item (in this case a light) belongs to the Wohnzimmer (living room) and it is also part of the Indirect Lights, which allows me to send ON/OFF to these groups separately. So, would be the solution to remove “Location” (I tried “equipment” first but it reveals the same problem) from the indirect lights?
@Mherwege AFAIK as you implemented it: I am aware that my indirect lights are not a physical location per se (you could imagine them to be a sub group of all lights of the living room, so it is indeed somewhat a physical location but I do not want to model it that way).
I feel that this leads to a broken window effect because it creates more than 20 health entries on my system which will make me overlook the real warnings. Therefore, I wonder if this warning is actually helping us or rather confusing? Maybe filtering types of health checks could be a solution but makes it even more complex…WDYT?
