MQTT - Recevoir une valeur sur un topic personnalisé

Bonjour à tous,

Suite à mon précédent post (Ores - Compteur électrique intelligent - #10 par pierre-gilles), je me suis rendu compte qu’il était nécessaire de passer par Node-RED pour transformer une information reçue par un capteur MQTT vers Gladys.

Pour faire simple, mon capteur envoie avec un topic (ex: « dsmr/reading/phase_currently_delivered_l3 ») et Gladys ne me permet que d’écouter sur un topic généré automatiquement et non modifiable (ex: « gladys/master/device/mqtt:consommation_instantanee/feature/mqtt:consommation_instantanee/state »)

Conclusion, pour faire quelque chose de ‹ simple ›, je dois passer par Node-RED pour transférer l’information d’un topic vers un autre.

Serait-il donc possible de créer un mapper pour combler ce manque ? Ou de rentre éditable le topic créé par Gladys ? :slight_smile:

Merci d’avance

Merci pour la demande, j’ai édité le titre pour que ce soit plus clair.

Pour moi 2 possibilités avec leur pour et leur contre :

  • Faire ça via les scènes, via un déclencheur « Quand un message MQTT est reçu », qui prend en paramètre un topic MQTT, et un exemple de message reçu. Ensuite, dans la scène, une variable est injectée qui est utilisable partout (envoyer un message Telegram, définir l’état d’un capteur, etc…). L’avantage c’est que c’est customisable à l’infini, l’inconvénient c’est qu’il faut faire une scène par capteur, ça peut-être lourd.
  • Faire ça dans l’intégration MQTT directement, via un topic « personnalisé » qui sera customisable. L’avantage c’est que c’est simple d’utilisation, l’inconvénient c’est que ce n’est pas customisable du tout (si le message MQTT a un format spécifique, on fait comment?)
1 « J'aime »

Il est vrai comme je l’avais déjà souligné que c’est une contrainte face à des publish ou suscribe figés ou limités sur certains équipements, reste à savoir si la possibilité d’affecter le fonctionnement d’un objet (commutateur, ampoule on/off etc) à un suscribe ou un publish personnalisable est réalisable dans Gladys plutôt que la syntaxe un peu lourde actuelle (le « mqtt: » est inutile dans le nom des suscribe ou publish) ?? Ce serait un plus car actuellement c’est une limitation pas logique avec le fonctionnement mqtt

2 « J'aime »

Partiellement dev par @Lokkye non?

pour la partie scène oui

pour la partie intégration mqtt c’est a dev éventuellement

j’avais proposé cela pour combler ce manque qui rejoint l’idée de mapping entre le mqtt externe vers le mqtt interne propre à gladys, en gros l’idée c’était Gladys s’abonne au mqtt externe et quand il reçoit ce mqtt externe il simule à l’intérieur une réception du mqtt gladys et pareil coté publish il y a juste le problème d’ajouter à la db ce mapping