[OH3] Model - Equipment vs Properites

[james_2_roberts (Jimbob)]

Hi all,

I’m a week into my transition to OH3 and I continue to be impressed. Features, Functionality and stability are impressive and a credit to those involved.

I’ve been trying to get my head around the semantic modelling bit - and I’m a little confused by the intent of a piece of equipment and and a point/property. More over, why I would use one over the other or what value there is in creating a piece of equipment with only one property.

As an example, I have a motion sensor (modbus) - I’ve added that as a point to the Hallway as that seem most logical, but others things when added are added as a piece of equipment - what would be the advantage of adding Equipment “Motion Sensor” then a point “Motion Sensor” - it feels like duplication?

Cheers
James

[KjetilA (Kjetil Asdal)]

As with many other things in openHAB (and in life for that matter) there is a lot of room for building the model the way you find best.

My personal view is something along the lines of this:

Sensors that are reporting ambient properties of a location, e.g. temperature, humidity, light level, etc. are best modeled as points directly on the location. I would say that a sensor reporting “detection of motion” is the same. In this case there is no distinct equipment involved.

On the other hand, you may have a laundry room (location) with a washing machine (equipment) with a sensor that reports the power usage (point). In this case, there most certainly is an equipment in the room and it makes sense to have this as part of the model.

[rlkoshak (Rich Koshak)]

@KjetilA

In this case there is no distinct equipment involved.

Alternatively, it can be models as a equipment that is just an Item with no Group. Though with Points and Properties, there is a richer set of meanings that can be created with the two tags finished to the one tag allowed on Equipment.

@james_2_roberts

and I’m a little confused by the intent of a piece of equipment and and a point/property. More over, why I would use one over the other or what value there is in creating a piece of equipment with only one property.

Frankly, a piece of Equipment with only one point is kind of a degenerative case. Most of the time you’ll have Equipment with multiple points, sometimes points that are linked to multiple Things from different bindings. A simple example is a status,power Point Item linked to the Network binding that shows whether the device is online or not.

So my suggestion is similar to Kjetil’s, if the motion sensor isn’t logically a part of some Equipment, add it to the location. Whether to choose an equipment tag or point/property tag pair depends on which gives the Item the most appropriate meaning in your model. Often your choice can be driven by where and how stuff appears in the pages

[ysc (Yannick Schaus)]

@KjetilA

Sensors that are reporting ambient properties of a location, e.g. temperature, humidity, light level, etc. are best modeled as points directly on the location. I would say that a sensor reporting “detection of motion” is the same. In this case there is no distinct equipment involved.

While that’s a good approach, the model also supports a point being both part of an Equipment and also directly a point to a Location. You simply add it to both groups (equipment & location) even if the equipment group is also a member of the location group. So a temperature measurement point can semantically be the temperature of the room but also displayed alongside the other points (humidity, motion…) of the sensor that provides it.

[konfetti (Stefan F.)]

@ysc

While that’s a good approach, the model also supports a point being both part of an Equipment and also directly a point to a Location. You simply add it to both groups (equipment & location) even if the equipment group is also a member of the location group. So a temperature measurement point can semantically be the temperature of the room but also displayed alongside the other points (humidity, motion…) of the sensor that provides it.

I’m struggling a little bit with Points being part of two groups. I understand and can confirm that a Point can be part of a Location and an Equipment. For my use case I want to have batteries in their Equipment on their location but also in a separated group.
My first choice was to make a new Equipment and putting all batteries in it, but then the Points are just in one group (logically understandable).
Is there a kind of logical Group for such use case? Using a Location feels like a bad idea

However what confuses me completely was that Points which are part of two Equipment’s are from a programmatically point of view in both groups but from model point of view not.

Following Groups & Items I have added with the developer tools:

Group gTestGroup1 "TG1"	["Equipment"]
Group gTestGroup2 "TG2"	["Equipment"]

Number TestItem1 "TI1 - both groups" (gTestGroup1, gTestGroup2)  ["Point"]
Number TestItem2 "TI2 - only 1st group" (gTestGroup1)  ["Point"]

