Bridge Offline - KNX MDT IP Interface

[fetze82]

Hallo OpenHAB Kenner,

ich bin ganz neu in der OpenHAB Welt und gerade am verzweifeln.
Ich habe mir zuhause einen kleinen Teststand aufgebaut. Dort lief eine kleine Anwendung. Jetzt bin ich in unser neues Haus umgezogen. Die Hardware habe ich angeschlossen und ich bekomme keine Verbindung.

Im Haus habe ich eine KNX Installation. Die Verbindung zu OpenHab geht über ein MDT IP Interface (MDT SCN-IP000.03) Dieses geht direkt an meinen Switch. Der Raspi mit Openhabian geht ebenso direkt an den selben Switch.

Übers Wlan kann ich mit dem IP Interface die KNX Devices Programmieren. Ebenso komme ich übers Wlan auf Openhab. Irgendwas ist bei der Verbindung aber nicht richtig eingestellt.

Bei Openhab bekommen ich die Fehlermeldung:
IP Interface: Status Offline, COMMUNICATION_ERROR
error response from control endpoint 192.168.0.50 the requested connection type is not supported

Heute morgen habe ich dein Firmewar Update vom IP Interface gemacht. Dann war das IP Interface Online, aber alle KNX Devices in Openhab als Bridge Error angezeigt. Als Anhang sind screens meiner Einstellungen.

Kann mir jemand einen Tipp geben. Das würde mich riesig freuen.
Danke und grüße
Chris

[udo1toni]

Das Interface unterstützt knx IP Secure und wenn ich den Screenshot richtig deute, ist das auch aktiv. openHAB kann mit knx IP Secure nichts anfangen, das muss abgeschaltet sein.

[fetze82]

Hallo Udo,
vielen dank für die Antwort. Du hast meinen Fehler gefunden.
Wenn ich das Secure Tunneling abschalte funktioniert es!
Vielen lieben dank!!
Grüße
Chris

[julian_august]

Hallo,
darf ich mich kurz hier dran hängen?
Ich setzte aktuell folgendes Interface ein "Weinzierl Modbus TCP Gateway 716". Leider bekomme ich ca. alle 2-4 Tage folgende Meldungen und dann kommt nichts mehr über das Gateway.

Code: Alles auswählen

2022-10-14 22:20:56.866 [WARN ] [NXnet/IP Tunneling 192.168.7.15:3671] - response timeout waiting for confirmation
tuwien.auto.calimero.KNXTimeoutException: no confirmation reply received for 0.0.0->4/0/1 L_Data.req, low priority hop count 6 repeat, tpdu 00 80 b6 14 2c
	at tuwien.auto.calimero.knxnetip.ClientConnection.doExtraBlockingModes(ClientConnection.java:269) ~[bundleFile:?]
	at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:261) ~[bundleFile:?]
	at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:213) ~[bundleFile:?]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend(KNXNetworkLinkIP.java:423) ~[bundleFile:?]
	at tuwien.auto.calimero.link.AbstractLink.send(AbstractLink.java:385) ~[bundleFile:?]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:402) ~[bundleFile:?]
	at tuwien.auto.calimero.process.ProcessCommunicatorImpl.send(ProcessCommunicatorImpl.java:461) ~[bundleFile:?]
	at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:410) ~[bundleFile:?]
	at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:365) ~[bundleFile:?]
	at org.openhab.binding.knx.internal.client.AbstractKNXClient.sendToKNX(AbstractKNXClient.java:473) ~[bundleFile:?]
	at org.openhab.binding.knx.internal.client.AbstractKNXClient.writeToKNX(AbstractKNXClient.java:433) ~[bundleFile:?]
	at org.openhab.binding.knx.internal.handler.DeviceThingHandler.lambda$7(DeviceThingHandler.java:253) ~[bundleFile:?]
	at org.openhab.binding.knx.internal.handler.DeviceThingHandler.withKNXType(DeviceThingHandler.java:148) [bundleFile:?]
	at org.openhab.binding.knx.internal.handler.DeviceThingHandler.withKNXType(DeviceThingHandler.java:142) [bundleFile:?]
	at org.openhab.binding.knx.internal.handler.DeviceThingHandler.handleCommand(DeviceThingHandler.java:248) [bundleFile:?]
	at jdk.internal.reflect.GeneratedMethodAccessor138.invoke(Unknown Source) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
	at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
	at org.openhab.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
	at com.sun.proxy.$Proxy905657.handleCommand(Unknown Source) [?:?]
	at org.openhab.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:80) [bundleFile:?]
	at org.openhab.core.thing.internal.profiles.SystemFollowProfile.onStateUpdateFromItem(SystemFollowProfile.java:60) [bundleFile:?]
	at jdk.internal.reflect.GeneratedMethodAccessor317.invoke(Unknown Source) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
	at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
	at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:829) [?:?]
