Ankündigung

Einklappen
Keine Ankündigung bisher.

Probleme mit KNXnet/IP-Tunnel und Routeranbindung

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • MarkusS
    antwortet
    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.

    Einen Kommentar schreiben:


  • wintermute
    antwortet
    Zitat von gaert Beitrag anzeigen
    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.
    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?

    Einen Kommentar schreiben:


  • wintermute
    antwortet
    Zitat von gaert Beitrag anzeigen
    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?
    Wenn Du das Wago Szenario meinst:
    -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:


  • gaert
    antwortet
    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:


  • ChrisP
    antwortet
    Bei mir ebenso. Kann lesen und schreiben

    Einen Kommentar schreiben:


  • Steph
    antwortet
    Zitat von gaert Beitrag anzeigen
    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?
    Ja. Das sieht man hier im Monitor-Log:
    https://knx-user-forum.de/forum/proje...095#post895095

    Einen Kommentar schreiben:


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

    Einen Kommentar schreiben:


  • gaert
    antwortet
    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:


  • SeatSLF
    antwortet
    Enertex Router macht keine Zicken, läuft Problemlos

    Einen Kommentar schreiben:


  • wintermute
    antwortet
    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:


  • coliflower
    antwortet
    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:


  • wintermute
    antwortet
    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:


  • coliflower
    antwortet
    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:


  • wintermute
    antwortet
    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
    Zuletzt 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:


  • gaert
    antwortet
    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:

Lädt...
X