OH2.3 with KNX2 - syntax of items not clear

Well, this is not fully correct: yes, you can still use the old OH1.x binding but it’s not supported anymore AND one must expect that somewhen in the future there will be breaking changes which prevent usage of newer versions of OH.

To be honest: I was really keen on the KNX2 binding but now I’m disappointed. I don’t see the added value/benefit for a user in comparison to the old v1.x binding, even worse - the configuration became needlessly complicated and would require a huge effort for . Just to have it “streamlined” with Eclipse SmartHome I would have preferred that all the efforts would have been spent in enhancements, stabilization, documentation of the old binding.

What about having a survey asking the KNX users about their satisfaction with the new vs. the old binding and where further development efforts should be spent. IMO this is much more “product thinking” (creating value) instead streamlining things just to have it streamlined.

Regards
John

P.S: As other users already stated: this is neither making developers work bad nor not appreciating that people are spending their spare time into open source development.

  1. knx2 is capable to be controlled via Paper UI
  2. knx2 is capable to be configured via Paper UI
  3. There is a more strict definition for channels (as written in OH2.3 with KNX2 - syntax of items not clear)
  4. A more strict separation between commands and changes or updates.

No, it’s not. The binding configuration moved from knx.cfg and knx.items to knx.things (or do the configuration via Paper UI, karaf, REST, HABmin…) Of course, now you have to define links to the channels, but even this is possible via Paper UI.

No, it’s not. The binding configuration moved from knx.cfg and knx.items to knx.things (or do the configuration via Paper UI, karaf, REST, HABmin…) Of course, now you have to define links to the channels, but even this is possible via Paper UI.

When I migrated my KNX Items (several hundred) I had indeed the impression that it is much more complicated.

In KNX1 I had on line in a configuration file per item, these files could be grouped by whatever I liked. In KNX2 I habe one entry in the things file, grouped by the KNX actuator, another entry in an items file, which must match the things definition. I had several hard to spot bugs, just because these entries where not matching correctly.

To make things worse, for some items I need another things definition for a “control type” and additional items for this as well, when wanting to use “received command” triggers. Rule triggers must be adapted and again a lot of opportunities to make errors and a illogical configuration.

Creating the items out of the things in VSCode might work for new installations, but not when migrating an old installation where the existing item names are used in a lot of places. Beside that, the problem with the additional “control” things persists.

I see the benefit in using the Paper UI for some, but as I do not use it and don’t want to (e.g. because this configuration can not be placed under version control) that is no advantage for me.

To be honest: Without the bugs in the current KNX1 Binding I would not even think about migrating…

This is one of the most confusing changes for me…Can someone maybe explain, why especially THIS change has been introduced? I have started playing around with zwave these days and couldn’t find anything similar there. No need for separate control items in zwave, so why in KNX ? (unless I have overlooked something here)

I do as well fully agree here…

Controlled: why should I do this? What is the benefit of the Paper UI vs. the app for mobile devices or the Basic UI?

Configured: again, why should I do this? In terms of KNX I have to do all the configuration mentioned by @juelicher anyway - where does the Paper UI brings the added value?

Don’t get me wrong: maybe I didn’t fully understand the value of the Paper UI but I made the experience that the file-based configuration is much more reliable than the Paper UI configuration.

What is required that the binding developers have a detailed look at this thread and consider the feedback seriously? With the current state of the binding a migration is no option at all for me.

Regards
John

Well, as noted before… you don’t need to migrate yet. In fact, knx1 will be available even in the next release (of course after activating legacy bindings).

But for the configuration, knx2 is exactly configured as any other OH2 binding.

But for the configuration, knx2 is exactly configured as any other OH2 binding.

Unification of the behavior is indeed a strong argument! On the other hand, a hammer should just be used for nails and not for screws :wink:

My main problem with this approach is the massiv amount of redundant information. I noticed that in other KNX2 bindings to, but could live with it as I do not have nearly as many items there as I have KNX items. Beside that, the things & items approach fits some systems better than other.

