[Neues Modul] 74_AutomowerConnect, Husqvarnas OpenAPI

[isy]

Bin mir nicht sicher mit deiner Begründung. Es gab nur den einen Change, also die Installation der neuen Modul-Version.

Ich habe jetzt die Version 27625 2023-05-29 01:26:46 geladen und mit den Koordinaten von gestern versorgt.
Sieht wieder normal aus.

Jetzt zurück zur heutigen Version mit den gestrigen Koordinaten: Alles verschoben.
Eingabe den heutigen, geänderten Koordinaten: Wieder ok.

Das deutet darauf hin, dass evtl. in der Programmlogik eine Berechnung geändert wurde.
Meinen Post hatte ich als Hinweis auf einen möglichen Bug verstanden.

Die Grafik ist für mich eine schöne Ergänzung und sie lässt sich ja leicht verschieben.
Das ist also keine Problematik, die die Funktion des Moduls beeinträchtig.

[Ellert]

An der Berechnung der Positionen hat sich nichts geändert, aber es werden nicht mehr immer alle Daten aktualisiert.
Beim ersten Aufbau der Detailansicht werden die mapDesignAttributes übertragen, die Ladestationskoordinaten, die Grundstücksgrenzkoordinaten, die Mähbereichsgrenzkoordinaten und die Koordinaten des bereits vorhanden Mäherpfades.
Wenn neue Positions oder es eine Fehlermeldung gibt werden nur noch die Positionsdifferenzdaten oder Fehlerdaten zur Aktualisierung der Karte übertragen. Vorher wurden bei jeder Aktualisierung alle Daten übertragen.

Als Koordinaten der Ladestation wird zuerst die Mitte Deutschlands genommen, wenn es Koordinaten des Mähers in der Ladestation gibt, dann werden die genommen. Falls aber das Attribut für die Ladestationskoordinaten gesetzt ist, dann wird die LS mit diesen Koordinaten angezeigt. Die berechnete Position der Ladestation verändert sich nur, wenn die Detailansicht neu geladen wird, dass ist aber nur nach einem Neustart oder bei Definition der Fall und nicht im eingeschwungenen Zustand. Wenn das stört, könnte ich das zurück bauen.

Wenn die Bildgröße mapImageWidthHeight nicht angegeben ist, wird '350 650' genommen.

Wenn mapImageCoordinatesToRegister nicht angegeben ist, werden die Extremwerte der vorhandenen Positionsdaten genutzt.

Wenn scaleToMeterXY nicht angegeben ist, dann wird die Skalierung verwendet, die in der Mitte Deutschlands gilt (67425, 108886).

Wenn mapImageCoordinatesUTM angegeben wird und vorher mapImageCoordinatesToRegister angegeben wurde dann wird scaleToMeterXY für die Lage des Mähbereiches berechnet.

Also, je nachdem was vorher gesetzt war oder nicht kann es zu unterschieden in der Skalierung oder Registrierung kommen.

Einen Fehler kann ich nicht erkennen.

Über die Genauigkeit der GPS-Daten sagt Husqvarna hier etwas: GPS-Verfolgung in der Automower® Connect-App

Diese Genauigkeit kann ich bestätigen für den AM430x. Ich würde mich wundern, wenn es keine Abweichungen beim Mäherpfad gibt. Mit AIM (Genauigkeit 1m) oder EPOS soll es wohl besser sein.

[RobertSch]

Danke für den Hinweis, hab's eingecheckt, ab morgen im Update und jetzt im Repository.

Moin Ellert!

Könntest du an der Stelle nochmal nachhelfen? Du hast zwar den Aufruf in dein Package eingefügt, leider an einer Stelle, wo es nichts bringt. Du müsstest das einmal vor das package (Zeile 27), also beispielsweise in Zeile 26 setzen. Den Fehler haben wahrscheinlich eh nicht viele, denn sobald ein Modul die Funktion schon mal eingebunden hat, dann ist sie überall verfügbar. Allerdings, wenn du eine neue FHEM Instanz aufsetzt und dann das AutomowerConnect Modul einsetzt, dann fehlt eben diese Funktion noch. Deshalb muss sie bereits global eingebunden werden, sonst meckert er über die fehlende Sub Routine und stürzt ab.

Auszug der Fehlermeldung im Log:

Code Auswählen Erweitern

Undefined subroutine &main::timelocal called at ./FHEM/74_AutomowerConnect.pm line 248
Wenn die Zeile vor dem package eingefügt wird, verschwindet diese Meldung und das Modul funktioniert einwandfrei.

Gruß
Robert

[Ellert]

Danke nochmal für Deine Hilfe, hab's korrigiert und eingecheckt.

timelocal wird jetzt im Package aufgerufen.