leads to:

var group1 = Java.from(itemRegistry.getItem("gTestGroup1").getAllMembers());  
var group2 = Java.from(itemRegistry.getItem("gTestGroup2").getAllMembers());  

for (var i in group1) {
  logger.info("Group1: " + group1[i].getName());
}
for (var i in group2) {
  logger.info("Group2: " + group2[i].getName());
}

2020-12-30 16:03:13.508 [INFO ] [org.openhab.rule.Debug              ] - Group1: TestItem2
2020-12-30 16:03:13.509 [INFO ] [org.openhab.rule.Debug              ] - Group1: TestItem1
2020-12-30 16:03:13.511 [INFO ] [org.openhab.rule.Debug              ] - Group2: TestItem1

… but they are not visible in the model.

Br,
Stefan

[rlkoshak (Rich Koshak)]

@konfetti

but also in a separated group.

That separate group need not be a part of the model. In fact is sounds like it wouldn’t make sense to make it a part of the model.

[konfetti (Stefan F.)]

@rlkoshak

That separate group need not be a part of the model. In fact is sounds like it wouldn’t make sense to make it a part of the model.

Yes indeed but for now I have two options. The first is to have two Equipments but that mean, I didn’t see the Point in one of the them (while I can access it from a rule). The 2nd is to make a location.

Maybe it is not necessary and I’m overseeing something (I’m playing a little bit around with the new features and search my way ) … what I’m thinking about is an easy way to group items for visible presentation (without picking up each Point separately from the model rather than using a grouped form). For now the presentation from OH3 UI / model with the semantic tags is awesome and enough for me but the more feature the more stupid ideas in my mind

From the rule perspective you can build your own systematic using naming and tagging but from modelling a UI it is maybe a hard work if you change your mind several times.

Br,
Stefan

[rlkoshak (Rich Koshak)]

@konfetti

what I’m thinking about is an easy way to group items for visible presentation (without picking up each Point separately from the model rather than using a grouped form).

The overview pages already does some of this grouping for you.

I didn’t so anything special to put all my lights into on card in the Properties tab. They are all tagged as lights so in the Properties view it put them all together.

[konfetti (Stefan F.)]

@rlkoshak

I didn’t so anything special to put all my lights into on card in the Properties tab. They are all tagged as lights so in the Properties view it put them all together.

Yes you are right and as I said what the model does is very good but as I wrote I’m playing around, reading, playing around … (and sometimes in between I’m also thinking ).
Even it is a little bit off-topic here, but another use case for such “virtual” group is the persistence. In my understanding what I have read so far there is an automatic persistence of all Points (not sure if this is the correct naming here) if I do not change something in the persistence config (e.g. change an Point / Item in the config).
But e.g. for zwave wall-switches this does not work for me. I have several wall-switches which are doing the same thing, they control my global scene. But some of them are not up to date (by means unused) and on a restart of OH the persistence reports an old value which triggers a rule.
Maybe that is a problem in my configuration at all (which I apparently not see) but this can be avoided by a selective persistence with “virtual” groups.
Okay as I wrote this is a little bit off-topic here and of course a kind of philosophy. My origin question was more or less if I have overseen something
Many thx for your patiently answering, I read a lot of your post and they help me a lot!

Br,
Stefan

[rlkoshak (Rich Koshak)]

@konfetti

In my understanding what I have read so far there is an automatic persistence of all Points (not sure if this is the correct naming here) if I do not change something in the persistence config (e.g. change an Point / Item in the config).

By default rrd4j will save all supported Items every minute and every change with restoreOnStartup. This has nothing to do with the model.

If you want to use the Group Based Persistence design pattern, that is certainly an option, but the persistence Groups would not be a part of the model.

[konfetti (Stefan F.)]

@rlkoshak

By default rrd4j will save all supported Items every minute and every change with restoreOnStartup. This has nothing to do with the model.

If you want to use the Group Based Persistence design pattern, that is certainly an option, but the persistence Groups would not be a part of the model.

