[SOLVED] Knx gateway flapping (online/offline) and question about port 3671

[vanja (galaxy)]

Hi all, I have been playing with settings of knx binding because of those issues (instability) and I came across one very bizarre behavior of the binding. when I inspect my knxd daemon config, it is clearly visible it is configured to listen to TCP port 6720. Also verified (with telnet), the machine listens on 6720, but not listening at all at 3671 (connection refused).
However, openhab knx binding only likes the port 3671, if I configure it to 6720, gateway is offline (communication error). This is very strange, I dont know how it works with this configuration, it probably in the background goes to the correct port as that is the only logical explanation…

now the reason I’m asking, as I have these episodes of gateway going offline every few days, and it comes back online after a minute. I’m lucky that it auto-recovers, as other people have to restart openhab, or binding, or disable enable the things…there is scripts for rules doing this job circulating on the forum
I noticed many threads with this issues, and no solution…other then try ROUTER mode instead, which unfortunately does not work for me. knxd allegedly supports it, and things come online, but I cannot switch any device.
I have exhausted all attempts of playing with configuration, (define local source, dont define, timeouts, bla blah…) Basically I don’t expect any solution, just starting a discussion about possible causes.
People usually mention that on knx1 binding everything was perfect, and their problems started on knx2.

I Noticed it happens to people running openhab on:

• windows
• linux
• vm
• docker
• rpi, openhabian…

knx gateway can be:

• gira IP interface gateway
• mdt usb
• tpuart usb
• various other brands of IP or USB interfaces

knx ip gateway can be knxd daemon with USB knx interface running either on openhab host itself or a separate machine, standalone IP interface device…

all of these scenarios have the same issue - gets randomly disconnected.

then again, I am sure there is a lot of people with those scenarios that have no issues at all
I cannot find any common thing in all those cases
I think it also happens to both UI things and file based .things.

I noticed it’s mentioned maybe that its better to have a direct serial connection configured, so there is no IP gateway business. But I am not sure I can configure this with USB interface, I guess it should be TPUART, proper serial…

here are my configs just for reference
knxd

/usr/lib/knxd_args --eibaddr=0.0.1 --client-addrs=0.0.2:10 --error=0 --listen-tcp=6720 --Name=KNX2 --Routing --Tunnelling --Discovery --Server=224.0.23.12 --listen-local=/var/run/knxd --trace=0 -b usb:1:2:1

knx.things

