ElabNET Technik Forum

N'Abend zusammen,

ich weiß - Leichfledderei, aber dies war der aktuelleste Faden zu Oauth und Gardena/Husquarna-API und ich dachte mir ich weise mal darauf hin, dass es jetzt mit dem TWS v4.5 IP5 (evtl. auch schon früher) funktioniert!

Ganz kurzer Ablauf:
1.) Server für Authentifizierung einfügen. KEINE Authentifizierung. Post-Methode, Body mit Application Key und Application Secret zusammenbauen. Ergebnis ist json mit dem Bearer-Token. Die Keys/Secrets kann man über eine (statische) Logik eingeben oder per Visu (Info & Schalten > Detailseite > Werte eingeben). Auslösung am Besten nach Trigger, damit regelmäßig ein gültiger Token vorliegt.
2.) den Bearer-Token muss man noch einmal durch ein Logik jagen, um ein "Bearer " davorzuhängen.
3.) Server für Kommunikation mit den Smart-Geräten anlegen. KEINE Authentifizierung. Get/Put-Methode. Header mit Bearer-Token und API-Key zusammenbauen. Ergebnis ist json.

VG
Stefan

Mod-Edit: Hier abgetrennt.

Hi Stefan
@AndererStefan
Danke das du es wieder aufgreifst.
Habe mich gerade mal ein wenig damit beschäftigt, scheitere aber leider an der Abfrage des Bearer Socken, per Terminal kann ich mit meinen Daten den Bearer abrufen, mit dem TWS habe ich es noch nicht geschafft.

wie genau muss den die API Abfrage im TWS aussehen ?
wie erstelle ich nun aber den Body, so das er richtig übertragen wird ?

Hi Andreas,

um den Header zusammenzubauen brauchst du für jedes Element des Headers (client_id, grant_type, client_secret) ein HTTP Application Objekt.

Für den Parameter Client ID sieht das z.B. so aus:


Die Client ID, das Secret und der Authentifizierungstyp sind quasi statische Werte und gelten solange wie die Application im Husquarna-Portal eingerichtet ist unverändert. Es wäre nun am schönsten, man könnte die hier direkt fest eintragen - geht aber nicht. Ich habe in meinem Beispiel die Werte zum Testen über die Visu gesetzt, aber ich stelle das im nächsten Schritt auf einen primitiven Custom-Logic-Block um der einfach aus 3 Textstrings im Input (als Parameter) -> 3*Output macht.

Das Bearer-Token holt man sich dann mit dem Selektor "access_token" aus der Antwort. Den muss man dann noch einmal durch eine Logik schicken, da dem reinen Token noch ein "Bearer " vorangestellt werden muss.


Es scheint übrigens so, dass die Anfrage die Gültigkeitsdauer des Bearer-Tokens zurücksetzt und nicht zwangsweise ein neues generiert. Ob der Trigger nach Zeit das sinnvollste ist, oder man lieber bei jeder Anfrage einmal die Tokengenerierung mittriggert muss ich noch überlegen/probieren.

VG
Stefan

EDIT: Eigentlich wäre es besser einen neuen Thread zu machen, wenn wir hier weiter in die Details einsteigen.

Hi Stefan

@AndererStefan

Ja das könnte jemand mit Berechtigung mal in einen neuen Thread machen.

Den Bearer Key erhalte ich nun, Danke für die Infos.
mit einer Logik schreibe ich nun auch "Bearer " davor, wie geht es nun weiter ?

SchateMuhl hat geschrieben: ↑So Mai 25, 2025 3:18 pm Ja das könnte jemand mit Berechtigung mal in einen neuen Thread machen.

Done!

Danke dir, Parsley

Hi Stefan, folgende Daten sende ich ab und bekomme aber einen Fehler, siehe Bild

wenn ich die Daten im Husqvarna Portal so eingebe, bekomme ich die Daten.

Ich glaube ich hab das Problem gefunden, ich nehme die Logik "KONKATENIERE multiple String-Opberanden" um das Wort Bearer vor den Key zu schreiben, bei dieser Logik darf ein Eingang aber nur 64 byte haben, demzufolge wurde er immer abgeschnitten.
Ich versuche es mal mit einer Custom Logik.

Wenn ich alle Optionen in den Optionalen Header schreibe, bekomme ich alle Daten zurück.

Danke Parsley

Nun, wenn man die Authentifizierung geschafft hat, hat man einen Bearer-Token. Der muss als Textstring mit dem Inhalt "Bearer xncdisdij032..." vorliegen. (Hinweis: Beim Konkatenieren darauf achten, dass die Logik 2048 Byte-Strings verarbeiten kann.)

