Cette demande concerne cette discussion
et me parait pas tout à fait similaire à celle-ci car ici c’est dans les scénes, d’où cette demande
Donc l’idée serait d’avoir la possibilité de créer un appareil dans l’intégration MQTT qui réagirait à un suscribe mqtt propre pour le transformer et l’utiliser dans gladys et permettre depuis Gladys de publier vers lui sans devoir passer par Node-red
donc passer d’un appareil « texte »
Voila j’espère avoir été clair ! A vos votes 
Je ne sais pas si cette demande est très clair et si elle a du sens…
Je réponds ici cela me semble plus approprié
Bonjour @pierre-gilles,
Je ne mélanges pas tout, du moins je l’espère 
…Mais comme disais Lao-Tseu « Si tu donnes un poisson à un homme, il mangera un jour. Si tu lui apprends à pêcher, il mangera toujours. » 
L’idée c’est via la demande de cette fonctionnalité de permettre d’utiliser n’importe quel appareil qui ne serait pas encore intégré sans devoir passer par Node-Red (maintenant si c’est ardu à faire ou pas dans les objectifs court terme je comprend que cela soit pas fait, il y a pas d’équivoque la dessus).
Voila j’espère avoir été plus clair et avoir donné du sens à cette demande… 
Tu confond l’intégration MQTT et l’intégration Zigbee2mqtt
Ces deux intégrations ne sont pas connectés entre elle, toi tu voudrais que l’utilisateur puisse envoyer des commandes manuelles au serveur Zigbee2mqtt.
Je ne pense pas que ce soit dans la philosophie du projet, pourquoi ne pas juste ajouter la sirène manquante (ce qui est un petit travail) ?
Alors à moins que j’ai déjà versé dans la sénilité et soit candidat à un EPHAD mais quand je relis
Je comprends bien que d’un coté on a des appareils (detecteurs prise etc) qui communiquent selon un protocole radio, le Zigbee, qui est hardware vers une passerelle dédiée au revendeur ou à une clé générique (Conbee, Deconz, Sonoff) qui permet de passer outre les passerelles vers un protocole TCP qui est le MQTT (à l’instar d’une carte réseau sur un PC).
J’ai bien compris que ce protocole MQTT transmet des trames TCP vers un broker (serveur http dédié) MQTT et de façon bi-directionnelle.
Que ce broker fonctionne à la manière
-je recois tel message MQTT (topic) avec un contenu (payload) je renvoie au personne qui se sont abonné à ce message(topic) dans la liste des abonnement que je possède la valeur du message (payload).
Dans le cas de l’alarme en regardant la doc je vois
Il faut donc bien envoyer (publish) au topic
zigbee2mqtt/FRIENDLY_NAME/set
le message
{"warning": {"duration": 10, "mode": "emergency", "strobe": false}}
Non ?
Non, je voudrais que l’utilisateur puisse envoyer des commandes manuelles au serveur MQTT
J’ai parfois l’impression de t’irriter @pierre-gilles 
Actuellement le broker MQTT de l’intégration MQTT n’est pas connecté au broker MQTT de zigbee2mqtt.
Ce sont 2 intégrations complètement différentes sans aucun lien
Je confirme tu ne comprend pas …
Il y a l’intégration mqtt qui a son broker pour communiqué avec node red ou alors avec gladys lui meme avec ces virtual device.
Et tu as l’intégration zigbee2mqtt qui se sert dun autre broker pour communiqué avec celui du projet zigbee…
Si tu ne crois tjrs pas regarde ton instance en faisant un docker ps et regarde le code…
Meme si tu nas jamais fais de node, cest lisibles…
Chaques intégration sur glagla est découper de façon a ce que si une intégration casse le reste fonctionne, d’où la multiplication de broker mqtt
Pour résumé oui il y a 2 broker mqtt.
1 dédié a zigbee2mqtt et un autre pour l’intégration mqtt.
Effectivement, je pensais que le paramétrage dans zigbee2mqtt pointais vers le serveur mqtt installé par gladys et en fait il pointe sur le serveur mqtt que le container héberge lui-même
C’est en regardant les ports ouvert que j’ai compris qu’il y avait le port 1883 pour le broker Mqtt du docker Mqtt
J’avais pas saisi la nécessité du doublon de broker mqtt, puis j’ai compris en regardant les différents codes des intégrations dans le github que le broker Mqtt du docker zigbe2Mqtt ne sert qu’à faire la transposition entre la syntaxe propre à Gladys et celle issue de zigbee2mqtt dans le container zigbee2mqtt.
Donc grosso modo en fait quand un appareil est intégré dans l’intégration zigbee2Mqtt de gladys il y a une correspondance de faite entre (pour reprendre l’exemple de l’alarme) la syntaxe gladys
gladys/master/device/mqtt:Heiman/feature/mqtt:Heiman/text
et la syntaxe zigbee2mqtt
l’envoi (publish) vers le broker zigbe2mqtt avec comme topic
zigbee2mqtt/FRIENDLY_NAME/set
et payload
{"warning": {"duration": 10, "mode": "emergency", "strobe": false}}
du moins quand l’appareil a été intégré, c’est bien cela ?
Pour reprendre la phrase de @spenceur
L’intégration Mqtt sert en quelque sorte d’API ou de moyen de communication entre gladys et node-red, j’ai bon ?
Quels que soient les appareils créés dans les différentes intégrations (hue xiaomi zigbee2mqtt, mqtt, etc) ils deviennent et sont traités comme des devices virtuels à l’intérieur de Gladys, la couche intégration servant d’interface (comme une API) entre gladys et les protocoles externes, c’est cela ou je me plante encore ?
Je m’excuse de faire mon relou mais comprendre comment la tambouille interne fonctionne ca aide aussi à saisir le fonctionnement externe et savoir ce qu’il est possible de demander ou d’avoir comme fonctionnalité ou même tenter d’aider au code ! Cela peut paraitre simple pour ceux qui ont compris le fonctionnement interne de gladys , pour les autres c’est pas facile à appréhender…Savoir comment gladys fonctionnes peut aussi attirer des personnes compétentes en développement à rejoindre l’équipe actuelle.
J’ai regardé le code dans github et je dois dire qu’il est pas très explicite ou pas assez documenté, c’est mon avis et il n’engage que moi…
Ne le prend pas mal, mais parfois tu interviens sur des sujets où un débutant pose une question simple où la réponse est toute simple, en répondant avec une réponse très compliquée et fausse 
Dans Gladys 4 j’ai vraiment eu cette volonté de simplification et de construction d’un produit grand public et sans jargon de développeur. Parfois dans tes interventions tu emmènes de nouveaux utilisateurs dans le sens inverse ce qui du coup effectivement peut m’irriter un petit peu (mais j’essaie de rester courtois ).
Je le prends pas mal, quand j’interviens pour répondre c’est aussi avec ce que je pense avoir compris (coté container mqtt zigbee2mqtt je m’étais planté j’en conviens) et dans la solution que je propose je peux me tromper (le forum est fait pour cela, pour progresser non ?), dans le cas présent proposer de passer par node-red me semble adéquat (mais ton approche de dire il faudrait mieux le développer est la bonne) mais en attendant il fait comment @Isage ? Moi avec mon IPX800V5 j’ai galéré pour l’interfacer avec gladys via le mqtt, j’ai trouvé et fait un mini-tuto pour cela en attendant qu’un jour cette intégration soit faite si elle l’est (elle existe sous HA et Jeedom) , en faisant ce mini-tuto que j’ai publié aussi sur le forum de l’IPX800, c’est pour faire découvrir gladys et montrer que même si le matériel n’est pas supporté par gladys on peut contourner en passant par node-red de même que pour cette alarme.
Je sais que le forum peut être chronophage parfois pour toi mais il est aussi source d’inspiration
Ma presque soixantaine 
t’en sais gré (mais je m’interroges sur le courtois, c’est pour le terme « iiriter » ou pour moi ? Non je plaisante mais comme quoi entre ce qu’on exprime et ce qui est interprété il y a matière à disserter et à digresser ! )
Je ferme cette demande en faveur de :