I think now you have pushed me into the right direction. What I have done now is to create a group without semantic tags and add the points/items to it. So I can use the GUI (developer tools) for creation. The points are still in the model and logically in my group which has nothing to do with the model.
That is what I want to have

Br,
Stefan

[tnemrap (Michael Parment)]

Sorry for hijacking.
So according to above discussion is a Lamp a point directly under Location.
What about a Color lamp with both Color and ColorTemperature shoud that be Properties under Point?

[rlkoshak (Rich Koshak)]

@tnemrap

So according to above discussion is a Lamp a point directly under Location.

If there is only one Item that represents that Lamp then sure, it can be a Point directly under a Location. If there is more than one Item that represents different aspects of the Lamp then you’d have a Lamp Equipment and put those Points under that.

@tnemrap

What about a Color lamp with both Color and ColorTemperature shoud that be Properties under Point?

That’s two Items so I would expect them to be grouped under an Equipment Group to represent the lamp.

Or, if you want to be consistent, You can force all your Points to be under Equipment. It’s all what works for you.

[EddieTx]

Thanks, I understand the Equipment better now after reading this thread, but I still don’t seem to understand what “Properties” are, at least from the perspective of how to get them to appear under the “Properties” tab on the overview. My .items file creates all my items, and I have played with various tags with no luck of items showing under “Properties”. An example item is listed below.

Group MasterBedroomDimmerGroup "Master Bedroom Dimmer" <slider> (MasterBedroom) [ "Equipment" ]
Dimmer MasterBedroomDimmer "Master Bedroom Dimmer" <slider> (MasterBedroomDimmerGroup) [ "Lighting","Lightbulb" ] {channel="zwave:device:zStickController:node#:switch_dimmer"}
Switch MasterBedroomDimmerSwitch "Master Bedroom Dimmer Switch" <light> (MasterBedroomDimmerGroup) [ "Lightbulb" ] {channel="zwave:device:zStickController:node#:switch_dimmer"}
Number MasterBedroomDimmerKWH "Master Bedroom Dimmer kwh" <energy> (MasterBedroomDimmerGroup, KWHsSensors) [ "Lightbulb", "Point" ] {channel="zwave:device:zStickController:node#:meter_kwh"}
Number MasterBedroomDimmerWatts "Master Bedroom Dimmer Watts" <energy> (MasterBedroomDimmerGroup, WattageSensors) [ "Lightbulb", "Point" ] {channel="zwave:device:zStickController:node#:meter_watts"}
Number MasterBedroomDimmerPower "Master Bedroom Dimmer Power" <energy> (MasterBedroomDimmerGroup) [ "Lightbulb", "Point" ] {channel="zwave:device:zStickController:node#:sensor_power"}

I also tried just adding items as just “Points”, but no matter how I configure the items tagging and grouping, nothing ever shows under “Properties”, so I’m trying to understand what goes under this tab. The Location tab shows all rooms (groups) with items populated, the Equipment tab shows all Equipment categories I have setup such as Locks, Lights, Doors, Fans, etc, but the properties tab s always blank. Am I missing something, can someone help me understand what I need to do to get items to show under there? I even tried tagging items with their property name to see if that helped (example Energy).

FYI: I did read the documentation you wrote up on Models @rlkoshak but I’m still a bit confused on this.

[hafniumzinc (T)]

@EddieTx

My .items file creates all my items, and I have played with various tags with no luck of items showing under “Properties”.

This link might be useful for you to check your configuration.

Lightbulb is an Equipment type , so you’re essentially telling openHAB ‘this is a group Item’ when you use the Lightbulb tag. Equipment Group Items don’t have Properties.

For Properties to work it needs to be a single Item, most often combined with a Point. Hopefully it’s clear in the link above!

EDIT: Removed misleading info.

[rlkoshak (Rich Koshak)]

@EddieTx

understand what “Properties” are, at least from the perspective of how to get them to appear under the “Properties” tab on the overview

Properties go with Points and it defines the “what” of the point. For example, if I have a temp sensor I’d define “Measurement” for what the Point represents and “Temperature” as the what, i.e. what is being measured. A humidity sensor would be “Measurement” for the Point and "Humidity for the Property, what is being measured. If I have a light switch I’d have Switch as the Point and “Light” as the Property, i.e. what the switch controls.

