did you try to use Routing mode also for knx.cfg?
I don’t use Tunneling in my system but I don’t think that using up 2 separate IAs it’s a correct setup…
post here the contents of the following 2 files:
/etc/openhab2/services/knx.cfg
/var/lib/openhab2/config/org/openhab/knx.config
I’m pretty sure that this picture is the result of a hickup in openHAB knx connection.
knx looses connection and does a reconnect. The gateway/router has an open connection and gets another connect request -> two bound tunnels.
After a while the first tunnel will be dropped, because it’s stale. But maybe openHAB will open even more connections under special circumstances? In openHAB log you should see a reconnect.
@Anton_Wedemeier: Thank you very much for providing your KNX binding. Will try this out first thing when I have time for (Wednesday I guess).
Just noticed that yours is “…1.9.0.jar” whereas mine is version 1.11.0 according to the following screenshot taken from Karaf console. I installed my binding using the PaperUI. Not sure but probably that’s the reason why even replacing the Calimero.jar didn’t work for me
@Udo_Hartmann I guess thats true. There have been quite few reconnects (i.eg. one post above), and after running for a while, the second tunnel was no longer listed on the routers web-interface.
Still need to investigate why connection is lost…
@Dim no, did not try Routing yet.
Simply because I had an interface for tunneling connection before (…) I want to know if it was indeed related to the interface or if TUNNELING is the problem.
Background: two of my friends are currently planning their (smart) home and are asking for my experience. If OH2 KNX can handle both, TUNNELING and ROUTER, I don’t see a reason for spending €150 more for same level of function.
Will post my config by the end of the day. Thanks for your care!
/etc/openhab2/services/knx.cfg
# KNX gateway IP address (optional, if serialPort or connection type 'ROUTER' i$
ip=192.168.0.22
# Local KNX Binding bus address.
# Use it, when two or more openHAB Instances are connected to the same KNX bus.
# (optional, defaults to 0.0.0)
busaddr=1.1.51
# Ignore local KNX Events, prevents internal events coming from
# 'openHAB event bus' a second time to be sent back to the 'openHAB event bus'.
# Note: To send back events second time is a Bug, but for backward compatibilit$
# For new installations, its recommend to set "ignorelocalevents=true"
# (optional, defaults to false)
ignorelocalevents=true
# KNX IP connection type. Could be either TUNNEL or ROUTER (optional, defaults $
# Note: If you cannot get the ROUTER mode working (even if it claims it is conn$
# use TUNNEL mode instead with setting both the ip of the KNX gateway and the l$
type=TUNNEL
# KNX gateway port (optional, defaults to 3671)
# Note: If you use eibd, setting to 6720
#port=
# Local endpoint to specify the multicast interface, no port is used (optional)
#localIp=192.168.0.210
# Serial port of FT1.2 KNX interface (ignored, if ip is specified)
# Valid values are e.g. COM1 for Windows and /dev/ttyS0 or /dev/ttyUSB0 for Lin$
#serialPort=
# Pause in milliseconds between two read requests on the KNX bus during
# initialization (optional, defaults to 50)
#pause=
# Timeout in milliseconds to wait for a response from the KNX bus (optional,
# defaults to 10000)
#timeout
# Number of read retries while initialization items from the KNX bus (optional,
# defaults to 3)
#readRetries
# Seconds between connect retries when KNX link has been lost
# 0 means never retry, it will only reconnect on next write or read request
# Note: without periodic retries all events will be lost up to the next read/wr$
# request
# (optional, default is 0)
autoReconnectPeriod=30
### Auto refresh feature
# Number of entries permissible in the item refresher queue.
# (optional, defaults to 10000)
#maxRefreshQueueEntries=
# Number of parallel threads for refreshing items. (optional, defaults to 5)
#numberOfThreads=
# Seconds to wait for an orderly shutdown of the auto refresher's
# ScheduledExecutorService. (optional, defaults to 5)
#scheduledExecutorServiceShutdownTimeoutString=
# Use NAT (Network Address Translation)
# (optional; defaults to false)
#useNAT=true
/var/lib/openhab2/config/org/openhab/knx.config
autoReconnectPeriod="30"
busaddr="1.1.51"
ignorelocalevents="true"
ip="192.168.0.22"
localIp="192.168.0.210"
service.pid="org.openhab.knx"
type="TUNNEL"looks good. nothing wrong with your knx.cfg & knx.config files.
I don’t know what could be the root-cause for this behaviour that you are experiencing (double tunnels to the KNX/IP device from the binding)… (maybe networking stability? change UTP cables, ports on the switch, etc)
I would try Routing to see if it works smoothly and then try to troubleshoot further the Tunneling mode.
Another thing that you can try while on Tunnel mode is: Set busaddr=1.1.50 (the first one that the MDT provides) and/or set it to 0.0.0 (don’t use 1.1.51)
changed to router. What might be the issue now? 
…/lib/openhab2/config/org/openhab/knx.config
autoReconnectPeriod=“30”
ignorelocalevents=“true”
localIp=“224.0.23.12”
service.pid=“org.openhab.knx”
type=“ROUTER”
log shows:
2018-02-23 16:21:31.145 [INFO ] [nx.internal.connection.KNXConnection] - Established connection to KNX bus on 224.0.23.12:3671 in mode ROUTER.
2018-02-23 16:21:31.166 [INFO ] [panel.internal.HABPanelDashboardTile] - Started HABPanel at /habpanel
2018-02-23 16:21:41.158 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Cannot read value for item ‘N_WZ_Temperatur’ from KNX bus: timeout waiting for group read response: timeout
2018-02-23 16:21:41.159 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Remaining retries for address ‘1/5/50’ = ‘2’
no connection to the KNX bus at all.
also replaced the ethernet cable and connected it to another port of the switch.
I never got a “ROUTER” connection working. But I am not a specialist.
I send you my last working version of the KNX binding, version 1.9.
I did look to version 1.10 but I did not see any difference with version 1.9.
Looking at github I see that the binding is still using the Calimero-2.3-beta. For me there was and is no reason to use a newer version. (If it is not broken don’t fix it).
But perhaps I should ask the development-team to include Calimero-2.3 in a new version of the binding.
localIp must not be 224.0.23.12, as this is the multicast address of the knx router (i.e. the parameter ip would be 224.0.23.12, while localIp is the ordinary ip address of your openHAB machine, for instance 192.168.178.155)
Hello Anton
for some reason, it seems that the binding you sent me does nor install for some reason. it throws the following error-log:
org.osgi.framework.BundleException: The bundle file:/usr/share/openhab2/addons/org.openhab.binding.knx-1.9.0.jar does not have a META-INF/MANIFEST.MF! Make sure, META-INF and MANIFEST.MF are the first 2 entries in your JAR!
at org.apache.felix.fileinstall.internal.DirectoryWatcher.installOrUpdateBundle(DirectoryWatcher.java:1004) [8:org.apache.felix.fileinstall:3.5.8]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:952) [8:org.apache.felix.fileinstall:3.5.8]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:871) [8:org.apache.felix.fileinstall:3.5.8]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:485) [8:org.apache.felix.fileinstall:3.5.8]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:361) [8:org.apache.felix.fileinstall:3.5.8]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:312) [8:org.apache.felix.fileinstall:3.5.8]
I uninstalled my KNX binding via paperUI, stopped OH2, copied your binding into /usr/share/openhab2/addons/ and the above appeared on restart of OH2 service
any idea?
Thank you!!
Hello Stefan,
Strange. I copied the file from my own installation and there it works.
And when I look into that file with Java Decompiler I see the directory MEATA-INF as first entry and in that directory the file MANIFEST.MF. So the error message does not make sense (to me).
Though I noticed that openhab copies the file to a tmp directory, something like userdata\tmp\mvn\org\openhab\binding. If you have used a different file before it is possible that it still has the old file. Usually I deleted the file in this tmp directory. After startup the (new) file shows up in that tmp directory.
greetings
Anton
P.S. I have asked (17 days ago) for a replace of the Calimero-2.3-beta version with the Calimero-2.3 in a new version of the knx-binding. But I did not get a response.
Though I have seen that a new binding is in the making for openhab version 2; this binding has a newer version of Calimero (at the moment version 2.4); see:
https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/binding/org.openhab.binding.knx/2.3.0-SNAPSHOT/
I use EIB KNX IP Interface in tunnel mode for a couple of years and in runs absolutely smoothly both on OH 1.x and now OH2.x.
Additions.
I never use the paperUI for configuration. I don’t know mixing config files and paperUI always result in the correct action. Just placing the binding inside the addons folder is not enough. You have to name “knx1” as a binding inside the addons.cfg file (and a knx.cfg file).
I found out that I did have the same error as yours, about a year ago. At that moment there was an error in the Manifest file. To test, I first I removed my own binding and replaced it with the original knx-binding; after restart openHAB did run ok. Then I corrected my own version and replaced the original binding with my own version. After restart openHAB did run ok and still does with the same binding. Before every restart I did remove the files in tmp.
Anton
Good morning Anton
Thank you so much for sending me your revised KNX-Binding and the instructions. I really much appreciate this!
(I’m posting here in order to keep this topic up to date)
At the moment, I’m running openHABian on a Raspberry 3, with just 2 Bindings installed via PaperUI (KNX and DMX). I’m using the recently purchased MDT KNX Router but in Tunnel mode, and everything is running not too bad at all. There is approximately 1 (up to 3) KNX connection-loss per day, but “auto-reconnect” helps and reconnects within about 5 seconds. Sometimes a light doesn’t go ON or OFF at the first try, but I can live with that.
I’m not really using UIs anymore, only sometimes for picking a color for RGB LEDs. Basically the actual setup is just a KNX-DMX daemon, but this covers 80% of what I ever wanted OH2 to do.
My actual desire still is the integration of my Denon AVR, as well as two Siemens Logo which I already installed in outside buildings for the purpose of remote controlled lights.
But due to all the draw-backs in the last months, I’m really afraid of touching anything. And I’m more and more wondering if it is worth the hassle (besides the fact that my girlfriend has forbidden me to ever touching the system again, in order to prevent myself from jumping out of the window one day 
)
Basically my plan is to give your binding a try on my previous, virtualized Linux machine, in conjunction with “the old” Siemens KNX Gateway. Hence I would not have to touch the more or less stable-running raspberry, and could play around on the VM. But at the moment I really cannot motivate myself at all.
The alternative is to sell the Siemens KNX Gateway which might be at least a little refund on my non-scheduled KNX-Router purchase. If anyone is interested, please send me a message including a price offer 
One question: is a daily (up to 3 times a day) “KNX link has been lost…” occurrence in the range of “normal”?
Best regards,
Stefan
Hello Stefan,
I understand what you feel.
I have KNX installed since 2012 and trying to control the installation with software ever since.
But my installation does not depend on controlling software. I use wall switches. My wife does not even know how to use the control software. So if the control software does not work, I don’t have to argue with her.
I start using openHAB in 2012, but had a lot of issues. I also tried other packages like knx@home (outdated at the moment) and OpenRemote. But I keep coming back to openHAB, because of the architecture, lots of addons and the community. Those arguments are important to me because I belief in IoT and integration.
KNX seems to be a difficult protocol. And I don’t think you can blame openHAB for the trouble it gives us to connect to the knx installation. Other software has the same problems with knx, although you don’t always see i: OpenRemote simply restarts the knx connection in case of a missing rcv-req.
But it is a little frustating that (it seems) that other users do not have the same problems.
I also regularly stop for month working on the automation of the house. After all there are more things to do. And then I have the energy again for a next try.
To answer your question I do not think that I have connection-losses. I just have missing rcv-seq request, problably once a day at avarage.
But don’t give up.
Best regards,
Anton
Hi,
I am an Openhab user for many years now but still have some issues with the KNX binding.
See the logging below:
2019-10-16 21:45:48.611 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling xxx.xxx.x.xxx:3671: tunneling request with invalid rcv-seq 114, expected 121
Is there any chance we get this solved one day?
Best regards,
Filip
Hello all together,
after a long time with no comments to this tread I have to open it again.
I do have this strange errors as well:
2021-11-13 16:42:17.259 [WARN ] [et/IP Tunneling 192.168.178.222:3671] - tunneling request with invalid rcv-seq 176, expected 197
2021-11-13 16:42:20.170 [WARN ] [et/IP Tunneling 192.168.178.222:3671] - tunneling request with invalid rcv-seq 177, expected 197
I’m usinig OpenHab for years now. It was running quite okay all the time but I experienced quite often the loss from my OpenHab server between KNX bus and ethernet with version 2.4 and decided to switch over to OpenHab 3. However I still experience this misbehaviour and have no clue how to fix it.
I happens 1-4 times per day. After 1-3 hours the connection is back to live.
Any good idea what the easiest way to fix is? I was thinking of using another IP-device (currently using BAB Eibport with tunneling).
Best regards,
Simon