[SOLVED] KNX Binding: no confirmation reply received

Dim · October 10, 2016, 2:25pm

My setup:
OpenHab 2 Snapshot (build: 526) on Raspberry Pi 3
KNX Binding: 1.9.0.201609250111
GIRA KNX/IP Router: Firmware version 3.1.3683.0
knx.conf:

ip=172.16.13.200
busaddr=1.1.249
ignorelocalevents=true
type=TUNNEL
port=3671
localIp=172.16.13.101
timeout=10000
autoReconnectPeriod=30
useNAT=false

My issue:
While OH2 establishes a connection to the KNX Bus on startup and I can send commands using the web interface and/or the mobile app, every time a command is delivered, I get the following (basically “no confirmation reply received” due to some kind of communications failure?):

"

2016-10-10 16:51:09.965 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Received update (item='P11_Light', state='ON')
2016-10-10 16:51:12.980 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Value 'ON' could not be sent to the KNX bus using datapoint 'command DP 1/0/10 P11_Light, DPT main 0 id 1.001, low priority' - retrying one time: no confirmation reply received
2016-10-10 16:51:12.985 [ERROR] [tuwien.auto.calimero                ] - [Thread-54] KNXnet/IP Tunneling 172.16.13.200:3671: send disconnect failed
java.net.SocketException: Socket is closed
	at java.net.DatagramSocket.send(DatagramSocket.java:658)[:1.8.0_65]
	at tuwien.auto.calimero.knxnetip.ConnectionBase.close(ConnectionBase.java:448)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:257)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:135)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.doSend(KNXNetworkLinkIP.java:457)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.send(KNXNetworkLinkIP.java:419)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:341)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:438)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:410)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at org.openhab.binding.knx.internal.bus.KNXBinding.writeToKNX(KNXBinding.java:149)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at org.openhab.binding.knx.internal.bus.KNXBinding.internalReceiveUpdate(KNXBinding.java:126)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at org.openhab.core.binding.AbstractBinding.receiveUpdate(AbstractBinding.java:119)[190:org.openhab.core.compat1x:2.0.0.201610011937]
	at org.openhab.core.events.AbstractEventSubscriber.handleEvent(AbstractEventSubscriber.java:38)[190:org.openhab.core.compat1x:2.0.0.201610011937]
	at org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:415)[3:org.apache.karaf.services.eventadmin:4.0.4]
	at org.apache.felix.eventadmin.impl.tasks.HandlerTask.run(HandlerTask.java:90)[3:org.apache.karaf.services.eventadmin:4.0.4]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_65]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_65]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_65]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_65]
	at java.lang.Thread.run(Thread.java:745)[:1.8.0_65]
2016-10-10 16:51:12.990 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Value 'ON' could not be sent to the KNX bus using datapoint 'command DP 1/0/10 P11_Light, DPT main 0 id 1.001, low priority' - retrying one time: link closed, connection closed
2016-10-10 16:51:12.986 [ERROR] [.binding.knx.internal.bus.KNXBinding] - Value 'ON' could not be sent to the KNX bus using datapoint 'command DP 1/0/10 P11_Light, DPT main 0 id 1.001, low priority' - giving up after second try: link closed, connection closed
2016-10-10 16:51:12.994 [ERROR] [tuwien.auto.calimero                ] - [Thread-54] KNXnet/IP Tunneling 172.16.13.200:3671: close connection - communication failure
java.net.SocketException: Socket is closed
	at java.net.DatagramSocket.send(DatagramSocket.java:658)[:1.8.0_65]
	at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:226)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:135)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.doSend(KNXNetworkLinkIP.java:457)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.send(KNXNetworkLinkIP.java:419)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:341)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:438)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:410)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at org.openhab.binding.knx.internal.bus.KNXBinding.writeToKNX(KNXBinding.java:149)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at org.openhab.binding.knx.internal.bus.KNXBinding.internalReceiveUpdate(KNXBinding.java:126)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at org.openhab.core.binding.AbstractBinding.receiveUpdate(AbstractBinding.java:119)[190:org.openhab.core.compat1x:2.0.0.201610011937]
	at org.openhab.core.events.AbstractEventSubscriber.handleEvent(AbstractEventSubscriber.java:38)[190:org.openhab.core.compat1x:2.0.0.201610011937]
	at org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:415)[3:org.apache.karaf.services.eventadmin:4.0.4]
	at org.apache.felix.eventadmin.impl.tasks.HandlerTask.run(HandlerTask.java:90)[3:org.apache.karaf.services.eventadmin:4.0.4]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_65]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_65]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_65]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_65]
	at java.lang.Thread.run(Thread.java:745)[:1.8.0_65]
