[OH3] Semantic Model setup via tags in configuration Items files

Tutorials & Examples Solutions
, ,
23

But in this case it should be able to add Equipment tag to an item like so:

Switch   GF_Bathroom_Light_Ceiling    "Deckenleuchte"     <light>  ["Lightbulb", "Light", "Switch"]

But with this, OH3 UI doesn’t render the Item as an equipment. It only works when adding additional group:

Group    gGF_Bathroom_Light_Ceiling   "Deckenleuchte"     <light>  (GF_Bathroom)                 ["Lightbulb"]
Switch   GF_Bathroom_Light_Ceiling    "Deckenleuchte"     <light>  (gGF_Bathroom_Light_Ceiling)  ["Light", "Switch"]
24

Ah, you can’t have an Item be both an Equipment and a Point. One or the other only.

25

I also have things/Items defined in files and other things/items in the UI and get a “flat model” on restart. If I fiddle something in a file, it is put back into the hierarchy until the next restart.
Is this going to be fixed in a future release (e.g. is that considered a bug/issue)? My items are really half/half coming from OH 2.5 and I intend to focus on the UI more in the future, but I hate to go through some 60-70 items in files and set them up one by one in the UI or at least want to take my time doing so without having a half working system in the meantime.

27

Great read, but how did you add a header image to the Groups/Locations?
Edit: Found out.

28

I’m new to OH3 and I’m trying to build a semantic model following your instructions, below is my definition, which I’m fairly sure is correct, but some of the groups don’t show up as Semantic items, any ideas?

//HOUSE MODEL

//INDOOR
Group    gIndoor               "Indoor"                                                    ["Indoor"]

//GROUND FLOOR
Group    gGroundFloor          "Ground Floor"           <groundfloor>    (gIndoor)         ["GroundFloor"]
Group    gLivingRoom           "Living Room"                             (gGroundFloor)    ["LivingRoom"]
Group    gLivingRoomLights     "Living Room Lights"     <light>          (gLivingRoom)     ["Lightbulb"]
Group    gLivingRoomHeating    "Living Room Heating"    <heating>        (gLivingRoom)     ["Heating"]
Group    gKitchen              "Kitchen"                <kitchen>        (gGroundFloor)    ["Kitchen"]

Group    gHallway              "Hallway"                                 (gGroundFloor)    ["Hallway"]


//FIRST FLOOR
Group    gFirstFloor           "First Floor"            <firstfloor>     (gIndoor)         ["FirstFloor"]
Group    gOffice               "Office"                 <office>         (gFirstFloor)     ["Office"]
Group    gOfficeLights         "Office Lights"          <light>          (gOffice)         ["Lightbulb"]
Group    gKeira                "Keira Bedroom"                           (gFirstFloor)     ["Keira"]
Group    gKeiraLights          "Keira Lights"           <light>          (gKeira)          ["Lightbulb"]
Group    gRyan                 "Ryan Bedroom"           <bedroom>        (gFirstFloor)     ["Ryan"]
Group    gRyanLights           "Ryan Lights"            <light>          (gRyan)           ["Lightbulb"]


//FIRST FLOOR
Group    gSecondFloor          "Second Floor"           <firstfloor>     (gIndoor)         ["SecondFloor"]

//OUTDOOR
Group    gOutdoor              "Outdoor"                                                   ["Outdoor"]

Group    gGarden               "Garden"                 <garden>         (gOutdoor)        ["Garden"]

image
image809×423 6.69 KB

29

It would be much easier if you mention which group you assume to see in the model instead of just say “some” :wink:
So I assume that you mean e.g.

Group    gKeira                "Keira Bedroom"                           (gFirstFloor)     ["Keira"]

Well it is a few month ago that I build my model, but I cannot remember a semantic tag named [“Keira”].
Why don’t you choose the semantic tag (or better build your model) with the UI?

Br,
Stefan

30

