knxd empfängt nur noch Daten, sendet aber keine mehr

[Smurf]

Statt den ganzen knxd neu zu starten, kannst du "-A retry-delay=1 -A retry-max=2 -b tpuarts:…" versuchen.

[Klaus Gütter]

Hallo Matthias,

Das Problem mit dem Multicast sind leider Kompatibilitätsprobleme, vulgo: die ETS5 hat da einen Bug. Wurde bereits eingekippt, hat aber soweit ich weiß noch nix geholfen.

Da weiß ich nichts davon. Hast du eine SupportCase-Nummer?

Übrigens kann man das alles auch mit der ETS5-Demo testen, Lizenz nicht erforderlich.

Gruß, Klaus

[misa]

Statt den ganzen knxd neu zu starten, kannst du "-A retry-delay=1 -A retry-max=2 -b tpuarts:…" versuchen.

Danke. Hab die Konfig angepasst. Mal sehen, ob die Fehler verschwinden :-)

[misa]

Kurzer Update: Die Fehler im knxd Log sind jetzt vollständig verschwunden. Ich bin begeistert.
Ich bin überzeugt, dass ich nicht der einzige mit meinem Hardware / Software Setup bin.
Es würde aus meiner Sicht Sinn machen, das als Best Practice zu dokumentieren.

Hat jemand einen Vorschlag, wo ich das am Besten unterbringen soll? Ich könnte es z.B. im knxd Wiki auf Git-Hub dokumentieren.

[Smurf]

misa

Aug 01 11:11:56 raspberrypi knxd[20173]: E00000055: [15:A.tpuarts] Driver timed out trying to send (A.tpuarts)
Aug 01 11:11:56 raspberrypi knxd[20173]: F00000000: [15:A.tpuarts] Link down, terminating

Diese Meldungen sind nicht wegen der Konfig-Änderung weg, sondern aus Zufall oder weil du noch irgendwas Anderes geändert hast. Im Gegenteil hast du, eben weil diese Meldungen seitdem nicht mehr gesehen hast, die retry-Funktion im Grunde noch gar nicht ausprobiert.

Ansonsten ist ein Hinweis im Wiki sicher nicht verkehrt. Die retry-Optionen sind noch ziemlich neu und nur mäßig getestet, daher auch nicht der Default.

[misa]

misa

Diese Meldungen sind nicht wegen der Konfig-Änderung weg, sondern aus Zufall oder weil du noch irgendwas Anderes geändert hast. Im Gegenteil hast du, eben weil diese Meldungen seitdem nicht mehr gesehen hast, die retry-Funktion im Grunde noch gar nicht ausprobiert.

Ggf. ist es weg wegen den dem delay=1. Ich habe ansonsten nichts geändert und einiges an Action auf den Bus gebracht.
Naja, da staunt der Laie und der Fachmann wundert sich....

[misa]

OK, ich muss mich korrigieren. Da ist der Issue wieder:

Aug 04 15:02:45 raspberrypi systemd[1]: Starting KNX Daemon...
Aug 04 15:02:45 raspberrypi systemd[1]: Started KNX Daemon.
Aug 04 19:11:15 raspberrypi knxd[463]: E00000055: [15:A.tpuarts] Driver timed out trying to send (A.tpuarts)
Aug 04 19:11:15 raspberrypi knxd[463]: E00000000: [17:A.tpuarts] send timeout: too many retries

Und diesmal gabs keinen Re-Start von Daemon. Musste per Hand starten.

[Smurf]

OK, danke für den Hinweis, ich seh mir das demnächst mal genauer an. Bis dahin empfehle ich dir, die retry-Parameter wieder rauszunehmen.

[misa]

OK, danke für den Hinweis, ich seh mir das demnächst mal genauer an. Bis dahin empfehle ich dir, die retry-Parameter wieder rauszunehmen.

Ooops, habe noch gesehen, dass ich eine fehlerhafte Konfiguration hatte. Es war nur der Retry-Delay gesetzt und nicht der Max-Retry Parameter. Werde das nochmals testen.

Manchmal bekomme ich auch noch diesen hübschen Fehler: F00000051: [19:router] internal error: send_more is not set
Gib bitte bescheid, wenn ich mal den Trace mitlaufen lassen soll.

