How does everyone connect to the KNX? I have an Weinzierl IP Interface (not router) and had no problems until the last few days (upgraded to 2.2 on christmas).
What I experienced:
my RPi 2 was more stressed than usual (>25% CPU compared to easy <10% usually)
I had accidentially knxd installed in parallel
As I’m using an KNX IP Interface, I normally connect via built in calimero with pretty standard configuration. What did I do yesterday (after having KNX detach Events nearly every 5mins):
deactivated knxd
rebooted my Pi
since then, it seems to work, at least not another detach event.
Do you get double telegrams as described in the github thread? I don’t… My KNX works (and ever had) fine - except the detach events lately, which seem to be solved. #strange
2018-02-23 00:17:37.438 [WARN ] [nx.internal.connection.KNXConnection] - KNX link has been lost (reason: server request on object tunneling link link (closed) 192.168.0.7:3671 TP1 medium, device 1.3.25, hopcount 6)
2018-02-23 00:17:37.443 [INFO ] [nx.internal.connection.KNXConnection] - KNX link will be retried in 10 seconds
2018-02-23 00:17:37.457 [ERROR] [.binding.knx.internal.bus.KNXBinding] - Received detach Event.
2018-02-23 00:17:37.649 [INFO ] [nx.internal.connection.KNXConnection] - Established connection to KNX bus on 192.168.0.7:3671 in mode TUNNEL.
2018-02-23 00:17:47.457 [INFO ] [nx.internal.connection.KNXConnection] - Trying to (re-)connect to KNX...
2018-02-23 00:17:47.496 [INFO ] [nx.internal.connection.KNXConnection] - Established connection to KNX bus on 192.168.0.7:3671 in mode TUNNEL.
2018-02-23 00:17:47.506 [INFO ] [nx.internal.connection.KNXConnection] - Connected to KNX
2018-02-23 00:17:50.515 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Cannot read value for item 'alarmSensorGPS' from KNX bus: no confirmation reply received for L-Data.req from 1.3.25 to 11/7/100, low priority hop count 6 repeat tpdu 00 00: timeout
2018-02-23 00:17:50.519 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Remaining retries for address '11/7/100' = '2'
2018-02-23 00:17:53.576 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Cannot read value for item 'currAzimut' from KNX bus: no confirmation reply received for L-Data.req from 1.3.25 to 11/7/5, low priority hop count 6 repeat tpdu 00 00: timeout
2018-02-23 00:17:53.578 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Remaining retries for address '11/7/5' = '2'
2018-02-23 00:17:56.633 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Cannot read value for item 'currPressureBaro' from KNX bus: no confirmation reply received for L-Data.req from 1.3.25 to 11/7/26, low priority hop count 6 repeat tpdu 00 00: timeout
2018-02-23 00:17:56.637 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Remaining retries for address '11/7/26' = '2'
2018-02-23 00:17:59.693 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Value '-2.3' could not be sent to the KNX bus using datapoint 'command DP 11/7/10 currTemp, DPT main 0 id 9.001, low priority' - retrying one time: no confirmation reply received for L-Data.req from 1.3.25 to 11/7/10, low priority hop count 6 repeat tpdu 00 80 87 1a
2018-02-23 00:18:02.695 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Value '-2.3' could not be sent to the KNX bus using datapoint 'command DP 11/7/10 currTemp, DPT main 0 id 9.001, low priority' - retrying one time: no confirmation reply received for L-Data.req from 1.3.25 to 11/7/10, low priority hop count 6 repeat tpdu 00 80 87 1a
2018-02-23 00:18:05.699 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Cannot read value for item 'blndRight' from KNX bus: no confirmation reply received for L-Data.req from 1.3.25 to 11/5/135, low priority hop count 6 repeat tpdu 00 00: timeout
2018-02-23 00:18:05.703 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Remaining retries for address '11/5/135' = '2'
Thanks for this excellent hint and all your help, Thomas!
After digging deeper in my ETS configuration, I found out that my KNX/IP interface wasn’t able to use more than one tunnel - due to the physical address I assigned. The documentation states clearly that I have to choose an address which is followed by four empty addresses.
Now that the interface is able to use all five tunnels, the issue seems to be gone :-).
I’m experiencing the same problem (my devices: openhab 2.3.0-1 (openhabian 1.4.1) on RPi3, Weinzierl 731 interface, tunnel mode) where my OpenHAB is loosing connection to the IP interface periodically (in different timeframes). @GoldenEye: what exactly did you change in your Weinzierl ETS configuration?
my config:
Bridge knx:ip:bridge [
ipAddress=“192.168.0.xx”,
portNumber=3671,
localIp=“192.168.0.xx”,
type=“TUNNEL”,
readingPause=50,
responseTimeout=5,
readRetriesLimit=10, ← I will comment this out
autoReconnectPeriod=5
]