2016-10-10 16:51:13.002 [WARN ] [tuwien.auto.calimero                ] - [Thread-14] KNXnet/IP Tunneling 172.16.13.200:3671: send invoked on closed connection - aborted
2016-10-10 16:51:13.003 [ERROR] [tuwien.auto.calimero                ] - [Thread-14] link 172.16.13.200:3671: send error, closing link
tuwien.auto.calimero.knxnetip.KNXConnectionClosedException: connection closed
	at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:192)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:135)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.doSend(KNXNetworkLinkIP.java:457)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.send(KNXNetworkLinkIP.java:419)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:341)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:438)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:410)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at org.openhab.binding.knx.internal.bus.KNXBinding.writeToKNX(KNXBinding.java:158)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at org.openhab.binding.knx.internal.bus.KNXBinding.internalReceiveCommand(KNXBinding.java:112)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at org.openhab.core.binding.AbstractBinding.receiveCommand(AbstractBinding.java:97)[190:org.openhab.core.compat1x:2.0.0.201610011937]
	at org.openhab.core.events.AbstractEventSubscriber.handleEvent(AbstractEventSubscriber.java:42)[190:org.openhab.core.compat1x:2.0.0.201610011937]
	at org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:415)[3:org.apache.karaf.services.eventadmin:4.0.4]
	at org.apache.felix.eventadmin.impl.tasks.HandlerTask.runWithoutBlacklistTiming(HandlerTask.java:102)[3:org.apache.karaf.services.eventadmin:4.0.4]
	at org.apache.felix.eventadmin.impl.tasks.SyncDeliverTasks.execute(SyncDeliverTasks.java:104)[3:org.apache.karaf.services.eventadmin:4.0.4]
	at org.apache.felix.eventadmin.impl.tasks.AsyncDeliverTasks$TaskExecuter.run(AsyncDeliverTasks.java:163)[3:org.apache.karaf.services.eventadmin:4.0.4]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_65]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_65]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_65]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_65]
	at java.lang.Thread.run(Thread.java:745)[:1.8.0_65]
2016-10-10 16:51:13.008 [ERROR] [tuwien.auto.calimero                ] - [Thread-54] link 172.16.13.200:3671: send error, closing link
tuwien.auto.calimero.knxnetip.KNXConnectionClosedException: connection closed
	at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:258)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:135)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.doSend(KNXNetworkLinkIP.java:457)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.send(KNXNetworkLinkIP.java:419)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:341)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:438)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:410)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at org.openhab.binding.knx.internal.bus.KNXBinding.writeToKNX(KNXBinding.java:149)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at org.openhab.binding.knx.internal.bus.KNXBinding.internalReceiveUpdate(KNXBinding.java:126)[192:org.openhab.binding.knx:1.9.0.201609250111]
	at org.openhab.core.binding.AbstractBinding.receiveUpdate(AbstractBinding.java:119)[190:org.openhab.core.compat1x:2.0.0.201610011937]
	at org.openhab.core.events.AbstractEventSubscriber.handleEvent(AbstractEventSubscriber.java:38)[190:org.openhab.core.compat1x:2.0.0.201610011937]
	at org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:415)[3:org.apache.karaf.services.eventadmin:4.0.4]
	at org.apache.felix.eventadmin.impl.tasks.HandlerTask.run(HandlerTask.java:90)[3:org.apache.karaf.services.eventadmin:4.0.4]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_65]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_65]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_65]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_65]
	at java.lang.Thread.run(Thread.java:745)[:1.8.0_65]
2016-10-10 16:51:13.013 [INFO ] [nx.internal.connection.KNXConnection] - Established connection to KNX bus on 172.16.13.200:3671 in mode TUNNEL.
2016-10-10 16:51:16.018 [ERROR] [.binding.knx.internal.bus.KNXBinding] - Value 'ON' could not be sent to the KNX bus using datapoint 'command DP 1/0/10 P11_Light, DPT main 0 id 1.001, low priority' - giving up after second try: no confirmation reply received

