Funktionsbeschreibung
Man kann einen API-Aufruf in Szenen ausführen, aber nur, um Aktionen auf entfernten Diensten auszulösen.
Es wäre super mächtig, zusätzlich einen API-Aufruf machen und die Antwort als Variable verwenden zu können.
Konkrete Beispiele:
Um 6 Uhr einen Aufruf an die Wetter-API auslösen
Mir eine Nachricht mit den Tagesvorhersagen schicken
Oder, wenn ich das Haus verlasse, mich warnen, ob es an diesem Tag regnen wird.
Ich stelle mir die Möglichkeit vor, einen zurückgegebenen JSON-Wert abzurufen, entweder wie in JavaScript {{ reponseapi.data.meteo.pluie }} oder in grafischer Form, wie bereits mit den vorhandenen Geräten gemacht.
Ich denke, wir werden es in grafischer Form machen. Dann müssen wir beim Erstellen der Karte einen „Test“-Aufruf machen. Und dann die JSON-Antwort lesen und eine Liste aller verfügbaren Schlüssel erstellen und diese in die Liste der verfügbaren Variablen einfügen
Das ist super sauber und genau das, was ich mir vorgestellt habe, als ich dieses Thema geschrieben habe!
Ich wollte, dass Gladys mir Nachrichten mit Daten schickt, die von extern abgerufen wurden, wie z. B. das Wetter, wenn ich das Haus verlasse – das ist Spitze!!!
Was passiert, wenn:
es kein Internet gibt?
Die Antwort während der Ausführung anders ist als erwartet (z. B. „API-Grenze überschritten“)?
Gute Frage, ich habe den Fall nicht behandelt, aktuell wird es ein bisschen wild werden ^^
Ich denke, man sollte die Ausführung der Szene stoppen.
Es wird wild werden, deine Nachricht wird Löcher haben.
Dann weiß ich nicht, was die Lösung wäre: Überprüfen, ob das Schema dasselbe ist, und wenn es nicht dasselbe ist, die Szene stoppen? Das Problem ist, dass einige API-Antworten möglicherweise variable Antworten haben und das muss nicht unbedingt ein Grund sein, die Ausführung der Szene zu stoppen… Gute Frage!
Ganz im Gegenteil, ich denke, es ist nützlich, auch mit anderen Statuscodes weiterzumachen.
Beispiel:
Du möchtest überprüfen, ob deine Website/API mit Gladys online ist. Du erstellst eine Szene, die alle Minuten läuft und einen GET-Request an deine Website sendet. Du machst ein „Weiter nur, wenn Status != 200“ und sendest eine Nachricht „Die Website ist offline, Status = {{status}}“
Du möchtest ein Gerät steuern und eine Nachricht zurücksenden, wenn alles gut gelaufen ist
usw.
Ich denke, in vielen Fällen sollte die Szene auch mit „Fehler“-Codes weiterlaufen, gerade damit der Benutzer diese Information in der Szene verwenden kann.
Für den Fall „Internet ist offline“ scheint mir das ein besonderer Fall zu sein, und da kann man die Szene tatsächlich abbrechen.
Ansonsten könnte man in der Box einen Parameter „Szene stoppen, wenn der Rückgabecode anders ist als: „Liste der Codes auswählen“, aber das erscheint mir etwas umständlich, ich weiß nicht
Hallo @lmilcent!
Ich verstehe dein Beispiel nicht ganz, bei dem eine API verwendet wird, um das Wetter abzurufen, obwohl wir bereits einen Dienst dafür haben.
Warum nicht diesen Dienst für die Szenen verwenden, anstatt einen API-Aufruf zu machen? (Vorausgesetzt, wir haben die Aktion?)
Ansonsten ist es sauber, was du vorschlägst @pierre-gilles, aber man könnte dem Benutzer die Wahl lassen, die Szene basierend auf x oder y Gründen zu stoppen, aber das haben wir bereits mit „nur fortsetzen, wenn“ (oder?).
Falls die Antwort jedoch anders ist, warum nicht eine Option hinzufügen, um ihm zu sagen, dass er basierend auf der Benutzerauswahl stoppen soll?
Ja, daher meine Frage am Ende .
Für mich, um diesem Wetterbedarf gerecht zu werden, müssten wir einfach die fehlenden Bausteine im Zusammenhang mit dem Wetterdienst ergänzen, heute OpenWeather, aber auch morgen TotoMeteo
Genau wie die fehlenden Bausteine im Kalenderservice (der uns heute nicht viel nützt, außer dass er das Gleiche wie die nativen Apps tut [nur schlechter, weil wir derzeit nicht mit den Ereignissen interagieren können])
Ich bin mir bewusst, dass das Arbeit bedeutet, ich bin selbst Entwickler und habe nicht die Zeit (so viel Zeit wie bei der V3), um euch zu helfen ^^.
Ich äußere nur Ideen oder meine Gedanken zu bestimmten Bedürfnissen
Abgesehen davon beobachte ich aus dem Augenwinkel den Fortschritt von Gladys (nur zur Info, seit zibee2mqtt bin ich endlich auf die V4 umgestiegen, während meine V3 weiterhin läuft, um die Lücke auszugleichen, aber das ist ein anderes Thema )
Das ist super sauber und genau das, was ich mir vorgestellt habe, als ich dieses Thema geschrieben habe!
.