Schaltverzögerung Weinzierl 730

[Tru]

Ich hatte die v 0.12 installiert und konfiguriert unter Jessy mit systemd. Jetzt habe ich festgestellt, dass plötzlich nach dem update auf v 0.14 die knxd.conf nur noch die default Werte enthät und meine Konfiguration in der etc/default/knxd steht. Das sollte nach meinem Verständnis bei Verwendung von systemd aber falsch sein.

Entscheidend ist wie du knxd gebaut hast. Es gibt die Methode alles gemäss Original-Source zu installieren. Dann wird die Konfigdatei als /etc/knxd.conf installiert. Aber es gibt auch eine Reihe von Anleitungen und Blogs mit eigenen Scripts, welche die Installation auf ihre eigene Weise vornehmen.
Auch die Konfiguration von systemd ist davon betroffen. Entscheidend ist hier wie der Aufruf in /lib/systemd/system/knxd.service und /lib/systemd/system/knxd.socket definiert ist.
Soweit ich es beurteilen kann wird /etc/default/knxd gemäss Original-Source nicht verwendet.

[masterjost]

Woah mal kurz die anzahl meiner Posts gesehen @ smurf? Du bist hoffentlich auch jemand der auch ein Fahrschulauto anhupt, weil der Fahrschüler in der ersten Fahrstunde an der Kreuzung das Auto abgewürgt hat?! Sorry dass ich nicht so tief im Quellcode stecke. Würde ich dies tun bräuchte ich nicht die Hilfe von Leute die in diesem Bereich erheblich mehr Ahnung haben wie dir. Also nochmals danke, dass du dich dem annimmst aber trotzdem immer schön auf dem Boden bleiben und nicht die Bodenhaftung verlieren ;-)

Trotzdem habe ich weiter gesucht, weil ich eben auch eine Lösung will und mich dabei nicht nur auf andere verlassen möchte. Folgendes ist mir aufgefallen:
Ich hatte die v 0.12 installiert und konfiguriert unter Jessy mit systemd. Jetzt habe ich festgestellt, dass plötzlich nach dem update auf v 0.14 die knxd.conf nur noch die default Werte enthät und meine Konfiguration in der etc/default/knxd steht. Das sollte nach meinem Verständnis bei Verwendung von systemd aber falsch sein. mit der v0.12 war das meiner Meinung nach nicht so.
Lange Rede kurzer Sinn: Ich habe meine Konfiguration in die etc/knxd.conf eingetragen und plötzlich hab ich gefühlt null delay zwischen erstem und zweitem Schalten. Werds aber erstmal weiter beobachten. Aus meiner Sicht aber komisch, da ich die Dateien so nicht konfiguriert hatte und es ja eigentlich dann überhaupt nicht funktionieren sollte, da knxd ja meine Konfiguration eigentlich hätte komplett ignorieren sollen....wer weiß. Vielleicht hilfts weiter.

meine Zeile in der knxd.conf:

KNXD_OPTS="-e 1.0.200 -E 1.0.210:5 -D -T -S -b ipt:192.168.178.200"

MDT IP Router

[schuma]

Nö, das musste so nicht raus. Vor allem dann nicht, wenn ich unter die Codeänderung schreibe,
und ich danach hier lesen muss

Ich bezog mich auch eher auf die Posts 47-51 was ja auch meine Zeit ist!
Und, es ist halt nicht jeder so Firm, dass alles gleich klappt. Ich verstehe ja, dass das nerft, aber es sind halt hier nicht alle Profis!
Jetzt ist aber gut...... Trotzdem vielen Dank für Deine unermütliche Arbeit in diesem Projekt.

[Smurf]

Weil, zumindestens aus meiner Sicht, wollte man den Fehler nicht wirklich finden.

Sorry, musste mal raus...

Nö, das musste so nicht raus. Vor allem dann nicht, wenn ich unter die Codeänderung schreibe,

Die geänderte Ausgabe soll uns sagen, woher der unfug kommt.

und ich danach hier lesen muss

Erstes Ergebnis der Änderung: kurzes Delay (…)

Sorry, aber: was soll das? es ist doch mehr als offensichtlich, dass der Patch nur die Ausgabe beeinflusst und dass es daher evtl. eine ganz tolle Idee wäre, diese geänderte Ausgabe aus dem Log rauszusuchen und hier einzustellen – statt sich (und den Rest der Welt) zu fragen, ob oder wie sich dadurch das tatsächliche Fehlerverhalten bessert oder ändert.

Dafür, dass ich hier die Probleme anderer Leute in meiner Freizeit behebe (von der ich nicht allzuviel habe, weswegen es auch mal dauern kann), erwarte ich ein Minimum an Mitdenken.

So. Das musste auch mal raus.

[henfri]

Zweiter Edit: Nach einer halben Stunde "Pause" hab ich einen zweiten Schaltversuch gestartet. Jetzt war die Verzögerung wieder größer (ca. 1,5s). Wenns dabei bleibt könnte man ja selbst damit noch irgendwie leben. Ich fürchte aber das wird noch mehr, wenn man länger wartet. Ich bleibe dran.

Die Code-Änderung erweitert nur den Debug-Output.

Gruß,
Hendrik

[schuma]

@schuma: zerfleischt euch nicht. Mich ärgert es auch, aber man darf niemals vergessen, dass das Ganze KOSTENLOS ist und jemand sich damit in seiner FREIZEIT beschäftigt!!!