The “funny” part is that the commands actually work fine and I am able to control the KNX device… (even though my debug log is full of “Value ‘ON’ could not be sent to the KNX bus” messages")

Does anyone have any idea what could be wrong here and what steps I should take to troubleshoot this situation?

So far, I have changed all UTP cables between the OH2 installation which is running on a RPi3 and the GIRA KNX router as well as the KNX Bus cable.

BR,
Dimitris

Dim · October 10, 2016, 2:36pm

Update: I deployed OH1 on another Debian host and I tried to connect to the same GIRA KNX/IP Gateway…

I am having the same problems. The log (OH1 on Debian) shows:

2016-10-10 16:39:05.273 [INFO ] [b.k.i.connection.KNXConnection] - Established connection to KNX bus on 172.16.13.200:3671 in mode TUNNEL.
2016-10-10 16:39:35.401 [WARN ] [.b.knx.internal.bus.KNXBinding] - Value 'ON' could not be sent to the KNX bus using datapoint 'command DP 1/0/9 P11_Large_LED, DPT main 0 id 1.001, low priority' - retrying one time: no confirmation reply received
2016-10-10 16:39:35.405 [WARN ] [b.k.i.connection.KNXConnection] - KNX link has been lost (reason: communication failure on object link 172.16.13.200:3671 tunneling mode (closed), TP1 hopcount 6)
2016-10-10 16:39:35.406 [INFO ] [b.k.i.connection.KNXConnection] - KNX link will be retried in 30 seconds
2016-10-10 16:39:35.408 [ERROR] [.b.knx.internal.bus.KNXBinding] - Value 'ON' could not be sent to the KNX bus using datapoint 'command DP 1/0/9 P11_Large_LED, DPT main 0 id 1.001, low priority' - giving up after second try: link closed, connection closed
2016-10-10 16:39:35.423 [ERROR] [tuwien.auto.calimero          ] - [qtp451878941-72] KNXnet/IP Tunneling 172.16.13.200:3671: send disconnect failed
java.net.SocketException: Socket is closed
	at java.net.DatagramSocket.send(DatagramSocket.java:663) ~[na:1.7.0_111]
	at tuwien.auto.calimero.knxnetip.ConnectionBase.close(ConnectionBase.java:448) ~[na:na]
	at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:257) ~[na:na]
	at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:135) ~[na:na]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.doSend(KNXNetworkLinkIP.java:457) ~[na:na]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.send(KNXNetworkLinkIP.java:419) ~[na:na]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:341) ~[na:na]
	at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:438) ~[na:na]
	at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:410) ~[na:na]
	at org.openhab.binding.knx.internal.bus.KNXBinding.writeToKNX(KNXBinding.java:145) ~[na:na]
	at org.openhab.binding.knx.internal.bus.KNXBinding.internalReceiveCommand(KNXBinding.java:104) ~[na:na]
	at org.openhab.core.binding.AbstractBinding.receiveCommand(AbstractBinding.java:97) ~[na:na]
	at org.openhab.core.events.AbstractEventSubscriber.handleEvent(AbstractEventSubscriber.java:42) ~[na:na]
	at org.eclipse.equinox.internal.event.EventHandlerWrapper.handleEvent(EventHandlerWrapper.java:197) ~[na:na]
	at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:197) ~[na:na]
	at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:1) ~[na:na]
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) ~[na:na]
	at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) ~[na:na]
	at org.eclipse.equinox.internal.event.EventAdminImpl.dispatchEvent(EventAdminImpl.java:135) ~[na:na]
	at org.eclipse.equinox.internal.event.EventAdminImpl.sendEvent(EventAdminImpl.java:78) ~[na:na]
	at org.eclipse.equinox.internal.event.EventComponent.sendEvent(EventComponent.java:39) ~[na:na]
	at org.openhab.core.internal.events.EventPublisherImpl.sendCommand(EventPublisherImpl.java:56) ~[na:na]
	at org.openhab.ui.webapp.internal.servlet.CmdServlet.service(CmdServlet.java:95) ~[na:na]
	at org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(ServletRegistration.java:61) ~[na:na]
	at org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:128) ~[na:na]
	at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:60) ~[na:na]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) ~[javax.servlet_3.0.0.v201112011016.jar:na]
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:598) ~[na:na]
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:486) ~[na:na]
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) ~[na:na]
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065) ~[na:na]
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413) ~[na:na]
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192) ~[na:na]
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999) ~[na:na]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) ~[na:na]
	at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250) ~[na:na]
	at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149) ~[na:na]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111) ~[na:na]
	at org.eclipse.jetty.server.Server.handle(Server.java:350) ~[na:na]
	at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454) ~[na:na]
	at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890) ~[na:na]
	at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944) ~[na:na]
	at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:630) ~[na:na]
	at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230) ~[na:na]
	at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:77) ~[na:na]
	at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:606) ~[na:na]
	at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:46) ~[na:na]
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:603) ~[na:na]
	at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:538) ~[na:na]
	at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_111]
2016-10-10 16:39:35.433 [ERROR] [tuwien.auto.calimero          ] - [qtp451878941-72] KNXnet/IP Tunneling 172.16.13.200:3671: close connection - communication failure
java.net.SocketException: Socket is closed
	at java.net.DatagramSocket.send(DatagramSocket.java:663) ~[na:1.7.0_111]
	at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:226) ~[na:na]
	at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:135) ~[na:na]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.doSend(KNXNetworkLinkIP.java:457) ~[na:na]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.send(KNXNetworkLinkIP.java:419) ~[na:na]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:341) ~[na:na]
	at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:438) ~[na:na]
	at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:410) ~[na:na]
	at org.openhab.binding.knx.internal.bus.KNXBinding.writeToKNX(KNXBinding.java:145) ~[na:na]
	at org.openhab.binding.knx.internal.bus.KNXBinding.internalReceiveCommand(KNXBinding.java:104) ~[na:na]
	at org.openhab.core.binding.AbstractBinding.receiveCommand(AbstractBinding.java:97) ~[na:na]
	at org.openhab.core.events.AbstractEventSubscriber.handleEvent(AbstractEventSubscriber.java:42) ~[na:na]
	at org.eclipse.equinox.internal.event.EventHandlerWrapper.handleEvent(EventHandlerWrapper.java:197) ~[na:na]
	at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:197) ~[na:na]
	at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:1) ~[na:na]
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) ~[na:na]
	at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) ~[na:na]
	at org.eclipse.equinox.internal.event.EventAdminImpl.dispatchEvent(EventAdminImpl.java:135) ~[na:na]
	at org.eclipse.equinox.internal.event.EventAdminImpl.sendEvent(EventAdminImpl.java:78) ~[na:na]
	at org.eclipse.equinox.internal.event.EventComponent.sendEvent(EventComponent.java:39) ~[na:na]
	at org.openhab.core.internal.events.EventPublisherImpl.sendCommand(EventPublisherImpl.java:56) ~[na:na]
	at org.openhab.ui.webapp.internal.servlet.CmdServlet.service(CmdServlet.java:95) ~[na:na]
	at org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(ServletRegistration.java:61) ~[na:na]
	at org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:128) ~[na:na]
	at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:60) ~[na:na]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) ~[javax.servlet_3.0.0.v201112011016.jar:na]
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:598) ~[na:na]
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:486) ~[na:na]
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) ~[na:na]
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065) ~[na:na]
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413) ~[na:na]
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192) ~[na:na]
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999) ~[na:na]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) ~[na:na]
	at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250) ~[na:na]
	at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149) ~[na:na]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111) ~[na:na]
	at org.eclipse.jetty.server.Server.handle(Server.java:350) ~[na:na]
	at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454) ~[na:na]
	at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890) ~[na:na]
	at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944) ~[na:na]
	at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:630) ~[na:na]
	at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230) ~[na:na]
	at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:77) ~[na:na]
	at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:606) ~[na:na]
	at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:46) ~[na:na]
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:603) ~[na:na]
	at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:538) ~[na:na]
	at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_111]