I forgot to mention this: The grouping of GAs according to KNX devices does not really match the KNX philosophy as the GAs are some sort of hardware abstraction too. A GA does not “belong” to s specific device, it is just a command send on the bus where all devices are listening and decide if they respond to a request send on a GA or not.

Not responding might have several reasons, e.g. the device is not configured or the current state of the system prohibits the action (e.g. blinds do not move when there is a wind alarm). Different devices may respond differently to the same command on the same GA, so there is no such thing as the “state of a GA”.

Well, as noted before… you don’t need to migrate yet. In fact, knx1 will be available even in the next release

There may not be an explicit need to migrate. But the KNX1 binding has quite some bugs when used with KNX2 where at least one is a real show stopper for me. Currently I have always a really bad feeling when leaving my home for some time because the automation stops every few weeks. As I have the feeling, that there will be no further work on the KNX1 binding (which I fully understand) there will be the need to migrate somewhere in the near future.

Hi Guys,
i really got into troubles and don’t know why. So to make the story short:

I’ve got successfully migrated to KNX2, everything worked well…
I’ve changed my Raspberry from Model 3 to 3+. This lead to a new IP address, which caused the KNX bridge to not working (because of the wrong IP configuration). I’ve changed this IP, restart… Well, i expected that it will work, but after 3 hours of angry debuging i’ve decided to purge OH2 and make a fresh install. Here we go, install bindings, restore files etc…
Now i’ve got all my defined items in the system except for all KNX items. I have no idea, it just does not recognize my Items… really strange… I’ve removed all my KNX items and just added one at the beginning of the file or at the end of the file. it just won’t recognize these items. Also in the console there is no mention of “reloading model …” Only if i change another item that was recognized then it shows this message.

The Bridge and the Device is online, so that works. If i add one of my thing as an item in PaperUI then it works. So it could only be an issue with the textual items and these look like this:

/* Aussen */
Switch Licht_Aussen_Carport			"Carport"	<garage>			(gAussen, Lights) [ "Lighting" ] { channel="knx:device:ipcontrol:generic:Licht_Aussen_Carport" }

My Things look like this:

Bridge knx:ip:ipcontrol [
    ipAddress="10.10.10.5", 
    portNumber=3671, 
    localIp="10.10.10.10", 
    type="TUNNEL", 
    readingPause=50, 
    responseTimeout=10, 
    readRetriesLimit=3, 
    autoReconnectPeriod=1,
    localSourceAddr="0.0.0"
] {
    Thing device generic [
    ] {
       
        Type switch         : Licht_Aussen_Carport       "Carport"       [ ga="2/2/0+<2/2/1" ]
        ...
    }
}

Has anyone an idea?

Cheers

this means that OH2 does not read that file
does it have the correct extension (*.items) ?
does it have proper permissions (can the user openhab read this file) ?
is it in the right subfolder (/etc/openhab2/items/) ?

Hi Dim, yes i did checked that. But if i change, lets say delete an existing, not KNX item within that same file it does recognize it as a change.
As said, really strange. It‘s like it ignores all my KNX items.

so: if you modify a line with an Item that is bound to KNX: the file is not processed? (no reloading model log entry?)

this is extremely strange… that shouldn’t happen. There is no filter on the item config from what I know. This simply… can’t happen :slight_smile: something else is wrong.

even if you had commented out (/* */) by mistake the lines containing Items bound to KNX configs: the file should be reloaded (since it suffers a change)

can you post the entire file content?

did you try to create a new *.items file and place there only 1 line (without any comment lines, etc) ?

Shouldn’t that be:

] {
Thing device generic {
Type switch : Licht_Aussen_Carport “Carport” [ ga=“2/2/0+<2/2/1” ]

}
}

I‘m sorry to have bothered you, but it turned out to be an SD card file error. There were some problems with this file. Maybe it was unable to save new content within that file but editing existing content was possible.
I have experienced the same file issue with a KODI installation on another RPi. I just deleted the file and created a new one. I guess my card is going to die.
Thanks anyway i appreciate.