@EddieTx

but the properties tab s always blank. Am I missing something

Either you are not adding Properties to your Point Items or there is something wrong about the way you are defining the tags.

Take MasterBedroomDimmerGroup. You have it tagged as Equipment, which is OK. But LightBulb is probably a better choice for an equipment tag.

MasterBedroomDimmer is a Point Item and a member of the above Group. You have it tagged as Lighting for the Point and LightBulb as the Property. But there is no Lighting Point tag. There is no LightBulb Property tag.

This is the full set of allowable Point tags:

[rant] And this is why I stopped supporting .things files and pretty soon may have to stop supporting creating the model in .items files. How much time have we all spent on this so far when if it were just done through the UI in the first place it’s obvious and apparent what goes where.[/end rant]

Given this is a Dimmer, I would probably define it with Setpoint as the Point tag and Light as the Property. Here’s your list of allowed properties:

• Temperature
• Light
• ColorTemperature
• Humidity
• Presence
• Pressure
• Smoke
• Noise
• Rain
• Wind
• Water
• CO2
• CO
• Energy
• Power
• Voltage
• Current
• Frequency
• Gas
• SoundVolume
• Oil
• Duration
• Level
• Opening
• Timestamp
• Ultraviolet
• Vibration

If it’s not in the above list, it’s not a Property tag. A Property tag can only appear after a Point tag (no properties allowed on Equipment nor on Locations). Locations are always a Group. Equipment is almost always a Group.

MasterBedroomDimmerSwitch Get rid of this Item. You don’t need it. You can send and receive ON/OFF commands to your Dimmer Item.

MasterBedroomDimmerKWH is a measurement of energy so use Measurement,Energy.

MasterBedroomDimmerWatts is a measurement of energy also so use Measurement,Energy.

MasterBedroomDimmerPower is a measurement of power so use Measurement,Power.

@hafniumzinc

Lightbulb is an Equipment type, so you’re essentially telling openHAB ‘this is a group Item’ when you use the Lightbulb tag. Equipment Group Items don’t have Properties.

This is mostly right. But not quite. It is perfectly reasonable to have an Equipment represented by a single Item. In that case you have three choices. The best choice will depend on context and preference.

1. Create an Equipment Group and make the Item a Point and a member of the Group.

2. Make the Item a Point Item and add it as a member of the Location Group without any Equipment at all.

3. Make the single Item the Equipment and the Equipment won’t have any points (and therefore no properties).

@hafniumzinc

For Properties to work it needs to be a single Item, most often combined with a Point.

Again, there is some gray area here. Let’s say I have a Group:Number:AVG which averages all the temperatures in the house and I want this to be a Point on my House Group. I can absolutely apply Measurement,Temperature as the tags on that Group Item which will make it a Point and therefore also allow setting a Property.

So the key is to pay attention to the tag more so to whether or not the Item is a Group because Equipment can be non-Group Items and Points can be Group Items, in some circumstances.

[hafniumzinc (T)]

Good points - I’ve edited my post to censor the misleading/grey area stuff.

@rlkoshak

How much time have we all spent on this so far when if it were just done through the UI in the first place it’s obvious and apparent what goes where

For me, I’ve tried both methods, including copy/pasting YAML (only relevant for Item metadata) and using the REST API Explorer, and I’m just so much faster when using configuration files, notwithstanding the known glitches with the UI necessitating a page refresh.

Does make debugging others’ problems more difficult though, for sure.

[EddieTx]

Thanks to you both @rlkoshak and @hafniumzinc.

@hafniumzinc

Hopefully it’s clear in the link above!

The link helped out, the link on that page to the GitHub SemanicTags.csv was a tremendous help which I’ve been playing around with. The strange thing is I could have sworn I tried the solo “Energy” tag, but perhaps I messed up because it now works.

@rlkoshak