Bridge knx:ip:bridge [
    ipAddress="192.168.4.1",
  //portNumber=6720,
    portNumber=3671,
    localIp="192.168.4.2",
    type="TUNNEL",
  //type="ROUTER",
    readingPause=50,
    responseTimeout=50,
    readRetriesLimit=3,
    autoReconnectPeriod=60,
    localSourceAddr="0.0.0"
] {
    Thing device generic  [
        fetch=false,
        pingInterval=300,
        readInterval=3600
    ] {
        Type switch        : Foyer             "Light"         [ ga="1/5/26+<1/5/27" ]
        Type switch        : Dining            "Light"         [ ga="1/5/33+<1/5/35" ]
        Type dimmer        : DiningDimmer      "Light"         [ position="5.001:1/5/36+<1/5/70" ] 
        Type switch        : Living            "Light"         [ ga="1/5/29+<1/5/31" ]
        Type dimmer        : LivingDimmer      "Light"         [ position="5.001:1/5/32+<1/5/69" ] 
        Type switch        : Entrance          "Light"         [ ga="1/5/24+<1/5/25" ]
        Type switch        : Corridor          "Light"         [ ga="1/5/20+<1/5/21" ]
        Type switch        : Balcony1          "Light"         [ ga="1/5/38+<1/5/39" ]
        Type switch        : Balcony2          "Light"         [ ga="1/5/6+<1/5/7"   ]  
        Type switch        : KidsEntrance      "Light"         [ ga="1/5/12+<1/5/13" ]
        Type switch        : KidsRoom          "Light"         [ ga="1/5/14+<1/5/16" ]
        Type dimmer        : KidsDimmer        "Light"         [ position="5.001:1/5/19+<1/5/68" ]
        Type switch        : Dressing          "Light"         [ ga="1/5/4+<1/5/5"   ]	      
        Type switch        : Bedroom           "Light"         [ ga="1/5/1+<1/5/3"   ]
        Type dimmer        : BedroomDimmer     "Light"         [ position="5.001:1/5/11+<1/5/67" ]
        Type number        : LivingTemp        "Temperature"   [ ga="9.001:<1/5/44"  ]
	Type number        : RoomsTemp         "Temperature"   [ ga="9.001:<1/5/55"  ]
        Type dimmer	   : ACLiving1         "Temperature"   [ position="5.001:1/5/48+<1/5/49" ]
	Type number	   : ACLiving2         "Temperature"   [ ga="9.001:<1/5/45+<1/5/53" ]
	Type switch	   : ACLiving3         "Switch"        [ ga="1/5/46+<1/5/47" ]
        Type number        : ACLiving4         "Temperature"   [ ga="9.001:<1/5/53"  ]    
        Type dimmer	   : ACRooms1          "Temperature"   [ position="5.001:1/5/59+<1/5/60" ]
	Type number        : ACRooms2          "Temperature"   [ ga="9.001:<1/5/56+<1/5/64" ]
        Type switch        : ACRooms3          "Switch"        [ ga="1/5/57+<1/5/58" ]
	Type number        : ACRooms4          "Temperature"   [ ga="9.001:<1/5/64"  ]
        Type number        : LivingOff         "Temperature"   [ ga="5.001:<1/5/22"  ]
        Type number        : CommonOff         "Temperature"   [ ga="5.001:<1/5/28"  ]
        Type number        : WelcomeOff        "Temperature"   [ ga="5.001:<1/5/50"  ]
        Type number        : HomeSleep         "Temperature"   [ ga="5.001:<1/5/43"  ]
          }
}

[Udo_Hartmann]

knxd can be a bit tricky

Maybe start with the default configuration:

/usr/lib/knxd_args --client-addrs=0.0.2:10 --Discovery --Tunnelling --Routing --Server --layer2=usb:1:2:1

This is:
knxd will use 0.0.1 as individual address for itself communicating with knx bus. (default)
It will allow up to 10 clients which will get individual addresses 0.0.2 to 0.0.12 (must not be used with any other knx hardware/software or knxd will crash)
The knxd Server will be discoverable, it will offer an EIBnet/IP tunneling interface at the local ip (Port 6720, default) and a router interface with multicast IP 224.0.23.12 and Port 3671 (default)
It will use an USB HID Mode knx Interface with Bus-ID 1.2.1
knxd will use /var/run/knxd as unix socket, it will use knxd as Server name.

Please be aware that you have to take the output to a configuration file which is then called when knxd is started.

Now to openHAB binding:
First, yes, knx1 was very stable on a OH1 installation, BUT it never was on a OH2 installation (trust me, I’m an openHAB user since OH1.0 )
knx1 had its own issues which you had to work around, and knx2 is very different to knx1. Thus, knx1 users had to adapt to new behavior.

If you want to use Router mode, just set the bridge like that:

Bridge knx:ip:bridge "knxd Router" [
    type="ROUTER",
    localIp="192.168.4.2" // this is the local IP of the openHAB system
]

but be aware that there may be some additional things to be done at ETS in question of filtering. Not sure how this is done, there is no documentation about filtering yet…

Please be aware that openHAB will always show the router interface as ONLINE, even if there is no Interface at all. This is due to Multicast and afaik there is no easy way to get around of this issue.

Almost the same settings for TUNNEL mode:

Bridge knx:ip:bridge "knxd Tunnel" [
    type="TUNNEL",
    ipAddress="192.168.4.2", // this is the local IP of the knxd system
    portNumber=6720,         // port which knxd tunnel is listening to
    localIp="192.168.4.2"    // this is the local IP of the openHAB system
]

You should not set any other parameter at all (don’t do it for default values)

If knxd is running on another hardware, fine, change ipAddress to this hardware IP address.
If it’s the same computer as openHAB (the same IP address) you also can use localhost or 127.0.0.1 as ipAddress (but NOT at localIp this has to be the real IP address of openHAB)

Now to the knx devices:
Please consider to use one thing per device, not just an one-for-all generic thing.
Although you can look at the whole knx bus as one big device, there are some drawbacks if doing so.
Instead, use multiple things and set the individual addresses (e.g. [ address="0.0.25" ]).

Please be aware that there is no such parameter as fetch or pingInterval for a generic knx device (i.e. no specific hardware with no specified individual address). The knx Binding will silently omit the parameter.
Plese be aware that readInterval is almost never needed and will increase communication on the knx bus (therefor, don’t use it by default)

You will end up with a list of things which represent your actual hardware, this is very close to the device list in ETS or the picture of your electrical cabinet.

[vanja (galaxy)]

@Udo_Hartmann

If you want to use Router mode, just set the bridge like that:

Bridge knx:ip:bridge "knxd Router" [
    type="ROUTER",
    localIp="192.168.4.2" // this is the local IP of the openHAB system
]

as mentioned, tried this, doesn’t work at all, i can get only tunnel mode working.

@Udo_Hartmann

Almost the same settings for TUNNEL mode:

Bridge knx:ip:bridge "knxd Tunnel" [
    type="TUNNEL",
    ipAddress="192.168.4.2", // this is the local IP of the knxd system
    portNumber=6720,         // port which knxd tunnel is listening to
    localIp="192.168.4.2"    // this is the local IP of the openHAB system
]

as mentioned, this config doesnt work.
but it works when setting port number to 3671
bizzare…

[stamate_viorel]

I still don’t understand your post. So you have an USB connected to the tp bus and then you use knxd (probably to have access to the bus from ets and openhab etc) and you are using tunnel to connect to knxd and you get random disconnects ?

It may be Knx binding has a bug and doesn’t take into consideration alternate ports but to be fair ets also uses the same port by default. Maybe file an complain and add also logs by putting the biding in debug mode.

As an workaround is there any specific reason as to why you need knxd to listen to that specific port ?

Also router mode you need to be sure about how your ets group adresses are passed along before attempting to connect, the old trick that I use is to put dummy devices.

Also stop putting all those defaults ask me why. And also local IP should be set in the network settings of openhab not in the binding.

[Udo_Hartmann]

depends on how you did your configuration (be aware that I only set the parameters which differ from default)

what’s the output of

systemctl status knxd.service

[vanja (galaxy)]

@stamate_viorel @Udo_Hartmann
I am running knxd on openwrt router, with usb interface connected to it.

these are the defaults of the service

/usr/lib/knxd_args --eibaddr=0.0.1 --client-addrs=0.0.2:10 --error=0 --listen-tcp=6720 --Name=KNX2 --Routing --Tunnelling --Discovery --Server=224.0.23.12 --listen-local=/var/run/knxd --trace=0 -b usb:1:2:1

6720 is the default TCP port
3671 is the default UDP port

but openhab knx binding does not care about that. it only wants you to set 3671 regardless if you set tunnel or router.
so I ended up configuring nothing and let it auto detect it or use internal defaults.

