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 Like

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 Likes

Partiellement dev par @Lokkye non?

Pour faire suite à cette discussion je trouve également que donner la possibilité de paramétrer le topic d’écoute serait intéressante

J’ai commencé le développement sur ce sujet :slight_smile:

Suite à notre discussion avec @Alyafride, je suis parti sur une interface ressemblant à ça :

Rien de définitif, je viens de commencer il y a 2 minutes :stuck_out_tongue:

Je vous tiens au courant dès que j’ai une image de test à vous proposer !

4 Likes

Top, je pense que cet ajout peux aider à intégrer facilement différents capteurs.

En terme d’UI j’aurais imaginé un switch au niveau de l’appareil pour définir si le payload est de type json ou « sous-topic » et éventuellement de définir le topic parent. Ensuite au niveau de la fonctionnalité définir le chemin json ou le sous-topic (pas certains que la combinaison des deux en simultanée soit nécessaire)

Premier test concluant !

Je créé un appareil qui écoute sur ce topic avec un body JSON :

J’envoie ce body JSON :

Disponible dans l’UI :

Il reste encore du boulot, parce qu’actuellement l’intégration MQTT ne gère pas l’écoute multiple d’un même topic, ce qui empêcherait d’utiliser un même topic sur plusieurs fonctionnalités, ce qui est gênant dans le cas de cette fonctionnalité

Je sais pas trop, ça risque de rallonger chaque feature en longueur (et c’est déjà long)

Ah ? Dans mon esprit ça complexifie un peut la création de l’appareil mais ça simplifie celle de la fonctionnalité

Ah j’avais pas compris que tu parlais au niveau du device !

Je sais pas, autant que ce soit le plus simple possible, rien à activer, juste à remplir si l’utilisateur veut s’en servir

Je vois des avantages/inconvénients au deux choix en fait :thinking:

D’un coté comme le topic des équipements en MQTT comporte souvent un id unique (le serial de l’équipement ou son adresse MAC) ça me paraissait plus simple de le définir qu’une fois au niveau de l’appareil mais ça impact plus lourdement l’interface.
De l’autre ça offre plus de souplesse de spécifier le topic complet à chaque fois et ça impact moins l’interface. En revanche ça implique un champ « chemin json » qui peut troubler si les métriques sont émise « à plat ».

Pour moi ça doit être au niveau de la fonctionnalité, on ne sait pas quelle marque fonctionne comment ^^

J’imagine que certains voudront un topic par fonctionnalité

Ça marche, je pourrai faire des tests avec ce que j’ai chez moi sur MQTT.

J’ai finis la fonctionnalité, et je rajoute actuellement un onglet « Debug MQTT » ce qui va permettre de comprendre plus facilement ce qu’il se passe sur l’instance :

Comme ça l’utilisateur n’est pas dans le noir si ça marche pas :slight_smile:

4 Likes

J’ai bien avancé et j’ai une version de test à vous soumettre :slight_smile:

Le build est en cours de build sur l’image Docker :

gladysassistant/gladys:mqtt-custom-topic

Edit: l’image est prête !

Aide: Tutoriel: Lancer une image Docker de test

Preneur de vos retours !

Je viens de tester, ça marche pour un équipement qui poste avec un topic/métrique. En revanche pour un équipement qui poste différentes métriques au sein d’un json, seule la première « fonctionnalité » fonctionne, la seconde paramétré sur le même topic mais avec une chemin json différent ne récupéré aucune données. Ex de données:

{"CO2": 588.235, "CO2|unit": "ppm", "Humidity": 43.0, "Humidity|unit": "%", "Temperature": 25.8, "Temperature|unit": "\u00b0C", "Day/Night": "Day", "Battery Autonomy": "62.5-50%", "_timestamp": 1714758545, "_rssi": -61, "_rorg": 210}

Enfin je n’avais plus ça en tête au moment de définir le comportement attendu mais il est clair que le remplissage de l’id externe est assez fastidieux; il serait pas mal d’avoir une valeur généré par défaut si le champ est laissé à mqtt:

Salut @Alyafride !

Je pense qu’il y a un bug d’UI lorsqu’on remplie ces valeurs à la création du device MQTT, par contre à l’édition ça marche très bien… Merci du retour, je vais travailler dessus et je reviens vers toi :slight_smile:

Par contre, j’ai testé le cas d’avoir plusieurs metrics au sein du même JSON et ça marche bien :

La configuration :

Pourquoi pas, genre le nom de la feature + un peu de random ?

1 Like

Oui pourquoi pas, perso j’aime assez la logique de netbox pour le définition des slug. En gros si le champ n’est pas remplis il le défini sur la base du nom qu’il rend « url safe »

2 Likes

@Alyafride J’ai compris ce qui n’allait pas, j’ai fais un correctif, est-ce que tu peux tester avec la nouvelle image ? :slight_smile:

gladysassistant/gladys:mqtt-custom-topic

Pense à faire docker pull, stop, rm, et re-créé le container :slight_smile:

1 Like

Ça me semble bon maintenant :slight_smile: j’ai testé dans du JSON et métrique « à plat »