Das vergesse ich ja auch nicht. Ich bin ja auch froh über den grundsätzlichen Einsatz hier.
Aber wenn jemand versucht hier zu helfen und diverse Logs erstellt etc. und das dann komplett ignoriert wird, ist das auch von mir oder demjenigen der da mitarbeitet komplett KOSTENLOS und eben auch meine oder demjenige Freizeit. Für den einen oder anderen ist es halt auch nicht so leicht Aufgaben gleich umzusetzen.

Was für den Profi evtl. 5 Minuten dauert, dauert bei anderen vielleicht 2 Stunden.

Da sollte man halt einfach auch nicht vergessen, dass auch das kostenlose Zeit ist!

Jetzt ist aber gut. Ich musste das ja nur mal loswerden. Ich will oder wollte hier auch keinen Diskussion vom Zaun brechen.

[masterjost]

@schuma: zerfleischt euch nicht. Mich ärgert es auch, aber man darf niemals vergessen, dass das Ganze KOSTENLOS ist und jemand sich damit in seiner FREIZEIT beschäftigt!!! Daher ein Danke an Smurf egal ob wir dem Problem nun auf die Spur kommen oder nicht.

Ich probiere jetzt erstmal die Codeänderung aus.

Erstes Ergebnis der Änderung: kurzes Delay aber minimal beim zweiten Schalten. Damit könnte ich aber in jedem Fall leben. Allerdings bin ich skeptisch ob das jetzt an der Codeänderung lag, oder aber an einer zu kurzen Pause nach dem letzten Schaltvorgang. Ich warte jetzt einfach mal eine Weile und probiere es dann nochmal.

Zweiter Edit: Nach einer halben Stunde "Pause" hab ich einen zweiten Schaltversuch gestartet. Jetzt war die Verzögerung wieder größer (ca. 1,5s). Wenns dabei bleibt könnte man ja selbst damit noch irgendwie leben. Ich fürchte aber das wird noch mehr, wenn man länger wartet. Ich bleibe dran.

[schuma]

Nein, du willst nicht downgraden, du willst den Fehler finden. (Zumindest aus meiner Sicht.)

Ich denke bald, wollen wir doch.
Weil, zumindestens aus meiner Sicht, wollte man den Fehler nicht wirklich finden.

Sorry, musste mal raus...

[Smurf]

Wie, wohin mit dem Code? steht da doch. src/backend/fpace.cpp, Zeile 130.

Dass du in der Konfig keinen Delay hast, ist mir klar, aber der "pace"-Filter hat eingebaute Defaults. Die erklären aber nicht wirklich, wieso der so groß ist. Die geänderte Ausgabe soll uns sagen, woher der unfug kommt.

[masterjost]

Finden will ich den Fehler schon. Aber wohin mit dem Code?
Hardware bei mir: MDT IP ROUTER, knxd auf raspi3 mit raspbian

Die Befehle werden im Übrigen nicht verschluckt. Nach dem ersten Schalten gibts irgendwie eine Art Sperre in der Ausführung. Betätige ich mehrfach den Lichtschalter so gibts nach Ende der "Sperre" erstmal nen Discoeffekt weil er dann alle Schaltbefehle unmittelbar nacheinander nachholt.

nen Delay habe ich nicht in der conf

[Smurf]

Nein, du willst nicht downgraden, du willst den Fehler finden. (Zumindest aus meiner Sicht.)

Mach mal bitte folgende Änderung, damit ich sehen kann wo diese seltsamen 8 Sekunden herkommen.

--- src/backend/fpace.cpp
+++ src/backend/fpace.cpp
@@ -127,7 +127,7 @@ PaceFilter::timer_cb (ev::timer &w UNUSED, int revents UNUSED)
   if (factor_in > 0 && nr_in > 0)
     {
       float this_delay = (size_in*byte_delay + nr_in*delay) * factor_in;
-      TRACEPRINTF (t, 2, "in %d/%d: delay more, for %.3f sec", nr_in,size_in, this_delay);
+      TRACEPRINTF (t, 2, "in %d/%d %f/%f/%f: delay more, for %.3f sec", nr_in,size_in, delay,byte_delay,factor_in, this_delay);
       timer.start(this_delay);
       nr_in  = 0;
       size_in = 0;

[Tru]

Gibts irgendwo eine Kurzanleitung zum Downgrade auf die V12?

git clone https://github.com/knxd/knxd
cd knxd
git checkout v0.12

und dann bauen wie gewohnt.

[masterjost]

Gibts irgendwo eine Kurzanleitung zum Downgrade auf die V12? Habe das gleiche Problem mit den ewig langen Schaltzeiten per KNXD beim 2. Schalten. Das ist relativ nervig wenn man morgens 2 Lampen anschalten will, die erste geht und die 2. dann nach vielleicht 10s Verzögerung. Ist der 2. Befehl endlich angekommen läufen alle weiteren völlig normal und zeitnah ab.

[olivers]

Smurfschuma , Ich habe mit meinem Gira Interface in Kombination mit Version 14 auf dem raspberry pi 2 das gleiche Verhalten gehabt: Sehr lange delays bei Verwendung von --send-delay. Nun habe ich ein Downgrade auf Version 12 gemacht und alles funktioniert einwandfrei.

[schuma]

Smurf Bist Du hier schon weitergekommen? Oder kann ich hier noch irgendwie helfen?