J’ai l’impression que c’est un sujet qui revient souvent, notamment chez les utilisateurs venant de Home Assistant : l’intégration MQTT est parfois mal comprise.
Dans Home Assistant, tous les appareils dont les données passent par un broker MQTT (Zigbee2MQTT, ZwaveJS, etc.) sont généralement regroupés dans l’intégration MQTT.
Dans Gladys, le paradigme est différent : on fonctionne avec des intégrations par technologie.
On distingue clairement Zigbee, Z-Wave, Nuki, etc., même si en interne ces intégrations peuvent utiliser MQTT.
Pour éviter cette confusion, j’ai donc décidé de renommer l’intégration “MQTT” en “Appareils Virtuels MQTT”.
L’idée est de rendre plus clair que cette intégration sert à créer des appareils personnalisés via MQTT, et non à gérer tous les équipements utilisant MQTT en arrière-plan.
Je suis désolé, mais pour le coup, pour ma part, c’est loin d’être plus clair — et je m’explique.
Mes appareils MQTT de base sont des appareils à part entière : même s’ils sont personnalisables, ils restent construits en tant qu’appareils réels. Or, Gladys nous « oblige » à passer par l’intégration MQTT pour concevoir des appareils fictifs utilisés uniquement en interne. C’est quelque chose que je dis depuis longtemps : ce n’est pas un fonctionnement normal à mes yeux. On vient polluer nos brokers MQTT avec des publications qui n’ont pas lieu d’être.
Et dans mon cas, les topics MQTT sont déjà très largement utilisés et gourmands en ressources. Ajouter des topics « virtuels » par-dessus génère des lectures/écritures supplémentaires qui peuvent provoquer des charges excessives, voire des dysfonctionnements, pour rien.
Renommer l’intégration en « Appareils Virtuels MQTT » ne résout pas ce problème de fond. Ce que j’aurais préféré, c’est une nouvelle intégration dédiée aux appareils virtuels, complètement découplée de MQTT. Les appareils virtuels n’ont pas besoin de transiter par un broker : ils pourraient être gérés directement en interne par Gladys, sans aucune publication MQTT. Ça permettrait de garder le broker propre et réservé aux vrais échanges avec de vrais appareils.
Je m’appuie également sur cette réalité :
Le principe de séparation des responsabilités (separation of concerns) est un fondamental en architecture logicielle. Un broker MQTT a pour vocation de faire transiter des messages entre des systèmes réels — capteurs, actionneurs, passerelles. Y faire passer des états purement internes à Gladys, c’est effectivement détourner l’outil de sa fonction première. Si tu as déjà un broker chargé (beaucoup d’appareils Zigbee2MQTT, des capteurs qui publient fréquemment, etc.), chaque topic supplémentaire « virtuel » ajoute du bruit et de la charge, même si individuellement c’est léger.
Merci d’avoir pris le temps de détailler ton point de vue, je comprends ta position.
De mon côté, la modification dont on parle ici est volontairement limitée au renommage, avec un objectif assez pragmatique : réduire la confusion pour les nouveaux utilisateurs (notamment ceux venant de Home Assistant), qui ne comprennent pas toujours le rôle de cette intégration aujourd’hui.
Si tu es partant, on peut ouvrir un sujet dédié pour en discuter plus en profondeur de ta problématique et voir quelles alternatives seraient envisageables côté Gladys.
