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)
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)
Je vois des avantages/inconvénients au deux choix en fait
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 ».
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 :
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:
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:
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
Par contre, j’ai testé le cas d’avoir plusieurs metrics au sein du même JSON et ça marche bien :
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 »
D’un point de vue technique par rapport eu scénarios que je décrivais le manque est comblé: il est possible de récupérer les info d’un équipement qui communique via MQTT sans avoir besoin d’implémenter d’adaptateurs dans node-red
Là où je manque de recul est sur l’expérience utilisateur: est-il pertinent de reserver ces nouveaux champs à un mode « avancé » et de conserver le form précédent par défaut ?
Enfin je pense que ça pourrait être pas mal d’avoir un mode auto pour les « ID externe » perso ce que j’ai fait pour le test c’est mqtt:<piéce>:<nom_appareil> pour l’appareil et mqtt:<piéce>:<appareil>:<nom_fonctionnalité>