Retours sur gladys

Configuration
1

Bonjour,

J’utilise actuellement comme « système domotique » un ensemble de services (zigbee2mqtt, deconz, node-red) + home-assistant (mais assez peu au final).
Afin de me rendre compte de ce qu’est Gladys j’ai déployé une instance de test en container: processus d’install nickel, l’interface est propre et réactive.
L’interface utilisateur est moderne et dénote avec beaucoup d’autre solutions domotiques souvent austère.

Une limitation que je trouve assez dommageable dans la Gladys est l’intégration MQTT. Le fait de ne pas pouvoir spécifier de topic spécifique (même en plus de celui défini automatiquement) directement au niveau de l’équipement est dommage. Bien qu’il soit possible de gérer la réception d’un message via une scène je trouve que cela rend la logique « fouillis » pour garder une logique d’équipement.
Selon moi la possibilité de:

  1. pouvoir spécifier un topic au niveau de l’équipement,
  2. définir si le contenu est un json ou « plain text »
  3. dans les fonctionnalités spécifier le sous-topic de la valeur ou la clef dans le json reçu du topic équipement
    permettrait de satisfaire un grand nombre de scénarios nécessitant node-red.

De plus avec cela rendrait les équipements shelly, teleinfo, enocean relativement facile à intégrer à Gladys.

mes deux centimes

Bonne journée

3 « J'aime »
2

Salut @Alyafride ! :slight_smile:

Bienvenue sur Gladys, et merci beaucoup pour ton retour ! :pray:

J’ai très souvent ce retour sur Gladys, mais je n’arrive pas à comprendre comment ça pourrait marcher.

MQTT est un protocole de communication (au même titre que HTTP), mais ce protocole ne définit aucun format de message (chacun met ce qu’il veut), il n’est d’ailleurs pas spécialement lié à la domotique.

Dans Gladys on a définit notre format de topic et de message. Chaque marque qui utilise MQTT utilise son propre format aussi (et c’est normal, c’est comme des API HTTP, ça n’a pas vocation a être uniformisé).

Du coup, disons qu’on proposait aux utilisateurs d’ajouter un topic custom à chaque appareil MQTT.

Comme tu dis, il faudrait aussi que l’utilisateur puisse définir le format des payloads (en entrée, et en sortie), puis il faudrait ensuite que l’utilisateur définisse le format des valeurs, ainsi que des fonctions de conversions.

Exemple: dans Gladys, une lampe “Allumée” la valeur c’est 1, dans Shelly c’est “true”.

Pour les couleurs, dans Gladys c’est un format entier, certains constructeurs c’est de l’hexa, d’autres du RGB, etc…

Bref, tout ce que je viens de décrire, en fait c’est du code :joy:

Pour prendre l’exemple de Shelly, quitte à faire la table de correspondance en Shelly et Gladys, pourquoi forcer tous les utilisateurs à la faire une par une par appareil, quand elle pourrait être faites une seule fois dans le code de Gladys et ensuite ça marche pour tout le monde ? C’est ce qu’on a fait dans le cas du Zigbee par exemple.

Où peut-être je n’ai pas compris quelque chose ?

Merci de ton retour en tout cas !

Mais vu que j’ai relativement souvent ce retour des utilisateurs venant de HA, il doit y avoir quelque chose que je ne comprend pas, donc je suis preneur de ta lumière :blush:

3

Alors dans un premier temps je n’ai en tête que la partie récupération et affichage des données de sorte à pouvoir afficher certains états (combien je consomme, équipement allumé etc) pour le passage de commande c’est en effet une autre paire de manche pour gérer les différents types de données. Mais personnellement j’aime assez faire remonter les données des sondes (qualité de l’aire, énergie etc) en MQTT. Pour le passage d’ordres la plupart c’est node-red ou home-assistant.

Typiquement dans le cas de shelly: Une personne qui voudrait tester Gladys et avoir un dashboard propre, bien que cela soit un peut fastidieux définir comme actuellement des fonctionnalités sous un appareil MQTT mais en spécifiant le topic de souscription et ainsi avoir ses métriques qui remontent directement.

Pour imager mon cas sur une sonde de CO2 qui remonte l’info via MQTT il m’a été obligé de créer un flow node-red qui ne fait que souscrire au topic de la sonde, modifier ce topic par celui attendu par Gladys et re-émettre le message, c’est un peut dommage.

4

Exemple pour un shelly EM, une personne pourrait simplement configurer le broker MQTT dans l’équipement celui-ci poussera un message de ce type (attention uniquement gen1, gen2 cela est sous forme de JSON):
image

Créer un appareil MQTT dans Gladys et créer une fonctionnalité pour la/les métriques qui l’intéresse.

5

Ok je comprends, après la c’est un cas facile si c’est juste des valeurs numériques (mais c’est peut être le cas dans la plupart de cas)

Dans ton screenshot, « power », « reactive_power », c’est des attributs json ?

6

Non en gras c’est l’arborescence du topic et en normal la valeur:
shellies/shellyem-XXXXXXX/emeter/0/total_returned 855.2

Pour la génération 2 et 3 des shelly en revanche les messages sont sous formes de json, je pourrai communiquer un exemple si besoin.

Je suis convaincu que ce cas assez simple est un des plus courant, autant MQTT n’est pas évident à gérer pour le passage d’ordre car il n’y a pas de gestion de retour d’état mais pour l’IoT et la remonté de valeur de capteurs de trouve ça très pertinent.

7

Ok, dans ce cas je veux bien que tu crée une demande de fonctionnalité sur le forum pour garder une trace de la demande :slight_smile:

Regarde peut être avant si il n’y a pas déjà une demande similaire

Et si tu es un peu dev, Gladys est open-source et toute PR est la bienvenue :hugs:

8

Ok, je vais trouver/rédiger une demande de fonctionnalité.

Pour le dev je suis plus à l’aise en python et déjà sur pas mal de projets en ce moment.

2 « J'aime »
9

bonjour @Alyafride

ta demande ressemble un peu à cette demande si je ne me trompe pas et si j’ai bien compris tes propos :wink:.

10

En effet, j’étais tombé sur celui ci , à ceci prés que l’idée dans un premier temps était simplement de définir le topic sans volonté de chercher à transformer la donnée. Grosso modo garder la même logique de traitement mais simplement donner la possibilité de spécifier le topic afin de pourvoir cibler les topics imposés par les constructeurs.

Une solution pertinente selon moi serait de pouvoir définir le topic « parent » au niveau de l’équipement et spécifier si le contenu du message est un json ou des valeurs à plat (dans des sous topics). Ensuite pour chaque « fonctionnalité » de l’équipement définir la clef de la valeur à savoir le sous topic si donnée à plat et la clef du dictionnaire si json.

11

@cce66 vu que c’est la même demande alors, j’ai fermé ta demande pour conserver l’autre qui est plus clair / a plus de votes :slight_smile:

1 « J'aime »