[Neues Modul] 74_AutomowerConnect, Husqvarnas OpenAPI

[Ellert]

Dann müsste

Code Auswählen Erweitern

{$defs{<devicename0>}->{helper}{mower_id}} und

Code Auswählen Erweitern

{$defs{<devicename1>}->{helper}{mower_id}} in der Befehlszeile mit Idx Idy übereinstimmen.

Dann könnte es sein, dass für beide Mäher WS-Event zur gleichen Zeit kommen.

Mit verbose 4 könntest Du sehen ob für beide Mäher Id eng beieinander liegende Events kommen, ggf das Attribut global mseclog 1 setzen

Sind die Inhalte der Readings, die gleichzeitig in beiden Mähern aktualisiert werden stimmig, passt die nächste Startzeit zu dem Mäher usw?

[Stefan H.]

Habe die beide Mäher versuchshalber in der Husqvarna Cloud noch umbenannt, um keine Leerzeichen im Namen zu haben. Die Info kam auch korrekt bei den beiden Devices an; das Verhalten bei Reading-Updates hat sich aber leider nicht verbessert.
Es werden immer noch die Readings beider Devices mit demselben Inhalt beschrieben, wenn von einem Mäher ein Update kommt.

Code Auswählen Erweitern

0 => Shorty-West 2d84075a-a676-4375-bfdd-5c7ab927c9cf
1 => Shorty-Sued aa1d3c59-aba6-4b7e-8c9f-600b988a8f60

[Stefan H.]

Sorry, hatte dein Update nicht gesehen - werde dies gleich prüfen.

[Stefan H.]

Dann müsste
Code Auswählen
{$defs{<devicename0>}->{helper}{mower_id}}
und
Code Auswählen
{$defs{<devicename1>}->{helper}{mower_id}}
in der Befehlszeile mit Idx Idy übereinstimmen.

=> Ja, stimmt überein!

Dann könnte es sein, dass für beide Mäher WS-Event zur gleichen Zeit kommen.

Mit verbose 4 könntest Du sehen ob für beide Mäher Id eng beieinander liegende Events kommen, ggf das Attribut global mseclog 1 setzen

Sind die Inhalte der Readings, die gleichzeitig in beiden Mähern aktualisiert werden stimmig, passt die nächste Startzeit zu dem Mäher usw?

Man sieht im Log, dass ein Update von einem Mäher jeweils beiden Mäher-Devices zugewiesen wird; d.h. die Readings sind jeweils nur für eines der beiden Devices stimmig. Man sieht im Log auch, dass bei beiden Event-Verarbeitungen jeweils dieselbe Mäher-ID im Log angezeigt wird. Beispiel:

Code Auswählen Erweitern

