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
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?
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.
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.
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.
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 . Equipment Lightbulb tagGroup 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.
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.
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:
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.
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.
Create an Equipment Group and make the Item a Point and a member of the Group.
Make the Item a Point Item and add it as a member of the Location Group without any Equipment at all.
Make the single Item the Equipment and the Equipment won’t have any points (and therefore no properties).
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.
Good points - I’ve edited my post to censor the misleading/grey area stuff.
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.
Thanks to you both @rlkoshak and @hafniumzinc.
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.
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"}
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?
True, I only did this because it added a switch for dimmers to the auto generated UI items, and didn’t see a negative.
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.
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.
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
Thanks @rich and @hafniumzinc,
This thread has helped improve my understanding no end - the combination of the text based and UI driven examples for me at least are what I need.
I’ve used the UI exclusively to migrate to OH3 and have found it mostly good - the model has been the biggest barrier to get my head around. I’ll have a think about why - whether it’s the concept, or the UI approach which has contributed (I’m not criticising the UI, I think it’s great and I completely see the benefit in preventing typo’s/simple mistakes which often make up the bulk of the issues in the forum - I find the constant clicking backwards and forwards comparing configs of similar items to make sure they’re consistent while you learn what does what - in a text file, it’s easy to compare two configs).
Thanks again, OH3 has rekindled my interest in HA 
James
Hi there,
May be, though I seem to have a few:
I haven’t yet grasped the Model concept fully, but I’m not clear what value in adding an Equipment with a single point is yet.
That said,
This could be what I’m missing - I haven’t even looked at Pages yet, the overview page appears to give me everything I need at the moment. I want to make the best start as changing looks like a lot of work.
Back to the motion sensor - I tried adding an Equipment, and then adding the point to the Equipment. I also have the point in two other groups. Only when I removed it from the other groups would it show up in the model under the Equipment, when I add it to the other groups, it disappears from the Equipment in the model. I’m using the UI here, so not sure what to post to explain the problem. Or How do I force the isPointOf to EnSuiteMotionSensor?
Can a point only be a member of one Group (as Equipment is a Group) ?
Cheers
James
Where and how everything that appears on that overview page comes from how things are tagged in the models and whether or not you’ve overridden and of the default widgets.
A Point can only be the direct member of one semantically tagged Group. The model makes the assumption that a physical device can only be in one location at a time and a Point can only be a part of a single piece of equipment at a time (or if it’s not a part of Equipment) only in on location at a time.
From a real world location base (as opposed to functional based) hierarchy, which the model is supposed to mirror, that makes perfect sense.
Why would you have the motion sensor be a member of any other semantically tagged Groups? Note, it can be a member of any number of non-semantically tagged Groups. In this case, gMotionSensors should not be a part of the model. It doesn’t make sense as being in the model anyway. You don’t have a MotionSensors Equipment. You have lots of separate Motion Sensor Equipment. It might be useful to have gMotionSensors to trigger a rule or aggregate the values into one or the like so I’m not saying to remove it nor am I saying to remove the sensors from the Group. What I am saying is to remove the Group from the model by deleting it’s semantic tag.
I’m looking for some help in understanding how to better use and take advantage of the new UI. I’m using text files for all .items and have tagged them as Groups(Locations),Equipment and Points and Properties. No major issues here as I’ve been able to see them in the Model and use them items to create Locations and Equipment in the UI.
My specific issue is that I have a Number: Item that is tagged as [“Setpoint”, “Temperature”] for which I want to create a Stepper or Slider inside of a Location and Equipment Card. Currently the Item value is displayed inside of the location as a Number but cannot be changed, only graphed. I can create an oh-stepper-card or oh-slider-card in the Overview and it works fine, but I am unable to use in side of an oh-equipment-card or oh-location-card.
I have tried all sorts of variants without any success so after beating head against the wall for far too long I realized I need some guidance.
So here is my slider code
component: oh-slider-card
config:
item: vVenstar_HeatSetPoint
min: 60
max: 80
title: Heat Setpoint
step: 0.99
scaleSteps: 1
unit: °F
that I would to insert into the equipment definition code that is fine and works as expected for what it is.
HVAC:
- component: oh-equipment-card
config:
backgroundImage: /static/files/hvac.jpg
invertText: false
slots:
default:
- component: oh-slider-card
config:
item: vVenstar_HeatSetPoint
min: 60
max: 80
glance:
- component: oh-link
config:
text: "=items.vVenstarThermostat_Mode.state "
color: "=items.vVenstarThermostat_Mode.state==='HEAT' ? 'red': 'blue' "
style:
font-size: 18px
- component: oh-link
config:
text: =items.vVenstarThermostat_HeatCoolState.state==='HEAT' ? 'HEATING':'' ||
items.vVenstarThermostat_HeatCoolState.state==='COOL' ?
'COOLING':'' ||
items.vVenstarThermostat_HeatCoolState.state==='OFF' ?
'IDLE':''
color: "=items.vVenstarThermostat_HeatCoolState.state==='HEAT' ? 'red':'' ||
items.vVenstarThermostat_HeatCoolState.state==='COOL' ?
'blue':'' ||
items.vVenstarThermostat_HeatCoolState.state==='OFF' ?
'white':'' "
style:
font-size: 18px
What is shown in Location/Equipment/Properties card is the “Default List Item Widget” for each item. You can customize this default widget by setting Metadata for it. So just head to the considered item in your model and click “Add Metadata > Default List Item Widget”. Now you can configure the widget via UI or via YAML
@rlkoshak,
As always, thanks!
and
Yes, that makes perfect sense, I can only assume when I started trying to understand the model I’d assumed it made sense to tag everything, clearly that makes little sense as the model is driving the UI - something I hadn’t fully appreciated. I’ve got a few more items to migrate, then I’ll start looking more closely at some of the rules and how they can be improved with the model.
Cheers
James
@rlkoshak will the properties be able to be used within .items files? I know a few work (Number:Temperature, for example) but some of them don’t seem to.
Don’t mix properties with item types. I know this can be a little confusing.
This is the type of the item. To be precise it’s a so called QuantityType meaning it’s a Number with an unit that can be used with openhab’s Unit of Measurement features.
What is used to build to semantic Modell used by the new UI to create e.g. the properties tab are just item tags. They are completely independent from the item type and can be set in .items files with square brackets
So an equipment must be a group, right?
I ask because I use sometimes
["Measurement", "Temperature"]
and wonder if it would be possible to use:
["Lightbulb","Switch"]
without using an extra group for equipment representation.