I feel this is a topic that comes up often, especially among users coming from Home Assistant: the MQTT integration is sometimes misunderstood.
In Home Assistant, all devices whose data goes through an MQTT broker (Zigbee2MQTT, ZwaveJS, etc.) are generally grouped in the MQTT integration.
In Gladys, the paradigm is different: we operate with integrations per technology.
We clearly distinguish Zigbee, Z-Wave, Nuki, etc., even if internally these integrations may use MQTT.
To avoid this confusion, I therefore decided to rename the integration âMQTTâ to âMQTT Virtual Devicesâ.
The idea is to make it clearer that this integration is meant to create custom devices via MQTT, and not to manage all equipment using MQTT in the background.
Iâm sorry, but in this case, for me, itâs far from clearer â and let me explain.
My basic MQTT devices are full-fledged devices: even though theyâre customizable, they are still built as real devices. However, Gladys « forces » us to go through the MQTT integration to design fictitious devices used only internally. This is something Iâve been saying for a long time: itâs not a normal way to operate in my view. We end up polluting our MQTT brokers with publications that have no reason to exist.
And in my case, the MQTT topics are already heavily used and resource-hungry. Adding « virtual » topics on top generates additional reads/writes that can cause excessive loads, even malfunctions, for no reason.
Renaming the integration to « MQTT Virtual Devices » doesnât solve this underlying problem. What I would have preferred is a new integration dedicated to virtual devices, completely decoupled from MQTT. Virtual devices donât need to transit through a broker: they could be managed directly internally by Gladys, without any MQTT publication. That would keep the broker clean and reserved for real exchanges with real devices.
I also rely on this reality:
The principle of separation of responsibilities (separation of concerns) is fundamental in software architecture. An MQTT broker is intended to route messages between real systems â sensors, actuators, gateways. Routing purely internal Gladys states through it is effectively misusing the toolâs primary function. If you already have a loaded broker (many Zigbee2MQTT devices, sensors that publish frequently, etc.), each additional « virtual » topic adds noise and load, even if individually itâs light.
Thank you for taking the time to detail your point of view. I understand your position.
From my side, the change weâre discussing here is deliberately limited to a rename, with a fairly pragmatic goal: to reduce confusion for new users (notably those coming from Home Assistant), who donât always understand the role of this integration today.
If youâre up for it, we can open a dedicated thread to discuss your concerns in more depth and see what alternatives might be possible on the Gladys side.
