I’ve got a quite old configuration, text base items files, and trying to fix issues that come from “Health Checks”.
Semantic Model Configuration Conflicts give me a few issues, and I’m little disappoint by one of them:
The text message is :
Belong to location [gDesk] and equipment [gRollerShutter]
Item : RollerShutterDesk (Equipment)
An equipment can only belong to one location, or to another equipment, but not both.
The message is clear, but why we can belong to a location and an equipment at the same time.
The idea is to have a group for location (Desk), and a group for equipment type (gRollerShutter).
My current definitions are:
Group
gRollerShutter
“Volet”
(gTechnical)
[ “Equipment” ]
Group
gDesk
"Bureau"
<bureau>
(gHaut,gRoom)
[ "Desk", "Office" ]
{
synonyms="Bureau"
}
It someone can point me out what I’m make wrongs there, it will be great.
Any Item can belong to one semantic group only, this is by design. It can be member of many non semantic groups. If you remove all semantic tags from one of your groups, your health issue will be solved.
Ok thanks to point this to me.
My main error is that I’ve got technical group to group type of same sort : RollerShutter, Door, Window, … But I’ve tagged this technical group with “Equipment” tags, so most of the time redundant / in conflict with location.
I’ve start to address all my model, but will take some time to tidy everything
I still have one more question.
But if I understand, this is not possible with current semantic group logic.
Let take an exemple: a Window.
The window is member of a location : a bedroom.
At the same time, the window as an alarm contact.
So what I would like is the contact be a member of a Window group, itself member of a Alarme group. But to display them in the semantic model, I would need to tag this group as “Equipment” ?
And do it will break the rule we talked before ?
Is this right ? How to code such scheme ?
Perhaps would we need an EquipmentCategory above the Equipment tag when we want to do such grouping ?
All my technical groups (batteries, windows, doors, etc…) are non semantic and include and/or math, to give me counters for empty batteries or open windows/doors….
Your Alarm group should not have sn equipment tag, as an Alarm is a function, not a device.
But, an open Window is not an alarm, it is a state….
Just to elaborate a bit on why the semantic model is the way it is.
The semantic model represents the physical layout of your home automation from the users of your home automation’s perspective. It is impossible for the same device to be in more than one location at a time. So the semantic model doesn’t let you do that. A Point can only belong to one Equipment or one Location (there is one hack that creates an exception to this rule that I’m going to ignore for now). A Point or Equipment can only be in one Location. A Location can only be in one Location (e.g. a Room on a Floor).
Functional Groups (e.g. all windows, all alarms, etc.) are still allowed though and they can be quite useful. But they do not belong in the semantic model because these Groups span equipment and locations.
My rule-of-thumb is roughly 60%-80% of your Items even belong in the semantic model. The rest are functional Groups, or Items that are relevant to OH’s being able to function but not something you’d expose to an end user of your home automation. It certainly should not be a goal to squeeze all your Items into the model.
Yes, I totally agree.
I do this tidy, because today I’ve got something like about only 20% of my item in the semantic models ! After a day of work, I’ve got something that is now cleaner then before
The only questioning I have with current semantic models is that there are equipment that I would like to expose in the model in some sort in 2 places (not 2 locations). One will be the real physical location of the items : a room. And the other a “Equipment type” group.
I think (but perhaps I’m wrong of course), that it would not introduce ambiguity in the model if correctly done. The idea will be two have another node above Equipment, something like an EquipmentGroup, or EquipmentType.
As said in my previous post, It can be useful two have some sort of logical grouping in the semantic model that are not by location, but by Equipment type for thing like Alarm, Power Meters, etc.
One other example will be:
Individual Power Meters can be locate in rooms (the one like outlet that implements power metering).
At the same time, could be great to have them group under the semantic model under a Power Meter Group.
Of course, you can do it using vertical group, and it would be sufficient in most case.
But I can see it as a facility two have a quick view in semantic model by device type, and perhaps implements new functionality base on this.
As always, this is not a request to have it tomorrow, it’s just an questioning / reflexion for future possible evolution if others thinks it can make sense.
That’s what the Equipment and Properties tabs of the Overview page are for. You already can see everything grouped by Equipment type (I’ve not updated the background images in these cards yet so some of them are grayed out).
The semantic model is primarily about your end users, not you as the administrator. The semantic model controls how the cards in MainUI’s Overview tab are organized. It’s not there to make a tree in the Model view to help you administer your home automation.
And, if you have a need to group things together for you home automation, you can use the oh-repeater to create a widget to show on the first page of the overview page for your users that use the semantic tags to identify the Items to show.
In the screenshot above, the lights, battery, and services widgets are built based on the tagging on the Items and the states of the Items.
To help organize your Items for you as the administrator, these types of functional Groups are very useful. But they will not be useful to you in the Model view. But you can still visualize and navigate them on Settings → Items and in the developer sidebar, and you can still use them in their own widgets (e.g. you can use group membership as the source for an oh-repeater card).
But you cannot use these in the semantic model. In order to use the semantic model for its primary purpose (populating the cards in the Overview tabs, HABot), the semantic model is limited in flexibility by design and by constraint.
Note, if you are not using the overview tabs of MainUI nor HABot, unless you have a strong reason to use the semantic model from your rules there really is no benefit to you for using the semantic model.