2016-10-10 16:39:35.442 [ERROR] [tuwien.auto.calimero          ] - [qtp451878941-72] link 172.16.13.200:3671: send error, closing link
tuwien.auto.calimero.knxnetip.KNXConnectionClosedException: connection closed
	at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:258) ~[na:na]
	at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:135) ~[na:na]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.doSend(KNXNetworkLinkIP.java:457) ~[na:na]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.send(KNXNetworkLinkIP.java:419) ~[na:na]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:341) ~[na:na]
	at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:438) ~[na:na]
	at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:410) ~[na:na]
	at org.openhab.binding.knx.internal.bus.KNXBinding.writeToKNX(KNXBinding.java:145) ~[na:na]
	at org.openhab.binding.knx.internal.bus.KNXBinding.internalReceiveCommand(KNXBinding.java:104) ~[na:na]
	at org.openhab.core.binding.AbstractBinding.receiveCommand(AbstractBinding.java:97) ~[na:na]
	at org.openhab.core.events.AbstractEventSubscriber.handleEvent(AbstractEventSubscriber.java:42) ~[na:na]
	at org.eclipse.equinox.internal.event.EventHandlerWrapper.handleEvent(EventHandlerWrapper.java:197) ~[na:na]
	at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:197) ~[na:na]
	at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:1) ~[na:na]
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) ~[na:na]
	at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) ~[na:na]
	at org.eclipse.equinox.internal.event.EventAdminImpl.dispatchEvent(EventAdminImpl.java:135) ~[na:na]
	at org.eclipse.equinox.internal.event.EventAdminImpl.sendEvent(EventAdminImpl.java:78) ~[na:na]
	at org.eclipse.equinox.internal.event.EventComponent.sendEvent(EventComponent.java:39) ~[na:na]
	at org.openhab.core.internal.events.EventPublisherImpl.sendCommand(EventPublisherImpl.java:56) ~[na:na]
	at org.openhab.ui.webapp.internal.servlet.CmdServlet.service(CmdServlet.java:95) ~[na:na]
	at org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(ServletRegistration.java:61) ~[na:na]
	at org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:128) ~[na:na]
	at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:60) ~[na:na]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) ~[javax.servlet_3.0.0.v201112011016.jar:na]
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:598) ~[na:na]
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:486) ~[na:na]
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) ~[na:na]
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065) ~[na:na]
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413) ~[na:na]
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192) ~[na:na]
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999) ~[na:na]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) ~[na:na]
	at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250) ~[na:na]
	at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149) ~[na:na]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111) ~[na:na]
	at org.eclipse.jetty.server.Server.handle(Server.java:350) ~[na:na]
	at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454) ~[na:na]
	at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890) ~[na:na]
	at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944) ~[na:na]
	at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:630) ~[na:na]
	at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230) ~[na:na]
	at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:77) ~[na:na]
	at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:606) ~[na:na]
	at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:46) ~[na:na]
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:603) ~[na:na]
	at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:538) ~[na:na]
	at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_111]
2016-10-10 16:39:57.268 [INFO ] [b.k.i.connection.KNXConnection] - Established connection to KNX bus on 172.16.13.200:3671 in mode TUNNEL.
2016-10-10 16:40:00.319 [WARN ] [.b.knx.internal.bus.KNXBinding] - Value 'OFF' could not be sent to the KNX bus using datapoint 'command DP 1/0/9 P11_Large_LED, DPT main 0 id 1.001, low priority' - retrying one time: no confirmation reply received
2016-10-10 16:40:00.320 [WARN ] [b.k.i.connection.KNXConnection] - KNX link has been lost (reason: communication failure on object link 172.16.13.200:3671 tunneling mode (closed), TP1 hopcount 6)
2016-10-10 16:40:00.323 [INFO ] [b.k.i.connection.KNXConnection] - KNX link will be retried in 30 seconds
2016-10-10 16:40:00.324 [ERROR] [.b.knx.internal.bus.KNXBinding] - Value 'OFF' could not be sent to the KNX bus using datapoint 'command DP 1/0/9 P11_Large_LED, DPT main 0 id 1.001, low priority' - giving up after second try: link closed, connection closed
2016-10-10 16:40:00.337 [ERROR] [tuwien.auto.calimero          ] - [qtp451878941-71] KNXnet/IP Tunneling 172.16.13.200:3671: send disconnect failed

