Starke Verzögerung bei der Steuerung knxd oder VISU?

[Medicusi]

Einen traumhaften sonnigen Pfingstmontag wünsche ich euch

Ich habe das Problem, dass meine gesendeten Befehle via smartVISU mitunter nur mit einer starken Verzögerung (5-7 min) ausgeführt werden.

Der erste Befehlt wird sofort innerhalb 1 sec ausgeführt, das Problem tritt ab dem zweiten Befehl auf und ist soweit ich es bisher testen konnte Browser und Geräte unabhängig.

Hardware: MDT SCN-IP100.02 IP Router 2TE REG

Folgende Änderungen in der knxd habe ich bereits vorgenommen:

#KNXD_OPTS="-e 1.1.251 -E 1.1.120:10 -c -B single --send-delay=70 -b ipt:192.168.1.220"
#neu:
KNXD_OPTS="-e 1.1.252 -E 1.1.112:2 -c --send-delay=30 -b ipt:192.168.1.220"

Hat jemand das selbe Problem, oder gar einen Lösungsweg?

[Medicusi]

Hallo nochmal,

hat niemand eine Idee, nutzt jemand von euch den MDT Router?

Meint ihr ein Tausch gegen die Hardware Rev. 3 bringt was?

Bin echt etwas verzweifelt.?.

[Klaus Gütter]

Dass es am IP Router liegt, ist wohl am unwahrscheinlichsten.
Kannst ja Mal mit Wireshark schauen.

[henfri]

Hallo,

probier es doch mal mit groupswrite.
Wenn es damit klappt, liegt es an der smartVisu (oder smarthomeng).
Wenn es damit auch nicht klappt, liegt es am knxd, dem Router, oder den Geräten.

Gruß,
Hendrik

[wvhn]

Wie hast Du denn abgesichert, dass das Problem wirklich in der knx-Verbindung liegt? Gib hierzu bitte etwas detailliertere Infos an.

SmarthomeNG bietet viele Logging-Möglichkeiten und auch das Admin-Interface sowie das Web-Interface des knx Plugins sind sehr auskunftsfreudig. Und das alles mit Zeitstempeln, so dass man einem Delay von 5 Minuten garantiert auf die Spur kommt.

Ich hatte Dir an anderer Stelle geraten, die knxtools zu verwenden. Damit kannst Du knx-Adressen direkt schreiben und prüfen, ob das Delay dort auch auftritt. Wenn ja, bist Du hier im Forum richtig. siehe auch Hendriks Post. Dann kommst Du mit dem Tipp von Klaus weiter, den ich Dir auch schon gegeben hatte.

Anderenfalls mit groupsocketlisten auf dem Bus mithören, während Du über das Admin-Interface von shNG items veränderst. Wenn der Fehler erst hier auftritt, ist die Wahrscheinlichkeit hoch, dass an Deiner item-Konfiguration etwas nicht stimmt.

Gruß
Wolfram

[wvhn]

Nachtrag: Während der Versuche solltest Du alle Browser mit SmartVISU schließen. Sobald die SV angemeldet ist, fordert sie nämlich bei shNG über den websocket die Aktualisierungen aller items an, die auf der geöffneten Seite verwendet werden. Durch das Abschalten der Seiten schließt Du die Auswirkungen möglicher Fehler in der SV erstmal aus. Das Web-Interface des visu_websocket Plugins zeigt Dir an, welche Clients angemeldet sind.

Wenn Du uns zwischendurch an den Ergebnissen der Versuche teilhaben lässt, können wir besser helfen.

[Medicusi]

Wenn Du uns zwischendurch an den Ergebnissen der Versuche teilhaben lässt, können wir besser helfen.

Mea culpa: Zwischen meiner Arbeit und meines 5 Wochen alten Sohnes versuche ich tatsächlich das Problem in den Griff zu bekommen ... was bisher geschah:

Wir loggen gerade die smarthomeNG, den knxd, und das ganze noch mit der ETS (habe mir jetzt eine Zusatzlizens besorgt)

Kleines Problem mit dem Websocket haben wir schon gelöst, das war es aber nicht.

- Den IP Router habe ich gegen eine neue Rev. 3 getauscht
- smartNG, smartVisu, knxd wurde komplett auf eine neue NUC aufgesetzt, das ganze mit meiner Raspi
- habe alle Geräte (KNX Router, NUC) auf einen Switch gepackt und haben alle eine LAN Verbindung

Später schicke ich LOGs wenn ich was genaues finde ....

[schuma]

Ich kann mich da nur wiederholen:
Nimm mal die letzte KNXD Version 0.12.
Damit sollte es wieder klappen.

Grüße, Marc

[Medicusi]

Ich kann mich da nur wiederholen:
Nimm mal die letzte KNXD Version 0.12.
Damit sollte es wieder klappen.

Grüße, Marc

das habe ich probiert, ich bekomme die Version aber nicht auf meiner NUC kompeliert

[Smurf]

Die 0.12 zu nehmen ist keine Lösung, wir müssen den tatsächlichen Fehler finden, zumal das mit 0.12 auch berichtet wurde.

Sollte mit ausreichenden Logs eigentlich möglich sein.

[Medicusi]

Die 0.12 zu nehmen ist keine Lösung, wir müssen den tatsächlichen Fehler finden, zumal das mit 0.12 auch berichtet wurde.

Sollte mit ausreichenden Logs eigentlich möglich sein.

nachdem wir (ein guter Freund unterstützt mich ein wenig) nun mal die alten Beiträge gelesen haben, sind wir auf einen Tipp von dir gekommen und haben mal von Tunneling auf Routing gestellt:

#KNXD_OPTS="-e 1.1.251 -E 1.1.130:10 -c --send-delay=100 -b ipt:192.168.1.150"
KNXD_OPTS="-f9 -t 1023 -e 2.1.1 -E 2.1.10:10 -c --send-delay=50 -b ip:"

damit hat sich das ganze nun auf eine Verzögerung von 10-20 Sekunden reduziert.

[Medicusi]

Guten Morgen zusammen,

es sieht alles danach aus als würde die Verzögerung tatsächlich durch die knxd verursacht.

Resized_20200617_082127.jpg

Tatsächlich kann man hier die Verzögerung nach Eingabe in der Visu bis zur Übergabe an den BUS von 22 sec. sehen.

Smurf wir haben versucht deiner Anregung zu folgend und haben die "fpace.cpp" gesucht. Auf meiner Debian ist diese Datei nicht vorhanden.

Wie können wir das Problem weiter erforschen?

[Smurf]

Aber selbstverständlich ist diese Datei vorhanden.

smurf$ git ls-files | grep pace
src/backend/fpace.cpp
src/backend/fpace.h

[Smurf]

Und BITTE kopiere Logs raus und füge sie hier ein statt Screenshots zu machen!

[Medicusi]

Und BITTE kopiere Logs raus und füge sie hier ein statt Screenshots zu machen!

mea culpa ich bin unterwegs und war nicht am Rechner habe mir schnell von jemanden ein Foto machen lassen