Diese Fehler fallen bei mir nicht auf, weil ich kein frisches System habe.

[Ellert]

Morgen im  Update:

Es besteht die Möglichkeit statt des Mäherpfades nur die Wegpunkte anzuzeigen.

Der Browsercache muss gelöscht und die Detailseite neugeladen werden.
Dann sind mapDesignAttibutes mit

Code Auswählen Erweitern

set <name> defaultDesignAttributesToAttribute auf die Standardwerte zu setzen, um die zusätzlichen Designattribute einzufügen.
Wenn das Designattribut mowingPathUseDots="1" gesetzt wird werden nur die Wegpunkte des Mäherpfades angezeigt. Das kann bei einer hohen Zahl von Linien die Übersichtlichkeit steigern.

Hier die kompletten Standarddesignattribute, falls jmd. sie vorher setzen möchte:

Code Auswählen Erweitern

areaLimitsColor="#ff8000"
areaLimitsLineWidth="1"
areaLimitsConnector=""
propertyLimitsColor="#33cc33"
propertyLimitsLineWidth="1"
propertyLimitsConnector="1"
errorBackgroundColor="#3d3d3d"
errorFont="14px Courier New"
errorFontColor="#ff8000"
errorPathLineColor="#ff00bf"
errorPathLineDash=""
errorPathLineWidth="2"
chargingStationPathLineColor="#999999"
chargingStationPathLineDash="6,2"
chargingStationPathLineWidth="1"
chargingStationPathDotWidth="2"
otherActivityPathLineColor="#999999"
otherActivityPathLineDash="6,2"
otherActivityPathLineWidth="1"
otherActivityPathDotWidth="4"
leavingPathLineColor="#33cc33"
leavingPathLineDash="6,2"
leavingPathLineWidth="2"
leavingPathDotWidth="4"
goingHomePathLineColor="#0099ff"
goingHomePathLineDash="6,2"
goingHomePathLineWidth="2"
goingHomePathDotWidth="4"
mowingPathDisplayStart=""
mowingPathLineColor="#ff0000"
mowingPathLineDash="6,2"
mowingPathLineWidth="1"
mowingPathDotWidth="4"
mowingPathUseDots=""


[Zergman]

Hallo Ellert,

nach dem Update vom 23.5. aktualisieren sich bei mir die userReadings leider nicht mehr. Du schreibst dazu:

Das neue Reading device_state übernimmt die Funktion von state, also auch die Triggerung von userReadings, usw.

Könntest du bitte noch ein Beispiel hier einstellen, wie die userReadings geändert werden müssen, damit sie wieder funktionieren.
Vielen Dank!

[Ellert]

Hallo Ellert,

nach dem Update vom 23.5. aktualisieren sich bei mir die userReadings leider nicht mehr. Du schreibst dazu:

Das neue Reading device_state übernimmt die Funktion von state, also auch die Triggerung von userReadings, usw.

Könntest du bitte noch ein Beispiel hier einstellen, wie die userReadings geändert werden müssen, damit sie wieder funktionieren.
Vielen Dank!

Da es kein Abfrageintervall mehr gibt, bzw. die Api nachts einmal gelesen wird ist es nur noch eingeschränkt sinnvoll auf device_state zu triggern.

Je nach dem welchen Wert Du mit userReadings darstellen möchtest gibt es vier grundsätzliche Möglichkeiten:

device_state: connected - alles was nur nachts aktualisiert wird ( https://developer.husqvarnagroup.cloud/apis/automower-connect-api#openapi )

mower_wsEvent: status-event - alle Daten, die mit Statusevents geliefert werden ( https://developer.husqvarnagroup.cloud/apis/automower-connect-api#websocket )

mower_wsEvent: positions-event - alle Daten, die mit Positonsevents geliefert werden ( https://developer.husqvarnagroup.cloud/apis/automower-connect-api#websocket )

mower_wsEvent: settings-event - alle Daten, die mit Settingsevents geliefert werden ( https://developer.husqvarnagroup.cloud/apis/automower-connect-api#websocket )

Welche Daten wie geliefert werden ist aus den vorstehenden Links ersichtlich.

Die Beispiele im Wiki habe ich angepasst, aber nicht getestet. Falls sie nicht funktionieren, hilft die Befehlsreferenz weiter: https://commandref.fhem.de/commandref_DE.html#userReadings

[Zergman]

Hallo Ellert,

vielen Dank für die schnelle Antwort.

Bisher habe ich die Werte von

Code Auswählen Erweitern

$hash->{helper}{mower}{attributes}{statistics}{totalCuttingTime} und

Code Auswählen Erweitern

$hash->{helper}{mower}{attributes}{statistics}{numberOfChargingCycles} als UserReadings ausgegeben und benutzt um die Aktivität des Automowers im Auge zu behalten. Wenn ich deine Nachricht richtig verstehe, werden diese Werte jetzt aber nur noch einmal pro Tag (in der Nacht) aktualisiert. Ist das richtig? Oder kann man den API-Aufruf irgendwie manuell triggern?

[Ellert]

Ja.
Regelmäßige Polling der API ist nicht vorgesehen.

Um die Aktivität des Mähers zu beobachten gibt es sicherlich aussagekräftigere Readings, wie zum Beispiel batteryPercent, das wird nach jedem Ladezyklus einmal mit 100% aktualisiert oder besser mower_aktivity zeigt ja direkt die Aktivität.

[Zergman]

noch eine Frage / Beobachtung:
Seit der Umstellung auf WebSocket kommen bei mir wesentlich weniger Wegpunkte des Roboters an als zuvor. Das zeigt sich in weniger roten Linien auf der Karte und die Fahrstrecke des Automowers kann nicht mehr so richtig nachvollzogen werden. Wenn der Mäher aktiv ist, sehe ich zwar in regelmäßigen Abständen "mower_wsEvent: positions-event" Events (ca. aller 3 ... 5 Minuten) aber wenn ich mir die Positionen ausgeben lasse

Code Auswählen Erweitern

{Dumper($defs{AutoMower}->{helper}{mower}{attributes}{positions})}ist in dem Array immer nur eine Position.

Sendet das WebSocket-Interface wirklich nur so wenige Positionen oder gehen die irgendwo anders verloren?

[Ellert]

Es geht nichts verloren, im Mowerhash stehen nur die aktuell über Websocket gelieferten Positionen (Reading statistics_newGeoDataSets). Alle Positionen stehen in hash->{helper}{areapos}

Mit verbose 4 kannst Du den Verkehr über Websocket anzeigen.

Die Positionen werden beim Mähen ca. alle 30s im Mäher erfasst. Ob Positionen fehlen könntest Du also überprüfen.

Falls nur noch Punkte statt Linien angezeigt werden, müsstest Du in dem Attribut mapDesignAttributes  mowingPathUseDots="0" auf mowingPathUseDots="" ändern, ggf. defaultDesignAttributesTo Attribut  setzen.

[Zergman]

Mit verbose=4 habe ich bei meinem Mäher (Automower 415X) folgende Beobachtungen gemacht:

• positions-event kommt immer nur kurz vor oder kurz nach einem status-event
• diese positions-events enhalten immer nur eine Position
• neben dieser status/positions Kombination empfängt das Modul zwar einmal pro Minute eine WebSocket-Nachricht, diese ist aber immer leer
• => bei mir kommt nur einen neue Position des Mähers an, wenn sich der Status (Batteriestand, Betriebsmodus, etc.) ändert

Kann diese Beobachtung noch jemand anderes bestätigen oder ist das ein spezielles Problem bei mir und meinem Mäher?

[Ellert]

neben dieser status/positions Kombination empfängt das Modul zwar einmal pro Minute eine WebSocket-Nachricht, diese ist aber immer leer

Das ist die Antwort des Servers auf den Keep Alive Ping des Moduls. Der Ping ist notwendig, damit der Server den Websocket nicht schliesst.
Zusätzlich wird alle 2 h ein Reopen des Websockets durchgeführt, da der Server sonst die Verbindung nach 2 Stunden schliesst.

Ich bekomme bei LEAVING/MOWING/GOING_HOME status-events in verschiedenen Zeitabständen (status_TimestampDiff) zwischen 30 s und 840 s, selten auch kürzer als 30 s.

positions-event kommt immer nur kurz vor oder kurz nach einem status-event

Das beobachte ich auch.
Es kommen status_TimestampDiff/30 Positionen mit dem positions-event. Wenn status_TimestampDiff = 30 s, dann wird eine Position und wenn status_TimestampDiff = 840 s, dann werden 28 Positionen geliefert.

Bei PARKED_IN_CS/CHARGING gibt es alle 840 s ein status-event und ein positions-event.

Unter scheidet sich der Pfad in der Smartphone App von dem im Modul angezeigten?

[Zergman]

Unter scheidet sich der Pfad in der Smartphone App von dem im Modul angezeigten?

Ja, deutlich. Im der Smartphone APP kann ich den Weg des Roboters nachvollzihen. In FHEM seit dem Umstieg auf Websocket nicht mehr.

[Ellert]

Gibt es Fehlermeldungen in der Nähe der Events im Log?


Unterscheiden sich die Events im Log von denen die Wscat liefert, wie hier beschrieben https://developer.husqvarnagroup.cloud/apis/automower-connect-api#websocket?

Wenn ja, dann hätte ich gern einen Logauszug und dazu passend das, was Wscat liefert.