Es kann sein dass die Wago den Request auf dem kurzen Dienstweg selbst beantwortet wenn sie weiss welchen Zustand die angefragte GA hat. Das sollten zumindest die GAs sein die in der Wago verwendet werden. Wenn Edomi (jenseits des ACK) eine Antwort von der Wago bekommt ohne dass der Read auf dem Bus auftaucht ist das wohl der Fall.
Ansonsten ist die Wago ein KNX-zertifiziertes Gerät und nach meiner Erfahrung sehr solide - allerdings fehlen mir Zeit und Lust, die Wago wieder rauszukramen und in Betrieb zu nehmen um rauszufinden was die ggf. anders macht wie Enertex, MDT & Co.
Ankündigung
Einklappen
Keine Ankündigung bisher.
Probleme mit KNXnet/IP-Tunnel und Routeranbindung
Einklappen
X
-
Aber auch wenn dem so wäre, müsste ich dann den Request nicht auf dem Bus sehen? Ob EDOMI auf das ACK wartet oder nicht: der Request müsste doch auf jeden Fall auf dem Bus ankommen, oder?Zitat von gaert Beitrag anzeigenNa dann dürfte der Fall relativ klar sein: Der Wago-Router (ggf. auch andere) ACKen den Read-Request nicht - führen den Request physisch aber aus.
Einen Kommentar schreiben:
-
Wenn Du das Wago Szenario meinst:Zitat von gaert Beitrag anzeigenEine wichtige Frage in diesem Zusammenhang:
Aller Fehlermeldungen zum Trotz - wird der Read-Request denn effektiv ausgeführt, also kommt eine Antwort der abgefragten GA?
-nutze ich direkt die Wago als Tunnel, kommt der Read Request garnicht am "anderen Ende des Tunnels" an, er taucht also nicht im Busmonitor auf
-nutze ich das Wiregate als Tunnel, sehe ich den Read Request im Busmonitor dreimal, es kommen 3 Antworten, EDOMI bekommt den korrekten Wert aber mit (vermutlich schon nach dem ersten Request)
Vielen Dank, dass Du versuchst Dich dem anzunehmen!!
gruesse :: Michael
Einen Kommentar schreiben:
-
Na dann dürfte der Fall relativ klar sein: Der Wago-Router (ggf. auch andere) ACKen den Read-Request nicht - führen den Request physisch aber aus. Ich werde dann wohl das "ACKen" des Read-Request optional machen, d.h. in der Konfiguration wird man in Zukunft angeben können, ob der Router einen Read-Request bestätigen muss oder nicht.
Einen Kommentar schreiben:
-
Ja. Das sieht man hier im Monitor-Log:Zitat von gaert Beitrag anzeigenEine wichtige Frage in diesem Zusammenhang:
Aller Fehlermeldungen zum Trotz - wird der Read-Request denn effektiv ausgeführt, also kommt eine Antwort der abgefragten GA?
https://knx-user-forum.de/forum/proje...095#post895095
Einen Kommentar schreiben:
-
Bei meinem abb Router ist mit dem initscan auch der fehlerlog voll
Einen Kommentar schreiben:
-
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?Zuletzt geändert von gaert; 20.01.2016, 09:42.
Einen Kommentar schreiben:
-
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
Einen Kommentar schreiben:
-
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
Einen Kommentar schreiben:
-
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?
Einen Kommentar schreiben:
-
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 ...
Einen Kommentar schreiben:
-
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 :: MichaelZuletzt geändert von wintermute; 19.01.2016, 23:44. Grund: Das Forum hat alle Zeilenumbrüche aufgegessen, zur besseren Lesbarkeit nochmals eingefügt...
Einen Kommentar schreiben:
-
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...
Einen Kommentar schreiben:


Einen Kommentar schreiben: