Not really. Yes, you’re right that groups in general have this function. But the semantically tagged groups within the model don’t have quite the right structure.
When you send a command to a group that command gets propagated to all the groups direct child members. The model, on the other hand, usually has at least one layer between the location (group) and the point (item you want to command) and that the equipment (also a group). But there are lots of different equipment with points in a room and even though you may want to turn off all the lights in that room you don’t want to turn off the TV so having the room send OFF to all points would be the wrong idea.
The easy solution here is that you can create another group (e.g., gLivingRoomLights) and add all your light items to that group in addition to whatever semantic equipment group they already belong to. This group doesn’t have to be part of the model at all. Now using commands on that group will work as you expect.
The obvious question then is what is the point of the semantic model at all. There are quite a few posts going into this in more detail so I encourage to search around if your interested in how other people utilize this, but really the model is not a required feature of OH3 at all. You can function just fine without it, but it does add some extra functionality (for example, the locations, equipment, and property tabs on the overview page) which means that most users prefer to put in the little extra work to set it up.
For one reason or another I built my semantic model so that I have rooms (gRoom) and under them equipment (gRoomLights). All lights are then placed under the Lights group. This allows me to do exactly what you are trying to do.
I am Openhab beginner and recently created my first configuration. I used the UI to create the things and floor location group. Then I added the room location and lights item using the nice script shared recently by @ysc on another thread here. Parent group were defined in each item sothat item are now visible in location group.
What I don’t understand is why the location hierarchy area/floors/rooms is not translated automatically in the location tab of the home page. When I look to the YouTube video , it seems to be automatic… what did I miss?
My light are managed by a domintell home system, the lights are managed by 3 modules controlling 8 lights plus some dimmers plus some roller shutter. So for me the idea get equipment from thing did not make sense. But do you mean I should create virtual equipment like a group of light for the same room? This is easy to do but make sense only for room with more than one light point…
is the equipment level necessary for Openhab to group all the room of the same floor together in the location tab of the homepage?
Yes, that’s exactly what the semantic model expects. In 99% of cases, for the model-based UI sections to work each “point” (interaction item) needs to be inside an “equipment”.
Even if there’s only one point, that point still needs an equipment parent and this can seem a little redundant, but make sense if you’re are actually using the model to its fullest because the equipment group adds an important layer of information not available in just a point item. For example, if you have a temperature point, without putting that in an equipment the model doesn’t know if that’s a sensor value or an HVAC setting or even an oven setting.
Thanks for the clarification.
I will try to add equipment layer that make sense …
You are speaking about temperature… this will be precisely my next project.
I plan to integrate my home heating system in Openhab to manage at least the temperatures measurement and setpoint for each room.
These value are managed in a separate system running codesys with wired temperature sensor and modbus slaves.
So I plan add in my model virtual thermostat equipment that will manage the selection and change of the temperature setpoint and monitoring of the temperature but the heating/ cooling order will stay on the lower level in the codesys program.
So these virtual thermostat could be some equipment layer for room temperature management.
Is this really true? As far as I understood it, you can define this exactly by the semantic class and property.
A sensor would be of class “measurement” and property “temperature”, but a thermostat would be of class “control” and property “temperature”.
A light switch would be of class “control” and property “light”. Thus, to switch off all lights in a room, you simply need to iterate all children and look for those light control items and send the off command. No additional layer is necessary. Or am I missing something?
You are partly correct, and my off-the-cuff example wasn’t 100% complete. You can still have more than one measurement-temperature in a room. For example, in my office I have both the measurement of the room temperature and the measurement of the internal temperature of my home server. These are measurements captured by different devices and even have completely different fundamental meanings: occupant comfort vs machine operational health.
Even if my initial example left out some details, the general idea remains the same:
At some point, in any even moderately-sized house setup you are very likely going to run into a situation where in one location you have multiple points that have the same semantic definition and you need to distinguish them based on the physical or logical distinction between these points.
You are not missing something, but you are also not taking advantage of everything the model has to offer (and nothing says you have to, there is no one-size-fits-all solution to the model). But, for example, imagine a room with overhead lighting (functional) and led accent lighting (decorative). The On/Off points for both of those would still be control-light from a semantic standpoint, but you might not want to turn off the decorative lighting when you turn off all the functional lighting. The equipment layer of the model provides you with the ability to make that logical distinction by modeling your overhead light as a Lightbulb or WallSwitch and your accent lighting as a LightStripe. To take your example of iterating over tags in a rule, it is much easier to iterate over the equipment in a location and just send the OFF command to any Lightbulb equipment group (which will then propagate down to the points contained therein) than to iterate over all the control-light points and then do further tests to decide whether or not to turn that device off.
The converse is also true: the equipment layer gives you the ability to collate different physical devices into a logically relevant system. Many of my home sensors have both motion and temperature sensing, but in my back yard I have two different devices one for temperature and one for motion. In the model, I can define both of those points in one semantic equipment and now the information coming from the backyard is equivalent in format and definition (e.g., for use in a standardized widget) to the information from all my indoor rooms.
Thanks for pointing that out. You’re absolutely right.
But that also means that it is incredibly hard for e.g. habot, alexa or Google Home to figure out the correct items, even if you have a proper model. That’s probably why they need more metadata to actually work, because the model itself does not contain enough information for a generic way to infer the correct items.
So it seems to me, the model alone has its use case for the nice tabs in MainUI, but from a coding/ automation perspective it is not very useful other than being the lowest common denominator as the starting point to enrich the model/ items with app specific (meta) data.
Please correct me, if I got it wrong. Thanks again, that makes the whole model part a lot clearer for me!