OH2.3 with KNX2 - syntax of items not clear

Zaphood1967 · April 3, 2018, 3:52pm

Hm, interesting answer.

Still not sure why it needed to become more complicated AND needed to have a new syntax, f.e. why do DPT‘s now carry a name as a definition for a DPT? The sole purpose of DPT‘s is to clarify the exact function of the respective object…

Splitting the config into things and items, I understand that this „is the way it is in OH2“…but maybe this „thing concept“ is just a little bit over the top for Knx, as the system itself uses HA abstractions via GA‘s. So connections are now done by a GA, that connects to a thing that is part of an item…?

Udo_Hartmann · April 3, 2018, 7:16pm

Sorry, I don’t understand?

But please be aware that openHAB is not a knx system. openHAB is to integrate most of “smart” systems in one.
The thing “thing” is to allow autoconfiguration and autodiscovery for some smart systems. In fact, knx2 will provide “sort of autoconfiguration” by reading knxproj (from ETS5) in a future “advanced” version. So there will be no need to configure any thing for knx, and even item configuration will benefit, I think.

Zaphood1967 · April 5, 2018, 9:20pm

I was refering to this:

“upDown”, “stopMove” or “position” are names for DPT, whereas these functions are already defined by DPT themselves in KNX.

Agreed, but this should not mean that a binding needs to make things overly complicated, just to be “fully correct” in terms of the underlying technical concepts. Especially when it worked quite well (and relatively simple) in former versions.

BTW: KNX is no auto-discovery system. Even importing the project file would be no really “auto-discovery”, so one would anyway have to manually set and correct some things when using KNX. Again, keep it simple would reduce the possibility of human errors.

(btw: I recently heard in a podcast that the roots of OH where indeed in KNX…back in the days when Kai was looking for a system for his own home that was equipped with KNX… ;-))

Udo_Hartmann · April 5, 2018, 10:29pm

No!
stopMove is the parameter name which refers to the corresponding GA, as is upDown and position. There are channels which have no reference to a special type of DPT at all (only one parameter named ga - but of course there is always a default DPT which is used, as is for specifically named parameters). It’s possible to use different DPTs for the same parameter (for example position, DPT 5.x or 9.x).

Yes, there is no real auto discovery for knx, because knx does not provide the necessary information, but to import the ETS5 project, is a nice way to ease the openHAB configuration.

In fact, you do not need to switch to OH2, and you do not need to use knx2 either.
But if using knx2, well, you should accept that it’s (very) different to knx1.
Every openHAB2 binding uses things and channels as an abstraction layer, that’s the way eclipse smarthome works.

Zaphood1967 · April 6, 2018, 5:50am

Maybe I am using the wrong terminology (it’s a parameter, got it), but you essetially confirmed what I just said. It is still a naming that refers to some kind of default DPT = added abstraction & added complexity.

Lol, when the 1.x binding becomes a legacy one, it will be no longer be under development I’d guess. So in the mid-term, the KNX2 is not really just optional. Or are you saying I do not need to use OH at all, so I’d rather should go away? Hm

That is what my whole thinking is all about - If things are changed, they should change for the better / simpler, not for being more complicated.

But I get the underlying messsage here: Take it as it is, because it is like it is and it needs to be like it is because this is the new way. Full stop.

So i’ll refrain from making suggestions or giving feedback in the future, as this is obviously not wanted.

Thanks for your efforts Udo, appreciate the time you took to reply and have a great weekend !

Udo_Hartmann · April 6, 2018, 12:36pm

But it’s very different! Let’s compare to openHAB1/knx1:

Rollershutter ItemOfChannel1 "My roller shutter [%d %%]" {knx1="GA1,GA2,GA3"}