[Intenos]

Hallo Community,
nachdem ich jetzt schon mehrere Tage damit Kämpfe das Openhab2 auf meinen KNX-Bus schreibt, bin ich auf diesen Thread gestoßen wo von MoA am 30.06.2017 genau mein Problem beschrieben wird:

• Verbindung von ETS5 auf KNX-Bus funktioniert ohne Probleme (Programmierung & Diagnose)
• knxtool groupswrite funktioniert, knxtool vbusmonitor funktioniert
• OH2 empfängt Temperaturwerte sowie die Info wenn ein Schalter betätigt wurde, kann aber keine Infos auf den KNX Bus senden. Weder Temperaturen, Datum/Uhrzeit noch das Signal zur Betätigung eines Schalters. Sowohl der Router als auch Tunnel-Modus in openHAB funktionieren gleichermaßen.

Mein System setzt sich folgendermaßen zusammen:

• Hardware:
  • Raspberry 3
  • Pigator Onewire mit KNX TPUART Erweiterung
• Software:
  • Raspbian Jessie
  • knxd 0.14
  • openHAB 2.1.0
  • knx binding 1.10.0
• Konfiguration:
  • knxd:
    • KNXD_OPTS="-e 0.0.1 -E 0.0.2:9 -D -T -R -S -b tpuarts:/dev/ttyAMA0"
  • knx.cfg (Router-Modus)
    • ignorelocalevents = true
    • ip = 224.0.23.12
    • localIp = 192.168.178.44 (IP des Raspberry)
    • service.pid = org.openhab.knx
    • type = ROUTER

Folgendes wird bspw. von openHAB geloggt beim Betätigen des Schalters aus openHab heraus:
00:11:28.989 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'Licht_EG_Esszimmer' received command OFF
00:11:28.990 [DEBUG] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: cEMI L-Data.ind from 0.0.2 to 0/1/0, low priority hop count 6 tpdu 00 80
00:11:28.993 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: add to multicast loopback frame buffer: L-Data.ind from 0.0.2 to 0/1/0, low priority hop count 6 tpdu 00 80
00:11:28.996 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: sending cEMI frame seq 0, non-blocking, attempt 1 (channel 0) 06 10 05 30 00 11 29 00 bc e0 00 02 01 00 01 00 80
00:11:28.998 [DEBUG] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: send to 0/1/0 succeeded
00:11:29.001 [DEBUG] [tuwien.auto.calimero ] - process 224.0.23.12:3671: group write to 0/1/0 succeeded
00:11:29.003 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: discard multicast loopback cEMI frame: L-Data.ind from 0.0.2 to 0/1/0, low priority hop count 6 tpdu 00 80



Ich hoffe irgend jemand hat eine Idee und kann mir weiter helfen.

[misa]

Hallo Community,
nachdem ich jetzt schon mehrere Tage damit Kämpfe das Openhab2 auf meinen KNX-Bus schreibt, bin ich auf diesen Thread gestoßen wo von MoA am 30.06.2017 genau mein Problem beschrieben wird:

• Verbindung von ETS5 auf KNX-Bus funktioniert ohne Probleme (Programmierung & Diagnose)
• knxtool groupswrite funktioniert, knxtool vbusmonitor funktioniert
• OH2 empfängt Temperaturwerte sowie die Info wenn ein Schalter betätigt wurde, kann aber keine Infos auf den KNX Bus senden. Weder Temperaturen, Datum/Uhrzeit noch das Signal zur Betätigung eines Schalters. Sowohl der Router als auch Tunnel-Modus in openHAB funktionieren gleichermaßen.

Mein System setzt sich folgendermaßen zusammen:

• Hardware:
  • Raspberry 3
  • Pigator Onewire mit KNX TPUART Erweiterung
• Software:
  • Raspbian Jessie
  • knxd 0.14
  • openHAB 2.1.0
  • knx binding 1.10.0
• Konfiguration:
  • knxd:
    • KNXD_OPTS="-e 0.0.1 -E 0.0.2:9 -D -T -R -S -b tpuarts:/dev/ttyAMA0"
  • knx.cfg (Router-Modus)
    • ignorelocalevents = true
    • ip = 224.0.23.12
    • localIp = 192.168.178.44 (IP des Raspberry)
    • service.pid = org.openhab.knx
    • type = ROUTER

