Ankündigung

Einklappen
Keine Ankündigung bisher.

LBS mit Exec (speziell Hue) stellen Dienst einfach ein

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

    LBS mit Exec (speziell Hue) stellen Dienst einfach ein

    Ich hab ein seltsames Phänomen. Ich hab LBSs, die einfach „stehen“ bleiben. Speziell ist es bei mir beim Hue-LBS und beim Home-Connect aufgefallen. Nach einer Zeit, manchmal 20 min, manchmal nach mehreren Stunden. Die Logs sind an und irgendwann schreiben die nichts mehr und die LBS machen nix mehr. Nach einem Neustart von Edomi läuft wieder alles wie es soll, aber eben nur eine gewisse Zeit.

    Derzeit hab ich Edomi 1.61 am laufen. Downgrades auf 1.59 und 1.60 brachten auch keine Besserung. Inzwischen hab ich Edomi komplett neu installiert, auch alle LBS neu installiert. Testweise auch alle Logikseiten bis auf Hue deaktiviert, ohne Erfolg.

    Beim Home-Connect-SSE könnte es sein, dass die Verbindung zum Server unterbrochen wird und sich deshalb nix mehr tut, ok. Aber beim HUE-Bridge LBS sollte doch wenigstens alle 5 Min ein Ping laufen. Das passiert auch eine Weile und wird brav ins Log geschrieben, nur irgendwann hört er damit auf, deshalb glaub ich weniger, dass es am Netzwerk liegt. In der Live-Ansicht blinken die LBS auch fröhlich vor sich hin, auch wenn schon längst nix mehr läuft (kein empfang von Änderung, kein senden).

    Edomi Version sollte auch nicht die Rolle spielen, nachdem ich schon verschiedene Versionen probiert hab. Systemlast hab ich auch nichts Außergewöhnliches. Keine Eintragungen im Fehlerlog. Im Monitor- oder Systemlog keine Eintragungen, die zeitlich im Zusammenhang stehen, also nichts was nicht, während die LBS funktionieren, auch da wäre. Dediziertes System.

    Den LBS würd ich jetzt auch nicht den Fehler zuschreiben, sonst wären schon mehr solche Fehler gemeldet worden, nehm ich an. Der Konfiguration, naja es funktioniert ja nach dem Neustart alles wie es soll. Und es betrifft irgendwie (mindestens) 2 verschiedene LBS. (ich muss mal schauen ob ich noch LBS hab die sich ähnlich verhalten)

    Ein Testdurchlauf kann durchaus lange dauern bis die wieder stehen, was die Fehlersuche bisher (downgrade, Logik deaktivieren…) sehr mühselig macht. Und inzwischen gehen mir die Ideen aus.

    Hat jemand ne Idee woran das liegen kann bzw. Vorschläge was ich machen kann um den Fehler zu finden?

    (gaert , jonofe bzgl. Hue-LBS)

    Danke schon mal
    Andreas

    #2
    Ohne im Moment in den Sourcecode reinschauen zu können, könnte es an der Änderung seit edomi 1.60 liegen, die per default nur den einmaligen s Start des EXEC Daemons erlaubt. Bei manchen meiner LBS wird der EXEC daemon aus dem LBS Teil gesteuert Bei diesem LBS stoppt der LBS den EXEC daemon ohne das edomi das mitbekommt. Zusammen mit der default Einstellung das ein daemon nur einmal gestartet werden darf, führt das dazu dass nach einem Stopp des LBS dieser nicht mehr neu startet.
    Deaktivierst du den HUE LBS? Wenn ja, startet dieses Verhalten danach? D. H. Wenn du ihn dann wieder starten willst?
    Ich muss die entsprechenden LBS updaten habe aber gerade nicht die Zeit.

    Kommentar


      #3
      Hallo, das "Problem" habe ich leider auch bei einigen meiner LBS... auch "friert" manchmal die EDOMI-Buskommunikation komplett ein. Ich kann das Problem aber auch gar nicht eingrenzen, da es mal 2 Wochen läuft und dann wieder nur 1 Tag.. Habt ihr eine Idee dazu?
      www.knx-Hausblog.de

      Kommentar


        #4
        Ich kenne jetzt die genannten LBS nicht, aber wenn es Daemons sind dann fehlt da vllt ein dbKeepAlive() im EXEC-Teil?

        Kommentar


          #5
          Sorry, für die späte Rückmeldung.

          Also beim Home-Connect-SSE LBS bin ich jetzt weiter gekommen. Wenn die Verbindung zum Server unterbrochen wurde, hörte der LBS schlicht auf was zu tun bzw. er wartete einfach bis was kommt, was nicht mehr kommen konnte. Ich hab ein wenig dran rum gebastelt und nun startet er die Verbindung neu, so wie es gedacht war (hat die fehlende Verbindung nicht erkannt bzw die leere Antwort nicht verarbeitet).

          Beim HUE-Bridge LBS ist die Sache vermutlich ähnlich. Inzwischen vermute ich, dass im Exec Teil auf eine Antwort gewartet wird, die nicht kommt. Genauer gesagt denk ich, dass es in der Unterfunktion „function updateDeviceStatus“ bei „$hueDevices = $con->getLights()“ hängen bleibt.

          Die Vermutung ist, dass es da stehen bleibt und auf eine Antwort wartet. Ich weis zwar noch nicht warum die Verbindung, netzwerkseitig, abbricht, aber ich geh jetzt mal davon aus, dass dort die Ursache liegt. Nun muss das anscheinend zu einem ungünstigen Zeitpunkt passieren, da der LBS normalerweise ein reconnect macht, was er an sich auch tut, nur wenn eben genau das timing passt scheint er hängen zu bleiben. Das würde auch erklären warum das so zufällig auftritt und auch nicht bei allen.

          Ich suche noch nach einer Lösung für den Hue-LBS. 2 Ideen hätte ich. Eine Art Timeout einbauen oder den LBS durch ne Logik neu starten wenn er länger nix tut. Ich teste das mal.

          Wie gesagt, ich denke nicht, dass es an Edomi liegt, hab verschiedene Versionen durchprobiert. Auch die Exec Teile laufen eigentlich und die Daemons auch.

          Ob ich mit meiner Vermutung richtig liege, weis ich nicht, aber ich meld mich. Vielleicht kann man dann auch andere LBS in diese Richtung robuster machen.

          (leider haben Änderungen im Netzwerk und Erweiterung des Hue-LBS um ein bisschen Logging dazu geführt, dass der jetzt viel länger läuft ohne auszufallen (Tage). Daher dauert es immer länger festzustellen, ob, wann und wie der Fehler auftritt. Kann also dauern bis ich da weiter bin)


          MFG

          Andreas


          Kommentar


            #6
            Es scheint als lag ich mit meiner Vermutung richtig. Fehler-Ursprung liegt wohl an Netzwerkproblemen bzw. Verbindungsabbrüchen.
            Für den HUE-LBS hab ich für mich folgende Lösung gefunden:

            Ich hab in die curl.php unter Phue/library/Phue/Transport/Adapter/Curl.php im Teil „public function send“ die Zeilen:

            curl_setopt($this->curl, CURLOPT_CONNECTTIMEOUT, 120);

            curl_setopt($this->curl, CURLOPT_TIMEOUT,120);


            ergänzt.

            Zwar bricht die Verbindung gelegentlich noch ab, aber der LBS bleibt nicht mehr hängen, sondern verbindet sich brav neu und funktioniert weiter.
            Soweit wären meine Probleme gelöst. Danke an alle für Tipps und Hinweise.
            Und "Netzwerk/Verbindungsabbrüche" ist scheinbar ein ganz heißer Tipp, für alle die so komisches Verhalten bei den LBSen, insbesondere mit Daemon, haben wie ich.


            Grüße

            Andreas

            Kommentar


              #7
              Gut dass es wieder läuft, dennoch würde ich empfehlen das Problem ursächlich (Netzwerk) statt symptomatisch (curl timeout) zu lösen.

              Kommentar


                #8
                Da hast du natürlich recht.
                Mir ist das Netzwerkproblem im Prinzip auch bekannt, nur war mein Problem immer, dass nicht jeder "Netzwerkabbruch" auch zu einem Ausfall des LBS führte und die Analyse daher erschwert wurde. Die Timeout-Sache ist nur eine Ergänzung, um Probleme zu vermeiden. Es gibt Konstellationen und Situationen da lassen sich Netzwerkstörungen nicht vermeiden (VPN, Router-Neustart, Zwangstrennung durch Anbieter..), aber damit ist sichergestellt, dass sich das nicht auf den HUE-LBS auswirkt und ich Edomi nicht gleich neu starten muss. Kann nämlich auch dauern bis man merkt das der LBS hängt. Und man kann dann beruhigt Standortvernetzung mit VPN und co machen
                Darauf test ich gerade.

                Kommentar

                Lädt...
                X