knx1 wants GA1 to be MOVE, GA2 to be STEP and GA3 to be Position.
If you don’t want to set GA2 at all, you can’t just omit the parameter, but you have to set the DPT for each following parameter (in this case 5.001:GA3). I’m not sure, if it’s even possible to change the order of the GA even when setting the DPT explicitly (and it’s the same for GA1 and GA2 anyway, so openHAB could not decide which is MOVE and which ist STEP)
Now in knx2 there is an explicit assignment for each parameter, so it’s not possible to mix them up anymore.

Type rollershutter : channel1 "My roller shutter" [upDown="GA1",stopMove="GA2",position="GA3"]

Yes, you have to type more characters, but this is way more readable than in knx1.
Yes, you have to link this channel to the item as an additional step, but with VSCode this is done with two klicks, and you could do it even without any textual configuration (Paper UI/HABmin/karaf/REST/…more to come).

Well, there are current bug fixes for other legacy bindings, and even new functionality, but to be honest, knx1 with openHAB2 is not as stable as it should be, and it’s not possible to change this without breaking knx in OH1, so, at least for knx you’re right nonetheless, OH1 is not end of life yet.

Well said… did you ever encounter such updates in ANY software?
Well, sometimes… but most of the time updates make things more complex, even for configuration, just because there are new possibilities.

When speaking of knx2, I see a more strict definition of channels, and it’s more clear where to put all those GA for the channels.
In question of -control channels, yes, it’s a pity that I have to define two items/channels for the very same thing, just to receive commands from the bus, but if that is the price to have a stable knx addon, I’ll bite the bullet, and to be honest, there is a difference between getting a rocker activity and the corresponding actuator state, so yes, one has to change old rules, but it’s correct and there’s not more complexity but only different triggers.

I didn’t want to be rude and I’m no developer but only end user, it’s my point of view. I’m an openHAB user since OH1.0.
I wasn’t pleased to see an additional layer (things), but in the end I did understand why this step was taken.
I’m pretty sure there will be no step back because openHAB2 is developed with eclipse smarthome, and eclipse smarthome is maintained not only by Kai, there are commercial products using (and developing) eclipse smarthome as well.
So yes, in the end it’s “Take it or leave it.” but please, don’t be offended. I don’t want to offend anyone!

Zaphood1967 · April 6, 2018, 4:26pm

Ok, again, I get your points and i am not offended at all It just sounded like you wanted to make it clear that I am on the wrong track and if I didn’t liked it i could go to a very hot place

I guess you are correct that almost any new software is the opposite of being less complicated than the old version. Maybe that is just what drives me so nuts, that everyone seems to prioritze technical aspects over usability (look at iOS, which lost the majority of it’s simplicity and elegance over the years and became fat, cluttered and sometimes really confusing).

So I will take the time and check the documentations, set up a test system and start to migrate everything to the new KNX2 binding within the next couple of weeks. Maybe while doing this I will eventually experience that “better concept” and “professionalism of that Binding” (which is something annother post called it)

Again, thanks for your time and have a great weekend!

JohnnyX · April 30, 2018, 7:21am

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.

Udo_Hartmann · April 30, 2018, 1:40pm

knx2 is capable to be controlled via Paper UI
knx2 is capable to be configured via Paper UI
There is a more strict definition for channels (as written in OH2.3 with KNX2 - syntax of items not clear - #19 by Udo_Hartmann)
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.

juelicher · April 30, 2018, 7:29pm

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…

Zaphood1967 · May 1, 2018, 7:35am

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…

JohnnyX · May 1, 2018, 8:59am

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

Udo_Hartmann · May 1, 2018, 12:54pm

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.

juelicher · May 1, 2018, 2:08pm

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

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.

saperlot · June 1, 2018, 9:29pm

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

Dim · June 1, 2018, 9:46pm

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/) ?

saperlot · June 2, 2018, 10:44am

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.

Dim · June 2, 2018, 6:38pm

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 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) ?

747driver · June 6, 2018, 3:39pm

Shouldn’t that be:

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

saperlot · June 6, 2018, 8:56pm

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.