OH3: Meaning of Locations and Groups

That’s exactly it. Thanks!

Now say you have heatings in all rooms as part of the room groups. Now you want to put the set points of all heatings in the house also in a common group to adjust them at once. How would that work in parallel to the rooms topology?

Ok then i will give some more information on how i have configured the model and semantic tags for them.

About the heating:
Sorry i have to pass here. My flat doesn’t give me the ability for a proper heating automation so i have left this part out of my own environment completely for now.
I could tell you something theoretically but i would like to avoid that since i have no own experiences here.

Ceiling Light

I will explain it “Top-Down” as this would be the solution how you would have to configure it in the Model.
I will also work with the original german terms, because that will fit to any screenshot.

First i have added one Equipment for the complete light Wohnzimmer Deckenleuchte standalone.

Ends in:

If you click on the item gCeleingLIght you will come to the item view where you can edit the item itself and its behavior.

I have clicked on edit and changed the *Group Settings area.

Then i went back to the Model page and did a Create Equipment from Thing for Wohnzimmer Fernsehbeleuchtung where i have choosen my light but only added the first 2 channels.

Again i will go the equipment group item and configure the Group Settings like done above for the first Equipment.

After this i will do the same

  • Create Equipment from Thing
  • Choose channel 3 and 4 this time
  • Save and add Group settings afterwards

again for Wohnzimmer Rückbeleuchtung.

Then i will end up with 3 lightbulds configured in 3 goups which will reflect their current states on ther behavior.

I am also able to switch all bulbs completely with the Wohnzimmer Deckenleuchte item or half of the lamp indipendent for Wohnzimmer Fernsehbeleuchtung or Wohnzimmer Rückbeleuchtung.

2 Likes

Awesome, thanks. Maybe that could support the official docs that @rlkoshak is developing with so much effort.

I should add that composed equipment such as color or dimmer lights still remain a bit unclear to me: The group functions e.g. of a dimmer only allow things like average, max or min, but I would like to have something like a “master dimmer” in the equipment group that rules them all :wink:
Same holds for color lights.

Is there anyone having a design template how to realize this in an elegant way (aside from writing rules)?

You are of course invited to contribute something yourself, if you find the information useful. :slight_smile:
I think @rlkoshak would appreciate some help too.

3 Likes

@Tobi77 : I realize I am a bit late to the party so to speak, but have you read this:

I think it does a good job of explaining the way locations, equipment, points, etc. are handled in terms of groups, items, tags, etc.

Hey @KjetilA thanks for joining the party. :slight_smile:
As far as i know @rlkoshak took this thread as blueprint for the docs article he contributed to the tutorial over there.

So i would be interested if there are bigger changes we have to transfer to the docs additionally.

To be honest, I have a hard time understanding what thread/wiki/doc that is the “correct” one and being actively worked on… There seems to be so many things going on, :slight_smile:

The wiki articles are meant as a strirting point where everyone can help iomproving those.
The long term goal is to move these wikis completely to the documentation so that they are available for everyone on our website. :slight_smile:

Right, thanks for clearing that up. As I understand it the wiki article in question (the one I linked to) has already been moved to documentation. I presume this means that suggestions should then no longer be made on the wiki article, but rather on the documentation in github. Correct?

1 Like

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 :wink:

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. :slight_smile:

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.