Semantic Model, Equipments and Points

Setup, Configuration and Use Beginners
, ,
1

Hi!

I’m new to openHAB3, and I would like to use it in a KNX installation.

I read a large part of the documentation, but there are still a few things unclear about Semantic Model setup, and how to make things clean.

I successfully added a KNX gateway (I’m using a Siemens N146), and a Device (ABB SA/S 12.10.1 relays). In the SA/S Device, I added channels matching all GA used in my ETS config (more questions about this later).

I created some nested Locations, and in the final one, I would like to create the light.

Do you confirm that the correct way is, from that location, to add a Point from a Thing (the SA/S KNX Device), and choose one of the channels? Then, change the Semantic Property to Light?

Thanks,

Fred

2

Hi Fred and welcome,

Sorry i might not get what it is exactly that you want to do…

To Create your light you create the Item (dimmer or switch) and connect it to the channel. The location is the group of your light item. Semantic property is the light.

you can add groups/tags/Properties,… later and also change them.

As i said i dont know what it exactly is you need. maybee you can elaborate a bit more.
I also use Openhab3 with my KNX installation.

Greetings
Manuel

3

Generally it goes like this:
Location → Equipment → Point.

An example, this is how I set up mine in textual config. The parentheses indicate the group(s) that the group/item belongs to, and the [] are for the semantic tags.

I refer to openhab-core/SemanticTags.csv at main · openhab/openhab-core · GitHub for the list of valid tags. If you’re working on the UI, I think it’s all laid out for you nicely.

// Locations
Group   gIndoor                                           ["Indoor"]
Group   gLivingRoom              (gIndoor)                ["LivingRoom"]

// Equipment
Group   LivingRoom_Light_Bulb    (gLivingRoom)            ["Lightbulb"]

// Points
Switch  LivingRoom_Light         (LivingRoom_Light_Bulb)  ["Control", "Light"]
Dimmer  LivingRoom_Light_Dimmer  (LivingRoom_Light_Bulb)  ["Control", "Level"]
4

Thanks for your answers!

I’ve been playing with OH3 for a couple of weeks, and had to restart from scratch a few times to make a robust structure, especially to have a good naming convention (as uid can’t be changed after creation, unless modifying the .json files, which I also did), in order to be able to easily use them in scripts.

About Location → Equipment → Point, this can’t always be used, at least with a KNX setup. For example, some lights of a room may not all be on the same physical relay (as the setup evolved with the years, I added/removed things; KNX is really nice for that). On the other end, I have some smart buttons with embedded temperature sensor, which are also able to handle the room heating. These are equipments.

So, here is what I finally did:

  • for lights, I created a generic global ‘KNX Lights’ device, and added all channels matching my lights GAD. Some of these GAD are not even linked to a specific light, but rather handle all lights of the house, or the ground floor, or the first floor, and so on.

  • for temperatures, as they match an equipment, I created a KNX Device for each KNX button. As said, some of these buttons also handle heating, so I added a heat control switch. I also created an HeliosVent Device, using the Modbus/Tcp gateway.

I’m still refining my naming convention, as I just found last night specific use case which breaks the one I chose. So, this week-end, I will have to play with rpl on json files to change that ;o)

There are a lot of things to understand in OH, some are well documented, some not (well, there is documentation for everything, but not always enough to understand how to correctly use them in a OH setup). Also, OH has a lot of features from previous versions which are no longer recommended. It can be confusing for beginners.

More generally, I found that all these powerful smart home softwares are more developers-oriented rather than users. That’s why I made my own web interface to control my KNX installation, a few years ago¹, but now, I would like something that other people in my house can manage (getting old, you realise you are not eternal). So, I’m trying to make things easy to understand, without fancy stuffs. For example, even if I’m a Python developer and love this language, I will only use Blocky for OH3 scripts.

For now, I think I have enough understanding to make a basic setup, but I will probably need some help for custom widgets, in the future.

Again, thank you for your help!

¹ Fred / pKNyXui · GitLab using Fred / pKNyX · GitLab (sorry, links on the mains web sites and documentation are down, as we migrated our server a few months ago, and didn’t take time to restart Trac).

5

The way I think of it, “equipment” is merely a logical grouping. While it may often correspond to a real device on a one-to-one mapping. Sometimes it doesn’t.

I encountered this in my system when it involves a smart multi-gang wall switch. Each gang/relay/button controls a different light bulb, curtain, or even the garage door (each of which is an equipment in its own right). So in this situation, I assign each switch as a point that belongs to their corresponding lightbulb equipment.

Also you do not need to even set up the semantic model at all for openhab to work.

In the event that I’m very sick or dead, I don’t expect other people to be able to understand or continue to maintain openhab.

Because of this, I chose the automation language that I like instead of choosing blockly for the sole reason that other people might have to inherit it one day.

I try to make it so everything can still work even when openhab is shut down. They would have to get used to doing things the manual way but I try to ensure that everything reverts to their pre-smart home functionality.

6

About the semantic model, this is something I really like with OH3: it is nice to have the UI built automatically! It’s very similar to what I made with pKNyXui, and I would like to keep this feature.

I see now how you use Equipments. I will give it a try, and see what this implies in the automatic UI: I don’t want too much clicks to reach what I want to switch…

And, BTW, I found Blocky fun to use ;o)