Ankündigung

Einklappen
Keine Ankündigung bisher.

Schaltverzögerung Weinzierl 730

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

    #61
    Zitat von masterjost Beitrag anzeigen
    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

    Kommentar


      #62
      Zitat von schuma Beitrag anzeigen
      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.
      1wire, KNX, OpenHAB, Python, Asterisk, SMD-Lötkolben

      Kommentar


        #63
        Zitat von Smurf Beitrag anzeigen
        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.


        Kommentar


          #64
          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:

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

          Kommentar


            #65
            Zitat von masterjost Beitrag anzeigen
            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.
            EIB/KNX, VISU mit knxd + linknx + knxweb, Steuerbefehle via SMS und Email mit postfix + procmail

            Kommentar


              #66
              Nur eine kurze Rückmeldung:
              Bin jetzt auch wieder auf die 0.12 zurück gegangen.
              Und auch bei mir funktioniert nun wieder alles wie gewohnt.
              Damit werde ich bei mir den Stand 0.12 einfrieren. Muss ja nur funktionieren, das reicht ja schon.

              Kommentar


                #67
                Reihe mich jetzt mal ein bei den 0.14-Verzögerern. Ich habe meine alte OH 2.0 Installation durch OpenHABian 2.2 ersetzt, alle Rules etc. mit übernommen und auf die aktuelle 0.14 knxd gesetzt. Seitdem habe ich das Problem, das Rules, welche auf KNX-Veränderungen triggern, zwischen 0 bis auch mal 45 Sekunden verzögert getriggert werden. So ein Verhalten hatte ich vorher nie. Habe dafür unter OH2 schon einen Thread offen, weil ich bis dahin knxd nicht in Verdacht hatte. Jetzt bin ich aber auf diesen Thread gestoßen und würde fast sagen, dass meine Probleme auch hier rühren. Testweise habe ich nun die 0.12 installiert, die ersten Tests, welche ich von der Arbeit aus direkt zu Hause gesteuert habe, zeigten dass die Rules nun wieder sofort (max. 100msec verzögert) getriggert werden, und die Rules sofort greifen.

                Ich würde mich auch zu Debug-Zwecken zur Verfügung stellen, ein Wechsel zurück auf die 0.14 wäre kein Thema.

                EDIT: Jetzt komme ich nach Hause und schon triggern die Rules wieder nicht ordentlich. Hatte gerade eine Verzögerung von gut 30 Sekunden...
                Zuletzt geändert von netzlaff; 07.03.2018, 18:31.

                Kommentar


                  #68
                  Gucke mal ob Du wirklich auf die 0.12 zurück gegangen bist.

                  knxd --version

                  Kommentar


                    #69
                    Bin nochmal wieder zurück auf die 0.14.24-3 zurück gegangen, da der Updater von OpenHABian mit der installierten 0.12 und den nicht erfüllten Abhängigkeiten zur anderen Pakete nicht mehr klar gekommen ist. Das war letzte Woche Mittwoch oder Donnerstag. Aber wieder keine Änderung. Die darauf folgenden Nächte oder frühen Morgen ist mir der ganze Rechner irgendwann stehen geblieben. Hier konnte ich dann nur noch Aus- und Einschalten. Komischerweise läuft der Rechner seit Samstag bis heute stabil, keine Abstürze und vor allem keine Verzögerungen der Rules und KNX-Trigger. Das macht mir das Debugging noch viel schwerer, auch wenn ich mich freue, dass aktuell alles läuft.

                    Kommentar


                      #70
                      Hallo Zusammen, ich habe das selbe Verhalten wie hier beschrieben. Ich habe einen Raspi 3 der mit einem Gira KNX-Router kommuniziert. Ich habe das Verhalten erst in der SmartVisu vermutet, dann im Apache2 und hatte daher auf die SmartVisu 2.9 umgestellt und auf nginx als Server .. das Verhalten ist jetzt nach der Umstellung so wie oben beschrieben. Vorher mit dem Apache2 hatte ich nach dem ersten Befehl bis zu 10min! Verzögerung. Nach der Umstellung auf nginx und die neue Smartvisu sind es nur noch 45sek .. eine deutliche Verbesserung, aber wenn wir da noch etwas runterkommen, wäre mir das sehr recht. Ansonsten stimme ich Smurf zu.. ich will eigentlich nicht zurück auf die 0.12 von knxd ich hätte gern die neue Version mit verbesserten Verhalten.

                      Meine Konfiguration-Zeile ist diese hier:
                      KNXD_OPTS="-u /tmp/eib -e 0.0.1 -E 7.0.100:8 -c -A delay=50 -B pace -b ipt:192.168.178.97"

                      ich habe den Eintrag von Smurf in der fpace-Datei geändert und wollte knxd neu comilieren. Dabei bleibt aber mein Raspi3 hängen (komplett :/) ich werd es morgen nochmal versuchen. Gibt es hier sonst noch neue Erkenntnisse?

                      Kommentar


                        #71
                        Hallo Alle,

                        ich bin durch googeln auf diesen Thread gekommen. Mein Verhalten war ebenfalls, dass der erste Tastendruck, der nach längerer Zeit eingegeben wurde stark, bis in den Minutenbereich, verzögert war. Dann ging's wieder. Das Ganze nur an einer Adresse, die ein Szene ansteuert. Alle anderen Adressen gingen ohne Probleme. Die Szene wird übrigens per Taster und per Bewegungsmelder angesteuert. Bei beiden das gleiche Verhalten.
                        Ich bin gestern zurück auf 0.12 und das Problem war sofort behoben. Sicher keine elegante Lösung, aber wie sagt man? Tore zählen!

                        Viele Grüße,
                        Jürgen

                        Kommentar


                          #72
                          Hallo zusammen,
                          die von Smurf eingebauten Traces ergeben folgendes:

                          Good case:
                          Layer 2 [12:C.pace/B.ipt 30.488] in 2/2 0.030000/0.001000/0.750000: delay more, for 0.046 sec

                          Bad case:
                          Layer 2 [12:C.pace/B.ipt 558.147] in 99/4 0.030000/0.001000/0.750000: delay more, for 2.230 sec

                          Ein Blick in den Code zeigt, dass das Problem die Variable nr_in ist, die durch empfangene Nachrichten (recv_L_Data (LDataPtr l)) immer weiter inkremtiert wird und erst von timer_cb zurückgesetzt wird, nachdem eine Nachricht gesendet wurde (wodurch sich die zweite zu sendende Nachricht um Sekunden verzögern kann).

                          Smurf
                          Könntest du mit dieser Voranalyse nochmal einen Blick auf das Problem werfen? Ich möchte ungern in deinem Code rumbasteln, ohne alle Zusammenhänge von knxd zu verstehen.

                          Gruß,
                          Paul

                          Kommentar


                            #73
                            Welche knxd Version ist eigentlich die letzte, die dieses Problem nicht hat? Ist es die 0.12?

                            Kommentar


                              #74
                              Ja, die 12

                              Kommentar

                              Lädt...
                              X