2023.06.29 20:56:29.603 4: AutomowerConnect ShortySued wsRead: received websocket data: >{"id":"aa1d3c59-aba6-4b7e-8c9f-600b988a8f60","type":"status-event","attributes":{"battery":{"batteryPercent":96}
2023.06.29 20:56:29.634 4: AutomowerConnect ShortyWest wsRead: received websocket data: >{"id":"aa1d3c59-aba6-4b7e-8c9f-600b988a8f60","type":"status-event","attributes":{"battery":{"batteryPercent":96}Die id 'aa1d3c59-aba6-4b7e-8c9f-600b988a8f60' entspricht hierbei dem Mäher/Device 'ShortySued' - die zusätzliche Zuordnung beim Device 'ShortyWest' ist falsch.

Hier noch als Referenz der Wert des Readings 'api_MowerFound':

Code Auswählen Erweitern

0 => Shorty-West 2d84075a-a676-4375-bfdd-5c7ab927c9cf
1 => Shorty-Sued aa1d3c59-aba6-4b7e-8c9f-600b988a8f60
Zu dem im angehängten Log abgebildeten Zeitpunkt haben wir folgende Ist-Situation:

• Mäher "ShortySued" ist im Modus "HOME" und kurz vor Ende des Ladevorganges (Akku 96-100%)
• Mäher "ShortyWest" ist im Modus "MAIN_AREA" und noch mitten im Ladevorgang  (Akku knapp über 50%)

[Ellert]

Ja, jetzt sehe ich das auch. wsRead wird in einer Instanz eines Mähers von DevIo zweimal aufgerufen, einmal mit dem Hash von ShortySued und einmal mit dem Hash von ShortyWest, das hatte ich nicht erwartet. Dann kann der Filter nicht greifen.



Da bisher weniger 98% der aller FHEM Installationen mit Automower nur einen Mäher definieren, wollte ich kein zweistufiges Konzept.

Also werden bis auf Weiteres keine zusätzlichen Mäher unterstützt.

[Ellert]

Mir ist immer noch nicht klar was da abläuft.

Beide Module erhalten die gleichen Daten über Websocket (vermute ich) und diese werden geloggt, unabhängig davon, ob diese Daten auch in die Readings geschrieben werden. Das köntest Du prüfen, wenn nur ein Gerät definiert ist und beide Id im Log auftauchen.

Wenn es so ist wie ich vermute, dann erkenne ich hier keinen Fehler.

2023.06.29 20:56:29.603 4: AutomowerConnect ShortySued wsRead: received websocket data: >{"id":"aa1d3c59-aba6-4b7e-8c9f-600b988a8f60","type":"status-event","attributes":{"battery":{"batteryPercent":96}
2023.06.29 20:56:29.634 4: AutomowerConnect ShortyWest wsRead: received websocket data: >{"id":"aa1d3c59-aba6-4b7e-8c9f-600b988a8f60","type":"status-event","attributes":{"battery":{"batteryPercent":96}

Daher würden mich ein Log nach dem heutigen Update interessieren, da gibt es einen Logeintrag nach dem Filter mit dem batteryPercent Wert als Referenz. Es sollte dann jede Instanz nur ihren Wert loggen.

Wenn DevIo wie vermutet wsRead mit jedem Hash in jedem Gerät aufruft müssten 2 von diesen Logeinträgen zusehen sein.

[Stefan H.]

Hallo Ellert,

wie gewünscht habe ich eines der beiden Devices aus FHEM gelöscht; aktuell ist nur noch ein AutomowerConnect Device definiert ('ShortyWest').

Im Log sieht man Events von beiden Mähern, welche an das Device 'ShortyWest' gesendet werden. Die betreffenden Readings wurden (leider) auch bei allen im Log dargestellten Events aktualisiert (sieht man im Log [noch] nicht, jedoch im FHEM Webinterface).

Code Auswählen Erweitern

2023.06.30 12:46:39.351 4: AutomowerConnect ShortyWest wsRead: received websocket data: >{"id":"aa1d3c59-aba6-4b7e-8c9f-600b988a8f60","type":"status-event","attributes":{"battery":{"batteryPercent":95},"mower":{"mode":"MAIN_AREA","activity":"MOWING","state":"IN_OPERATION","errorCode":0,"errorCodeTimestamp":0},"planner":{"nextStartTimestamp":0,"override":{"action":"IPLANNER_OVERRIDE_ACTION_FORCE_MOW"},"restrictedReason":"NOT_APPLICABLE"},"metadata":{"connected":true,"statusTimestamp":1688121999224}}}<
Zeile 32851: 2023.06.30 12:47:19.936 4: AutomowerConnect ShortyWest wsRead: received websocket data: >{"id":"2d84075a-a676-4375-bfdd-5c7ab927c9cf","type":"status-event","attributes":{"battery":{"batteryPercent":100},"mower":{"mode":"HOME","activity":"PARKED_IN_CS","state":"RESTRICTED","errorCode":0,"errorCodeTimestamp":0},"planner":{"nextStartTimestamp":1688130000000,"override":{"action":"IPLANNER_OVERRIDE_ACTION_NOT_ACTIVE"},"restrictedReason":"WEEK_SCHEDULE"},"metadata":{"connected":true,"statusTimestamp":1688122039701}}}<
Da wsRead die Mower ID auch ans Modul übergibt, müsste die Filterung danach doch funktionieren? So wie ich verstanden habe, ist es aktuell implementiert?

Gerne werde ich morgen ein FHEM Update durchführen und den entsprechenden Log Auszug wieder hier posten.

Gruss,
Stefan

[Stefan H.]

Hallo Ellert, hab grad gesehen, dass dein Checkin @27715 schon im heutigen FHEM Update mit drin war. Hier der resultierende Log-Auszug:

Code Auswählen Erweitern

2023.06.30 13:20:45.532 4: AutomowerConnect ShortyWest wsRead: select websocket data for $result->{id} 2d84075a-a676-4375-bfdd-5c7ab927c9cf, $hash->{helper}{mower_id} 2d84075a-a676-4375-bfdd-5c7ab927c9cf, battery 90
2023.06.30 13:20:45.618 4: AutomowerConnect ShortyWest wsRead: received websocket data: >{"id":"2d84075a-a676-4375-bfdd-5c7ab927c9cf","type":"status-event","attributes":{"battery":{"batteryPercent":90},"mower":{"mode":"MAIN_AREA","activity":"MOWING","state":"IN_OPERATION","errorCode":0,"errorCodeTimestamp":0},"planner":{"nextStartTimestamp":1688130000000,"override":{"action":"IPLANNER_OVERRIDE_ACTION_NOT_ACTIVE"},"restrictedReason":"NOT_APPLICABLE"},"metadata":{"connected":true,"statusTimestamp":1688124045433}}}<
2023.06.30 13:20:45.659 4: AutomowerConnect ShortyWest wsRead: received websocket data: >{"id":"2d84075a-a676-4375-bfdd-5c7ab927c9cf","type":"positions-event","attributes":{"positions":[{"latitude":47.3466962,"longitude":7.8706346}]}}<
2023.06.30 13:20:46.367 4: AutomowerConnect ShortyWest wsRead: received websocket data: ><
2023.06.30 13:21:10.580 4: AutomowerConnect ShortyWest wsRead: select websocket data for $result->{id} aa1d3c59-aba6-4b7e-8c9f-600b988a8f60, $hash->{helper}{mower_id} 2d84075a-a676-4375-bfdd-5c7ab927c9cf, battery 55
2023.06.30 13:21:10.713 4: AutomowerConnect ShortyWest wsRead: received websocket data: >{"id":"aa1d3c59-aba6-4b7e-8c9f-600b988a8f60","type":"status-event","attributes":{"battery":{"batteryPercent":55},"mower":{"mode":"MAIN_AREA","activity":"MOWING","state":"IN_OPERATION","errorCode":9,"errorCodeTimestamp":1680702307000},"planner":{"nextStartTimestamp":0,"override":{"action":"IPLANNER_OVERRIDE_ACTION_FORCE_MOW"},"restrictedReason":"NOT_APPLICABLE"},"metadata":{"connected":true,"statusTimestamp":1688124070478}}}<
2023.06.30 13:21:10.763 4: AutomowerConnect ShortyWest wsRead: received websocket data: >{"id":"aa1d3c59-aba6-4b7e-8c9f-600b988a8f60","type":"positions-event","attributes":{"positions":[{"latitude":47.3465912,"longitude":7.8706805}]}}<
2023.06.30 13:21:10.790 4: AutomowerConnect ShortyWest wsRead: select websocket data for $result->{id} aa1d3c59-aba6-4b7e-8c9f-600b988a8f60, $hash->{helper}{mower_id} 2d84075a-a676-4375-bfdd-5c7ab927c9cf, battery 55

Beide Mower waren zu dem Zeitpunkt aktiv. Die angegebenen Akkuwerte sind - bezogen auf $result->{id} - korrekt.
Nun müsste das Modul eigentlich "nur" noch nach '$result->{id}' filtern - dann müsste es passen.

Beste Grüsse,
Stefan

[Stefan H.]

Hallo Ellert, ich habe den Fehler gefunden:

Common.pm, Zeile 2530:

Code Auswählen Erweitern

if ( defined( $result->{type} && $result->{id} eq $hash->{helper}{mower_id} ) ) {Die gesamte Zeile ist hier der Input für die Funktion 'defined' - eigentlich sollte ja nur '$result->{type}' auf 'defined' geprüft werden.

Common.pm, Zeile 2530: Vorschlag (verschobene und zusätzliche Klammern):

Code Auswählen Erweitern

if ( defined( $result->{type} ) && ( $result->{id} eq $hash->{helper}{mower_id} ) ) {
=> Ein erster Test war erfolgreich; es wird jeweils nur noch das betroffene Mäher-Device aktualisiert.

Könntest du dies bitte so anpassen und einchecken? Vielen Dank!

Gruss,
Stefan

[Ellert]

Einen Filter gibt es schon, da stand leider eine Klammer an der falschen Stelle.

Es wäre hilfreich, wenn Du kurz probierst ob die Readings richtig geschrieben werden.

Die Datei im Anhang nach ...fhem/lib/FHEM/Devices/AMConnect/ kopieren.

Fhem neu starten.

Wenn alles o.k. ist, dann gibt es die Änderung morgen im Update.

[Ellert]

Ok. Du warst schneller.

[Stefan H.]

Hallo Ellert,

Vielen Dank. Ich habe deine Version von Common.pm eben auch noch getestet; funktioniert einwandfrei! 

Beste Grüsse
Stefan

[Ellert]

Eingecheckt und morgen im Update.

@Stefan H.: Danke für Deine aktive Mitarbeit.

[Stefan H.]

@Ellert Danke ebenso für die schnelle Behebung!

[Ellert]

Tipp:
Die per Getter verfügbaren Listen können in userReadings dauerhaft angezeigt werden, z.B. StatisticsData

Code Auswählen Erweitern

attr <device name> userReadings A_Stat:mower_wsEvent..status-event {fhem "get $name StatisticsData", 1}
Das funktioniert auch in DOIF uiTable, wenn $name durch den Gerätenamen ersetzt wird.