Me parece que es un tema que suele repetirse, especialmente entre los usuarios que vienen de Home Assistant: la integración MQTT a veces no se entiende bien.
En Home Assistant, todos los dispositivos cuyos datos pasan por un broker MQTT (Zigbee2MQTT, ZwaveJS, etc.) suelen agruparse en la integración MQTT.
En Gladys, el paradigma es diferente: trabajamos con integraciones por tecnología.
Se distinguen claramente Zigbee, Z-Wave, Nuki, etc., aunque internamente estas integraciones pueden usar MQTT.
Para evitar esta confusión, he decidido renombrar la integración “MQTT” a “Dispositivos Virtuales MQTT”.
La idea es dejar claro que esta integración sirve para crear dispositivos personalizados mediante MQTT, y no para gestionar todos los equipos que usan MQTT en segundo plano.
Lo siento, pero en este caso, para mí está lejos de ser más claro — y te explico.
Mis dispositivos MQTT básicos son dispositivos completos: aunque sean personalizables, siguen siendo construidos como dispositivos reales. Sin embargo, Gladys nos « obliga » a pasar por la integración MQTT para diseñar dispositivos ficticios utilizados únicamente en interno. Es algo que llevo diciendo mucho tiempo: no es un funcionamiento normal a mis ojos. Estamos contaminando nuestros brokers MQTT con publicaciones que no deberían existir.
Y en mi caso, los temas MQTT ya están muy ampliamente utilizados y son muy demandantes en recursos. Añadir temas « virtuales » encima genera lecturas/escrituras adicionales que pueden provocar cargas excesivas, incluso disfunciones, sin motivo.
Renombrar la integración como « Dispositivos Virtuales MQTT » no resuelve este problema de fondo. Lo que me hubiera gustado es una nueva integración dedicada a los dispositivos virtuales, completamente desconectada de MQTT. Los dispositivos virtuales no necesitan pasar por un broker: podrían ser gestionados directamente en interno por Gladys, sin ninguna publicación MQTT. Esto permitiría mantener el broker limpio y reservado para los verdaderos intercambios con dispositivos reales.
También me baso en esta realidad:
El principio de separación de responsabilidades (separation of concerns) es fundamental en la arquitectura de software. Un broker MQTT está destinado a hacer transitar mensajes entre sistemas reales — sensores, actuadores, pasarelas. Hacer pasar estados puramente internos de Gladys por ahí es efectivamente desviar la herramienta de su función principal. Si ya tienes un broker cargado (muchos dispositivos Zigbee2MQTT, sensores que publican con frecuencia, etc.), cada tema adicional « virtual » añade ruido y carga, aunque individualmente sea ligero.
Gracias por tomarte el tiempo de detallar tu punto de vista, entiendo tu posición.
Por mi parte, la modificación de la que hablamos aquí está intencionalmente limitada al cambio de nombre, con un objetivo bastante pragmático: reducir la confusión para los nuevos usuarios (especialmente los que vienen de Home Assistant), que no siempre entienden el papel de esta integración hoy en día.
Si estás interesado, podemos abrir un tema dedicado para discutir más a fondo tu problema y ver qué alternativas serían posibles en Gladys.
