i admire the way the online designer works and is running. But isnt there a way to move 12 existing .item files with a total of 150+ KNX items into OH4.x more easily than
creating channels per item
manually link an item to it?
when trying to sideload thru the developper interface - it tells me item created - and it shows in the item list. But its not working. Currently trying items to side load with the following syntax:
The groups are created and show under items as well. My only use case is to use OH in the android app, so i dont need fancy floor maps or such things.
What would be the sytax for sideloading the items to also link them to a channel as the way the arguments are loaded seem to have no connecion to the KNX binding. I am still hesitant to spend 6 hrs in manually adding all the single items/ channels to OH4.x. Its ok for 20 or so - but not for 150+…
I created the things and configured the channels for each actuator or sensor.
and then let it auto-create the items accordingly. If you name the channels already, and have a structure in place in the model, this is IMHO the easiest way.
The problem you have is the 1.x KNX binding is no longer supported. Consequently all that knx-= stuff simply isn’t something OH 4 is going to understand or know what to do with. There really is nothing in common between the 1.x KNX binding and the 2.x+ KNX binding and the OH architecture is vastly different. So unfortunatly there is no other option than to create the KNX Things and Channels you need.
However, as @binderth suggests, once the Things exist, instead of manually linking the Items to them it’s far faster and easier to use “add equipment from thing” to create all the Items instead of importing them. This will create the semantic model Group, all the Items, and link all the Items to the Channels all in one go.
Means you create one thing per KNX item - and not one thing like “Livingroom” and then KNX items like Lmaps, shutters, … as channels inside? I am still lost on the best approach.
Right now i am creating one thing per room and all within this a lot of channels for all single items.
simply because I then can compare the GAs and stuff with the structure in the ETS. It has an disadvantage though: My model in openHAB is based on location/rooms and of course the rollershutter-actuator is not room-based, but serves more rooms. That’s why I had to run the “add equipment from thing”-action more than once. But my thinking was: having the same structure in openHAB as in ETS makes my personal work easier.
[1] you can ask the KNX-bus for e.g. 1.1.8 for an actuator, but even if you query the actuator it won’t result in an auto-sense of all stored GAs. You have to do that manually (as it also was in OH1.x).
Representing location in the model is handled at the Item level, though Things do have a Location property which you can supply and then sort your Things based on that property in the Things settings page in MainUI.
One Thing per device also means that if things change (e.g. add or remove a device) it’s easier to manage those changes.
I’m not sure how KNX works, but for some technologies it also means you can monitor the online/offline status of individual devices. For example, because I have each device represented as a separate MQTT Thing, I can configure that Thing to go OFFLINE when just that one device stops responding instead of needing to mark all my MQTT devices as OFFLINE just becuase one is. This may not be possible in KNX though.
As this is “kinda” true, I’ll try to elaborate on KNX a bit more.
The concept is to “combine” similar let’s say “actions”. Meaning, there is one “big actuator”, which offers all technology to control multiple identical devices. Simplest examples are lights. You don’t have the actual “switching on/off” device near the light/lamp, but in the central switchboard. Means, you have to wire some more electrical wires from each device to the central switchboard, of course. And in parallel you have to combine all sensors in a bus-system. Staying with the light in the bathroom you’ve got a sensor (aka switch) in the bathroom. You’ve got the lightbulb and you’ve got the “actuator - channel 1 and 2”. Whereas channel 1 switches the light on/off and channel 2 signals the current state of the actuator (on/off).
In my screenshot it would be the physical device “1.1.06” aka “Dimmaktor/dimming actuator”. This device offers the technology to be able to have 4 lights dimming (there are really about 16or more “channels” for each dimming light, would be too much to elaborate here, but let’s say there’s channels for percentages, stairwell configuration, …). Of course the actuator is not phyiscal in the bathroom, but in the switchboard. I also use one of the 4 to dim lights in the living room, master bed room and the entrance (if this actuator fails, I don’t have blackout in connected rooms, therefore 1.1.07 in return is used in rooms connected to the ones above).
And as I mentioned, the KNX “programming/parameterizing” is not as easy as it looks. And - a obviously intended - “feature” is, that you cannot “read out” the parameterization of your KNX installation from each device (1.1.06 being one). You have to have the original “ETS file”, meaning a central piece of software intended to be used by electricians. That way (if you don’t press your electrician to give out this file) you are “locked in” with your electrician. (and ETS license is a few hundred bucks!)
so much so long! The essence is:
there is no “real” connection as it would be in other technology to rooms
there is no “readout” from a KNX device
=> you can simply add KNX-things as you like and what suits best for you. I went the “like ETS”-way, but you’re free to use one KNX-thing for EVERYTHING (could be a bit complex then) or one KNX-thing per device/room/type of devices/…
From the perspective of the humans who use the house, the light is in a specific location. A wall switch is in a specific location. Those are the devices. The fact that the actual relays are hidden in a closet somewhere is not meaningful to them. In fact, the location of the wall switches that control the light are not really meaningful to them most of the time but might be meaningful to you as the admin of your OH instance.
If one were to control the lights by voice they would say “turn on the lights in the bathroom”, not “ask the KNX system in the utility closet to turn on the lights 1, 5 and 7”.
So if there is a KNX Thing that represents one light or even all the lights in the bathroom, I would represent that as one Thing with a location of “bathroom” for the Thing. The fact that there’s really a central closet with relays and all that sort of thing is as irrelevant as the fact that my MQTT Broker is running in my office but my garage door controller is in the garage (and yes, my Broker Thing has a location “Rich’s Office” and my garage door controll Generic MQTT Thing has a location of “Garage”).
Note: the location property of Things isn’t really all that useful so it’s not really that big of a deal one way or the other. But you can sort your Things by location. If you do so, do you want all your Things to show up under “utility closet” or would you rather see a bit more about where groups of channels are actually in the home?
Setting up the Things is the first layer of abstraction from the specifics of the technoloigy to a normalized and human friendly representation of your home automation. Items are the second layer. I’m convinced it makes sense, where possible, to take advantage of that by abstracting as much of the details about any specific technology as possible even at the Things level.
I do recognize that it may be more work but if it can be done, I think it should be done that way. This gives you maximum flexibility and greater usability in the long run.
I agree - if it was “written in stone” as it usually is in a “classic setup” of building a house. But with KNX you could easily re-invent the way you use the whole thing.
I for one changed my installation nearly yearly or at least every other year. It’s easy to do, as all the wires are centralized and the sensors/switches are easily replaced into other places and/or let actuators reroute their actions…
It is a bit long-hauled I admit, but I had a more physical approach in my openHAB-configuraiton - and completely rewrote all my KNX-things twice since. And as I used the “KNX-way”, I was finally there. Of course this is, because I am lucky to have both the “ETS file” (complete configuration) and ETS licence and can change my KNX-configuration myself. And I guess, I “think” KNX in editing ETS-led configuration. So I’m way more comfortable finding the KNX-devices as KNX-things - and it is less error-prone for me. (and in the end, it IS a KNX-thing approach, as this way the openHAB-things represent KNX-“things”)
That being said, of course if you’re a openHAB user and less into KNX-configuration, an “room”-approach can be a viable option.
Well, that’s not true you can read basic configuration per Device.
But: you will always only get a list of CO (communication objects), its flags and the configured GA (group addresses).
You won’t get any additional data such as naming, parameters of channels and so on. If it’s an advanced device (e.g. RTC/HVAC) you won’t get any of the advanced stuff.
But it’s possible to rebuild a basic configuration of communication from bus readings.
The ETS project is part of the documentation. It’s NOT private property of the electrician (although there are many electricians out there which will try to argument like that).
Best option is to clarify from start that the ETS project is part of the contract and it’s payed property of the home owner.
From my perspective, one knx device is one Thing. There is the individual address (in german “physikalische Adresse”), which is configurable per Thing, and each knx device has an IA.
Of course you don’t need to use the IA at all - it will provide ONLINE/OFFLINE messages, though, but as knx is most likely TP (twisted pair), there is almost never a real offline device, but only false positives, as the messages for check are low priority and therefor sometimes some packets get lost due to collision.
Some knx devices will provide additional information, e.g. manufacturer and model, but there is (up to now) no real benefit in openHAB for this data.
Perhaps I have just too much advanced devices.
I tried ti readout one time just for fun. And it failed for some “basic” stuff like stairway automatic lights out or my dimming settings. Of course also the rollershutter settings… scenes…
But that’s slightly OT here, I guess…
Jepp. I heard that a loooooooot. And I recommended that to my friends everytime to be sure to get the ETS file…