Openhab 3 - KNX binding (Raspberry Pi with KNXD and Openhab3)

[Clover4x4 (Yarne Klaver)]

hi all,

A few years back I already made my KNX system work with openhab on my Raspberry Pi with KNXD. Back than I already had to use a very strange setup.

[SOLVED] OpenHab2 KNX-usb Binding Issue

Pid: org.openhab.knx BundleLocation: mvn:org.openhab.binding/org.openhab.binding.knx/1.9.0 Properties: busaddr = 1.1.128 ignorelocalevents = true ip = 224.0.23.12 localIp = 192.168.1.10 port = 3671 service.pid = org.openhab.knx type = TUNNEL

A few days ago i installed OH3 but now i’m not able to connect OH3 to my knx system anymore.
First: my installation proces:

1. Installed clean raspbian OS
2. Gave pi static ip

[Match]
Name=eth0
[Network]
Address=192.168.178.2/24
Gateway=192.168.178.1
DNS=192.168.178.1
[Route]
Destination=224.0.23.12/32

3. installed KNXD

via Raspberry Pi: EIB/KNX IP Gateway and Router with knxd

made is USB backend (/etc/default/knxd)
K NXD_OPTIONS="--eibaddr=1.1.128 --client-addrs=1.1.129:8 -d -D -T -R -S -i --listen-local=/tmp/knx -b usb:

I think so far so good:
root@raspberrypi:~# ps ax|grep knxd
882 ? Ssl 0:00 /usr/local/bin/knxd -p /run/knxd/knxd.pid --eibaddr=1.1.128 --client-addrs=1.1.129:8 -d -D -T -R -S -i --listen-local=/tmp/knx -b usb:
12857 pts/9 S+ 0:00 grep knxd

I’m able to toggle my lights via the terminal:
knxtool groupswrite ip:localhost 7/0/0 1

----------------- OPENHAB 3 install --------------------

openHAB on Linux

All worked great.

Next made a binding: knx.things

Bridge knx:ip:bridge [  
    type="ROUTER", 
    ipAddress="224.0.23.12", 
    portNumber=3671, 
    localIp="192.168.178.2",
    readingPause=50, 
    responseTimeout=10, 
    readRetriesLimit=3, 
    autoReconnectPeriod=60,
    localSourceAddr="1.1.128"
    ] {
        Type switch        : demoSwitch        "Licht OH3things ROUTER"       [ ga="1.001:7/0/0" ]
        Type switch        : demoSwitch2        "Licht3 OH3things ROUTER"       [ ga="1.001:<7/0/0" ]
        Type switch        : demoSwitch3        "Licht3 OH3things ROUTER"       [ ga="<7/0/0" ]
        Type switch        : demoSwitch4        "Licht4 OH3things ROUTER"       [ ga="7/0/0" ]
    }

(i made different switches to find out what adress format worked)

This bridge shows up in things as “Online”

Made knx.items:

Switch        demoSwitch         "Light_ITEMs_OH3 [%s]"               <light>          { channel="knx:device:bridge:generic:demoSwitch" }
Switch        demoSwitch2         "Light_ITEMs_OH3 2 [%s]"               <light>          { channel="knx:device:bridge:generic:demoSwitch2" }
Switch        demoSwitch3         "Light_ITEMs_OH3 3[%s]"               <light>          { channel="knx:device:bridge:generic:demoSwitch3" }
Switch        demoSwitch4        "Light_ITEMs_OH3 4[%s]"               <light>          { channel="knx:device:bridge:generic:demoSwitch4" }

Made a sitemap;

sitemap knx label="KNX Demo Sitemap" {
Frame label="Demo Elements" {
Switch item=demoSwitch
Switch item=demoSwitch2
Switch item=demoSwitch3
Switch item=demoSwitch4
}                
}

However, i’m not able to control my lights

Can anyone help me finding the mistake i’m making?

Kind regards,
Yarn

[michi (Michael Geramb)]

I have the same issue. If I use the router mode with the knxd, reading from KNX bus works fine, writing to the KNX bus does not work. Writing with the knxtool works fine and also my OH2 installation works fine with the same knxd instance. So the problem seems to be related to OH3 somehow.

If I use the tunnel mode and connect directly to my MDT interface SCN-IP000.03, write works but very delayed and I got a lot of these errors:

2021-01-03 17:28:06.112 [WARN ] [NXnet/IP Tunneling 192.168.0.99:3671] - response timeout waiting for confirmation
tuwien.auto.calimero.KNXTimeoutException: no confirmation reply received for 1.1.3->5/2/1 L_Data.req, low priority hop count 6 repeat, tpdu 00 00
	at tuwien.auto.calimero.knxnetip.ClientConnection.doExtraBlockingModes(ClientConnection.java:244) [bundleFile:?]

Any ideas?

[michi (Michael Geramb)]

@Clover4x4 I’am using the 64 bit version of the Rasperry PI OS. You too?

[Clover4x4 (Yarne Klaver)]

I’m using 32 bit
Still not managed to get it up and running

[michi (Michael Geramb)]

I have tested now a while with my two rasperry pi’s.

1. is running 32 bit with OH 2.5
2. is running 64 bit with OH 3.0

• If I start knxd on the 1), OH 2.5 and OH 3.0 is working fine with the knx binding in the router mode
• If I start knxd on the 2), OH 2.5 is working fine, OH 3.0 can only read from the knx bus

So what I know for now is, that knx itself and OH 3.0 seem to be ok. But the write commands to the knxd on the same machine are not working, it seems that the routing of the UDP packages to the local running knxd is not working. Very strange, no idea how to solve this problem.

[michi (Michael Geramb)]

Sorry, I’am wrong, also running the knxd on another computer does not work correct. In this case, writing to knx is working, but reading does only work, if the GA is set with the knxtool. If the change come from knx, OH3 does not receive it.

[bob1 (Bob Bobbins)]

Hi @michi @Clover4x4

Did you manage to resolve this? I have the same/similar problem.

BasicUI can read from the bus, but not write.
PageUI can write to the bus but not read.

Latest stable version OH3 and KNXD running Debian Buster on a Pi3

Scenario 1
knxd in ROUTER mode.

1. knxtools is able to read/write from the knx bus
2. Using BasicUI, OH Sitemap controls do not dynamically update their value but a browser refresh does set them to the correct value.
3. Using BasicUI, OH Sitemap controls cannot write to the bus.
4. Using PageUI. PageUI controls cannot read or write to the bus.

Scenario 2
knxd in TUNNEL mode.

1. knxtools is able to read/write from the knx bus
2. Using BasicUI, OH Sitemap controls do not dynamically update their value but a browser refresh does set them to the correct value.
3. Using BasicUI, OH Sitemap controls cannot write to the bus.
4. Using PageUI. PageUI controls cannot read but can write to the bus.

Any help much appreciated.

[FoxWhiskey (Bernie)]

Hi there,

I haven’t tested with the UIs yet, but I noticed, that switches and controls on the item views do not work reliably. The malfunction got worse the more “knx-things” I created (each actuator is represented by a thing, with all required channels added to it).
I have been using OH2.4 for years and did only have negligible problems with OH reading/writing to the KNX-bus via knxd (0.14.8).
I’m certainly not an expert in software development, yet I have a suspicion that there is a connection between a bug in knxd and the way the OH3 KNX-binding reacts to it.

I’m curious if the problem still exists! If not, what was your solution? And what version of knxd have you been using?
If yes, are there any error messages in the syslog (knxd-related)?
Do your knx-things change their state from online to err:bridge at times?

Best regards,
-bernie

[yazuna (Chris)]

Hello,
Have a similar problem with the OH 3.4.0.
knxd is working fine with ETS5 and knx utils with RPi A + (KNX HAT)[KNX Raspberry Pi HAT | Hackaday.io]

The knxd params:

--eibaddr=1.1.12 -E 1.1.1:5 -n RPihat -D -T -R -S -i --layer2=tpuarts:/dev/ttyKNX1

I am able to create both the tunnel and router gateways, but it is impossible to create a working device on either of them: they are both marked as offline and do not send messages to the bus, nor show any living signs:

What could be the reason? I could not see any errors in the OH logs.

Would appreciate any hints!
Chris

[schorbi]

Hello,

any solution for this behavior?

[stamate_viorel]

Please do give more details about what is not working by using knxd?
Do you have an possibility to use the build in openhab Calimero as an alternative to knxd?
Or better yet is it a possibility to buy a knxd router ?

[Filip_Ysenbaert]

Hi all,

I am using Openhab for many years on a Pi and is working well connecting directly to a KNX/IP gateway in tunneling mode along with lots of other bindings. It works fine and can use knx devices in rules, via GUI and REST without issues.

However, sometimes, in combinations with other devices (such as Hue) the KNX synchronisation is lost on protocol level. See below a post of 2017 which is still not solved. Update the bindings didn’t help nor installing new versions. As a workaround, I made a rule to detect & notify when the issue happens by checking the loggings on a regular basis. In case there is a mismatch, I generate some dummy traffic on the KNX bus to restore the synchronization faster (cycling 255 times to get the sync realized).

Is there any advantage of using KNXD ? Would the sync issue be solved ?

KNX Binding: tunneling request with invalid rcv-seq - sporadic dysfunction - help needed

Hi Stefan, George, I have exactly the same issue and would appreciate your help in finding a solution. I am using a Siemens IP interface N148/22 (no router). At first everything works fine, but after a while there is a sync issue. The cause is not really known. I also updated manually my KNX binding from 1.10 to the latest version of the KNX binding (version 1.11.0.201708271339) but seemly the issue remains. Here is a typical extract: 2017-11-26 18:04:56.462 [WARN ] [tuwie…

Best regards,
Filip

[stamate_viorel]

Hello
Knx openhab config files network topology and ets topology please. Most likely when of them has some kind of influence toward your problem.
In order for someone to help you – help them also.

[Filip_Ysenbaert]

Thanks for your reply!

Here is additional information which I hope somebody will be able to help me find the cause.

My topology is as follows: KNX twisted pair with actors (lights, blinds, sockets, rollershutters,…) and sensors (switches, sensors,…) and configured via ETS. There is 1 IP KNX IP interface on the local network connected to a RaspBerry PI 3 where openHab runs. Several bindings are active, configured and running well.

OpenHAB is mainly configured via files and uses standard values for the KNX binding. The only parameter which I changed is the KNX configuration is the readRetriesLimit, which has been set to 1 instead of 3. It limits the time to sync again.

Things file is as follows:

/* === THINGS === */
Bridge knx:ip:bridge [ 
    type="TUNNEL",
    ipAddress="XXX.XXX.XXX.XXX",
    portNumber=3671,
    autoReconnectPeriod=60,
	readingPause=20,
	readRetriesLimit=1 
] { // 6f-Schaltaktor 
    Thing device M1  "M1" @ "KNX" [ address="1.1.1" ] 
    {   Type switch :            LGF_Toilet             "Toilet"              [ ga="0/0/12+<0/1/12" ]
        Type switch :            LGF_Hall_Wall          "Hall"                [ ga="0/0/8+<0/1/8" ]
        Type switch :            LGF_Office             "Office"              [ ga="0/0/3+<0/1/3" ]
        ...
    }

An example item is as follows:

Switch        LGF_Toilet           "Toilet [%s]"                   <Light>          (GF_Toilet ,gLight)              ["Lightbulb"]        { ga="Light", channel="knx:device:bridge:M1:LGF_Toilet" }

Everything works fine however out of nothing, without any preceding event I get a invalid rcv-seq
which is 1 higher than expected. I tried to figure out what the event could be, but haven’t found it
Extract from the event.log file

2023-09-30 17:01:50.172 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'DoorTemperature' changed from 24.94 to 24.37
2023-09-30 17:02:31.985 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Current_DateTime' changed from 2023-09-30T17:01:31.974+0200 to 2023-09-30T17:02:31.977+0200
2023-09-30 17:03:00.599 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Socket_2' received command OFF

Extract of the openhab.log file:

2023-09-30 17:02:57.027 [WARN ] [Xnet/IP Tunneling XXX.XXX.XXX.XXX:3671] - tunneling request with invalid rcv-seq 7, expected 6
2023-09-30 17:02:58.027 [WARN ] [Xnet/IP Tunneling XXX.XXX.XXX.XXX:3671] - tunneling request with invalid rcv-seq 7, expected 6
2023-09-30 17:03:00.013 [WARN ] [Xnet/IP Tunneling XXX.XXX.XXX.XXX:3671] - response timeout waiting for confirmation
tuwien.auto.calimero.KNXTimeoutException: no confirmation reply received for 0.0.0->1.1.2 L_Data.req, system priority hop count 6 repeat, tpdu 80

The counter rcv-seq increases each time, the expected remains fixed. The address 1.1.2 above is a status request of a rollershutter, but doesn’t matter and can be anything else. Once the damage is done it continues (look to the time and counters):

2023-09-30 17:11:55.715 [WARN ] [Xnet/IP Tunneling XXX.XXX.XXX.XXX:3671] - tunneling request with invalid rcv-seq 193, expected 6
2023-09-30 17:11:56.715 [WARN ] [Xnet/IP Tunneling XXX.XXX.XXX.XXX:3671] - tunneling request with invalid rcv-seq 193, expected 6
2023-09-30 17:11:58.699 [WARN ] [Xnet/IP Tunneling XXX.XXX.XXX.XXX:3671] - response timeout waiting for confirmation
tuwien.auto.calimero.KNXTimeoutException: no confirmation reply received for 0.0.0->3/0/1 L_Data.req, low priority hop count 6 repeat, tpdu 00 80

As a workaround, as this issue is already there since OpenHAB 1.8, I wrote a rule to speed up the synchronization, because each command increases the rcv-seq.
The rule checks the event of “invalid rcv-seq” in the log file, sends extra commands to a socket (send OFF) - here addr 3/0/1 till the sync is done. See also event.log extract above ‘Socket_2’

2023-09-30 17:15:04.517 [WARN ] [Xnet/IP Tunneling XXX.XXX.XXX.XXX:3671] - tunneling request with invalid rcv-seq 3, expected 6
2023-09-30 17:15:05.517 [WARN ] [Xnet/IP Tunneling XXX.XXX.XXX.XXX:3671] - tunneling request with invalid rcv-seq 3, expected 6
2023-09-30 17:15:05.563 [INFO ] [rg.openhab.core.model.script.KNXSync] - Not in sync yet! nb1 = 5.0 nb2 = 6.0
2023-09-30 17:15:07.501 [WARN ] [Xnet/IP Tunneling XXX.XXX.XXX.XXX:3671] - response timeout waiting for confirmation
tuwien.auto.calimero.KNXTimeoutException: no confirmation reply received for 0.0.0->3/0/1 L_Data.req, low priority hop count 6 repeat, tpdu 00 80

It takes about 15 minutes to restore the sync.

The issue happens about once or twice a day. I receive a notification via the rule when it happens.
I guess it is not related to the stability of the network nor the stability of the IP interface device. Some years ago I used OpenRemote where the issue was not there. Also with ETS configuration & monitoring I don’t have any issues.

If you have any idea what I can do next, it would be very appreciated!

Thanks!

Filip

[stamate_viorel]

I had issues like this everything worked great on knx but in openhab I got a lot of errors like that and by trial and error I found out it was some settings in my unifi network. Do you have some fancy networking in your setup ?

[Filip_Ysenbaert]

Not that I know. I do have some bridges (e.g. Hue, Velux) and other stuff in my network, however the issue was already before the installations of those. How can I check the unifi network?
What kind of setting did you change in your unifi network to get it solved?

[stamate_viorel]

see first if igmp proxy or igmp snooping are enabled(try disable or enable and check the difference in the logs of openhab). if not then more information about your network topology. There is no general config or settings it all depends. what you can also do is take the knx ip and a dumb switch that connects directly to openhab and see after some time for errors if nothing then you are sure its going to be something within unifi. Search the internet about unicast and unifi and read about it.

[Filip_Ysenbaert]

Thanks for the hints Viorel ! Really appreciate it.
Will investigate further once I have a bit more time to look into it