Bridge knx:ip:bridge [
    ipAddress="192.168.4.1",
    type="TUNNEL"
] {

it still goes offline at least once per day.

maybe I should install knxd on the rpi where openhab is running…

[stamate_viorel]

/usr/lib/knxd_args  --error=0 --Name=KNX2 --Discovery --Tunnelling --Routing --Server --listen-local=/var/run/knxd --trace=0 -b usb:1:2:1

Network interfaces
Local server
The -i or --listen-tcp option tells knxd to accept client connections on a specific IP. The -u or --listen-local option tells knxd to accept client connections on a Unix socket. You want one or both of these if you have client programs which specifically talk to knxd. This includes the tools, examples and language bindings which come with knxd.

Multicast server
The -S or --Server option starts a multicast server; the default is port 3671 on address 224.0.23.12. Most likely, you really want options -R -S or --Routing --Server so that knxd actually routes multicast data. This is the network mode ETS uses when you attach to an interface. Note that multicast packets get blocked by some WLAN APs.

Tunneling server
-T -S or --Tunnelling --Server starts a UDP-based server to which clients can connect. This is the network mode ETS uses if you attach to a specific host. Most likely, you really want -n HOSTNAME -D -T -R -S or --Name=HOSTNAME --Discovery --Tunnelling --Routing --Server.

Multicast client
The -b ip: option also connects to multicast; however, it just treats the multicast address like a glorified KNX wire with no bells and whistles. Use this if some other device (knxd or otherwise) provides the server features.

Some older and/or buggy WLAN gateways don't forward multicast data.

Non-Multicast client
Use -b ipt:your-knx-gateway or -b iptn:your-knx-gateway. depending on whether you need address translation.

Some older KNX/IP interfaces don't really work with this method. It's recommended to use multicast wherever possible.

Single-server mode
With the exception of multicast, technically a server is not an interface – it creates a new one for every connecting client. Thus, starting knxd -u or knxd -TS just to facilitate a couple of clients to talk to each other (i.e. not using any other interface option) makes sense – in theory. However, in actual practice this is a configuration error because it's almost never what you actually want. If you really intent to run knxd that way, you need to add a dummy interface.

[vanja (galaxy)]

yeah, it works so unstable, I guess it’s a bug in knx bundle, because the gateway (knxd) is working fine, listening to port, restart of knxd doesnt help, but restart of knx binding helps. all devices are on 100mbit wire, no wifi involved.
so I “solved” it with a rule, like many people before me:

rule "KNX Binding Restart"
when
    Thing "knx:ip:bridge" changed to OFFLINE
then
    executeCommandLine("sudo /usr/bin/ssh -p 8101 -i /home/pi/openhab.id_rsa openhab@localhost bundle:restart org.openhab.binding.knx", 6000)
end

[Udo_Hartmann]

@vanja

I guess it’s a bug in knx bundle

At least it’s no general bug, as knx here is working rock stable (since openHAB1.0 with only exceptions as openHAB2 came out and there was not knx2 binding yet)

[vanja (galaxy)]

Well, as I mentioned in my first post, its rock solid to most of the people, but there are cases of instability

Knx2 mentioned here

KNX2 stopps working after a while (received disconnect response status 0x21)

I solved it by programming a service restart every time it goes offline. I got the result by creating in my raspberry openhabian installation this sh file (install sshpass before with: apt-get install sshpass): // restartknx.sh sudo -u [YOUR_SYSTEM_USER] sshpass -p [YOUR_SYSTEM_PASSWORD] ssh openhab@localhost -p 8101 'bundle:restart org.openhab.binding.knx' and running it by this cron rule: rule "Restart KNX" when Time cron "0/10 * * ? * *" then val allThings = sendHttpGetRe…

Here

OH3: KNX binding a bit instable, multiple OFFLINE errors of bridge

Running KNX on openHAB3 since December now, and I’m experiencing multiple “Bridge OFFLINE”-errors occuring after a few days of uptime. Rebooting seems to solve the issue for some time, but it builds up from the feeling I get more and more. 2021-01-15 09:39:07.862 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'knx:ip:pl12' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): server request [...] all Things coming offline one after another 2021-01-15 09:40:07.894 [INFO ] [ab.event.Thi…

Also Here

Knx bridge randomly detached and not reconnected

Dear all Since lately my knx bridge disconnects sporadically. In the openhab.log I get following messages: 019-04-16 05:02:55.705 [INFO ] [.process.process 192.168.178.26:3671] - detached from 192.168.178.26:3671 2019-04-16 05:02:55.708 [INFO ] [calimero.link.192.168.178.26:3671 ] - link closed 2019-04-16 05:02:55.710 [INFO ] [o.device.process 192.168.178.26:3671] - detached from 192.168.178.26:3671 2019-04-16 05:02:55.713 [INFO ] [net/IP Tunneling 192.168.178.26:3671] - establish connection…

Here…

OH3: KNX binding a bit instable, multiple OFFLINE errors of bridge

Running KNX on openHAB3 since December now, and I’m experiencing multiple “Bridge OFFLINE”-errors occuring after a few days of uptime. Rebooting seems to solve the issue for some time, but it builds up from the feeling I get more and more. 2021-01-15 09:39:07.862 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'knx:ip:pl12' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): server request [...] all Things coming offline one after another 2021-01-15 09:40:07.894 [INFO ] [ab.event.Thi…

[stamate_viorel]

Did you try the knxd configuration that I proposed ? Also keep in mind tunnel is unicast and router is multicast maybe your networking is playing tricks on you ?
It’s pretty easy to blame openhab sometimes but keep in mind the people that developed this spend a lot of time on it and Knox is one of the oldest binding.

[vanja (galaxy)]

the implementation of knxd on openwrt is strange, it has /etc/knxd.ini that it completely ignores and starts with whatever settings it wants.
I will install knxd on raspbian where oh is running and run your proposed config from there. on debian i hope i will be able to edit knxd.ini or knxd.conf and define the start options that i want…thanks for your help

[stamate_viorel]

You can also search Calimero knx that is what the binding is using. As a side note the knxd package hasn’t been maintained in openwrt for 4 years…
But why don’t use the knx binding directly in openhab seeing you can move the USB ?
https://www.openhab.org/addons/bindings/knx/#serial-gateway

[vanja (galaxy)]

I was thinking i need a real serial TPUART device to use the serial-gateway with the binding, but if it works with usb crap, i will most definitely give it a go, as I dont really need to route it through the network, the devices are next to each other.

the version i’m running
[OpenWrt Wiki] package: knxd
is from 2022 ( 0.14.53)
actually when I installed knxd on rpi buster, it took from buster repository 0.14.30
so router is more up to date then my rpi

[stamate_viorel]

What usb are you using ??? That connects to the bus without it ??

[vanja (galaxy)]

i use some usb interface, and as I understood TPUART is better then usb because it behaves as serial port, but I may be mistaken…

[stamate_viorel]

Just for my knowledge do you have a model ?

[vanja (galaxy)]

its ESYLUX
EC10430541 - ESYLUX

[stamate_viorel]

For a second you got me but KNX USB interface uses a TPUART (Twisted Pair Universal Asynchronous Receiver-Transmitter) to communicate with KNX devices on the bus so your included that is why I was curious. Try directly to use the serial connection of openhab and post the result.

[vanja (galaxy)]

but my device is just a USB device, it does not create /dev/ttyXXX…

The subnet connection type is one of
{ “ip”, “knxip”, “ft12”, “usb”, “tpuart”, “user-supplied”, “virtual”, “emulate” }.

The KNX communication medium is one of
{ “tp1” (default), “pl110”, “knxip”, “rf” }.

so the communication medium is twisted pair, but device type can be usb, uart, ip…
…and mine is unfortunately usb.
I would love to try it, but I dont see how…I’m trying to force the udev rules to create a symlink as dev/ttySomething for this crappy device, but it doesnt create it…

what i’m saying is my device is not usb-to-serial, its just pure usb device