Ahh, I thought that was something we defined, changed it to Bedroom and all sorted, thanks!

31

No it is not something you can define by yourself. Some posts above is a link to the complete list of tags as far as I remember (or as I mentioned just use the UI :smiley: )
Br,
Stefan

32

Yep, found it, thanks

33

This tutorial is absolutely Fantastic !!
thanks
(I love configuration via text files instead of GUI)

1 Like
34

I am also trying to understand how to add a bulb with onoffSwitch/brightness/color with semantic model. Do i need to define a bulb as an equipment and then add these as sub properties OR do i simply add these definition to the existing equipment “gLivingRoomLights”?

35

I want to have a selection for an item like this thread. How can i specify Metadata/State/Options in an item file?

36

https://community.openhab.org/t/oh3-add-metadata-to-items-via-configuration-files/112843

1 Like
37

Hi Hafniumzinc,
did you manage to have your mqtt definitions in text files?
The broker and all the things are defined here
./userdata/jsondb/org.openhab.core.thing.Thing.json
in my OH3 setup.
I prefer to have them in the conf folder and split up among several files.
Thanks
Marco

1 Like
39

Should a light item (switch or dimmer) be a point “Control” or a property “Light”?

I don’t quite understand the differences between point and property as listed

40

I have light switches as POINT=Switch and PROPERTY=Light

Switch sLivingRoomShortLight "Living Room Short Light" <light> ["Switch", "Light"]  { channel="mqtt:topic:swLivingRoomShortLight:switch"}

In this case I think of the POINT as the description of the physical thing your interacting with, whilst the PROPERTY is the thing that you’re affecting (or is being affected).

41

The way I model thing, the Point tag is what the Item does. The Property is what the Item does it to.

For example, I have modeled a water leak sensor with a Point tag of “Alarm” and a Property of “Water”.

The what it does is indicate an alarm. The property indicates what it’s alarming about. A smoke alarm might use a Point tag of “Alarm” and a Property tag of “Water”.

Given that, I’ve modeled my lights as Switch for the Point and Light as the Property. I don’t have Dimmers. If I did, I’d probably use “Control” as the Point and keep “Light” as the Property.

To me, this generates the most consistent model and consistency is key. You don’t want one light control to work and look one way and another one to work differently because they were modeled differently.

In MainUI, the key is the Property tag. That is what will control what appears on the fourth Properties tab and control under which card the Items appear. The Point will control how the Items are organized within that card.

For example, I have a number of DIY smart humidifiers. In OH these consist of a sensor, a switch, and a setpoint.

Type Point tag Property tag
Sensor Measurement Humidity
Switch Switch Humidity
Setpoint Setpoint Humidity

It looks like this:

image
image1334×1324 98.4 KB

Note that this is how I do it and how I recommend doing it. There can be other approaches. If I did have color lights or dimmers, I might use Control as the Point instead of Switch for my lights. But since I’ve only simple light switches I just use Switch.

At this point, I mainly let the Properties tab guide me. If things don’t look right or get broken up in weird ways on the Properties tab, I know I’ve been inconsistent in my modeling.

4 Likes
42

For window contacts there must be an equipment “Window” to see the status badge on the location card, but this also means that they show up as equipment. I rather would prefer to have it available in the properties of the location card.
If I change the window contact to a Point like e.g. [“OpenState”, “Opening”] without equipment and right under a location then the status badge disappears.

Is there a way to have the window contacts in Properties tab of the location card but also keep the status badge?

43

No. The badges show the status of Equipment. No Equipment, no badge. So you have to decide which is more important to you, making these contracts a property of the room instead of an equipment, or having the badge. There is no right answer.

44

This already seems to be working for a switch but not for a contact.
I would like to have everything what is hand operated (e.g. a switch) as equipment and all sensors as property.
Do you see a possibility to make something like a feature request that this gets supported in one of the next Openhab versions?