Also: When I configure the knx.conf in Router mode (back in OH2 on RPi3), I get the following errors (every few seconds!):

2016-10-10 17:35:04.725 [DEBUG] [nx.internal.connection.KNXConnection] - KNXBinding configuration present. Setting up KNX bus connection.
2016-10-10 17:35:04.727 [DEBUG] [nx.internal.connection.KNXConnection] - Not connected yet. Trying to connect.
2016-10-10 17:35:04.757 [DEBUG] [org.openhab.binding.knx             ] - BundleEvent STARTED - org.openhab.binding.knx
2016-10-10 17:35:04.803 [INFO ] [nx.internal.connection.KNXConnection] - Established connection to KNX bus on 224.0.23.12:3671 in mode ROUTER.
2016-10-10 17:35:04.807 [DEBUG] [nx.internal.connection.KNXConnection] - Success: connected.
2016-10-10 17:35:04.845 [INFO ] [ui.habmin.internal.servlet.HABminApp] - Started HABmin servlet at /habmin
2016-10-10 17:35:07.078 [WARN ] [tuwien.auto.calimero                ] - [KNXnet/IP receiver] KNXnet/IP Routing 224.0.23.12:3671: received unknown frame, service type 0x538 - ignored
2016-10-10 17:35:09.197 [WARN ] [tuwien.auto.calimero                ] - [KNXnet/IP receiver] KNXnet/IP Routing 224.0.23.12:3671: received unknown frame, service type 0x538 - ignored
2016-10-10 17:35:11.349 [WARN ] [tuwien.auto.calimero                ] - [KNXnet/IP receiver] KNXnet/IP Routing 224.0.23.12:3671: received unknown frame, service type 0x538 - ignored
2016-10-10 17:35:13.746 [WARN ] [tuwien.auto.calimero                ] - [KNXnet/IP receiver] KNXnet/IP Routing 224.0.23.12:3671: received unknown frame, service type 0x538 - ignored
2016-10-10 17:35:16.049 [WARN ] [tuwien.auto.calimero                ] - [KNXnet/IP receiver] KNXnet/IP Routing 224.0.23.12:3671: received unknown frame, service type 0x538 - ignored
2016-10-10 17:35:18.366 [WARN ] [tuwien.auto.calimero                ] - [KNXnet/IP receiver] KNXnet/IP Routing 224.0.23.12:3671: received unknown frame, service type 0x538 - ignored
2016-10-10 17:35:20.934 [WARN ] [tuwien.auto.calimero                ] - [KNXnet/IP receiver] KNXnet/IP Routing 224.0.23.12:3671: received unknown frame, service type 0x538 - ignored
2016-10-10 17:35:23.180 [WARN ] [tuwien.auto.calimero                ] - [KNXnet/IP receiver] KNXnet/IP Routing 224.0.23.12:3671: received unknown frame, service type 0x538 - ignored
2016-10-10 17:35:25.236 [WARN ] [tuwien.auto.calimero                ] - [KNXnet/IP receiver] KNXnet/IP Routing 224.0.23.12:3671: received unknown frame, service type 0x538 - ignored

I might be experiencing a hardware (?) related communications problem… maybe a UTP cable or a KNX Bus cable is problematic…
Or could it be something wrongly configured in my system?

Is anyone else running the same (latest) firmware (3.1.3683.0) on the GIRA KNX/IP Router without any problems?

I have used this GIRA Router to connect to ETS and it’s working ok.

I checked also this thread: KNX binding problem from @Ferryb4 but it didn’t help me. I experience the same with or without a local busaddr set.

Dim · October 11, 2016, 9:59am

I am still stuck with this problem… I did some troubleshooting but I can’t solve the issue…

I am thinking to change the GIRA KNX/IP Router with another router and/or interface.

Anyone has any recommendations for such device that has been tested and working properly with OH1/OH2 KNX binding?

BR,
Dim

Dim · October 13, 2016, 7:29am

No-one is using the GIRA KNX/IP Router (model 2167 00) with their OpenHab 1 or 2 deployments?
Is it working properly? If yes: which firmware revision is the GIRA Router running?

I still can’t find a solution to this communications problem…

BR,
Dim

Dim · October 13, 2016, 2:18pm

Update: Half of the problem has been resolved!
I also learned alot of stuff by talking to the GIRA tech support team but more importantly, to the creator (Boris) of the Calimero project!

I reprogrammed the GIRA KNX/IP Router to act as a line coupler x.y.0 (it used to be setup as a line repeater x.y.z) and to allow full routing of all telegrams and now it works in OH2 with the 1.9 snapshot KNX binding

I am still having some troubles with the tunneling connection setup but I am sure that I will fix it.

Stay tuned for more good news…

BR,
Dimitris

