5 min. (Fehler kommt erst seit dieser Version)
die version hat nur einen zusätzlich test im debug, keine funktionelle änderung.
der http-code sagt eindeutig, das zuviele abrufe erfolgt sind
https://developer.husqvarnagroup.cloud/apis/automower-connect-api#readme
Limits
The following limitations currently apply to the Automower® Connect API:
- Max 1 request per second and
appKey. - Max 10 000 request per month and
appKey.
Any additional requests above these limits will be throttled.
der zugang ist dann für 24h gesperrt.
am einfachsten: weiteren key anlegen
1 „Gefällt mir“
Hi,
da sich so langsam das Frühjahr nähert habe ich das Modul mal wieder eingebunden.
Was mit auffällt ist, dass im Webfront nur Schnitthöhe und Licht schaltbar sein. Die Profile sind richtig verlinkt - fehlt evtl. die Request_Action?
Ging in einer vorherigen Version. Ich wollte das Modul ab diesem Jahr nutzen um den Mäher via Wetterstation zu steuern was Blattfeuchte und auch Schnitthöhe in Bezug auf Hitze angeht.
Mache ich evtl. was falsch oder muss man es manuell aktivieren.
Edit: Also manuell geht es - sollte aber evtl. direkt vom Modul „richtig“ gesetzt werden?
Hmm, sollte eigentlich noch funktionieren.
Nun kann ich das gerade nicht ausprobieren, mein Mähger ist noch im Service und demzufolge noch nicht verbunden.
Was siehst Du denn, was passiert, ggfs. auch im Instant-Debug von AutomowerDevice / AutomowerIO?
Hallo demel,
habe das Modul wieder in Betrieb genommen. Bekomme aber wenn ich die Parkaktion aufrufen will folgende Fehlermeldung:
Kannst du damit etwas anfangen?
danke+lg
hagi
Ja, bin gerade nicht zuhause, kümmere mich
Dasselbe gilt auch für die Pausen-Aktion 
danke!
ja, das ist generell bei alle aktionen. dachte das hätte ich schon gefixed … bist du auf beta?
war ich nicht, hab auf beta gewechselt und keine Fehlermeldung mehr!
danke+lg
hagi
okidoki.
n.z.I: es gibt demnächst mal eine größeres update, weil die API eine übertragung bietet per PUSH. d.h. husqvarna schickt daten, sobald der mäher was an die cloud geschickt hat.
das erfolgt bei positionsänderungen o.ä. aber auch nur in einem intervall von ca. 5 Minuten
weil das intern eine größere umstellung ist, ist das bei mir noch im Test
Hallo,
folgende Frage. Seit einiger Zeit kann man bei einigen Fehlern (z.B. wenn der Mäher sich „festgefahren hat“ oder wenn der Mäher „gefangen ist“) den Fehler über die App und von der Ferne zurückstellen, so dass man ihn dann wieder starten kann und er nochmal versucht sich aus der misslichen Situation zu befreien.
Meine Frage ist nun: Geht das auch mit dem Modul? Und wenn nicht: könnte man versuchen das zu implementieren?
Beste Grüsse
gros_ibou
aha, interessant.
hatte ich bisher noch nicht.
ich schau mal, ob die api was hergibt
Nachtrag: ich habe in der API-Dokumentation nichts neues gefunden.
Was macht man dann genau? Kannst Du mir Screenshots schicken, wenn das bei Dir wieder auftritt? Eventuell kann ich mir da was zusammen reimen.
Mach ich gerne. Muss halt nur warten, bis er sich wieder irgendwo verfängt…
Ist schon etwas merkwürdig, ich meine, das sich meiner (ein 430X) die Tage auch mal festgefahren hatte und da ist mir in der App nichts aufgefallen. Aber vielleicht war ich da einfach aus Routine schon auf dem Weg zu Mäher …
Praktischer Weise ist es gerade passiert 
. Screen Shots anbei. Bei dem Fehler habe ich auf „weitere Informationen“ gedrückt und dann kommt der zweite screen
Es gibt nun eine neue Beta-Version.
Hier wurden erhebliche Änderungen durchgeführt, um die WebSocket-Schnittstelle von Husqvarna zu nutzen - bedeutet, sobald der Mäher Updates an die Husqvarna-Cloud geschickt hat werde diese an die Instanz weiter geleitet.
Trotz langem Test durch mich sind natürlich Probleme nicht auszuschliessen. Bitte unbedingt erst die Versionshinweise im README lesen!
@gros_ibou: in der Geräte-Instanz ist eine Aktion „FORCE RESTART“, die ich zum Test für das o.g. „FEHLER ZURÜCKSETZEN“ eingebaut hatte. Ist nur der damals angekündigte Test, vielleicht klappt es damit. Dann könnte ich es weiter integrieren.
1 „Gefällt mir“
Danke demel für dein neues Beta!
Funktioniert auch soweit. Nur bekomme ich die Anzeige der fehlerhaften Instanzen nicht weg. Auch ein erneutes Öffnen der Console hilft nicht. Bei mir werden sowohl die I/O (Automower I/O) als auch die Splitter-Instanz (ws Client) als fehlerhaft angezeigt.
lg
hagi
P.S. Muss mich korrigieren: Hat nur 2 Stunden funktioniert - jetzt bekomme ich keine Daten mehr rein und kann auch manuell nicht aktualisieren ;-(
Update: Klassiker, Neustart von Symcon hat mal die Fehlermeldungen der Instanzen behoben, werde es beobachten
Ach, wie unschön.
Mach bitte mal folgendes
- in allen 3 Instanzen Debug aktivieren (Limitierung erhöhen)
- in der Splitter-Instanz das Panel „Referenz“ ausklappen und Screenshot machen (mich interessiert der Timer)
- von der IO-Instanz bitte auch Screenshot
- dann in der Splitter-Instanz „Zugriff testen“ durchführen
Ändert sich etwas?
Bitte die Dumps und Screenshot an mich schicken
Welche Art des Zugriffs hast Du? Anwendungs-Schlüssel oder via Symcon?
Hi demel,
ich habe den Zugriff über den Anwendungsschlüssel realisiert.
Der Fehler ging wie oben ergänzt mit einem Neustart von Symcon weg. Die Debugs die ich vorher gemacht hatte, habe ich leider nicht gespeichert.
Es läuft jetzt die letzten 12 h fehlerfrei -
Danke nochmals für deinen Support!
lg
hagi
Jepp, alles klar.
Das Problem hier ist eine Mischung aus Husqvarna-API und Symcon-Vorgabe
Es geht ja um eine Websocket-Schnittstelle und die benötigt einen API-Token im Header der API-Key wird - wie üblich - durch das Login geholt.
Nun ist die Wegsacket-Schnittstelle ja ein Modul von Symcon, das genau eine spezifische Funktion hat, nämlich Websocket.
Das Login muss von jemand anderem gemacht werden, das ist in diesem Fall der Splitter (was der frühere IO ist).
Nun ist es aber so, das bei fehlendem oder abgelaufenen API-Key die Websocket-IO-Instanz in „INAKTIV“ geht und das die der Parent vom Splitter ist, ziehht der sich auch in die Schmollende zurück (und das Device natürlich dann auch) und damit gibt es kein Rennen des Token mehr.
Ich habe für diese Fälle im Splitter einen Timer („RenewTimer“) etabliert, der 2 Funktionen hat
- er sorgt rechtzeitig dafür, das vor Ablauf der Gültigkeit des API-Tokens dieser erneuert wird - das sind meiner Erinnerung nach immer so 24h, d.h. ein paar Minuten vor Ablauf der Gültigkeit wird ein neuer Token angefordert und im Header der IO-Instanz eingetragen
- wenn aus irgend einem Grund die IO.Instanz inaktiv wird, startet dieser Timer nach 60s ebenfalls eine Login.
Also hätte eigentlich nach einer Minuten sich die von dir geschilderte Sperre auflösen müssen.
Aber es gibt wohl eine Raise-Condition, die ich nicht bedacht habe …
Egal, wenn es nochmal auftreten sollte, bitte die o.g. Debugs etc machen.
Durchbrechen kann man diese Deadlock auf jeden Fall indem man manuell durch „Zugriff testen“ eine Login erzwingt, was dann den Token holt und im IO setzt.