Vorbereitungen
Um die Kommunikation mit den Geräten einzurichten muss man deren sog. Service ID herausfinden. Für diese Schritte empfehle ich das Interface
bei Gardena zu benutzen: https://developer.husqvarnagroup.cloud/ ... b=api%20v2.

• Zuerst gilt es die Location-ID zu ermitteln. Dazu führt man den GET /locations Befehl aus.
• Diese Location-ID gibt man dann darunter in GET /locations/{locationId} ein und erhält eine vollständige Auflistung, aller Geräte, Fähigkeiten und Messwerte. Dies ist auch der spätere Weg mit dem TWS die Daten aus der API abzufragen.

Wichtig: Es gibt Rate-Limits für die Abfrage. Es sind max. 700 Abfragen pro Woche möglich, d.h. ca. alle 15 Minuten. Es ist eigentlich gedacht, dass man websockets benutzt.

Aus der Gesamtliste der Daten muss man die ServiceIDs der Geräte herausfinden. Am einfachsten geht das an der Stelle, wo die Gerätenamen aus der App im Klartext stehen.

API Konfigurieren
Nun muss man einen weiteren HTTP-API Server hinzufügen (die URL für die API und die Kommunikation sind unterschiedlich):



Danach werden die Ressourcen hinzugefügt. Das Abfragen (GET) ist bei der Auswertung etwas komplizierter - da bin ich noch nicht fertig, daher nehm ich für mein Beispiel das Senden eines Befehls (PUT) um ein Ventil zu öffnen.

Die Serivce-ID wird dabei in der URL übermittelt. Man erstellt eine Ressource mit PUT und legt in der URL einen Platzhalter für die serviceid an. (Man könnte die auch "hart" eintragen, aber ich finde es so sauberer)



Als nächstes erstellt man das HTTP-Objekt welches die serviceid überträgt.



Dann legt man die HTTP-Objekte mit den Informationen für die Authentifierung an. Die ClientID und das Bearer Token müssen in den Header.:





Nun geht es an das Zusammenbauen des eigentlichen Befehls. Dieser wird im Body übertragen und ist ein verschachteltes json.
In der Doku sieht man wie der fertige Befehl aussehen muss. Die id hier ist ein Text-String der nur für Logging benutzt wird. Sucht euch was aus (z.B. request-tws). Die anderen drei Parameter sind selbsterklärend. Für diese 4 Parameter werden nun 4 weitere HTTP-Objekte angelegt.


Die Selektoren lauten wie folgt:

• data.id
• data.type
• data.attributes.command
• data.attributes.seconds

Einen davon setzt man als Trigger, sodass alle Daten übertragen werden. Nun nur noch die Objekte auf der rechten Seite verknüpfen:
Über das Error-Flag darf man sich nicht wundern! Der Server gibt "202" zurück was "Success, smart Gateway received command and will forward it to device." bedeuetet. 202 wertet der TWS aber als Fehlercode (derzeit).



Zum Übergeben der Inhalte habe mir eine Custom Logik angelegt, wo ich die Strings einfach als Parmeter eintippen kann. Dann noch einen Trigger dazugeklickt und mit einer Schaltfläche in der Visu verbunden.


Das Grundgerüst für die Logik hat mir Gemini produziert (auf Basis des Referenzdokuments von @eib-eg -danke!) Eine entsprechende Logik habe ich mir auch noch für die API-Zugangsdaten gemacht. Das ist nicht unbedingt optimal, weil ich nicht weiß wie gut die auf dem TWS geschützt sind. Aber anders geht es bei Oauth derzeit leider nicht.

Damit kann ich nun über den TWS das Bewässerungsventil im Garten öffnen. Eine Rückmeldung über den Ventilstatus gibt es nicht unmittelbar. - Das ist bei HTTP-API der Technik geschuldet. Man könnte die Status-Codes der Server-Rückmeldung aber eine Abfrage des Ventil-Status koppeln. An der Anfrage bastel ich aber noch. Wie oben geschrieben stehen alle Daten in einem großen json. Das zu filtern ist nicht ganz einfach.

Ich hoffe die Anleitung hilft dir weiter!
VG Stefan

Frage @AndererStefan
Welche meiner Versionen hast Du benützt ?
Denn aktuell bin ich bei Version 4.10.4

eib-eg hat geschrieben: ↑So Mai 25, 2025 8:03 pm Frage @AndererStefan
Welche meiner Versionen hast Du benützt ?
Denn aktuell bin ich bei Version 4.10.4

Ich nutze noch immer die v4.6.2 (hast du die neuen bereitgestellt?).
Für diesen trivialen Fall dürfte das aber keine Rolle spielen, ging wirklich fix im ersten Anlauf.

VG
Stefan