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

Add-ons Bindings
,
1

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.ThingStatusInfoChangedEvent] - Thing 'knx:ip:pl12' changed from OFFLINE (COMMUNICATION_ERROR): server request to ONLINE

[...] all Things coming online one after another

This behaviour repeats througout the day and disappears after a reboot, just to re-occur after some days uptime. I do not recognize a pattern, sometimes there’s minutes in between the ONLINE - OFFLINE events, sometimes it’s an hour, but no more than two hours - until a reboot.

Is there something I can do?

my bridge (Weinzierl IP Interface 730)

UID: knx:ip:pl12
label: KNX/IP Gateway PL12
thingTypeUID: knx:ip
configuration:
  useNAT: false
  readRetriesLimit: 3
  ipAddress: 192.168.xx.xx
  localIp: 192.168.yy.yy
  autoReconnectPeriod: 60
  type: TUNNEL
  readingPause: 50
  localSourceAddr: 0.0.0
  portNumber: 3671
  responseTimeout: 10

I have “virtual” generic KNX devices for every location (mostly rooms) in my Model and they contain the channels:

UID: knx:device:pl12:964ac269f0
label: KNX KG Technikraum
thingTypeUID: knx:device
configuration:
  pingInterval: 0
  readInterval: 0
  fetch: false
bridgeUID: knx:ip:pl12
channels:
  - id: TechnikraumDL
    channelTypeUID: knx:switch
    label: Licht Technikraum
    description: null
    configuration:
      ga: 1.001:1/0/80+<1/0/83
...

here’s my OH3 environment

###############################################################################
###############  openHAB3  ####################################################
###############################################################################
##        Ip = 192.168.78.10
##   Release = Raspbian GNU/Linux 10 (buster)
##    Kernel = Linux 5.4.79-v7l+
##  Platform = Raspberry Pi 4 Model B Rev 1.1
##    Uptime = 10 day(s). 16:1:27
## CPU Usage = 7.59% avg over 4 cpu(s) (4 core(s) x 1 socket(s))
##  CPU Load = 1m: 1.47, 5m: 1.09, 15m: 0.98
##    Memory = Free: 2.45GB (65%), Used: 1.33GB (35%), Total: 3.78GB
##      Swap = Free: 1.66GB (100%), Used: 0.00GB (0%), Total: 1.66GB
##      Root = Free: 22.45GB (81%), Used: 5.13GB (19%), Total: 28.80GB
##   Updates = 0 apt updates available.
##  Sessions = 1 session(s)
## Processes = 128 running processes of 32768 maximum processes
###############################################################################

                          _   _     _     ____   _
  ___   ___   ___   ___  | | | |   / \   | __ ) (_)  ____   ___
 / _ \ / _ \ / _ \ / _ \ | |_| |  / _ \  |  _ \ | | / _  \ / _ \
| (_) | (_) |  __/| | | ||  _  | / ___ \ | |_) )| || (_) || | | |
 \___/|  __/ \___/|_| |_||_| |_|/_/   \_\|____/ |_| \__|_||_| | |
      |_|                          3.0.0 - Release Build
2

Dear Thomas,

I’m using an older KNX router (version 1.0) from MDT and always had trouble with it using the TUNNEL mode. So even under OH 2.x, I’ve only used it in ROUTER mode. You can see my configuration in this post:

openHAB 3.0 –> KNX. Don’t have channels, Post #24

But even with ROUTER mode and this specific Router, I still had troubles concerning *-control items. My experiences I also have described here:

KNX control item doesn’t respond to read request from the bus

3

my IP-Interface only works in TUNNEL mode. and if it’s running, it works (except for “Fetch”, see KNX and OH3: does "fetch" work with JIRA actuators?)

4

And for that I’ve drawn a conclusion, that maybe, just maybe, the KNX binding is not to blame here, because it does pretty basic IP communication.

My impression is that, the problem lies within the software implementation on the router side and that is a problem of lot’s of IoT devices. They simply must base their development on some kind of IP Stack and some kind of KNX Stack.

Sure, this doesn’t help, if you bought one and it doesn’t work.

5

KNX1 did work for years with OH2, though! :wink:
My 2cents are either on some kind of misconfiguration on my side or some buffer within the binding keeps overflowing…