knxtool groupwrite schaltet nichts

[Smurf]

??? knxtool verwendet eine TCP/Pipe-Verbindung und die wird selbstverständlich sauber beendet, d.h. nach der letzten Adresse ist wieder die erste dran.

Irgendwas ist bei dir oberfaul, ich kann das überhaupt nicht reproduzieren.

[pakka]

Ich habe das mal beobachtet und folgendes fällt auf:

- nach einem Überschreiben des "Applikationsprogramms" des IP Routers aus der ETS heraus funktioniert knxd sauber: über die Kommandozeile kann ich Schaltbefehle senden, jeder Befehl kommt von einer neuen phys. Adresse, er schafft auch den Überlauf von 1.1.8 zurück zu 1.1.3

- knxd wird von smarthomeNG bzw. dessen Plugin genutzt. Ob der smarthomeng Dienst läuft oder nicht macht keinen Unterschied

- smarthomeNG behält eine physikalische Adresse bei, Schalten darüber funktioniert erstmal auch problemlos.

- nach einer Weile Inaktivität ist dann aber kein Schreiben auf den Bus mehr möglich. Die Befehle gehen raus, kommen aber anscheinend nicht durch den Router durch im verdrahteten Netz. Lesen vom Bus ist weiterhin möglich (groupsocketlisten).

- Erst ein Neustart des IP Routers ermöglicht dann wieder ein Schreiben.

- Nachdem die Schaltbefehle nicht mehr im TP-Bus ankommen, wechselt knxd aber die physikalische Adresse munter weiter druch (laut PA-Statistik vom smarthomeNG-knx-Plugin). Die Adresse unter der der knxd sendet wird aber vom Router festgelegt? Oder schaltet er selbstständig weiter?

Ich verstehe nicht, was der Auslöser sein kann, es muss ja fast am Router liegen!?

[Smurf]

nach einer Weile Inaktivität

Wie genau hast du das smarthomeNG konfiguriert? Verwendet das Teil TCP oder Tunnel? Siehst du die Datagramme mit Wireshark, wenn ja wie sehen sie aus und gibt es eine Rückmeldung?

[wvhn]

Das Abschalten nach gewisser Zeit weckt in mir Erinnerungen. Schau mal, ob die Firewall des Netzwerk-Routers Pakete an den KNX-Router nach einiger Zeit blockiert, oder ob ein Port-forwarding nötig ist. Als Schnelltest sollte es reichen, den Netzwerk-Router neu zu starten, wenn die Verbindung zum KNX das nächste Mal stockt.

EDIT: Der Effekt hängt natürlich von der Netzwerktopologie ab. Wenn die ETS z.B. am gleichen Switch hängt, wie das IP-KNX-Interface, aber der Raspberry am Netzwerksrouter oder im WLAN, dann wäre das Verhalten erklärbar - auch dass der knxd lesen kann, aber die geschriebenen Pakete nicht ankommen.

[saul]

Zitat von baumiksdeh Beitrag anzeigen
Code:

knxtool groupwrite ip:localhost 8/14/4 1




Dafür wäre aber dieser Befehl korrekt Code:

knxtool groupswrite ip:localhost 8/14/4 1

Das hat MIR aber geholfen!

Und jetzt im ernst, nicht mal im ETS-Gruppenmonitor habe ich den Unterschied erkannt!

Ich weiß, dass ich ein blutiger KNXd Anfänger bin, aber eine richtige Einleitung würde dem knxd Projekt echt gut tun... nur so meine bescheidene Meinung, nebenbei.

[pakka]

Als Schnelltest sollte es reichen, den Netzwerk-Router neu zu starten, wenn die Verbindung zum KNX das nächste Mal stockt.

Es hilft wenn man den Netzwerkrouter, den KNX IP Router oder den knxd Server neu startet. Alles führt dazu, dass das Senden einer Gruppenadresse wieder kurzzeitig funktioniert. Bis er dann nach wenigen Minuten wieder blockiert.
Die Frage ist wie man es mehr eingrenzen kann, oder ob man in der Fritzbox irgendwelche Freigaben erteilen kann, die jeglichen Einfluss der Fritzbox ausschließen könnten?

PS: sorry for the delay... ein Haus musste fertig gebaut werden