OH2.3 with KNX2 - syntax of items not clear

Add-ons Bindings
1

Hi!

I luckily found the KNX2 binding for OH2.3 at
https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/binding/org.openhab.binding.knx/2.3.0-SNAPSHOT/

I managed to install and see this binding running - but what is the syntax of the items?

The Thing is listed as: “knx:ip:ca82718b”

I tried my switch as:
Switch eg_gast_licht_ea “EG Licht Buero” (gLicht,gEG) {channel=“knx:ip:ca82718b:3_0_0”}

The log is showing no error …

But how to connect the item to the correct channel?
Any hint ??

Thanks
Michael

2

Meanwhile I managed to create the THING via file:

Bridge knx:ip:ip1 [ ipAddress="192.168.1.87", portNumber=3671, localIp="192.168.1.129", type="TUNNEL", readingPause=50, responseTimeout=10, readRetriesLimit=3, autoReconnectPeriod=1,localSourceAddr="1.1.10", knxProj=""] {
    Thing generic someactor {
        Type statusswitch :  someswitch [ switchGA="3/0/0", statusGA="3/0/2", read=true, interval=3600]
    }
}

But I am still not able to switch …
Any hint where the knxproj shall be placed ?

3

How did you find the jar? I’m pretty sure the version is from knx2 basic binding (see https://github.com/openhab/openhab2-addons/pull/2323) which afaik does not support knxproj as input.

4

Please check your channel definitions:

If you are using the jar from knx2 basic binding as @Udo_Hartmann said, then your channel config is not valid. E.g. “switchGA=” is not a valid channel parameter. So try just “ga=” for example for your switch :wink:

5

Hi all,

thanks for your help !! I made some progess.
Please allow me to bother- as I am not still able to connect fully to the knx.

My knx.things

Bridge knx:ip:bridge [ 
    ipAddress="192.168.1.85", 
    portNumber=3671, 
    localIp="192.168.1.129", 
    type="TUNNEL",  
    readingPause=50, 
    responseTimeout=10, 
    readRetriesLimit=3, 
    autoReconnectPeriod=1,
    localSourceAddr="0.0.0"
] {
    Thing device generic [
        address="1.1.10",
        fetch=true,
        pingInterval=300,
        readInterval=3600
    ] {
        Type switch        : kg_buero_licht_ea        "KG Büro Schreibtisch"       [ ga="9/0/0+<9/0/1" ]
/*        
        Type rollershutter : demoRollershutter "Shade"       [ upDown="4/3/50+4/3/51", stopMove="4/3/52+4/3/53", position="4/3/54+<4/3/55" ]
        Type contact       : demoContact       "Door"        [ ga="1.019:<5/1/2" ]
        Type number        : demoTemperature   "Temperature" [ ga="9.001:<5/0/0" ]
        Type dimmer        : demoDimmer        "Dimmer"      [ switch="5/0/0+<5/0/1", position="5/0/2+<5/0/3", increaseDecrease="5/0/4" ]
        Type string        : demoString        "Message"     [ ga="5/3/1" ]
        Type datetime      : demoDatetime      "Alarm"       [ ga="5/5/42" ]
*/        
    }
}

My knx.items:

Switch kg_buero_licht_ea	"KG Büro Schreibtisch [%s]" 	<light>	(gLicht,gKG) { channel="knx:device:bridge:generic:kg_buero_licht_ea" }

The log shows:

    >     > 2018-03-10 11:50:19.610 [hingStatusInfoChangedEvent] - 'knx:ip:bridge' changed from ONLINE to OFFLINE
    >     > 2018-03-10 11:50:19.614 [hingStatusInfoChangedEvent] - 'knx:device:bridge:generic' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)
    >     > 2018-03-10 11:50:19.618 [hingStatusInfoChangedEvent] - 'knx:ip:bridge' changed from ONLINE to UNKNOWN
    >     > 2018-03-10 11:50:19.624 [me.event.ThingUpdatedEvent] - Thing 'knx:ip:bridge' has been updated.
    >     > 2018-03-10 11:50:19.629 [me.event.ThingUpdatedEvent] - Thing 'knx:device:bridge:generic' has been updated.
    >     > 2018-03-10 11:50:19.653 [hingStatusInfoChangedEvent] - 'knx:ip:bridge' changed from UNKNOWN to ONLINE
    >     > 2018-03-10 11:50:19.655 [hingStatusInfoChangedEvent] - 'knx:device:bridge:generic' changed from OFFLINE (BRIDGE_OFFLINE) to UNKNOWN
    >     > 2018-03-10 11:50:22.896 [hingStatusInfoChangedEvent] - 'knx:device:bridge:generic' changed from UNKNOWN to ONLINE

… In the PaperUI I can see the KNX Device and the KNX/IP Gateway - both are running. I can see the Switch item …

But still no connection to the bus. I think the localSourceAddr and the address (Address @ knx) of the Thing are not correct - but only this combination was showing that Device and Gateway were online.

Any suggestion, what I am doing wrong?
Thanks
Michael

6

Hi all,

any thoughts how to debug the situation?

ANY help would be appreciated
Michael

7

I can’t really help you as I am trying to figure it out myself at the moment but there was something about the sourceaddress and so on recently on the github-thread here. Maybe you can get some helpful information there.

8

To debug KNX2, return this at openhub console:

log:set TRACE org.openhab.binding.knx

To debug calimero, return this at openhub console:

log:set TRACE calimero

If you get too much logs, instead of TRACE use INFO, WARN, DEBUG, TRACE.

9

Hi all,

thanks for the great support !!

I see in the log that the knx bus is monitored.
When I switch the device in paper ui the trace shows:

 Value 'ON' could not be sent to the KNX bus using datapoint 'command DP 12/0/3 'knx:ip:bridge', DPT id 1.001, low priority': no confirmation reply received for 1.1.99->12/0/3 L_Data.req, low priority hop count 6 repeat, tpdu 00 81. Giving up now.

I followed lewie´s advice (on github!) how to configure the address for the hardware
The knx device remains offline.

… any hint ?
Thanks MICHAEL

10

Update: It seams my gateway refused the connection as all connections were in use … i am investigating!

11

Hi all,

here my learnings - thanks to the team supporting me:

The syntax description within the thing must show per device a new block and an individual device name. Each device points directly to the device on the bus with the KNX address. --> This leads to a high number of devices in the configuration->Things.
Syntax within the Bridge:
Thing device my1stDevice [] {} Thing device my2ndDevice [] {} …

Sidenote: My Devices are still “offline” in paperUI - but functional

Michael

12

Looking at the syntax provided, I am really scratching my head where the progess and advantages are with this new binding. Configuration looks to me way more complicated than the syntax of the 1.x binding, so what would be the users benefit here?

13

First of all: It’s the OH2 way of configuration. :slight_smile:
There is an explicit hardware abstraction. This is done through the things.
Items do only refer to a thing channel (or sometimes more than one).
If all is set up in a proper way, and assumed that the hardware provides the functions, you can get more information about the hardware devices.

When using VSCode, to generate an item from a thing channel is two clicks (!) and if you organized the channels in things, you can generate all items for a thing by two clicks, so it’s not so much harder.
But if you don’t want to use textual configuration, it’s now possible and easy to do in the OH2 way of configuration, whether to use Paper UI, HABmin, REST or even karaf.

14

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

15

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.

16

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… ;-))

17

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.

18

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 :thinking:

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. :joy:

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

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

19

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 :wink: 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 :slight_smile: 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!

20

Ok, again, I get your points and i am not offended at all :slight_smile: 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 :wink:

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) :joy:

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