Can some please explain me the difference between point and equipment.
Bedroom Window is a switch and an equipment
Bedroom Lights is a switch and an point
so why is there a difference in the definition. The effect is, as i think, shown in the following picture
Windows is found in Equipment, and Light is found in Properties.
This is not obvious for me
Have a look here.
As to my limited understanding, an equipment is a “group” of points and represents an actual device (usually). Points though can also be stand alone properties and if not under an equipment would appear in the properties tab. Say you would move your Bedroom Lights switch under your Bedroom Window equipment, this point would move to the Equipment tab and be shown there under the Bedroom Window equipment.
Example:
Thermostats usually make good examples of this sort of thing.
A thermostat is piece of equipment, located in one place.
So far as openHAB is concerned, it has multiple interesting properties - the actual temperature, the target temperature, the on/off output state. Each is a ‘point’. Note that they don’t even have to be of the same type. There’s a sensor, a variable control, and an on/off state that may be controllable too.
For consistency sake, I’ve been recommending more and more to only use Groups to represent Equipment and always put Points inside an equipment. But at a minimum you must be consistent. For example, if you have one light switch that controls a light and that’s it and if you have another light switch that both controls the light and reports how much energy the light is using:
the first light should have a Group Item with the WallSwitch Equipment tag with just the one Switch Item with “Switch,Light” as the tags as a member
the second light should have a Group Item with the WallSwitch Equipment tag with the two+ Point Items as members; the Switch Item will be tagged with “Switch,Light” as the tags.
Why create the equipment for the first Item? Because you want all your light switches to appear and work in a consistent way in all three tabs of the overview page.
But as for why there is a difference in the definition? Well, it’s because you defined them differently. It’s perfectly OK to define them as you have, but if you want them to appear consistently you must apply your semantic tagging consistently. In this case, either both need to be tagged with an Equipment tag or both need to be tagged with a Point,Property pair of tags. Equipment and Point,Properties are not interchangeable. They have different purposes in the model.
The following relationships are possible in the semantic model:
| Tag | Have as members | Be member of |
|---|---|---|
| Location | One or more Locations, one or more Equipment, one or more Points | Zero or one parent Location |
| Equipment | One or more Equipment, one or more Points | Zero or one Location, Zero or one Equipment |
| Point | None | Zero or one Location, Zero or one Equipment |
So Locations can have sublocations and can have Equipment or Points as children. But Locations can only have another Location or nothing as a parent. There can be only one parent.
Equipment can have subequipment and/or Points as children but never a Location. Equipment can have nothing, another Equipment, or a Location as a parent. There can be only one parent.
Points cannot have any children. Points can be a child of an Equipment or a Location. There can be only one parent.
Therefore, Points are really the lowest level. These are the actual sensors and actuators. An Equipment is typically a collection of one or more sensors and/or actuators, i.e. Points, though for complex equipment it can be represented using subequipment. A Location represents a physical part of the home and is a collection of sublocations, Equipment, and/or Points that are in that location.
Equipment -------> Location
^ ^
| |
\ /
\---------Point----/Actually you can have both one parent Equipment and one parent Location.
This scenario is interesting and useful when you want to promote certain Points directly under the location to control a bit what is considered to compute the badges in the location cards.
When you have multiple “candidate” points with a given class/property, for example “Measurement/Temperature”, those points directly under the Location will be considered first. Only if there are no matches, those related to Equipment will come into play.
Example:
I have a window sensor and a motion sensor in the living room, both happen to have a temperature measurement point.
The motion sensor is away from openings, while the window sensor is - obviously - near the window and thus reports a temperature way lower than the actual ambient temperature in the room is.
I decided I want to consider the temperature of the room to be the one reported by the motion sensor (ZW074) because it’s arguably more accurate to the actual ambient temperature.
So I have added my temperature measurement to both the Equipment and the living room Location. You can see in Model treeview that when you select it it is recognized to be one single item (it appears twice but is also highlighted twice).
And in the semantic classification details you can see it has both “hasLocation” and “isPointOf” relationships:
So as said above, since I have a temperature measurement directly under my Salon location, in my card badge I will only see this one:
If I hadn’t “promoted” that item by adding it to the gSalon group, this is how it looks:
It took the 2 temperature measurements found under Equipment indistinctly, and shows the average (that’s how the badge works).
Hope that’s clear!
When I’ve tried that the Point only shows up in one of the Location/Equipment in the Model view. Has this changed or did I mess something up when I tested it?
That indeed can be useful to separate the setpoints from the sensor readings among other things.
Nope that’s always been possible AFAIK.
In this particular case you would have a “Setpoint/Temperature” and a “Measurement/Temperature” so in any case you would have 2 readings in the temperature badge.
(the one between parentheses is the setpoint)
But you can use this technique to exclude potential matches.
Same thing if you have e.g. lightbulbs with both a “Switch/Light” and a “Control/Light” (the brightness dimmer), if you don’t promote one or the other they will be counted twice.
Thanks for the many answers. In addition of buliding my model, now i think i understand it
What about the following thought:
I have a KNX actuator in the switch cabinet (basement). I add it as KNX thing and add each actuator channel as channel. So far, so obvious.
Now I have several possibilities.
Does it make sense that I think that adding a point item for an actuator makes no sense if I want to have the touchable equipment anyway in the model? If that poweroutlet had any further data to offer, then I would add it as point to the equipment. But in most cases the channel linked to the equipment is enough for a lightbulb plugged into a poweroutlet controlled by anactuator, is it not?
Ultimately it’s up to you to decide what makes sense. Just keep in mind that what decisions you make will change how and where the Item appears in the Overview Pages and, in the future elsewhere as well.
Looking at it from a usability perspective, do you users care that it’s KNX? Do they care that the actual physical relays are in a closet somewhere? Do they even care if it’s an outlet? Probably not. They only care that if they flip this switch, that lamp goes on. So model the lamp. The lamp almost certainly isn’t in the closet in the basement so don’t put the Items that control it in the basement, put them in the room where the lamp is.
Given that right now the model primarily drives the UI, that sort of thought process should be your guide. You should shoot for consistency and reflect how your house is actually used by end users of your home. Keep details that don’t matter to the users out of your model, or failing that set their visibility to false.
Agreed, that’s why I stopped creating point items for each KNX channel and started creating equipment with a link to the channel only.
The lamp appears in the UI in the room and in the equipment. So for me, I do find the objects where I would look for them.
One drawback of my approach seems to be that the UI automatically expands equipment which contains points, i.e. it uses the equipment as heading and lists the e.g. switches underneath. For equipment with equipment in it (switch) it does not expand but one always has to open the group to access the items in it.
Does somebody know the reasoning behind that? Is it because equipment could be a group and point not?
This. In fact the vast majority of the time the equipment is a Group. Only rarely will an equipment be an Item.
Personally I never make a plain Item an Equipment. Equipment are always a Group. This keeps the UI consistent. The Switch that is a part part of some more complicated piece of equipment is shown the same way was a stand alone Switch. So yes I do occasionally have an Equipment with only one member.
Also, Equipment has a completely different set of tags from Points and Equipment doesn’t support Properties meaning you won’t find them on the Properties tab of the Overview page at all.
So if you had a simple light switch that controls a lamp tagged as Equipment and a smart bulb with both a Color and Color Temperature Channel combined into one Equipment, they way the two lights controls will appear in the Overview page will be very different. Since both control lights, both should be consistently represented in the UI which means the simple switch needs to be a Point, not an Equipment.
Somehow each approach breaks at some point.
For example, I have an oven, a microwave, a cooker and a mixer in the kitchen. The poweroutlets they are plugged-in are most probably not important to the user. If one would plug them into another poweroutlet, the object’s channel link would change but not the object itself.
I can create an equipment “kitchen machinery” within the location “kitchen” in order to separate the kitchen “machinery” from other equipment within the kitchen and group the items. The “kitchen machinery” should contain all of the above.
If one uses points to add the objects to that group, they do appear on the locations page within the “kitchen” card’s equipment tab, grouped by the header “kitchen machinery”. But there is no way to assign “oven” or “whitegood” to them, since those are equipment tags. Without these tags, all objects are shown as part of the general equipment card on the equipment page instead of having a separate “oven” and “whitegood” card on the equipment page.
So instead of “point”, one can add them as sub-equipment of the “kitchen machinery” equipment/group, the oven, the microwave etc., and assign the “oven” and “whitegood” tag. That way they appear in the equipment tab as card “oven” and “whitegood”.
But now they do not appear on the location page’s “kitchen” card - equipment tab anymore. It seems that the cards do not show second level equipment, i.e. equipment in an equipment.
If I do not group the kitchen machinery with an equipment, they do show up on the locations page’ kitchen card, but without group header. Isn’t grouping what equipment is for? Why does the location card not show second level equipment by using the first level equipment as header and the sub-equipment as switches or whatever object they are?
Additinal information to the above: The sub-equipment does not appear on the location card if the equipment-group it is part of does also contain a point. If an equipment group has only sub-equipment as members the card does show them as collapsed group.
They do but you have to click through to them. When you nest Equipment you end up with a nested set of cards. Note that I believe the header is only shown for Equipment Groups and I also believe the click through only works for Equipment Groups. That’s another argument for not applying Equipment Tags to anything but a Group.
One has to ask, what purpose does the “Kitchen Equipment” Equipment serve? It’s kind of a misuse really because “Kitchen Equipment” isn’t really an equipment, it’s a collection of independent equipments. So I’d say this parent Group is not needed. It doesn’t really add anything semantically and it doesn’t keep the model consistent. Instead, eliminate the “Kitchen Equipment” entirely. Create a separate Equipment Group for each device. Put the switch and what ever else inside that Group.
Kitchen
|_Toaster
| |_Switch
| |_Power Usage
|_Coffee Machine
|_Switch
|_Power Usage
Or, if you want to keep the “Kitchen Equipment” for some reason, you still need to use the separate Equipment Group Items.
Kitchen
|_Kitchen Equipment
|_Toaster
| |_Switch
| |_Power Usage
|_Coffee Machine
|_Switch
|_Power Usage
It’s more than that. Equipment is indeed intended to Group Points, but it does so for a single piece of equipment. For example, you might have a light fixture with three smart bulbs in it. The Equipment is the light fixture. Each light bulb might itself be modeled as a separate Equipment that is part of that light fixture. Or it might not and the Points for each light bulb is a direct member of the light fixture Group. In either case though, the light fixture is a single logical Equipment.
Semantically, “Kitchen Equipment” doesn’t add anything. You already know it’s equipment because they are tagged with Equipment tags. You already know they are in the Kitchen because they are members of that Group.