In der V3 war es möglich, Applikationstoken zu generieren, um den Zugriff auf die REST-API zu erleichtern, indem &token=xxxxx zum Aufruf hinzugefügt wurde.
Dies würde die Erstellung von Skripten für Automate oder Tasker erleichtern.
Guter Punkt, das ist ein Feature, das ich im Kopf habe! Aber gute Idee, es hier zu erwähnen, das gibt mir eine Vorstellung von der Nachfrage für die offene API 
Ich füge das zugehörige GitHub-Issue zur Nachverfolgung hinzu
Ich habe gesehen, dass du den Titel umbenannt hast, wirst du dich dem bald widmen? 
Das war vor allem, um dem Issue einen klareren Titel zu geben
Einfach mal so gefragt, was interessiert dich an dieser Funktion? Welche API-Routen interessieren dich am meisten?
Gib mir deine Anwendungsfälle
Es gibt zwei Anwendungsfälle:
Der erste ist die Vereinfachung der Erstellung von Skripten für Automatisierung/Tasker.
Ich lege mein Telefon auf den Nachttisch, und es startet automatisch ein Automate- oder Gladys-Szenario → Ladegerät einschalten, bestimmte Geräte ausschalten usw…
Daher wäre es ideal, den Token im Header oder am Ende der URL hinzuzufügen
Der zweite Anwendungsfall ist, dass ich nicht jedes Mal ein Authentifizierungstoken abrufen muss, wenn es in einer Android-App, die ich gerade entwerfe, abläuft. In diesem Fall dient es nur dazu, die Entwicklung zunächst zu erleichtern. In jedem Fall werde ich die Abrufung der Zugriffstoken über die Anmeldedaten implementieren.
Was die API-Routen betrifft, ginge es darum, auf den Ein-/Ausschalter der Geräte zuzugreifen und die Farbe/Helligkeit von Lampen einzustellen, die Liste der Objekte nach Räumen, wenn möglich sortierbar nach einer ihrer Eigenschaften: Lampe, Marke, vielleicht ein- oder ausgeschaltet.
Falls das, was in der Dokumentation steht, immer noch gültig ist, ist das bereits teilweise möglich.
Ich habe vor, die gesamte REST-API von Gladys in eine Kotlin-Bibliothek (und vielleicht später in Flutter) zu übertragen, um die Erstellung von Android-Apps für diejenigen zu erleichtern, die daran interessiert sind. (Und auch, weil ich sie für meine Entwicklungen benötige )
Ok, ich verstehe also:
1/ Eine Szene von Tasker aus starten
2/ Den Zustand eines Geräts von Tasker aus ändern.
Für den Punkt 2) kannst du das bereits über MQTT machen (Tasker unterstützt MQTT, glaube ich)
Außerdem kannst du in der Zwischenzeit MQTT nutzen, um den Punkt 1) zu erledigen. Du erstellst ein virtuelles MQTT-Gerät, mit dem du eine Szene starten kannst (über einen Trigger „Gerätezustandsänderung“)
Du entwirfst eine Android-App? Nur eine Frage: Reicht dir die PWA Gladys Assistant nicht?
Persönlich habe ich Gladys zu meinem Home-Bildschirm hinzugefügt und es ist wie eine native App, ich könnte den Unterschied nicht sagen.
Tutorial:
(Ich habe « Gladys Plus » in den Titel geschrieben, aber im Prinzip funktioniert es auch mit Gladys Assistant)
Das Gleiche gilt für PWA, es läuft.
Der Fall Tasker + mqtt ist nicht für externe Netzwerke gültig (Gladys +).
Für diejenigen, die diesem Gespräch folgen, wissen Sie, dass es eine offene REST-API in Gladys Plus gibt, die von überall auf der Welt zugänglich ist!
Kleines Beispiel für einen API-Aufruf, um einen neuen Temperatur-Sensorwert remote zu pushen:
(Der API-Key wurde ausgeblendet)
Ich habe diese API kürzlich in einem Live-YouTube-Video (bei 39 Minuten) vorgestellt:
Und es gibt ein Tutorial in der Dokumentation:
https://gladysassistant.com/de/docs/plus/open-api
Zögern Sie nicht, es zu testen, es gibt eine kostenlose 14-Tage-Testversion: https://gladysassistant.com/de/plus/