Dim · October 14, 2016, 9:57am

Ok… here it goes… My Lessons Learned from my recent efforts to make OpenHab talk to the the GIRA KNX/IP Router.

TL;DR: For the GIRA Router to work properly with OpenHab/KNX Binding: Don’t enable Reliable Communications and set the device in Line Coupler mode (not Line Repeater)

Having a KNX installation in my home, I wanted to play around with it as an enthusiast and I stumbled upon OpenHab for the first time in August 2016. The first thing that I saw is that I need a way to communicate to the KNX Bus over IP and in one of the wiki entries I saw that the GIRA KNX/IP Router was mentioned, so I decided to go for it (to be sure that it would work :))

I ordered it, installed it in my KNX Bus and configured it using ETS 5 as a line repeater device (Physical Address of X.Y.Z type). During the ETS configuration, I also enabled the “reliable communications” option in the Router Applications. This is recommended when using Wireless LAN from your PC running ETS to connect to the GIRA Router.

The decision to enable these 2 features (line repeater and reliable comms) caused me a lot of headache later on…

I couldn’t get the OpenHab KNX Binding to talk to the Router neither in Tunneling not in Routing mode.

Note:
In “Routing” I mean multicast (and connection-less) based communication between my device and the GIRA Router
In “Tunneling” I mean unicast (and connection-oriented) based communication between my device and the GIRA Router
For deeper dive: Read 03_08_05 Routing v01.05.01 AS.PDF (247.2 KB) and 03_08_04 Tunnelling v01.05.03 AS.PDF (297.4 KB)

When I configured the KNX Binding to work in Routing mode (set type=ROUTER in /etc/openhab2/services/knx.cfg), I was getting multiple log entries regarding “KNXnet/IP Routing 224.0.23.12:3671: received unknown frame, service type 0x538 - ignored”. Also, no commands where being delivered from OH2 to the KNX Bus.

When I configured the KNX Binding to work in Tunneling mode (set type=TUNNEL, set the KNX gateway ip address,and set the localIp address), I was getting log entries of “confirmation reply received” type and due to that, lots of communication errors and the tunnel was being torn down and re-established every few seconds (based on the setting of autoReconnectPeriod in the knx.cfg).

After having some discussions with both the GIRA Technical support team as well as the Calimero team, I realized that the line repeater configuration was not the proper one and I had to configure the GIRA router as a line coupler (Physical Address of X.Y.0 type). Also, I had to disable the reliable communications in order to get rid of these strange “received unknown frame, service type 0x538” messages.

These service type messages belong to the KNXnet/IP Routing address range (in hex is: from 0x530 to 0x53F) and only 2 are defined in the KNX standard: 0x530 for “ROUTING_INDICATION” and 0x531 for “ROUTING_LOST_MESSAGE". The 0x538 one is used by GIRA to exchange messages between their GIRA Router and their own GIRA G1 central operating unit.

Following the re-configuration of the GIRA Router to act as a line coupler, I had to also to modify the routing parameters of the device to allow routing of all telegrams from IP->Bus and from Bus->IP (see ETS screenshots below:)

There is an alternative way to this: Instead of routing all telegrams back and forth, you can setup a dummy application device in your ETS project and link it to the Group Addresses (GAs) that you want to access from OpenHab. In this way, the Filter Table in the Router gets automatically populated with these GAs and the router will allow those telegrams to go through.

Following these 2 changes, my OpenHab 2 installation and KNX Binding starting working properly!

The messages are being transmitted over multicast to the Router and the entire system is extremely responsive (within milliseconds from the moment that I switch an item on the web interface, the KNX endpoint reacts).

A huge thank you goes out to Boris Malinowsky from the Calimero Project who helped me a lot with debugging with his Calimero-GUI client.

Best Regards,
Angelos

PeteW · October 22, 2016, 11:00am

Dim

I also have a Gira KNX setup and just starting to try to get openHab setup. My setup is mainly Gira kit - but I already have a Gira IP Router and Gira Homeserver that I currently use to control everything.

Have tried to setup openHab to control some switches, but unfortunately I’m not getting any response from the KNX IP Router. just get these errors when I try to connect in TUNNEL mode:

[ManagedService Update Queue] KNXnet/IP Tunneling 192.168.1.12:3671: establish connection from /192.168.1.107:63525 to /192.168.1.12:3671
2016-10-22 11:44:32.647 [INFO ] [tuwien.auto.calimero          ] - [ManagedService Update Queue] KNXnet/IP Tunneling 192.168.1.12:3671: wait for connect response from /192.168.1.12:3671 ...
2016-10-22 11:44:32.651 [ERROR] [tuwien.auto.calimero          ] - [KNXnet/IP receiver] KNXnet/IP Tunneling 192.168.1.12:3671: could not accept new connection (maximum reached)
2016-10-22 11:44:32.653 [ERROR] [b.k.i.connection.KNXConnection] - Error connecting to KNX bus: error response from control endpoint /192.168.1.12:3671, could not accept new connection (maximum reached)
2016-10-22 11:44:32.653 [WARN ] [b.k.i.connection.KNXConnection] - Inital connection to KNX bus failed!
2016-10-22 11:44:32.658 [ERROR] [tuwien.auto.calimero          ] - [ManagedService Update Queue] KNXnet/IP Tunneling 192.168.1.12:3671: establishing connection failed

