[SOLVED] KNX2 - massive problems

Add-ons Bindings
1

Dear all,

I’m trying to upgrade from KNX1 to KNX2, but this just drives me crazy…
In principle, I managed to control the KNX also with KNX2 quite fast, but I can’t get rid of the “response timeout waiting for confirmation” warning, no matter what I try.
My HW/SW configuration is OH2 2.4.0 on raspbian, the KNX-IF is a MDT SCN-IP000.01.

The .things file looks like

Bridge knx:ip:SCN-IP "KNX/IP Gateway" @ "KNX" [ 
    type="TUNNEL", 
    ipAddress="192.168.178.27", 
    portNumber=3671, 
    localIp="192.168.178.41", 
    readingPause=500, 
    responseTimeout=500, 
    readRetriesLimit=3, 
    autoReconnectPeriod=0,
    localSourceAddr="1.0.1"
] {
    Thing device AKD-0401_1 "Dimmer 1 (4 Ch)" @ "KNX" [
        address="1.0.11",
        fetch=false,
        pingInterval=600,
        readInterval=0
    ] {
        Type dimmer     : Ch_1        "Dimmer 1.1"   [ switch="2/1/17+<2/2/17", position="2/4/17+<2/5/17", increaseDecrease="2/3/17" ]
        Type dimmer     : Ch_2        "Dimmer 1.2"   [ switch="2/1/18+<2/2/18", position="2/4/18+<2/5/18", increaseDecrease="2/3/18" ]
        Type dimmer     : Ch_3        "Dimmer 1.3"   [ switch="2/1/16+<2/2/16", position="2/4/16+<2/5/16", increaseDecrease="2/3/16" ]
        Type dimmer     : Ch_4        "Dimmer 1.4"   [ switch="2/1/19+<2/2/19", position="2/4/19+<2/5/19", increaseDecrease="2/3/19" ]
    }
}

Soon as OH2 is starting, I get continuous WARNings like

2019-02-10 17:06:28.882 [WARN ] [net/IP Tunneling 192.168.178.27:3671] - response timeout waiting for confirmation
tuwien.auto.calimero.KNXTimeoutException: no confirmation reply received for 1.0.1->2/5/18 L_Data.req, low priority hop count 6 repeat, tpdu 00 00
	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.process.ProcessCommunicatorImpl.readFromGroup(ProcessCommunicatorImpl.java:418) ~[?:?]
	at tuwien.auto.calimero.process.ProcessCommunicatorImpl.read(ProcessCommunicatorImpl.java:346) ~[?:?]
	at org.openhab.binding.knx.internal.client.AbstractKNXClient.readNextQueuedDatapoint(AbstractKNXClient.java:284) ~[?:?]
	at org.openhab.binding.knx.internal.client.AbstractKNXClient.lambda$1(AbstractKNXClient.java:199) ~[?:?]
	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) [?:?]

As I did not find any solution for this issue, I decided to ignore the warnings by setting the log-level for the KNX-IF to ERROR, but with no success.

Logger                               │ Level
─────────────────────────────────────┼──────
ROOT                                 │ WARN
...
org.openhab                          │ INFO
org.openhab.binding.knx              │ ERROR
...
tuwien.auto.calimero                 │ ERROR

But still the WARNings appear in the log file.

Has anyone got a clue

  • If the MDT KNX-IP000.01is not fully supported?
  • If I’ve got an issue in my Things file?
  • How to change the Log-Level for the above warnings?

For the time beeing I will switch back to KNX1.

Regards,
Dirk

2

You can’t use knx1 and kn2 at the same time. did you uninstall knx1 before installing knx2?

Please ensure that no old configuration was left (i.e. delete knx.cfg AND delete the configuration by using the karaf console

config:edit org.openhab.knx
config:property-list
config:property-delete (for each option found)
config:update

Please be aware that you are using very uncommon values for the bridge, consider to only set type and ipAddress, don’t set other values at all.

3

Hi Udo,
thanks for your help.
KNX1 was disabled and the knx.cfg removed.
Do I need to delete the configuration via Karaf even after stopping/ re-starting Openhab?
What values do you mean with “uncommon values”?
OK, I’ve increased the readingPause and responseTimout in trying to solve my issues, but the other values should be fine as far as I understand the documentation.
Yesterday evening I read something that there might be an issue if the IP-IF is not on KNX address 0.0.0; I will try to adopt this tonight.

4

Well, at least, the configuration is not actively deleted because you deleted the knx.cfg. restarting openHAB will not help either, as the configuration is stored in another file and reread from this source on startup.
I don’t know if openHAB itself will actively delete configuration when uninstalling the knx1 addon, but as you are getting WARN messegas although knx is set to ERROR…

readingPause=500, 
responseTimeout=500, 
autoReconnectPeriod=0,
localSourceAddr="1.0.1"

The common way to eliminate warnings would be to set as less as possible parameters (i.e. only type="TUNNEL", ipAddress="192.168.178.27") and not experimenting :wink: with parameters…

5

Hi Udo,

it looks like my problems are solved.
The issues have most probably been the missing deletion in the Karaf console and the localSourceAddr="1.0.1"
For type="TUNNEL" it looks like the localSourceAddr must always be "0.0.0", independent of what is configured in ETS.

6

localSourceAddr has to be an unused individual address, i.e. it must not be used anywhere else. This is the individual address of openHAB itself (or the knx part of openHAB) If using the Group Monitor in ETS, you will see all GA sent from openHAB with this individual address. by setting it to 0.0.0, the Interface itself will choose the address (not necessarily always the same)

7

OK, I understood the documentation wrong and thought the local adress of the ETH-IF should be provided in localSourceAddr.

But it’s still weird. If I choose 1.0.2, which is definitely free, I get the error messages again…
If I leave it at 0.0.0 openhab chooses 15.15.250 and everything is OK.

:thinking: so I’ll just leave it at 0.0.0 and let OH decide, up to now I don’t care which adress is used in the end.

8

For me it’s the same. When defining localSourceAddr by myself I get such warnings:

An error occurred on channel knx:device:GIRA2168:GENERIC:Licht_EG_Arbeitszimmer_Schalten: no confirmation reply received for 1.9.99->0/1/26 L_Data.req, low priority hop count 6 repeat, tpdu 00 80

After setting the localSourceAddr="0.0.0" the warnings are gone.

9

Now things get really weird. I had openHAB running with localSourceAddr=15.15.250 since mid of February without any issues. Suddenly two nights ago (at 4:30 AM) all my KNX Things went to status OFFLINE and whatever I tried I could not get them back to ONLINE.
After setting the localSourceAddr=0.0.0 it worked again with OH2 talking/listening on 1.0.2. So I set localSourceAddr=1.0.2 (which did not work earlier, see 2 posts above) and everything is fine since then.
But for how long?

Note: I do not like to leave it on 0.0.0 as I like to know who is who on the bus when working with ETS.