2022-10-14 22:20:56.874 [WARN ] [nx.internal.client.AbstractKNXClient] - Value '2022-10-14T22:20:44.782+0200' could not be sent to the KNX bus using datapoint 'command DP 4/0/1 'knx:ip:KNX_Gateway', DPT 10.001, low priority': no confirmation reply received for 0.0.0->4/0/1 L_Data.req, low priority hop count 6 repeat, tpdu 00 80 b6 14 2c. Giving up now.
2022-10-14 22:20:56.875 [WARN ] [.internal.handler.DeviceThingHandler] - An error occurred on channel knx:device:KNX_State:cSA_NtpUhrzeit: no confirmation reply received for 0.0.0->4/0/1 L_Data.req, low priority hop count 6 repeat, tpdu 00 80 b6 14 2c
tuwien.auto.calimero.KNXTimeoutException: no confirmation reply received for 0.0.0->4/0/1 L_Data.req, low priority hop count 6 repeat, tpdu 00 80 b6 14 2c
	at tuwien.auto.calimero.knxnetip.ClientConnection.doExtraBlockingModes(ClientConnection.java:269) ~[bundleFile:?]
	at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:261) ~[bundleFile:?]
	at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:213) ~[bundleFile:?]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend(KNXNetworkLinkIP.java:423) ~[bundleFile:?]
	at tuwien.auto.calimero.link.AbstractLink.send(AbstractLink.java:385) ~[bundleFile:?]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:402) ~[bundleFile:?]
	at tuwien.auto.calimero.process.ProcessCommunicatorImpl.send(ProcessCommunicatorImpl.java:461) ~[bundleFile:?]
	at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:410) ~[bundleFile:?]
	at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:365) ~[bundleFile:?]
	at org.openhab.binding.knx.internal.client.AbstractKNXClient.sendToKNX(AbstractKNXClient.java:473) ~[bundleFile:?]
	at org.openhab.binding.knx.internal.client.AbstractKNXClient.writeToKNX(AbstractKNXClient.java:433) ~[bundleFile:?]
	at org.openhab.binding.knx.internal.handler.DeviceThingHandler.lambda$7(DeviceThingHandler.java:253) ~[bundleFile:?]
	at org.openhab.binding.knx.internal.handler.DeviceThingHandler.withKNXType(DeviceThingHandler.java:148) [bundleFile:?]
	at org.openhab.binding.knx.internal.handler.DeviceThingHandler.withKNXType(DeviceThingHandler.java:142) [bundleFile:?]
	at org.openhab.binding.knx.internal.handler.DeviceThingHandler.handleCommand(DeviceThingHandler.java:248) [bundleFile:?]
	at jdk.internal.reflect.GeneratedMethodAccessor138.invoke(Unknown Source) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
	at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
	at org.openhab.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
	at com.sun.proxy.$Proxy905657.handleCommand(Unknown Source) [?:?]
	at org.openhab.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:80) [bundleFile:?]
	at org.openhab.core.thing.internal.profiles.SystemFollowProfile.onStateUpdateFromItem(SystemFollowProfile.java:60) [bundleFile:?]
	at jdk.internal.reflect.GeneratedMethodAccessor317.invoke(Unknown Source) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
	at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
	at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:829) [?:?]