Just can’t get it connect! Any ideas?

Pete

Dim · October 22, 2016, 6:06pm

Hi @PeteW,

Which GIRA KNX/IP Router do you have? (is it the 216700 model? which firmware version is it running?)

From the log, I can see that the Router is rejecting new connections in tunneling mode (reports: “(maximum reached)”)

In theory, the 216700 allows up to 4 concurrent tunneling sessions to be established. I don’t know how many sessions the Gira Homeserver establishes to the Gateway, but it shouldn’t take all 4…

Anyway, I recommend that you switch to a ROUTER connection type in your /etc/openhab2/services/knx.conf file (instead of TUNNEL).

Try:

# KNX gateway IP address [...]
ip=224.0.23.12

# Ignore local KNX Events, prevents internal events coming from [...]
ignorelocalevents=true

# KNX IP connection type. Could be either TUNNEL or ROUTER (optional, defaults to TUNNEL) [...]
type=ROUTER

BR,
Dim

PeteW · October 22, 2016, 9:47pm

thanks for the reply Dim.

Will take a look at the router model. Strange on the connections. I have been using Homeserver and clients on ipads/iphones so wonder if thats not releasing connections. Will do some monitoring and let you know.

Pete

PeteW · October 23, 2016, 7:12am

My router is a 901001 or 10303290 – anyway, it’s this one!

Have rebooted all the KNX panel – try to get rid of any connections on the KNX Router.

Not getting the same error now I’m in Router mode…

In the log have this…

08:00:55.667 [DEBUG] [.o.b.knx.internal.KNXActivator:31   ] - KNX binding has been started.
08:00:55.690 [DEBUG] [i.internal.GenericItemProvider:341  ] - Start processing binding configuration of Item 'Light_GF_Kitchen_LEDs (Type=SwitchItem, State=Uninitialized)' with 'KNXGenericBindingProvider' reader.
08:00:55.739 [DEBUG] [i.internal.GenericItemProvider:341  ] - Start processing binding configuration of Item 'Light_GF_Kitchen_Island (Type=SwitchItem, State=Uninitialized)' with 'KNXGenericBindingProvider' reader.

Then this……

08:00:55.756 [DEBUG] [b.k.i.connection.KNXConnection:296  ] - KNXBinding configuration present. Setting up KNX bus connection.
08:00:55.756 [DEBUG] [b.k.i.connection.KNXConnection:408  ] - Not connected yet. Trying to connect.

Then this……

08:01:01.729 [DEBUG] [.b.knx.internal.bus.KNXBinding:113  ] - Received update (item='Light_GF_Kitchen_LEDs', state='ON')
08:01:01.737 [DEBUG] [m.r.internal.engine.RuleEngine:264  ] - Executing startup rule 'Initialize heating states'
08:01:01.737 [INFO ] [runtime.busevents             :26   ] - Light_GF_Kitchen_LEDs state updated to ON
08:01:01.738 [DEBUG] [.b.knx.internal.bus.KNXBinding:113  ] - Received update (item='Light_GF_Kitchen_Island', state='OFF')

but when I try to switch the lights on/off with openHab, just get the openHab messages in the log……can’t see any trace of the KNX commands…

08:07:28.268 [INFO ] [runtime.busevents             :22   ] - Light_GF_Kitchen_Island received command OFF
08:07:29.765 [INFO ] [runtime.busevents             :22   ] - Light_GF_Kitchen_Island received command ON
08:07:31.004 [INFO ] [runtime.busevents             :22   ] - Light_GF_Kitchen_LEDs received command ON
08:07:31.770 [INFO ] [runtime.busevents             :22   ] - Light_GF_Kitchen_LEDs received command OFF

What do you think?

Pete

PeteW · October 23, 2016, 7:17am

Oh…and these are my settings of the two KNX lights I want to switch. Using the group addresses from the KNX actuator…

I’ve used +

Switch Light_GF_Kitchen_LEDs 		"LEDs" 			(Kitchen, Lights)	{ knx="1/1/18+1/2/18"}
Switch Light_GF_Kitchen_Island 		"Island" 		(Kitchen, Lights)	{ knx="1/1/19+1/2/19"}

cheers - Pete

Dim · October 23, 2016, 7:22am

@PeteW

Analyzing now I will let you know what I find later on (expect an answer in 2-3h :))

Quick question: Do you know what is the PA (Physical Address) of the Router in your KNX line?

Is it acting as:
A Line Coupler (PA of x.y.0 type)
An Area Coupler (PA of x.0.0 type) or
A Data Interface (PA of x.y.z type) ?

BR,
Dim

PeteW · October 23, 2016, 7:48am

Yes, it’s 1.0.255

PeteW · October 23, 2016, 8:01am

Sorry Dim – missed your 2nd question!

I believe it’s a data interface. Setup to get Homeserver working. I also had another think about number of connections. I don’t think the iPhone Homeserver clients are anything to do with it, as they connect directly to the Homeserver not the KNX IP Router. They use a different IP address.