Folgendes wird bspw. von openHAB geloggt beim Betätigen des Schalters aus openHab heraus:
00:11:28.989 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'Licht_EG_Esszimmer' received command OFF
00:11:28.990 [DEBUG] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: cEMI L-Data.ind from 0.0.2 to 0/1/0, low priority hop count 6 tpdu 00 80
00:11:28.993 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: add to multicast loopback frame buffer: L-Data.ind from 0.0.2 to 0/1/0, low priority hop count 6 tpdu 00 80
00:11:28.996 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: sending cEMI frame seq 0, non-blocking, attempt 1 (channel 0) 06 10 05 30 00 11 29 00 bc e0 00 02 01 00 01 00 80
00:11:28.998 [DEBUG] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: send to 0/1/0 succeeded
00:11:29.001 [DEBUG] [tuwien.auto.calimero ] - process 224.0.23.12:3671: group write to 0/1/0 succeeded
00:11:29.003 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: discard multicast loopback cEMI frame: L-Data.ind from 0.0.2 to 0/1/0, low priority hop count 6 tpdu 00 80



Ich hoffe irgend jemand hat eine Idee und kann mir weiter helfen.

Ich kann nur dringend raten, knxd im Router Modus zu verwenden.
Bitte beachte: fixe IP Adresse im R-Pi setzen, kein DHCP und in der knxd Konfiguration das Multi-Port flag setzen (siehe weiter oben in dieser Diskussions), da es sonst nicht gut mit dem Multicast klappt.

[Intenos]

Eine fixe IP-Adresse hat mein Raspberry.

Das mit "-A multi-port=true" habe ich mit viel Hoffnung auch schon probiert:
KNXD_OPTS="-e 0.0.1 -E 0.0.2:9 -D -T -R -A multi-port=true -S -b tpuarts:/dev/ttyAMA0"

Allerdings hat es leider nicht zum Erfolg geführt. Ich kann nach wie vor nicht von openHab aus auf den KNX-Bus schreiben. Stattdessen bricht mit dem Multi-Port Flag die Verbindung des ETS5 Gruppenmonitor regelmäßig ab wohingegen es zuvor absolut stabil lief.

Entschuldigt die Anfängerfrage, aber wie komm ich denn an das knxd Logging heran wenn ich das mittels "-f9 -t1023" aktiviere?

[Intenos]

Hallo allerseits,
hat irgend jemand noch eine Idee woran es liegen könnte das openHab Daten vom KNX-Bus empfängt, jedoch nichts auf den Bus senden kann?

Nach mehrfachen Versuchen funktioniert bei mir die KNDX Konfiguration ohne "multi-port=true" deutlich stabiler, zumindest was bspw. die Kommunikation mit ETS5 angeht.

Ich wäre um jede Idee dankbar.

Viele Grüße,
Tobias

[chris5020]

Ich bin mir nicht sicher, ob das hier passt, klingt aber sehr nach einem ähnlichen Problem:

Ausgangssituation:
KNXD auf einem Rasperry PI, verbindet sich per ipt auf ein Wiregate als Interface.

Funktioniert soweit einwandfrei, kann auch mit knxtool Befehle an den Bus senden oder den Bus auslesen.

Fällt jetzt das Netzwerk kurz aus und stecke ich es wieder an, dann funktioniert alles einwandfrei.
Wenn ich aber im ausgesteckten Zustand z.B. ein

knxtool on ip:localhost 1/1/81

mache, dann funktioniert nach dem Anstecken kein Senden mehr.

Das Lesen, z.B. mit

knxtool groupsocketlisten ip:localhost

funktioniert weiterhin.

Ein Neustart des Service löst das Problem.

Gibt es dafür eine Lösung, oder kann ich das irgendwie automatisch erkennen und restarten?

danke, Christian

[vento66]

Warum macht ihr euch das Leben so schwer? Auf dem Wiregate läuft doch schon ein eibd. Warum einen knxd an einen eibd hängen? Das Wiregate alleine reicht doch als Buszugriff.