Probleme mit KNXnet/IP-Tunnel und Routeranbindung

[coliflower]

Ich habe mit GIRA-Router genau das gleiche Problem ….
Nicht dass da eine Kleinigkeit NOK ist, wie zum Anfang mit der PA wo es ursprünglich hieß die anderen Router machen ein Problem … ?
Meine Anmerkung soll nicht als „Meckern“ verstanden werden ;-)

[gaert]

Ich glaub's Euch ja Aber ich verstehe es nicht... Außerdem gibt es zahlreiche Fehlerquellen, z.B. irgendwelche Einstellungen und Konfigurationen. Leider habe ich nur einen Router und kann daher nur in der Theorie versuchen das Problem zu verstehen.

Die Sache mit der PA war mein Fehler und ist ja inzwischen behoben. Die Sache mit dem Read-Request kann ich beim besten Willen nicht nachvollziehen - aber ich werde die Spec gerne nochmal Wort für Wort analysieren

[WagoKlemme]

Ich bin zwar der in der Runde, der offentsichtlich am wenigsten Ahnung hat von Multicast, Port, usw., aber meiner Meinung nach liegt das Problem an den 2 Ports 3671 und 3672. Die anderen Anwendungen, die ich kenne arbeiten anscheinend mit nur einem Port und das ist eindeutig der 3671. Ich habe nun zig Routerbeschreibungen gelesen und alle gehen nur über den 3671 (IP->knx). Vielleicht biegen manche Hersteller intern was um und andere wieder nicht.
Wenn ich in den Verbindungseinstellungen 3672 als Port eingebe kommt "Schnittstelle nicht gefunden".

[SeatSLF]

WagoKlemme auf meinem jetzigen Edomi Rechner wird auch nur ein Port genutzt.

Aber die ETS scheint auch 2 Ports zu nutzen, zumindest seh ich das so in meinem Router

[WagoKlemme]

SeatSLF
So wie das aussieht kannst Du über 3672 verbinden - ich nicht.

[SeatSLF]

Habt ihr es in einer VM laufen? Vielleicht kommen da die Ports durcheinander.

Edomi in einer VM hatte bei mir auch 2 Ports, aber ich hatte nicht solche Probleme.

[gaert]

Die Ports (bzw. der zweite) hat mit dem IP-Router direkt nichts zu tun - es geht dabei mehr um die Kommunikation auf IP-Ebene. Wenn Ihr mit WireShark mal den Verkehr zwischen ETS (Tunnel!) und Router captured, werdet Ihr ebenfalls 2 Ports erkennen...

[wintermute]

Um mal eventuelle Fehlkonfigurationen meinerseits auszuschliessen:
Ich hab hier nochn Wiregate welches auch mittels Multicast über die die Wago auf den Bus kommt (schon seit langer, fehlerfreier Zeit). Da hab ich grad mal testweise im eibd das Tunneling aktiviert und in der edomi.ini die entsprechende IP geändert.
Nu hab ich nachm EDOMI Start eine Fehlermeldung wegen eines Timeouts, dann kommt ein KNX-Reconnect und dann werden alle GAs (oder besser die eine GA) beim Start korrekt vom Bus gelesen. Write-Requests funktionieren (natürlich) weiterhin. Also ist Bus- & EDOMI-seitig alles korrekt konfiguriert, der Fehler lässt sich damit IMHO recht konkret auf eine Inkompatibilität zur Wago einschränken.

Dummerweise ist das mit dem Wiregate keine Alternative für mich, ich werd wohl mal probieren einen eibd direkt auf dem EDOMI zu parken. Ist dann zwar doof wegen hintenrum ins Knie geschossen und so, aber immer noch besser als jetzt extra Geld für ein Gerät auszugeben das ich explizit nie im Haus haben wollte

gruesse :: Michael

[coliflower]

Ist dann der GIRA-Router auch inkompatibel ?
Denn wenn ich die Funktion „Init-Scan“ bei einer Status-GA, z.B. Licht AN/AUS einschalte, dann läuft der Error-Log voll ...

[wintermute]

Isses bei Dir auch so, dass write-Requests funktionieren und EDOMI mitbekommt was auf dem Bus vor sich geht - nur read-Requests (also zB beim Init-Scan) funktionieren nicht? Dann ist das Verhalten ziemlich identisch zur Wago KNX-Lösung.
Wieviele Tunnel erlaubt dein Router, auch nur einen?

