I had some logical groups like “Group of all MQTT Lamps at Home” which breaks with the convention of a physical representation and messed up the model view. So I overworked my model based on the quoted and got some questionmarks.
I found out that some elements in the model have a Group-Location and other a Location-Location classification.
The one with Group-Location has an option to “Add X to model”, the one with Location-Location does not have it.
Furthermore it is not possible to link sub-elements (Equipments) to the Location-Location elements.
I marked the mentioned areas in red in the screenshots below:
The missing possibility to link sub-elements is now an issue for me because I want to re-structure my MQTT power sockets (marked in green) in a way like this:
Group with all MQTT Sockets in the living room
Group with MQTT Socket controlling music
MQTT Socket 1
MQTT Socket 2
Group with MQTT Sockets controlling electronic devices
MQTT Socket 3
MQTT Socket 4
Group with MQTT Sockets controlling lamps
MQTT Socket 5
MQTT Socket 6
I will create such a group in each room.
My issue now is that I cannot create a new group below “Wohnzimmer” because it does not show up as an option for a parent element. I do not understand my misconception here; why the “Wohnzimmer”-Location is not behaving as “Wohnung”; and why I cannot define that second level as Group-Location. Or is it not the idea of that model to represent the physical Hierarchy?
The follow up question is: Am I allowed to add a Group(Equipment) under another Group(Equipment)?
Your screenshot shows that Wohnzimmer is a Location type item. All semantic locations must be Group items.
Note that under the item label Garage, the item type and semantic tags are listed. For my garage location, the type is Group and it’s only designated as a location because it has the location semantic tag. OH does have Location type items, but this is just an unfortunate overlap of terminology. Location type items are for only holding Lat\Long data; they are not “locations” in the semantic sense.
So, in your case, because Wohnzimmer is not a Group type item then there is no possibility to nest other items inside of it.
On this point, I would recommend that you think through a little bit what the use case is for your re-structuring. I’m not saying you shouldn’t do it, but it is an important idea to understand that not all items and not even all functional structure in OH needs to be part of the semantic model. The model is really intended just to represent the actual physical layout of the devices that OH interacts with so that parts of the system (i.e., the MainUI model cards, and HabBot) can utilize the relationship between devices in a manner similar to how human users understand it. When it comes to some greater system grouping such as what you are presenting here, it is possible that there’s no reason at all to worry about adding it to the model. Just food for thought.
ooooookay, that explains the issue - i picket the wrong element!
I think I know what you mean by this - but the semantic model is such a great structured overview to dig through the items and see their relations. The item-list UI section contains 110 items for me and I cannot see the parent-child relations between them.
If there would be an addon showing a non-semantic tree (similar to the Model) I would really love it.This is why I am (mis)using the model in that way (and when reading through the forum here some other newbies seem to do it in the same way). Is there another way to get the items in a well structured visual hierarchical representation?
On the bottom of the model page, there is a checkbox option to show non-semantic items. If you click this then you get a similar tree structure for non-semantic groups and items:
Yes true and I already use it but it overlaps with another “issue” that an equipment or item can only have one semantic parent - this leads to a displaying “issue” that some non semantic groups do not show all child-elements in the model.
I’ll just add that you should think of the users of your home automation as the audience for your semantic model. Do those who live with you care about it or need to interact with it? If not it probably doesn’t belong in the semantic model.
Right now the primary use of the Semantic Model is to generate the Overview tabs in MainUI. There is also some utility in rules. Be careful you don’t complicate those by cluttering your semantic model with relationships that don’t belong there.
It really depends on why and what you are using this representation to do. Is it just a “feel good” or “look at the pretty tree structure” or is there an actual problem it helps you solve. If the latter, there is almost certainly plenty of alternative approaches that could be suggested. For example, if I’m going to work on my humidifiers, I’ll bring up the Developer Sidebar, put “Hum” in the search box (because everything related either has “Hum” in the name or is tagged with “humidifier”, and pin all the Items, Things, and Rules. Now I have everything a single click away.