Comme dit dans un autre post ici, je trouve qu’il n’y a pas assez de logs, notamment dans les scènes.
J’utilise Rundeck pour lancer pas mal de jobs de domotique…je voudrais donc faire mes scènes dans Rundeck (et ça ne me dérange pas).
l 'accès à l’API, c’est pour vérifier les états des devices, surtout en lecture(get, donc) avant ou après manipulations dans Gladys.
Mais on dirait que je n’ai pas compris, dans la documentation, la différence dans les api, et la manière de s’en servir. Je vais refaire une passe de lecture
Pour les scènes, c’est quelque chose que j’aimerais ajouter à Gladys: la possibilité de suivre l’exécution des scènes dans l’UI de façon simple et clair.
On en avait parlé récemment ici si ça t’intéresse :
Ok je comprend mieux.
En fait Gladys et Gladys Plus c’est 2 choses différents :
Gladys c’est un programme local qui tourne sur ta machine (Raspberry Pi, serveur, NAS) à la maison.
Ce programme a une API REST qui est utilisée par le frontend local et cette API est décrite ici => https://apidoc.gladysassistant.com (le lien que tu as posté plus haut)
Gladys Plus c’est un proxy cloud qui donne accès à l’instance local d’un utilisateur de n’importe où dans le monde. Ce proxy a une API Websockets chiffrées de bout en bout qui permet quand tu accède au front plus.gladysassistant.com de voir la même chose que ce que vois ton instance locale. L’API Websockets est pour usage du front uniquement et n’a pas vocation a être utilisé par l’utilisateur. Ce proxy a aussi une « Open API », celle-ci qui n’est pas chiffrée de bout en bout de par sa nature (chiffrée en transit en revanche via SSL), qui permet d’envoyer des états de capteurs et positions de ton téléphone à ton instance locale. De par la nature de cette API (pas chiffrée de bout en bout), je n’ai pas pour l’instant mis de route en lecture, uniquement quelques routes en écriture. Après je peux ajouter des routes en lecture mais je veux que ce soit clair avec la communauté que si on ajoute des routes en lectures (optionnelles), le proxy Gladys Plus voit donc le traffic passer (ce qui n’était pas le cas actuellement).
Savoir si on est dans une scène, où l’on est dans une scène, date et heure des dernières exécutions (certaines peuvent être instantanées), graphiquement, visuellement, ce serait bien
Je pense que pour développer ceci, il faut d’abord commencer par des logs/journaux…et ensuite faire la partie graphique, mais je comprends que la cible soit la facilité d’utilisation…La majorité ici « bidouillent » un peu, pas trop de Madame Michu, même si c’est la cible.
Ensuite, nous confions à Gladys notre électricité ou notre eau(si je mets en route une pompe d’arrosage, par exemple), et derrière, ce sont des sous qui sont en jeu…il faut donc pourvoir tracer ce qui se passe
Concernant l utilisation des API, effectivement, je vais me rapprocher de l api interne, mais je ne vois pas dans la doc la manière de procéder, comment on attaque l api interne ?
non, parce que je ne sais pas comment faire… parce que sauf erreur de ma part,la page decrit tres bien le infos/actions que l on peut faire avec l api, par contre comment comment on l’utilise, il n’y a rien…
Effectivement! En fait cette doc est un peu à usage interne lors du développement, le but c’est de voir quelles routes sont disponible pour le front.
Après, toi pour ton usage je sais vraiment pas si c’est adapté. Rundeck c’est quoi ? C’est un programme que tu fais tourner en local sur la même machine que Gladys ?
rundeck est un ordonnanceur. Je m’en sers pour créer des scènes, parce que je l’ai déjà dit ici, pas assez de logs. Je fais tourner des jobs de domotique et d’exploitation, sur mes raspberry. Il est installé sur un raspberry différent de Gladys
Si oui, dans ce cas c’est bon tu peux utiliser cette API locale
Pour utiliser cette API, tu peux d’abord utiliser la route de login pour récupérer un access token (POST /login. La doc: Gladys Assistant REST API documentation ), en tapant sur l’IP de ton Pi local