Properties go with Points and it defines the “what” of the point. For example, if I have a temp sensor I’d define “Measurement” for what the Point represents and “Temperature” as the what, i.e. what is being measured. A humidity sensor would be “Measurement” for the Point and "Humidity for the Property, what is being measured. If I have a light switch I’d have Switch as the Point and “Light” as the Property, i.e. what the switch controls.

Below is what I currently have working. I tried to add both a Point and a Property to each channel item, and Setpoint is what made sense for Dimmers to me, correct me if I’m wrong.

Group MasterBedroomDimmerGroup "Master Bedroom Dimmer" <slider> (MasterBedroom) [ "Lightbulb" ]
Dimmer MasterBedroomDimmer "Master Bedroom Dimmer" <slider> (MasterBedroomDimmerGroup) [ "Lighting","Setpoint", "Light" ] {channel="zwave:device:zStickController:node6:switch_dimmer"}
Switch MasterBedroomDimmerSwitch "Master Bedroom Dimmer Switch" <light> (MasterBedroomDimmerGroup, MasterBedroomLights) [ "Switch", "Light" ] {channel="zwave:device:zStickController:node6:switch_dimmer"}
Number MasterBedroomDimmerKWH "Master Bedroom Dimmer kwh" <energy> (MasterBedroomDimmerGroup, KWHsSensors) [ "Measurement", "Energy" ] {channel="zwave:device:zStickController:node6:meter_kwh"}
Number MasterBedroomDimmerWatts "Master Bedroom Dimmer Watts" <energy> (MasterBedroomDimmerGroup, WattageSensors) [ "Measurement", "Energy" ] {channel="zwave:device:zStickController:node6:meter_watts"}
Number MasterBedroomDimmerPower "Master Bedroom Dimmer Power" <energy> (MasterBedroomDimmerGroup) [ "Measurement", "Power" ] {channel="zwave:device:zStickController:node6:sensor_power"}

@rlkoshak

Given this is a Dimmer, I would probably define it with Setpoint as the Point tag and Light as the Property.

Lighting is the tag I had set on all the lights so they are exposed correctly to the Google Assistant which I have had set for a long time, and didn’t want to remove it for that reason. I now went back to the list and noticed that the Property “Light” has synonyms “Lights” and “Lighting” which I didn’t realize until I just re-read your post. In my iteration above, I have the tags “Lighting” (point), “Setpoint” (point), and “Light” (property). As I noted, I use the Lighting for exposing to Google Assistant so it knows what it is (as opposed to Switchable), since it’s a dimmer which has a setpoint rather than binary off/on, does it make any difference in this case if I just left it as Lighting only?

@rlkoshak

MasterBedroomDimmerSwitch Get rid of this Item. You don’t need it. You can send and receive ON/OFF commands to your Dimmer Item.

True, I only did this because it added a switch for dimmers to the auto generated UI items, and didn’t see a negative.

@rlkoshak

[rant] And this is why I stopped supporting .things files and pretty soon may have to stop supporting creating the model in .items files. How much time have we all spent on this so far when if it were just done through the UI in the first place it’s obvious and apparent what goes where.[/end rant]

For me it’s quicker and easier to configure as well as keep structured. Sorry for the confusion, I know I tried with just the Energy tag on one of my tries, but perhaps I was too quick and forgot to refresh the changes.

I’m still getting used to 3.0 which I upgraded to by mistake when forgetting to exclude my OH2.5 node when doing clustered apt upgrade However, I’m kinda happy it happened, now I see how great the upgrade is.

Thanks again guys.

[rlkoshak (Rich Koshak)]

@EddieTx

Lighting is the tag I had set on all the lights so they are exposed correctly to the Google Assistant which I have had set for a long time, and didn’t want to remove it for that reason

GA now uses metadata instead of tags. And you should move to using metadata as tags only provide legacy support. All the new features are only available in metadata.

[james_2_roberts (Jimbob)]

@hafniumzinc

This link might be useful for you to check your configuration.

That’s exactly the kind of explanation that helps me understand how the Semantic model is designed to work. Now to work out how to re-work what I’ve got via the UI.

Cheers
James