Vielleicht könnt ihr mir ein stabiles IP Interface nennen oder erkennt sogar den Grund weshalb mein Weinzierl ausfällt. Auf eine Ping Anfrage kommt sofort einen Antwort und wenn ich dann die ETS öffne und Verbinde bekommt dies auch wieder alle Protokolle.

Bin generell nicht so vom Interface überzeugt, da der Modbus Teil auch nicht korrekt mit meinem SMA Tripower kommunizieren kann. Der Support von Weinzierl ist echt super, kann sich aber auch nicht erklären weshalb die Kommunikation über Modbus TCP zum SMA Tripower nicht geht. Dies nur als Info Falls jemand mit dem Gedanken spielt sich dieses Gateway zu kaufen.

Gruß Julian

[udo1toni]

Das ist leider Stochern im Nebel.
Ganz grundsätzlich wird irgendwann die Verbindung zum Gateway aus irgendeinem Grund gestört und in der Folge nicht mehr automatisch wiederhergestellt.
Der Letzte Punkt (das automatische Wiederherstellen einer unterbrochenen Verbindung) ist leider schon immer ein Problem diverser Addons, knx ist hier also kein besonderer Problemfall.
Allgemein gibt es viele Möglichkeiten, warum eine Verbindung abbricht, das können Störungen im LAN sein, ein Wackelkontakt, eine andere Software... ohne eine exakte Analyse des gesamten Datenverkehrs wird es schwierig werden, das einzugrenzen (weshalb dieses Problem auch immer mal wieder hoch kommt).
Vielleicht kann einer der Entwickler was dazu sagen, die wirst Du allerdings nur im englischen Forum finden können. Ich weiß auch nicht, ob momentan überhaupt jemand aktiv am knx Addon weiter entwickelt (wobei wohl zumindest knx Secure irgendwann aktivierbar werden soll, also müsste es jemanden geben...)

Eigentlich sollte jedes Addon selbst erkennen, wenn es keinen Kontakt mehr hat und diesen selbständig wieder herstellen - eigentlich.

[julian_august]

Hallo,
zuerst mal vielen Dank für deine Antwort.
Nachdem ich nun ca. alle drei Tage in dieses Problem laufe habe ich mir überlegt, jede Minute abzufragen ob ein bestimmtes Item längere Zeit kein update mehr bekommen hat.

Über Blocky habe ich das ganze nun hin bekommen.

blocky.png

Leider würde ich es aber gerne in VS Code machen.
Wie kann ich hier die Funktion "run rule or script" verwenden die ich im Blocky verwendet habe um das Scrit zum Stoppen/Starten an zu schucken.

script.png

Oder gibt es gar eine noch elegantere Lösung.
Leider bleibt das KNX Binding ja online.

Danke schon mal für eure / deine Zeit.

Gruß Julian

[udo1toni]

Du kannst mal spaßeshalber die Autoreconnect Period auf 90 Sekunden einstellen. Zu niedrige Werte (30 Sekunden ist Minimum!) sind kontraproduktiv - das System kommt nicht mehr auf die Beine. Ich hatte das vorher nicht gesehen.

Eine DSL Rule, die das Update eines Items checkt wäre umgekehrt sinnvoller:

Code: Alles auswählen

var Timer tTimeout = null

rule "update timeout"
when
    Item MQTTopenWB_cEVUaktuelleLeistung received update
then
    if(tTimeout === null) {
        tTimeout = createTimer(now.plusSeconds(90), [|
            logWarn("timeout","Item MQTTopenWB_cEVUaktuelleLeistung seti 90 Sekunden ohne Update!")
            executeCommandLine("/bin/bash","script.sh")
            Thread::sleep(3000)
            executeCommandLine("/bin/bash","script.sh")
            tTimeout.reschedule(now.plusSeconds(180))
        ])
    } else {
        tTimeout.reschedule(now.plusSeconds(90))
    }
end

