Anyone who can recommend a KNX/IP Interface device (brand/type) that is working well with OH2? 
I would go for a router (if the budget allows it) from MDT - SCN-IP100.02, or a gateway SCN-IP000.02. I like these because they do not require a suplementary power supply!
George, thanks for your advise.
“if the budget allows” - basically yes, but I’d like to understand why this would be the better choice, if OH2 is supposed to be working with “cheaper” gateway just as well.
However, I have an update now.
I had some time left yesterday, and I decided to give it a last try before I additionaly spend €250++ for my home automation…
Thus I re-installed the latest Ubuntu 16.04.03 LTS, and the most recent OH2 snapshot version (apt-get). This snapshot comes with DMX Binding 2.x rather than DMX 1.x as the official release, and it comes with KNX 1.11 instead of KNX 1.10.
And for some reason, everything seems to be working well now. Probably it is too soon to say that, but it looks like something has changed indeed.
I still have the same warnings in the log, but something is different now. Even though the warnings appear, OH2 is working well from functional view.
BTW: could it be, that also the “KNX read results in bus telegram”-issue has been resolved with the 1.11 binding? 
I’ll observe it for a while and close the thread if applicable.
AFAIK, your problem has nothing to do with it!
When using a router, you can connect OH2 via router mode (with routing/filtering for telegrams) and connect ETS via tunneling mode in the same time! The router mode connection offers a not so intrusive method of connection (the devices can not be programmed via a router mode connection).
Update: KNX-Binding is still running well and stable with the latest snapshot-versions. I’m looking forward to the official releas of OH2.2 
1 Like
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 ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling xxx.yyy.zzz.www:3671: tunneling request with invalid rcv-seq 42, expected 45
2017-11-26 18:04:57.462 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling xxx.yyy.zzz.www:3671: tunneling request with invalid rcv-seq 42, expected 45
2017-11-26 18:04:58.462 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling xxx.yyy.zzz.www:3671: tunneling request with invalid rcv-seq 43, expected 45
2017-11-26 18:04:59.462 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling xxx.yyy.zzz.www:3671: tunneling request with invalid rcv-seq 43, expected 45
Strange that if the value corresponds (after 256 events), the sync is again established, but only for a while. 
Is there a newer version of the binding available I could use?
Any suggestions?
Thanks !
Filip
Hi Filip
I’m somehow glad that I’m not the only one with that issue, even though this is no help for either of us - sorry.
From my side, I can only tell that everything has worked well and stable, after I completely re-installed Ubuntu Server + OH2 snapshot release via apt-get, end of September.
I’m doing updates from time to time, but have never experienced this kind of dysfunction anymore. (Actually KNX has turned to the most stable binding in my environment.)
I’m not sure if this is related more to the re-installation, or snapshot- “upgrade”, but I think it is the second…
By the way, I should mention that I’m only using the “most basic” KNX function -> Switches, with only one GA assigned to (~40 of them).
Due to all the issues experienced before, I could not yet evolve trust to letting OH2 control blinds or roof window.
regards,
Stefan
Hi Stefan,
Thanks for your reply and your advise!
FYI: I am using OpenRemote for many years now (using the same infrastructure - Synology/PI) and I was interested to pass to OpenHab especially with the number of additional bindings and extended possibilities.
I installed about one year ago a version OH 1.8 on a PI but was a bit dissapointed about the stability (status of items) and the manual actions needed to get it running with KNX.
With OH2, I was surprissed to see the facility to install it and getting it running! I took very care with the configuration and the advise as mentioned on the openhab site and this forum.
Hower, still one blocking to go live - the sync issue… 
I also found an improvement patch for KNXD and hope the installation of this will improve the lower-levels behavior.
Regards,
Filip
Just a quick update:
OH2 is running 24/7 and has been running without any issue since my last post back in November, until end of 2017. However now I’m faced with the “invalid rcv-seq…” issue again (second time this year). I did really not do anything. No update, no changes, … just nothing! Really anoying.
Just a short excerpt from my log (sudden occurrence. Nobody has been at home that time, therefore actually no activity I could see relations to):
2018-01-06 00:11:55.360 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 131, expected 32
2018-01-06 00:11:56.360 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 132, expected 32
2018-01-06 00:11:57.360 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 132, expected 32
2018-01-06 00:11:58.360 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 133, expected 32
2018-01-06 00:11:59.360 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 133, expected 32
2018-01-06 00:12:00.360 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 134, expected 32
2018-01-06 00:12:01.360 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 134, expected 32
2018-01-06 00:12:02.360 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 135, expected 32
2018-01-06 00:12:03.360 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 135, expected 32
2018-01-06 00:12:04.360 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 136, expected 32
2018-01-06 00:12:05.360 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 136, expected 32
2018-01-06 00:12:06.359 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 137, expected 32
2018-01-06 00:12:07.359 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 137, expected 32
2018-01-06 00:12:08.359 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 138, expected 32
2018-01-06 00:12:09.359 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 138, expected 32
2018-01-06 00:12:10.359 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 139, expected 32
2018-01-06 00:12:11.359 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 139, expected 32
2018-01-06 00:12:12.359 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 140, expected 32
2018-01-06 00:12:13.359 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 140, expected 32
2018-01-06 00:12:14.359 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 141, expected 32
2018-01-06 00:12:15.359 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 141, expected 32
2018-01-06 00:15:07.040 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 142, expected 32
2018-01-06 00:15:08.040 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 142, expected 32
2018-01-06 00:15:09.040 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 143, expected 32
2018-01-06 00:15:10.040 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 143, expected 32
2018-01-06 00:17:21.168 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 144, expected 32
2018-01-06 00:17:22.167 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 144, expected 32
2018-01-06 00:17:23.167 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 145, expected 32
2018-01-06 00:17:24.167 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 145, expected 32
Any advice… probably else than buying a “better/different” KNX router/interface just for testing, I would be much appreciating!!!
Sorry for a late reaction, but I don’t visit this site regularly.
I have had the same problem with missing rvc’s. I do not know the cause, but I also think it is the IP router (in my case a Hager TH 210).
Thanks to Boris Malinkowsky, developer of Calimero, I have a got workaround.
Calimero is a library inside the KNX-binding fort OpenHAB.
Calimero has an option to ignore missing rvc’s. The option is available since v2.3 of Calimero.
To use the option you have to set it in the EXTRA_JAVA_OPTS:
EXTRA_JAVA_OPTS="-Dcalimero.knxnetip.tunneling.resyncSkippedRcvSeq"
The line is the only line inside the file: /etc/default/openhab2
Sadly at the moment the knx-binding (vs. 1.9.0) is using Calimero version 2.3-beta.
So I renamed a download of calimero-core-2.3.jar to Calimero-core-2.3-beta.jar and replaced this version inside the knx-binding.
It worked; I see warnings when a rvc number is missing but the openhab2 keeps running.
Regards,
Anton
Hi Anton
thank you very much for your detailed explanation of your workaround. Glad to hearing that you found a solution.
I had the hope that this issue could be finally fixed for me as well now.
To be honest - my latest “unstable release version” has been running without too many issues the last weeks, but I anyway decided to spend another 4 hours for a complete re-install of Ubuntu+OH2, and to giving it another “last try”.
Well. I’m now at a point between hating myself - and hating the whole electronics/smart-home world.
After rebooting, everything works well for a few minutes (+/- 15), before the log is flooded with “tunneling request with invalid …” 
Another sunny sunday afternoon for nothing.
It’s getting dark outside, no main light in my flat. Guess what my family is telling me (again) 
I’m not against trying around, and playing with this stuff. Realy not! But I need a solution now before going crazy. So again: any recommendation, please???
PS: I ordered a router now (MDT, SCN-IP100.02.) €250 just to giving it a try … 
Hi Stefan,
I hope things go better now.
The flooding of errors is caused by one missing rcv.
It took me a long time before I even found that out. I am not a specialist in hardware or software. I learned to use the Wireshark tool to see the network traffic (there is even a Protocol code voor KNXnetIP).
As I said the knx-binding in openHAB is still using Calimero version 2.3-beta. You need Calimero 2.3. If it helps I can send you my modified version of the knx-binding. But I think I need a mailadres to send it to.
Greetings
Anton
I guess I’m too stupid for OH. Installed the router now, and retried in TUNNELING mode. Well, the fault message is different but the outcome is the same. OH2 not receiving any command from KNX except the first 10 minutes, + log flooded with warnings and errors:
2018-02-19 21:44:23.946 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.22:3671: connection state response status: server could not find active data connection with specified ID
2018-02-19 21:44:33.946 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.22:3671: connection state response status: server could not find active data connection with specified ID
2018-02-19 21:44:43.946 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.22:3671: connection state response status: server could not find active data connection with specified ID
2018-02-19 21:44:53.946 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.22:3671: received disconnect response status 0x21 (no active data connection with that ID)
2018-02-19 21:44:53.948 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.22:3671: close connection - no heartbeat response
2018-02-19 21:44:53.948 [WARN ] [nx.internal.connection.KNXConnection] - KNX link has been lost (reason: no heartbeat response on object tunneling link link (closed) 192.168.0.22:3671 TP1 medium, device 1.1.65, hopcount 6)
2018-02-19 21:44:53.949 [INFO ] [nx.internal.connection.KNXConnection] - KNX link will be retried in 30 seconds
2018-02-19 21:44:53.952 [ERROR] [.binding.knx.internal.bus.KNXBinding] - Received detach Event.
2018-02-19 21:45:23.950 [INFO ] [nx.internal.connection.KNXConnection] - Trying to (re-)connect to KNX…
2018-02-19 21:45:23.956 [INFO ] [nx.internal.connection.KNXConnection] - Established connection to KNX bus on 192.168.0.22:3671 in mode TUNNEL.
2018-02-19 21:45:23.956 [INFO ] [nx.internal.connection.KNXConnection] - Connected to KNX
2018-02-19 21:45:27.025 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Value ‘24.3’ could not be sent to the KNX bus using datapoint ‘command DP 1/5/50 ‘N_WZ_Temperatur’, DPT main 0 id 9.001, low priority’ - retrying one time: no confirmation reply received for L-Data.req from 1.1.65 to 1/5/50, low priority hop count 6 repeat tpdu 00 80 0c bf
2018-02-19 21:45:27.025 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.22:3671: response timeout waiting for confirmation
tuwien.auto.calimero.exception.KNXTimeoutException: no confirmation reply received for L-Data.req from 1.1.65 to 1/5/50, low priority hop count 6 repeat tpdu 00 80 0c bf
at tuwien.auto.calimero.knxnetip.ClientConnection.doExtraBlockingModes(ClientConnection.java:239) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:269) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:149) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend(KNXNetworkLinkIP.java:263) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.link.AbstractLink.send(AbstractLink.java:304) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:240) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:466) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:438) [214:org.openhab.binding.knx:1.11.0]
at org.openhab.binding.knx.internal.bus.KNXBinding.writeToKNX(KNXBinding.java:149) [214:org.openhab.binding.knx:1.11.0]
at org.openhab.binding.knx.internal.bus.KNXBinding.internalReceiveUpdate(KNXBinding.java:126) [214:org.openhab.binding.knx:1.11.0]
at org.openhab.core.binding.AbstractBinding.receiveUpdate(AbstractBinding.java:113) [215:org.openhab.core.compat1x:2.2.0]
at org.openhab.core.events.AbstractEventSubscriber.handleEvent(AbstractEventSubscriber.java:39) [215:org.openhab.core.compat1x:2.2.0]
at org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:415) [3:org.apache.karaf.services.eventadmin:4.1.3]
at org.apache.felix.eventadmin.impl.tasks.HandlerTask.runWithoutBlacklistTiming(HandlerTask.java:82) [3:org.apache.karaf.services.eventadmin:4.1.3]
at org.apache.felix.eventadmin.impl.tasks.SyncDeliverTasks.execute(SyncDeliverTasks.java:104) [3:org.apache.karaf.services.eventadmin:4.1.3]
at org.apache.felix.eventadmin.impl.tasks.AsyncDeliverTasks$TaskExecuter.run(AsyncDeliverTasks.java:166) [3:org.apache.karaf.services.eventadmin:4.1.3]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
2018-02-19 21:45:39.026 [ERROR] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.22:3671: close connection - maximum send attempts
tuwien.auto.calimero.exception.KNXAckTimeoutException: maximum send attempts, no service acknowledgment received
at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:261) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:149) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend(KNXNetworkLinkIP.java:263) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.link.AbstractLink.send(AbstractLink.java:304) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:240) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.process.ProcessCommunicatorImpl.readFromGroup(ProcessCommunicatorImpl.java:486) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.process.ProcessCommunicatorImpl.read(ProcessCommunicatorImpl.java:422) [214:org.openhab.binding.knx:1.11.0]
at org.openhab.binding.knx.internal.bus.KNXBindingDatapointReaderTask.readFromKNXBus(KNXBindingDatapointReaderTask.java:99) [214:org.openhab.binding.knx:1.11.0]
at org.openhab.binding.knx.internal.bus.KNXBindingDatapointReaderTask.run(KNXBindingDatapointReaderTask.java:67) [214:org.openhab.binding.knx:1.11.0]
2018-02-19 21:45:39.032 [WARN ] [nx.internal.connection.KNXConnection] - KNX link has been lost (reason: maximum send attempts on object tunneling link link (closed) 192.168.0.22:3671 TP1 medium, device 1.1.65, hopcount 6)
2018-02-19 21:45:39.032 [INFO ] [nx.internal.connection.KNXConnection] - KNX link will be retried in 30 seconds
2018-02-19 21:45:39.037 [ERROR] [.binding.knx.internal.bus.KNXBinding] - Received detach Event.
2018-02-19 21:45:39.038 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Cannot read value for item ‘N_BU_Temperatur’ from KNX bus: maximum send attempts, no service acknowledgment received: timeout
2018-02-19 21:45:39.039 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Remaining retries for address ‘1/6/50’ = ‘2’
2018-02-19 21:45:39.039 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.22:3671: send invoked on closed connection - aborted
2018-02-19 21:45:39.039 [ERROR] [tuwien.auto.calimero ] - calimero.link.192.168.0.22:3671: send error, closing link
tuwien.auto.calimero.knxnetip.KNXConnectionClosedException: connection closed
at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:226) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:149) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend(KNXNetworkLinkIP.java:263) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.link.AbstractLink.send(AbstractLink.java:304) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:240) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:466) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:438) [214:org.openhab.binding.knx:1.11.0]
at org.openhab.binding.knx.internal.bus.KNXBinding.writeToKNX(KNXBinding.java:158) [214:org.openhab.binding.knx:1.11.0]
at org.openhab.binding.knx.internal.bus.KNXBinding.internalReceiveUpdate(KNXBinding.java:126) [214:org.openhab.binding.knx:1.11.0]
at org.openhab.core.binding.AbstractBinding.receiveUpdate(AbstractBinding.java:113) [215:org.openhab.core.compat1x:2.2.0]
at org.openhab.core.events.AbstractEventSubscriber.handleEvent(AbstractEventSubscriber.java:39) [215:org.openhab.core.compat1x:2.2.0]
at org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:415) [3:org.apache.karaf.services.eventadmin:4.1.3]
at org.apache.felix.eventadmin.impl.tasks.HandlerTask.runWithoutBlacklistTiming(HandlerTask.java:82) [3:org.apache.karaf.services.eventadmin:4.1.3]
at org.apache.felix.eventadmin.impl.tasks.SyncDeliverTasks.execute(SyncDeliverTasks.java:104) [3:org.apache.karaf.services.eventadmin:4.1.3]
at org.apache.felix.eventadmin.impl.tasks.AsyncDeliverTasks$TaskExecuter.run(AsyncDeliverTasks.java:166) [3:org.apache.karaf.services.eventadmin:4.1.3]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
2018-02-19 21:45:39.041 [ERROR] [.binding.knx.internal.bus.KNXBinding] - Value ‘24.3’ could not be sent to the KNX bus using datapoint ‘command DP 1/5/50 ‘N_WZ_Temperatur’, DPT main 0 id 9.001, low priority’ - giving up after second try: link closed, connection closed
does anyone have a working KNX connection in tunneling mode? (except Anton)
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)