[knx] Device status cannot be polled

On some installations, apparently the device status polling does not work as expected:

As a result, the following symptoms can be observed:

• the device-Things are OFFLINE
• the log contains warnings like

2018-03-18 08:19:54.209 [WARN ] [Xnet/IP Tunneling 192.168.10.26:3671] - response timeout waiting for confirmation
tuwien.auto.calimero.KNXTimeoutException: no confirmation reply received for 3.1.101->3.1.23 L_Data.req, system priority hop count 6 repeat, tpdu 80
	at tuwien.auto.calimero.knxnetip.ClientConnection.doExtraBlockingModes(ClientConnection.java:244) ~[?:?]
	at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:258) ~[?:?]
	at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:178) ~[?:?]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend(KNXNetworkLinkIP.java:243) ~[?:?]
	at tuwien.auto.calimero.link.AbstractLink.send(AbstractLink.java:351) ~[?:?]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:222) ~[?:?]
	at tuwien.auto.calimero.mgmt.TransportLayerImpl.connect(TransportLayerImpl.java:327) ~[?:?]
	at tuwien.auto.calimero.mgmt.ManagementClientImpl.send(ManagementClientImpl.java:796) ~[?:?]
	at tuwien.auto.calimero.mgmt.ManagementClientImpl.sendWait2(ManagementClientImpl.java:824) ~[?:?]
	at tuwien.auto.calimero.mgmt.ManagementClientImpl.readDeviceDesc(ManagementClientImpl.java:447) ~[?:?]
	at tuwien.auto.calimero.mgmt.ManagementProceduresImpl.isAddressOccupied(ManagementProceduresImpl.java:310) ~[?:?]
	at org.openhab.binding.knx.internal.client.AbstractKNXClient.isReachable(AbstractKNXClient.java:338) ~[?:?]
	at org.openhab.binding.knx.handler.AbstractKNXThingHandler.pollDeviceStatus(AbstractKNXThingHandler.java:144) ~[?:?]
	at org.openhab.binding.knx.handler.AbstractKNXThingHandler.lambda$1(AbstractKNXThingHandler.java:184) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
	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) [?:?]

The communication though works perfectly fine, i.e. they can be used despite the fact that they are displayed as OFFLINE.

As possible work-around is to remove (or comment-out) the address="1.2.3" configuration parameter from such things.

Any help in understanding the reasons why it doesn’t work on some systems/configurations is appreciated!

[kgoderis]

@sjka Simon, on a separate note but related to polling the KNX devices, and based on my own experience with the KNX Basic binding, I would opt to change the behaviour of the Handler slightly, in the sense that the polling or not polling of the device depends solely on the value of the pingInterval, and not the presence of the device address in the configuration of the Thing. For example, if pingInterval = 0 -> no polling. Having the address in the config, with no polling, is interesting to have for further enhancements of the binding. As you mentioned before a long time, either the whole bus is up, or the whole bus is down, so the polling mechanism is somewhat an auxiliary nice to have feature but nothing more…

[sjsf]

Yes, I vaguely remember that - I guess it was too tempting to leave it in, as it was working pretty nicely on those installations where it actually worked at all.

Nevertheless, with @lewie having no idea anymore and seeing @sikksakk’s results, I share your conclusion! I will drop the ONLINE/OFFLINE polling and only keep the device property polling as an optional “nice-to-have” feature, which won’t really hurt if it is not working.