Ankündigung

Einklappen
Keine Ankündigung bisher.

LBS19000935 - Husqvarna Automower Connect API

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

    Zitat von MrIcemanLE Beitrag anzeigen
    Ich habe jetzt nochmal genauer in den Logs geschaut. Es vergehen schon ein paar Minuten, bis die erste Message über den Websocket kommt.
    Bei mir funktioniert es auch, vielen Dank

    Allerdings kommt beim Neustart von EDOMI durch den LBS ein Fehler, hervorgerufen durch das EXE-Skript:
    Fehlercode: 8 | Zeile: 41 | Undefined property: stdClass::$data ERROR (Zeile 41: $data = $obj->data; )
    Fehlercode: 2 | Zeile: 43 | First parameter must either be an object or the name of an existing class ERROR (Zeile 43: if(!property_exists($data, 'attributes')){ )

    Den Status-LBS habe ich angepasst und in Version 0.5 hochgeladen. Hab ihn aber noch nicht aufgeräumt, es sind noch doppelte Informationen enthalten.

    Kommentar


      Version 0.4.1 sollte den Fehler beim ersten Start des LBS jetzt sauber im LBS-Log statt im System-Log dokumentieren. Vielleicht kannst du aber mal den Log-Ausschnitt davon posten, damit ich sehen kann, warum der Fehler entstanden ist? Das kann ich gerade nicht so ganz nachvollziehen.

      Außerdem läuft die 0.4.1 jetzt komplett mit logic_setOutputQueued()

      Ich weiß nicht genau, ob ich schon darauf hingewiesen habe, aber der Eingang A1 darf jetzt nicht mehr extern getriggert werden. Auch nicht über das System-KO "Systemstart". Die vordefinierte "1" genügt für den Autostart.
      Gruß
      Stefan

      Kommentar


        Ich habe gerade die 0.4.1 eingespielt, jetzt bekam ich beim Start drei Fehler, konnte diese aber eingrenzen. Es lag daran, dass mein API-Limit überschritten war. Hintergrund: E5 habe ich beim ersten Test leer gelassen und der LBS hat dann in kürzester Zeit viele API-Calls ausgeführt und das Limit war überschritten. Jetzt habe ich die ID wieder an E5 angegeben und einen anderen API-Key verwendet, dadurch läuft es und es kommt auch kein Fehler beim Start.

        Der vollständigkeitshalber die Logs mit dem Fehler beim Start:
        {EDOMI,ERRLOG_2022-06.htm,11.06.2022,10:40:18,080324,11793}
        Zeitstempel ms Prozess PID Meldung Status
        2022-06-11 10:40:18 080285 ? 11793 Datei: /usr/local/edomi/www/data/liveproject/lbs/EXE19000935.php | Fehlercode: 8 | Zeile: 42 | Undefined property: stdClass::$data ERROR
        2022-06-11 10:40:18 080703 ? 11793 Datei: /usr/local/edomi/www/data/liveproject/lbs/EXE19000935.php | Fehlercode: 2 | Zeile: 42 | First parameter must either be an object or the name of an existing class ERROR
        2022-06-11 10:40:18 080852 ? 11793 Datei: /usr/local/edomi/www/data/liveproject/lbs/EXE19000935.php | Fehlercode: 8 | Zeile: 43 | Undefined property: stdClass::$data ERROR

        Der zugehörige Log:
        {EDOMI,CUSTOMLOG_Huqvarna Automower API --- LBS19000935.htm,11.06.2022,10:40:17,019984,11793}
        Zeitstempel ms PID LogLevel Meldung
        2022-06-11 10:40:17 019637 11793 err EXE19000935 [v0.4.1]: Husqvarna Automower Connect Daemon started
        2022-06-11 10:40:17 021780 11793 debug EXE19000935 [v0.4.1]: new husqvarna_api
        2022-06-11 10:40:17 907145 11793 debug EXE19000935 [v0.4.1]: login husqvarna api successful
        2022-06-11 10:40:17 909452 11793 debug EXE19000935 [v0.4.1]: connecting websocket client to server
        2022-06-11 10:40:18 079788 11793 crit EXE19000935 [v0.4.1]: Fehlerhafter Inhalt
        2022-06-11 10:40:18 079978 11793 crit EXE19000935 [v0.4.1]: ================ ARRAY/OBJECT START ================
        2022-06-11 10:40:18 080097 11793 crit EXE19000935 [v0.4.1]: stdClass::__set_state(array([LF] 'message' => 'Limit Exceeded',[LF]))
        2022-06-11 10:40:18 080177 11793 crit EXE19000935 [v0.4.1]: ================ ARRAY/OBJECT END ================
        2022-06-11 10:40:18 082552 11793 crit EXE19000935 [v0.4.1]: Property 'attributes' not found
        2022-06-11 10:40:18 091979 11793 debug EXE19000935 [v0.4.1]: E2 refresh --> update username
        2022-06-11 10:40:18 095339 11793 debug EXE19000935 [v0.4.1]: E3 refresh --> update password
        2022-06-11 10:40:18 096309 11793 debug EXE19000935 [v0.4.1]: E4 refresh --> update apikey
        2022-06-11 10:40:18 098016 11793 debug EXE19000935 [v0.4.1]: E5 refresh --> update mowerid
        2022-06-11 10:40:18 100847 11793 debug EXE19000935 [v0.4.1]: E10 refresh --> update LogLevel
        2022-06-11 10:40:18 494667 11793 debug EXE19000935 [v0.4.1]: Websocket-Message: {"ready":true,"connectionId":"TjI14cJuDoECI8s=" }
        2022-06-11 10:40:18 497687 11793 debug EXE19000935 [v0.4.1]: String to be decoded:
        2022-06-11 10:40:18 497891 11793 debug EXE19000935 [v0.4.1]: value of var => {"ready":true,"connectionId":"TjI14cJuDoECI8s=" }
        2022-06-11 10:40:18 499650 11793 debug EXE19000935 [v0.4.1]: begin websocket => setting output
        2022-06-11 10:40:18 500752 11793 notice EXE19000935 [v0.4.1]: Skipping data - property id not found
        2022-06-11 10:40:18 500894 11793 notice EXE19000935 [v0.4.1]: ================ ARRAY/OBJECT START ================
        2022-06-11 10:40:18 500988 11793 notice EXE19000935 [v0.4.1]: stdClass::__set_state(array([LF] 'ready' => true,[LF] 'connectionId' => 'TjI14cJuDoECI8s=',[LF]))
        2022-06-11 10:40:18 501072 11793 notice EXE19000935 [v0.4.1]: ================ ARRAY/OBJECT END ================

        Kommentar


          Zitat von panzaeron Beitrag anzeigen
          E5 habe ich beim ersten Test leer gelassen und der LBS hat dann in kürzester Zeit viele API-Calls ausgeführt und das Limit war überschritten.
          Stimmt, das ist ein Problem der "schnellen" while-Schleife, welches ich nicht bedacht habe. Ich sehe hier spontan zwei kurzfristige Lösungsmöglichkeiten:
          wenn keine Mower-ID angegeben ist, macht der LBS einen Request, gibt das Ergebnis aus und
          1. beendet dann den EXEC teil. Nach dem die ID dann eingetragen wurde, kann man mit einer 1 über die Live-Ansicht den LBS wieder starten oder ein Edomi-Restart mit Mower-ID führt dann zum "normalen" verhalten
          2. wartet 15 Minuten und fragt dann die Daten erneut ab, das würde in den 15 Minuten den Exec-Teil blockieren und dennoch nur Daten an A15 liefern.
          Mittelfristig könnte man versuchen die MowerID zu ermitteln, wenn es nur einen Mäher gibt. Das braucht aber wieder etwas Zeit und Testaufwand.
          Gruß
          Stefan

          Kommentar


            Also ich finde die 1. Lösung am idealsten.
            Denke die Anleitung zur Ermittlung der Mower-ID ist plausibel, diese dann in die Beschreibung des LBS gepackt...
            dann seh ich da keine Probleme
            Beim 2. Lösungsansatz gefällt mir nicht das der LBS dann in einer 15 min. Schleife fest hängt.

            Kommentar


              Das waren auch meine Gedanken, wobei der LBS seine "normale" Arbeit aufnehmen würde, sobald die ID per Live-View gesetzt wurde. (theoretisch) 🙃
              Gruß
              Stefan

              Kommentar


                Also ich bekomme seit 2 Tagen regelmässig diese Einträge im Fehler-Log und der LBS bleibt "stehen".....
                Wenn ich den LBS dann manuell neu triggere dann läuft er wieder paar Stunden und dann wieder das gleiche....
                Kann das was mit dem LBS zu tun haben?

                2022-06-18 21:56:14 449947 ? 23960 Datei: /usr/local/edomi/main/include/php/vendor/textalk/websocket/lib/Base.php | Fehlercode: 2 | Zeile: 444 | fread(): SSL: Connection timed out ERROR
                2022-06-18 21:56:14 450735 ? 23960 Datei: /usr/local/edomi/main/include/php/vendor/textalk/websocket/lib/Base.php | Fehlercode: 2 | Zeile: 430 | fwrite(): SSL: Broken pipe ERROR
                2022-06-18 21:56:14 454610 ? 23960 Datei: /usr/local/edomi/main/include/php/vendor/textalk/websocket/lib/Base.php | Fehlercode: 1024 | Zeile: 478 | Could only write 0 out of 6 bytes.

                Kommentar

                Lädt...
                X