Probleme mit KNXnet/IP-Tunnel und Routeranbindung

[coliflower]

Update:

ich habe nun wieder 4 Einträge, die letzten zwei wurden schon besprochen, anscheinend gehen hier Telegramme verloren oder Edomi konnte die nicht lesen, was auch immer ...

Der erste Eintrag ist relativ neu ...

2016-01-06 12:01:16 005850 KNX 8482 ERROR: HEARTBEAT TIMEOUT (no ACK). Reconnect... ERROR
2016-01-06 12:01:16 016722 KNX 8482 KNX-Verbindung verloren, Reconnect... ERROR
2016-01-06 12:07:02 072067 KNX 8482 ERROR: IPRTR --> RECEIVE 1.1.13 ---> 0/2/10 = 30494.72 / Rtg:88!=89 Size:3 / 061004200017042c58002900bce0110d020a0300805dd1 ERROR
2016-01-06 12:07:03 112569 KNX 8482 ERROR: IPRTR --> RECEIVE 1.1.13 ---> 0/2/13 = 135.84 / Rtg:89!=90 Size:3 / 061004200017042c59002900bce0110d020d0300801ea2 ERROR

[gaert]

Naja... Dann wäre es allerdings sinnvoller, wenn EDOMI (so wie ganz am Anfang des Projekts) direkt per Socket mit eibd plaudert. Sonst wäre es ein wenig redundant:

EDOMI spricht "Router", eibd emuliert "Router", eibd kommuniziert mit Bus

Dann lieber so:

EDOMI spricht (per Socket) mit eibd, eibd kommuniziert mit Bus

[gaert]

Update:

ich habe nun wieder 4 Einträge, die letzten zwei wurden schon besprochen, anscheinend gehen hier Telegramme verloren oder Edomi konnte die nicht lesen, was auch immer ...

Der erste Eintrag ist relativ neu ...

2016-01-06 12:01:16 005850 KNX 8482 ERROR: HEARTBEAT TIMEOUT (no ACK). Reconnect... ERROR
2016-01-06 12:01:16 016722 KNX 8482 KNX-Verbindung verloren, Reconnect... ERROR
2016-01-06 12:07:02 072067 KNX 8482 ERROR: IPRTR --> RECEIVE 1.1.13 ---> 0/2/10 = 30494.72 / Rtg:88!=89 Size:3 / 061004200017042c58002900bce0110d020a0300805dd1 ERROR
2016-01-06 12:07:03 112569 KNX 8482 ERROR: IPRTR --> RECEIVE 1.1.13 ---> 0/2/13 = 135.84 / Rtg:89!=90 Size:3 / 061004200017042c59002900bce0110d020d0300801ea2 ERROR

Heartbeat-Timeout... Sprich: Der Router reagierte nicht auf den Heartbeat. Dies wird ein Problem des Routers oder der Netzwerkverbindung sein!

Die andere Meldung ist vom Routingcounter: Hier sind offenbar Telegramme verloren gegangen. Dafür kann EDOMI nichts...

Ich hatte bei mir innerhalb 1/2 Jahres genau 1 Telegramm mit dieser Fehlermeldung. Warum auch immer - es war quasi "kaputt" Das ist aber grundsätzlich nichts Schlimmes - der physische KNX-Layer ist ja entsprechend darauf vorbereitet (daher gibt es ja den Routingzähler).

[ulrich]

Bei mir funktioniert jetzt der Gira KNX/IP Router (2167 00 - V2.0 901610) auch problemlos.
Gruppenadressen importiert.
Schalten und Dimmen getestet.
Keine Fehler mehr in den Logs.

[gaert]

Ausgezeichnet Ich denke, das Problem ist gelöst - war mein Fehler...

[toggle]

Zur Info:
In meinem Test hatte EDOMI Daten vom eibd bekommen. Im EDOMI-Gruppenmonitor erschien alles korrekt. Sobald ich aber Datenarchive für 2 Gruppenadressen angelegt hatte, hat eibd für diese Gruppenadressen keine Daten an smarthome.py weitergegeben, bis EDOMI beendet wurde. Alles andere lief wie gewohnt.

PS: Es ist mir klar, dass es sich um eine (noch) nicht unterstützte Konfiguration handelt.

[SeatSLF]

ist der eibd den mit routing Funktion?

[gaert]

Datenarchive haben mit eibd nichts zu tun... Das Problem wird wohl an anderer Stelle zu suchen sein

