Feature description
On peut faire un appel API dans les scènes, mais seulement pour déclencher des actions sur des services distant.
Ça serait super puissant de pouvoir en plus faire un appel API et utiliser la réponse en tant que variable.
Exemple concret :
a 6h, déclencher un appel à l’API météo
m’envoyer un message avec les prévisions de la journée
Ou si je sors de chez moi, m’avertir s’il va pleuvoir dans la journée.
J’imagine la possibilité de récupérer une valeur renvoyée en JSON, soit comme en JavaScript {{ reponseapi.data.meteo.pluie }} soit sous forme graphique comme déjà fait avec les devices existants.
Je pense qu’on le fera sous forme graphique. Il faudra du coup faire un appel « test » lors de la création de la carte. Et ensuite lire le json response et faire une liste de toutes les clés disponibles, et les populate dans la liste des variables dispo
c’est super propre et exactement ce que j’avais imaginé en écrivant ce sujet !
Je voulais que Gladys puisse m’envoyer des messages avec des données récupérées depuis l’externe, comme la météo quand je pars de chez moi, c’est top !!!
Que ce passe-t-il si :
il n’y a pas internet ?
La réponse est différente qu’attendue pendant l’exécution (du genre “seuil API dépassé”) ?
Bonne question, j’ai pas géré le cas, actuellement ça va faire un peu n’importe quoi ^^
Je pense qu’il faudrait arrêter l’exécution de la scène.
ça va faire n’importe quoi, ton message aura des trous.
Après je sais pas quelle serait la solution: valider que le schéma est le même, et si il n’est pas le même, arrêter la scène ? Le souci, c’est que certaines réponse d’API ont peut-être des réponses variables et ça doit pas forcément être une raison d’arrêter l’exécution de la scène… Bonne question!
Justement non, je pense que c’est utile de continuer même avec d’autres status code.
Exemple:
Tu veux vérifier que ton site/api est up avec Gladys. Tu fais une scène qui run toutes les minutes et qui fait un GET sur ton site. Tu fais un « continuer seulement si status != 200 » et tu envoie un message « le site est down, status = {{status}} »
Tu veux contrôler un périphérique et renvoyer un message si tout s’est bien passé
etc…
Je pense que dans pas mal de cas, la scène doit continuer même avec des code « d’erreur », justement pour que l’utilisateur puisse utiliser cette information dans la scène.
Pour le « internet est down », ça me semble être un cas particulier, et là effectivement on peut couper la scène.
Sinon, on pourrait dans la box mettre un paramètre "stopper la scène si le code de retour est différent de: « choisir liste de code », mais bon ça me parait un peu lourd, je sais pas
Hello @lmilcent !
Je ne comprend pas trop ton exemple d’utilisé une api pour récup la météo alors qu’on a déjà un service qui le fait.
Autant utilisé ce service pour les scènes plutôt que de faire un appel API ? (encore faut il qu’on est l’action ?)
Autrement, c’est propre ce que tu proposes @pierre-gilles, mais effectivement on pourrait laisser le choix au user de stopper la scène en fonction de x ou y raison mais ça on l’a déjà avec le continuer seulement si (non ?).
Après dans le cas ou la response est différente pourquoi pas ajouté une option pour lui dire de stopper en fonction du choix utilisateur non ?
Yes d’ou mon interrogation à la fin .
Pour moi, pour répondre a ce besoin de météo, il faudrait juste dev les briques manquantes lié aux service de météorologie, aujourd’hui OpenWeather mais aussi demain TotoMeteo
Tout comme les briques manquante au service agenda (a l’heure d’aujourd’hui ne nous sert pas a grand chose a par faire la même chose que les application native [en moins bien pour le moment car nous ne pouvons pas interargir avec les évènements])
Je suis conscient que cela représente du taff, je suis moi même dev et je n’ai pas le temps (autant de temps que sur la V3) pour vous aider ^^.
Je ne fais qu’émettre des idées, ou mes réflexions concernant certain besoin
En dehors de ça je regarde du coin de l’oeil l’avancé de Gladys (pour info depuis zibee2mqtt je suis enfin passé sur la V4 avec ma V3 qui tourne tjrs pour compensé le gap, mais c’est un autre sujet )
c’est super propre et exactement ce que j’avais imaginé en écrivant ce sujet !
.