Many thanks for your help – I got a bit stumped!

Pete

Dim · October 23, 2016, 11:25am

Hi @PeteW,

Even though I couldn’t find any reference in the technical specifications of the GIRA 1030 00 model that you have, it seems that it supports only 1 concurrent tunneling connection.

In theory, this single tunneling connection is used up by the Gira Homeserver and that’s why you were getting that response from the Router in the OH Logs (could not accept new connection (maximum reached)).

The other terminals that connect to the GIRA Homeserver do not affect this parameter since the only device communicating with the GIRA KNX/IP Router is the Homeserver.

You could retry (just for testing purposes) to temporarily shut down the Homeserver and see if OpenHab will establish a tunnel to the Router.

Now, in ROUTER mode, this limitation does not apply and you should be able to connect to it.

Did your logs show this message: “Established connection to KNX bus on 224.0.23.12:3671 in mode ROUTER.” ?

Your items config looks good (the 2 switches with their GAs) and I the only reason that I can identify for this situation is that the GIRA KNX/IP Router should be set as a Line Coupler (PA of type: x.y.0) and not as a Data Interface.

In my case (with the 216700 model) in order to get the ROUTER mode to work, I had to change the PA from 1.1.200 (configured as a Line Repeater/Data Interface) to 1.1.0 (configured as a Line Coupler).

Can you modify the PA of the Router and try ROUTER mode again?

By the way: Which version of OH and KNX Binding are you using?

BR,
Dim

PeteW · October 23, 2016, 11:41am

Thanks, this is really useful info, maybe worth investing in a new IP module!

Will try switching off the Honeseever and see if it connects. Will report back!

Thanks again

Pete

PeteW · October 23, 2016, 5:19pm

Hi

Have tried switching off the Homeserver to see if I’m limited to 1 connection. It was still giving the same ‘max connections’ error. I’m going to try a few more options as you suggest over the next day or so.

Thanks for your help – am sure I’ll find out what it is shortly – I’ll report back!

Pete

PeteW · October 24, 2016, 5:24am

Now, when you mentioned about the router settings, i thought I’d check to see if there were parameters set…I had a suspicion that there must be a setting to say where to receive telegrams from in IP - see pic…

Must have some setting in here to restrict the IPs it receives comands from?

It makes sense, probably some security setting so you can’t just send comands from any device on the IP network. I see that the new Gira Router has an encryption option too - lucky i don’t have that

Will report back

Pete

Dim · October 24, 2016, 5:36am

Hi @PeteW

I don’t think that you can control this aspect from the ETS parameters of the device (to accept/receive communications from a specific remote IP Address (e.g. the Homeserver) only).

By the way: The IP Routing multicast in your screenshot is correct. No need to change that.
Multicast IP Address 224.0.23.12 is registered for use by the KNXnet/IP protocol and can be used by many devices concurrently.

To simplify: This acts like a broadcast channel. An IP device can broadcast to this address and all listening to it will receive the message. It is connection-less (no point to point link is established), contrary to the tunnel configuration where a permanent connection is established and uses the individually assigned IP Address (in this case: 192.168.1.12) and UDP port 3167.

In my experience, the best way for OpenHab to connect to a KNX system via a Router is to use multicasting (ROUTER type in the knx.cfg). There are some additional considerations to be made when using the KNX/IP device as a router: You need to configure the Filter Table of the Router device within ETS to allow routing of KNX Telegrams from the KNX Bus to the IP network (and from IP to Bus).

This can be done either with:
a) A Dummy application in ETS that has the required Group Addresses linked to it (prefered)
or
b) Allow mass routing of telegrams from Bus->IP and from IP->Bus (not really recommended :))
or
c) Manual editing of the Filter Table of the KNX Router (really, really not recommended :))

I would try to get Routing working… it is the best way and it will work in parallel with your existing setup (with the Homeserver).

I have only 1 concern… I am not 100% sure if the Router will respond in parallel to both unicast (Tunneling) as well as multicast (Routing) IP communications… From what I know (from my GIRA 216700): This works fine.

BR,
Dim
Ps: IP Config tabs are all looking good! IP Config 1 shows you the multicast address and allows you to change the individual device IP Address assignment and since you have set it to manual (correctly), it enables IP Config 2 tab (where you set the static IP of the GIRA KNX Device) and IP Config 3 tab (where you set the default gateway)

Dim · October 24, 2016, 6:22am

@PeteW

Important note: If you want to use multicasting to communicate to the GIRA 103000 KNX/IP Router, you will need to change it’s Physical Address (PA) in the KNX Line from 1.0.255 to 1.0.0.

The PA of x.y.z type (1.0.255) sets the device in a Line Repeater mode and will not allow proper routing of KNX Telegrams. It works fine for tunneling.
The PA of x.y.0 type or x.0.0 (1.0.0) sets the device in Line Coupler / Area Coupler mode (the correct setting for a routing environment). Tunneling also works fine here.

The IP Address can remain the same (192.168.1.12) and this PA change should not affect the communications with the GIRA Homeserver (which is most likely using unicast (tunnel) to connect to the Router… can you check that please from the configs of the Homeserver and let me know?))

BR,
Dim