Yep if you find some inconsistences or improvements it would be pretty helpful to track them on github.
I think too many people are putting to much emphasis on the wrong things when it comes to the model and I don’t know how to deal with that yet.
There is nothing special about a Location or Equipment Group except that tag is applied to it that tells OH a little more about it’s meaning (e.g. “this group represents an office which is a location”). Beyond that it’s just a Group like any other.
A Group can itself be a member of another Group.
Not all Items and Groups need to be a part of the model. There are many cases where an Item or Group would not be a part on the model.
The model is there for your benefit. Or into it what makes sense for you. Exclude what doesn’t make sense. You can make it as simple or complex as you want to.
Define a Group:Dimmer and put all your Dimmers into it. Choose an appropriate aggregation function or not This Group she’s not need to be part of the model. But if you do tag it, use a Point tag and put it in the parent Group that represents the Home.
4 Likes
Great, thanks. I basically followed this approach. But when I put all dimmers in a common group, there ist no master: The aggregation function determines the group behavior. What I was looking for is a separate master dimmer that does not aggregate, but overwrite.
Then create a separate item and a rule to send changes to that new item as commands to all the other rollershutters.
I think too many people are putting to much emphasis on the wrong things when it comes to the model and I don’t know how to deal with that yet.
I fear, I’m one of them 
There is nothing special about a Location or Equipment Group except that tag is applied to it that tells OH a little more about it’s meaning (e.g. “this group represents an office which is a location”). Beyond that it’s just a Group like any other.
I spend a lot of effort to re-model all my items into group-groups, location, equipments and points. It’s not only the model itself. The model will be reused for the UI afterwards. Which card (e.g. which location) is showed and how the points are accessible are highly dependent from the model. For example, it’s a difference (obviously) if I have single-level or multi-level equipments in a location.
I guess, if you care less about the generated UI (Loc / Equip. / Prop.) and use more the layouts, widgets and floor plans, the model is less important.
Does anybody know, why the model allows only one equipment per location? In general, it makes sense. But I have a case where it makes (probably) sense. I have a pump which circulates the warm water. Equipment semantic class “Boiler”. The Boiler (warm water) is assigned to Kitchen AND Bathroom. But the model tree shows only in Kitchen the equimpent. Not in bath. In addition only the kitchen card is displayed. No Bath. Is this the correct behavior? I found a workaround but would like to understand. 
Cheers thefechner
It’s a limitation of the model and it’s one that is somewhat reasonable. The boiler doesn’t actually exists in both of those rooms. In fact, the actual boiler probably exists in some utility room somewhere and you have radiators in those rooms. Anywaym you can still model that in multiple different ways.
For example, put the equipment only into the room where the controller resides. Another alternative is to represent the boiler using separate Items for the bath and the kitchen. You could also create a parent location that contains the two rooms and put the boiler in that parent location instead of in the rooms themselves.
1 Like
Hi Rich
I’m wondering how to solve the next :
I’m lacking the option to have a “zone” as a location. A point can be part of multiple zones:
The floor-standing light is halfway into the “seating area” and halfway into the “dining area”. As such it is part of both groups. Depending on how you aggregate the info of the group you get different behaviour when switching on/off groups.
Different example:
Stairs: the stairs are part of both the first- and second-floor. How do we best include them into the model? Choose a floor? Make it part of the “house” at the same level as first/second floor?
Or is the best way to put the desired behaviour into rules?
Your choices are:
- pick one location and not put it in both
- create a duplicate item to represent it twice, once in each location
- not include it in the model at all
So if I have groups already defined in my item file (eg. gFirstFloor). it won’t let me create a location in the semantic model with gFirstFloor as the name…I get this… so do I have to remove all my groups in my items and use the semantic model? is there a way of importing?
Thanks
Yes.
- Go to Items
- Click “+” in the bottom right
- Click " Import from Textual Configuration" or similar wording
Make sure your actual Items file has been removed before you do this, otherwise the two will clash.
Does this mean I can’t have textual files if I go down the route of semantic model?
No, it doesn’t mean that.
Just don’t use both UI and configuration files for your Semantic Model setup: unpredictable things happen…
1 Like
Thanks very much
I have come across the casuistry that if within a location, I have a team_1 which in turn has another team_1.1 inside, in the locations tab I can only see the points that team_1 has and there is no trace of team_1.1 .
Is it possible to see a team within another team in the locations tab?
Thank you very much, great community.