[coliflower]

Der Gira hat 4 Tunneln …
Ich habe nur die 1bit Schaltstatus GA abgefragt (klein beginnend) und die Init-Scan Funktion aktiviert, dann ging der Fehler Log voll …

Vielleicht habe ich auch etwas falsch gemacht ..?
Ich habe ein bisschen gespielt und es ist mir aufgefallen dass der Fehler Log erst dann losgeht, wenn ich das Projekt neu lade (Projekt —> aktivieren) …
Und hört erst auf wenn die Prozedur - siehe Bild vorbei ist … und das dauert ein bisschen ...


Bildschirmfoto 2016-01-20 um 00.13.26.png

[wintermute]

Ja, das Verhalten scheint prinzipiell identisch zu sein.
Ich hab mir das mit dem eibd@Wiregate nochmal genauer angeschaut und so die wirklich beste Lösung ist das auch nicht wirklich (was man aber evtl irgendwie wegkonfigurieren könnte)...

eibd in EDOMI eingetragen:
-Init-Scan läuft durch und bekommt korrekte Werte, allerdings tauchen die Read-Requests jeweils dreimal im Busmonitor auf (im Abstand von jeweils 4s)
-Read-Requests funktionieren, tauchen aber ebenfalls dreimal im Busmonitor auf
-Write-Requests funktionieren, tauchen aber nur einmal im Busmonitor auf
-dummerweise wird der Tunnel ziemlich genau alle 60s ab & wieder aufgebaut - ich weiss nicht wieso genau, ich habs nur im EDOMI Log gesehen

Wago direkt in EDOMI eingetragen:
-Read-Requests tauchen im Busmonitor garnicht auf
-Init-Scan (und damit der EDOMI Start) braucht gefühlte 30 Minuten und bekommt (logischerweise) keine Werte
-Write-Requests funktionieren und tauchen jeweils einmal im Busmonitor auf
-Tunnel bleibt stabil

Jetzt tut mir das zwar leid, aber Occams Razor nötig mir förmlich unausweichlich folgende Diagnose auf
-read-Requests zeigen (im Gegensatz zu write-Requests(!)) ein auffälliges oder zumindest mal originelles Verhalten
-da der read-Request im gewünschten Szenario nicht das Tunnelende erreicht, kann eine Bus-seitige Fehlkonfiguration (zunächst) ausgeschlossen werden - das Paket wird scheinbar direkt von der Wago verworfen (zB weil fehlerhaft)
Daraus folgt IMHO zwingend ein Fehler in der Implementierung von Read-Requests seitens EDOMI - oder aber bei mir ist alles völlig wirr konfiguriert. Das möchte ich schlussendlich dann auch nicht wirklich ausschliessen müssen

Haben vllt noch andere Leute dieses "3fach Problem" bei den Read-Requests bemerkt? Weil normal ist das doch auch nicht wirklich, oder?

gruesse :: Michael

[SeatSLF]

Enertex Router macht keine Zicken, läuft Problemlos

[gaert]

Scheinbar ACKed der Wago die Read-Requests nicht - die Writes aber schon. Auf Deutsch: Wenn EDOMI einen Read-Request absetzt, wartet EDOMI solange, bis der Router den Empfang des Read-Request bestätigt. Offenbar bestätigt dieser Router den Empfang aber nicht - andere (wie auch meiner) aber schon. Mag sein, dass beide Verhaltensweisen Spec-Konform sind, das entzieht sich meiner Kenntnis.

Allerdings wäre dieses Verhalten etwas unlogisch, denn Writes funktionieren im Prinzip genauso, d.h. der Router ACKed jedes Write, das er von EDOMI bekommt. Und das funktioniert ja offenbar auch. Bei Reads wäre demnach ein "fire and forget"-Prinzip implementiert (beim Wago), bei Writes hingegen muss alles bestätigt werden?!

Eine wichtige Frage in diesem Zusammenhang:
Aller Fehlermeldungen zum Trotz - wird der Read-Request denn effektiv ausgeführt, also kommt eine Antwort der abgefragten GA?

[ChrisP]

Bei meinem abb Router ist mit dem initscan auch der fehlerlog voll