Ahh, I thought that was something we defined, changed it to Bedroom and all sorted, thanks!
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 
)
Br,
Stefan
Yep, found it, thanks
This tutorial is absolutely Fantastic !!
thanks
(I love configuration via text files instead of GUI)
1 Like
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”?
I want to have a selection for an item like this thread. How can i specify Metadata/State/Options in an item file?
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
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
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).
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:
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
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?
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.
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?
That’s somewhat a misuse of the model and in not sure you can do that completely. The model is intended to have Equipment, for example an HVAC system. All the setpoints, controls, and sensors are a part of the HVAC equipment.
If you separate the stairs from the actuators you completely lose what is part of what devices, which is kind of the main point if the model in the first place.
Given your unintended way of using there model, I would’ve expect consistent behaviors and assistants in the UI.
You could make a feature request but I don’t know if it would be implemented.
Hmm, actually I have only one equipment/thing and this is KNX with a lot of channels.
This is the reason why I have to create for every room (virtual) equipments like for Lights, Rollershutters (e.g. Kitchen Lights, Kitchen Rollershutters, Living Room Lights, Living Room Rollershutters…). In this way I could make a clear spearation between switch as equipment and sensors as properties.
I would not say this is a misuse, only a straightforward solution in terms of usability.
KNX is a little different in how it represents devices. It may not be a one-to-one Thing to Equipment with KNX.
The key thing is the model should represent the physical layout of your home. If you have a lights with three smart lamps in the living room that are always treated was a unit, then you have one lights Equipment in the Livingroom and each lamp is a point under that. The fact that it’s actually controlled by a KNX module in the closet is not something that belongs in the model.
Creating equipment groups is not a misuse of the model. Separating the sensors from the actuators is.
For example, I’ve a door equipment. This equipment has a Contact as a member as well as a sub equipment for the lock. The lock equipment has a locked/unlocked sensor as well as an actuator to cause the lock to open or close. The sensors and actuators are part of the same equipment.
I fully understand this. My problem is if somebody else wants to use the MainUI how can I explain to him what is under equipment and what under property. Also for me it is not 100% clear.
Maybe the best way is to only use equipments and only in some special cases properties.
That’s the typical approach. The Equipment also adds information to the model. It’s not just a placeholder. Grouping all the stuff that is logically a part of the same equipment in the real world, even if it’s Items linked to different Things from different bindings, is the way to go.
@xela @trumee
that´s right and there´s already an issue.
according to my analysis the problem could be solved as soon as the txt items are loaded AFTER the UI items after a reboot. As a workaround my following rule can be used:
configuration: {}
triggers:
- id: "1"
configuration:
startlevel: 100
type: core.SystemStartlevelTrigger
conditions: []
actions:
- inputs: {}
id: "2"
configuration:
considerConditions: true
ruleUIDs:
- 25e67a5f02
type: core.RunRuleAction
and the appropriate Python script is as following:
import os
import time
item_path = '/etc/openhab/items'
tmp_path = '/etc/openhab/items/tmp'
os.mkdir(tmp_path)
for file in os.listdir(item_path):
if file.endswith(".items"):
os.rename(os.path.join(item_path, file), os.path.join(tmp_path, file))
time.sleep(1)
for file in os.listdir(tmp_path):
if file.endswith(".items"):
os.rename(os.path.join(tmp_path, file), os.path.join(item_path, file))
os.rmdir(tmp_path)