Feature description
Suite à notre discussion ici
Une scène doit pouvoir être déclenchée quand un message MQTT arrive sur un topic particulier.
Et ce serait utile dans d’autres cas je pense !
Faut que je libère un vote pour le faire ici 
1 « J'aime »
J’ai fait une petite proposition sur cette PR :
J’ai n’ai pas rajouter de nouveau declencheur. J’ai juste rajouter le fait que l’on peux lancer n’importe quel scene depuis un message mqtt.
Pour cela il faut publier un message « START » dans le channel : « gladys/scene/[sceneSelector] »
Qu’est ce que vous en pensez ?
4 « J'aime »
@Lokkye juste un mot : Génial ! 
Pour cela il faut publier un message « START » dans le channel : « gladys/scene/[sceneSelector] »
Faudra expliquer car là je vois pas le « comment » ?
Sinon c’est super pour l’ouverture des scènes depuis l’extérieur via mqtt ou node-red !
Bravo pour ces dev !!! 
Super cool @Lokkye !
Pour le format du topic, il faut garder le format qu’on a actuellement sur les autres topic MQTT, notamment le prefix « master » qui indique qu’on s’adresse à l’instance « maitre ». C’est pas encore le cas dans Gladys, mais l’idée de ce « master » c’était d’avoir à l’avenir de instances « pod » détachée qui puisse exécuter des service distants.
Du coup je verrais bien quelque chose comme:
gladys/master/scene/[sceneSelector]/start
Pas de body spécifique.
Tu en penses quoi ?
PS: J’ai fais aussi une petite review technique: Run scene when receive message on MQTT by callemand · Pull Request #1911 · GladysAssistant/Gladys · GitHub
2 « J'aime »
@pierre-gilles : Je ne connaissait pas l’existe du topic ‹ gladys/master/… ›.
Je viens de modifier mon code en concéquence. C’est beaucoup plus simple 
Merci pour la revu technique
1 « J'aime »
Effectivement c’est beaucoup plus simple 
Super PR, j’ai testé et ça marche chez moi !
C’est mergé et ça sera disponible dans la prochaine version de Gladys.
Par contre je ne suis pas sûr qu’on ferme cette demande de fonctionnalité car ce n’est pas exactement le besoin demandé (ça parlait de topic custom ici)
1 « J'aime »
Merci @pierre-gilles pour le merge
Je vais voir pour rajouter aussi le nouveau déclencheur dans une scène dans une autre PR
1 « J'aime »
@pierre-gilles :
Voila la PR qui répond a la fonctionnalité :
Dis moi ce que tu en penses
2 « J'aime »
@Lokkye Je t’ai fais une review ! Add scene trigger : MQTT message by callemand · Pull Request #1913 · GladysAssistant/Gladys · GitHub
J’aimerais un peu mieux comprendre la logique derrière ce développement pour comprendre les choix d’implémentation Si tu préfère expliquer ici en français plutôt que sur Github en anglais, comme tu préfère !
@pierre-gilles : Merci pour la relecture.
Donc pour le fait que je n’utilise pas le mot « mqtt », j’ai voulu me déconnecter complètement du service. Je fais beaucoup de clean architecture dans mon boulot et donc j’aime séparer les concepts. Je voulais aussi éviter de rajouter des mots technique dans Gladys. Mais il est vrai que en faisant cela je ne suis pas forcement plus clair.
Est ce que dans un future plus ou moins proche nous allons mettre d’autre message queue ?
Je comprend l’idée, après parfois d’un point de vue utilisateur, faire du « ultra-générique » ça embrouille juste à l’utilisation, et il vaut mieux au contraire faire du « ultra-spécifique » ce qui permet d’utiliser le bon vocabulaire.
Niveau UX
Dans le cas ici, l’utilisateur qui veut connecter un script MQTT externe va forcément chercher le mot « MQTT » en temps que déclencheur. Certes c’est technique, mais celui qui veut ça est technique.
Si MQTT n’est mentionné nul part, c’est impossible de savoir ce que ça veut dire
Même si dans le futur on a d’autres technos de queues, on pourra créer d’autres déclencheurs spécifiques à ces technos.
Si on prend l’exemple de Zapier ( https://zapier.com/ ), quand tu sélectionne un trigger, ils te proposent toutes les technos possibles directement pour que ce soit clair :
Je pense qu’on peut mentionner MQTT dans ce cas et parler de MQTT un peu partout dans le code sans soucis
Niveau implémentation
Je suis pas certain que l’implémentation fasse sens pour ce cas précis, notamment l’utilisation des eventEmitter pour cancel les trigger et set les triggers, car on a pas la garantie de l’exécution du code avant de passer à la suite.
Dans l’implémentation actuelle, rien ne met dit que le listener :
this.gladys.event.on(EVENTS.MESSAGE_QUEUE.UNSUBSCRIBE, this.handleGladysEventUnsubscribe.bind(this));
Va bien être exécuté avant:
this.gladys.event.on(EVENTS.MESSAGE_QUEUE.SUBSCRIBE, this.handleGladysEventSubscribe.bind(this));
Donc potentiellement, si j’édite ma scène, mon listener est ajouté une deuxième fois puis supprimé et donc on est dans un état « batard »
Pas sûr qu’on ait le choix, je pense qu’il faut appeler this.service.mqtt dans scene. D’ailleurs, en général quand on vient de Gladys vers les services, c’est ce qu’on fait dans le reste du code (par exemple dans l’intégration Telegram c’est ce qu’on fait)
Tu en pense quoi ?
Ok, je comprend mieux.
Oui, après réflexion tu as complétement raison
Je ne pensais pas que le « core » pouvais être lié directement avec les services. Donc il faut aussi gérer le fait que le service ne soit pas activé
Je m’occupe de faire cela
1 « J'aime »
Si on le fait dans l’intégration Telegram par exemple
Yes, et même je dirais que dans l’idéal il faut que dans l’UI du trigger ça soit aussi reflété si jamais le service MQTT nest pas configuré
Top ! Je regarde ça aujourd’hui
Super cool @Lokkye, ça marche nickel chez moi comme ça
Je t’ai fais quelques retours mais rien de grave
1 « J'aime »
@pierre-gilles : Je viens de faire les modifications de tes retours.
N’hésite pas à me dire si j’ai loupé quelque chose.
1 « J'aime »
Merci pour les correctifs, c’est bon pour moi et ça partira dans la prochaine version de Gladys ! 
3 « J'aime »
Cette fonctionnalité est disponible dans Gladys Assistant 4.31 ! 
Je ferme ce sujet pour libérer les votes, n’hésitez pas à créer un autre sujet en cas de bugs sur cette fonctionnalité
3 « J'aime »