Die Rule trigert jedes Mal, wenn es ein Update des Items gibt.
Wenn der Timer nicht existiert (die Variable tTimeout zeigt auf null), wird ein Timer angelegt, der 90 Sekunden in der Zukunft abläuft. Existiert der Timer schon, so wird der Zeitpunkt zum Ausführen des Codes auf 90 Sekunden in der Zukunft gesetzt.
Läuft der Timer ab, wird eine Warnmeldung geloggt, anschließend wird ein Bash Script ausgeführt, danach wartet der Code drei Sekunden und führt das Script erneut aus. Zum Abschluss wird der Timer drei Minuten in der Zukunft erneut geplant.

Der Code ist als Beispiel zu verstehen, wie man so ein Timeout umsetzt. Wenn es darum geht, ein Addon per Script neu zu starten, böte es sich an, den gesamten Prozess (Addon stoppen, warten, Addon starten) ins Script zu packen, statt zwei Scripte aufzurufen und zwischen den beiden Aufrufen eine Pause einzulegen.

[julian_august]

Guten Abend,

Danke für den Code.
Der Timer wird auch erfolgreich getriggert, leider wird das ECMA Script nicht angestoßen.

Code: Alles auswählen

var Timer tTimeout = null

rule "KNX Bridge down?"
when
    Item OWB_EMU_Aktuelle_Leistung received update
then
    if(tTimeout === null) {
        tTimeout = createTimer(now.plusSeconds(90), [|
            logWarn("timeout","Item MQTTopenWB_cEVUaktuelleLeistung seti 90 Sekunden ohne Update!")
            executeCommandLine("/bin/bash","KnxGatewayDisable.sh")
            Thread::sleep(3000)
            executeCommandLine("/bin/bash","KnxGatewayEnable.sh")
            tTimeout.reschedule(now.plusSeconds(180))
        ])
    } else {
        tTimeout.reschedule(now.plusSeconds(90))
    }
end

Du hast vollkommen Recht, alles in eine Rule zu packen und nicht aus einer Rule die zwei Scripte aufzurufen.
Leider kann ich in meiner DSL Rule nicht auf osgi oder Java zugreifen und dies verwendet ja das Script.

Gruß Julian

[julian_august]

Inzwischen hat sich das Problem erledigt. Habe alle Channels nochmals neu angelegt.
Seitdem ist Ruhe und es läuft sehr zuverlässig!
Danke nochmals für die Unterstützung.

[AGH]

Ich muss mich hier mal einhängen, denn meine Bridge geht auch offline:

Code: Alles auswählen

tuwien.auto.calimero.KNXTimeoutException: no confirmation reply received for 0.0.0->1.1.51 L_Data.req, low priority hop count 6 repeat, tpdu 43 00

Mit der Meldung kann ich nichts anfangen.
Dies ist meine Konfiguration:

Code: Alles auswählen

Bridge knx:ip:bridge "1.1.1 | HV D2: IP Schnittstelle" @ "KNX"[ 
    ipAddress="10.3.2.6", 
    //portNumber=3671, 
    type="TUNNEL",
    //readingPause=100,
    //responseTimeout=15,
    readRetriesLimit=6, 
    autoReconnectPeriod=60
    //localSourceAddr="0.0.0"
]

Thing device Musik-1-1-51 "1.1.51 | Musik: Jung 4194TSM" @ "Musik"[
        address="1.1.51"
        //fetch=false,
        //pingInterval=600,
        //readInterval=10
    ]
    {
		Type number : Temperatur 	"Musik: Temperatur"	   	    	    [ga="3/7/33"]
    }

Das ganze läuft auf einem Raspberry 4, weitere Dienste sind Apache (Nextcloud und PHP) Webmin, Grafana, Frontail
Loadaverage liegt bei 0.3
Warum ich das angebe, weil bei mir manchmal der Eindruck entsteht, als ob das KNX-Binding ein Timingproblem hat. Nachweisen kann ich das nicht. Dafür tritt der Fehler zu sporadisch auf.
Noch eine Ergänzung, weil es mir gerade einfällt, alle KNX Things waren alle online, aber es ließ sich nichts steuern. Erst nach abschalten eines Things, kam der online-Status nicht zurück. Erst der Neustart der Bridge hat dann alles wieder ermöglicht.