Nochmal zur Sicherheit: eibd wird von EDOMI nicht offiziell unterstützt und wird's auch nie werden! EDOMI spricht ausschliesslich(!) direkt mit einem IP-Router/Schnittstelle.

[wintermute]

Hallo,

fürs Protokoll, ich habe exakt dieselben Probleme mit einer KNX-Wago wie hier beschrieben:
https://knx-user-forum.de/forum/proj...400#post901400

Scheinbar kann ich zwar auf den Bus schreiben, aber kurioserweise nicht lesen. Anders ausgedrückt:
-Tunnel PA wird (laut EDOMI Log) korrekt zugewiesen - Tunnelzugang prinzipiell funktioniert natürlich (zB via ETS)
-ich kann über die EDOMI Visu schalten
-EDOMI Initscans laufen in Timeouts
-extern ausgelöste Schaltvorgänge werden von EDOMI registriert (kann man im KO Livelog schön nachvollziehen)

Beim Initscan sehe ich auch keine Leseanfragen im ETS-Busmonitor, die bleiben augenscheinlich irgendwo kleben. Was ich jetzt irgendwie extremst sch..ade finde

gruesse :: Michael

[gaert]

Das tut mir leid - aber ich kann dazu nichts sagen... Offenbar funktioniert es ja mit den gängigen Routern/Schnittstellen ohne Probleme. EDOMI hält sich strikt an die KNX-Spec, also ist das Problem vermutlich bei dem Wago-Gerät verwurzelt?! Ohne ein solches kann ich natürlich keine Ursachenforschung betreiben...

[wintermute]

Ja, verstehe ich. Irgendwelche Debug-Logs die näheren Aufschluss bringen können lassen sich nicht aus EDOMI rauskitzeln, oder?
Oder könnte man vllt nen eibd im EDOMI CentOS verbuddeln, der zwischen Tunnel-Modus und Multicast vermittelt? Weiss irgendwer ob der eibd sowas hergeben würde?

gruesse :: Michael

[gaert]

Macht das Wago-Gerät denn nun Multicast oder Tunneling?! EDOMI kann "nur" Tunneling...

Die Urversion von EDOMI konnte nur Multicast (ironischer Weise), aber ich habe davon Abstand genommen (obwohl es viel einfach zu implementieren ist), da zumindest per WLAN häufig Telegramme verloren gingen. Hängt natürlich stark von der Infrastruktur ab - aber zumindest bei mir war Multicast nicht zufriedenstellend. Daher habe ich Tunneling implementiert - deutlich aufwändiger, aber m.E. auch stabiler.

[wintermute]

Ich beschränke mich mit Antworten zur Wago jetzt mal auf diesen Fred, sonst wird das alles zu verwirrend...

Das Gerät kann beides (wenn man will, kann es auch nur im Gerätemodus arbeiten - der Vollständigkeit halber erwähnt). Ich nutz(t)e bisher ausschliesslich Multicasts weswegen ich von der Tunnelei jetzt auch keine Ahnung habe
Was ich nicht verstehe ist erstmal, dass ich der Wago selber keine Tunnel-PA mitgeben kann, ich kann die aktuelle aber über die Wago-Web-GUI abfragen. Setzte ich jetzt über die ETS Kommunikationseinstellungen eine PA, dann wird die auch von der Wago übernommen und die ETS funktioniert komplett wie erwartet (abgesehen vom Busmonitor, aber AFAIK ist das "by-design"). Die über die ETS vergebene PA ist dann auch die, die in EDOMI auftaucht... Was vllt alles damit zu tun hat, dass die WAgo nur einen Tunnel aufbauen kann - ob das jetzt aber so Standard-konform ist oder nicht kann ich leider nicht sagen...

Aber "prinzipiell" funktionieren tut es - ich kann via EDOMI Lampen schalten und sehe korrekte Diagramme im Busmonitor der ETS (der dann natürlich über Multicasts verbindet).

[gaert]

Mal ganz zaghaft nachgefragt: Die GAs hast Du aber schon in EDOMI bekannt gemacht - einschl. DPT? Und die DPTs werden auch unterstützt? (aktuell: 1,5,7,8,9,10,11,13,232)

[wintermute]

Ich hab extra vorsichtig angefangen und mich auf DPT1 beschränkt
2/0/30 schaltet (über ein DALI-Gateway) eine Lampe, 2/4/30 fragt (über dasselbe DALI-Gateway) den Status on/off ab. Beide GAs sind in EDOMI eingetragen, fürs das 2/4/30 (um das es konkret geht) hänge ich einfach mal nen Screenshot an, vllt stimmt ja auch was in der Notation nicht - oder so...