Ich habe den Eindruck, dass dies ein Thema ist, das oft vorkommt, insbesondere bei Nutzern, die von Home Assistant kommen: Die MQTT-Integration wird manchmal missverstanden.
In Home Assistant werden alle Geräte, deren Daten über einen MQTT-Broker (Zigbee2MQTT, ZwaveJS, etc.) laufen, in der Regel in der MQTT-Integration zusammengefasst.
In Gladys ist das Paradigma anders: Wir arbeiten mit Integrationen pro Technologie.
Wir unterscheiden klar Zigbee, Z-Wave, Nuki, usw., auch wenn diese Integrationen intern MQTT verwenden können.
Um diese Verwirrung zu vermeiden, habe ich beschlossen, die Integration „MQTT“ in „MQTT-Virtuelle Geräte“ umzubenennen.
Die Idee ist, klarer zu machen, dass diese Integration dazu dient, benutzerdefinierte Geräte über MQTT zu erstellen, und nicht, alle Geräte zu verwalten, die MQTT im Hintergrund verwenden.
Hier ist das Ergebnis auf Französisch und Englisch
Es tut mir leid, aber in diesem Fall ist es für mich alles andere als klarer — und ich erkläre warum.
Meine grundlegenden MQTT-Geräte sind eigenständige Geräte: Auch wenn sie anpassbar sind, bleiben sie als echte Geräte konstruiert. Gladys « zwingt » uns jedoch, die MQTT-Integration zu nutzen, um fiktive Geräte zu erstellen, die nur intern verwendet werden. Das ist etwas, was ich schon lange sage: Für mich ist das kein normaler Betrieb. Wir verschmutzen unsere MQTT-Broker mit unnötigen Veröffentlichungen.
Und in meinem Fall sind die MQTT-Topics bereits sehr weit verbreitet und ressourcenintensiv. Das Hinzufügen von « virtuellen » Topics darüber hinaus erzeugt zusätzliche Lese-/Schreibvorgänge, die übermäßige Lasten oder sogar Fehlfunktionen verursachen können — und das alles umsonst.
Die Umbenennung der Integration in « MQTT-Virtuelle Geräte » löst dieses grundsätzliche Problem nicht. Was ich mir gewünscht hätte, wäre eine neue Integration, die speziell für virtuelle Geräte gedacht ist und komplett von MQTT getrennt ist. Virtuelle Geräte müssen nicht über einen Broker laufen: Sie könnten direkt intern von Gladys verwaltet werden, ohne jegliche MQTT-Veröffentlichungen. Dadurch könnte der Broker sauber bleiben und nur für echte Austausche mit echten Geräten reserviert werden.
Ich stütze mich auch auf diese Realität:
Das Prinzip der Trennung von Verantwortlichkeiten (Separation of Concerns) ist ein Grundprinzip in der Softwarearchitektur. Ein MQTT-Broker dient dazu, Nachrichten zwischen echten Systemen — Sensoren, Aktoren, Gateways — zu übertragen. Ihn für rein interne Zustände von Gladys zu nutzen, bedeutet tatsächlich, das Werkzeug von seiner ursprünglichen Funktion abzulenken. Wenn du bereits einen stark belasteten Broker hast (viele Zigbee2MQTT-Geräte, Sensoren, die häufig veröffentlichen, etc.), fügt jedes zusätzliche « virtuelle » Topic Rauschen und Last hinzu, auch wenn es einzeln leicht ist.
Danke, dass du dir die Zeit genommen hast, deinen Standpunkt zu erläutern, ich verstehe deine Position.
Von meiner Seite aus ist die hier besprochene Änderung absichtlich auf die Umbenennung beschränkt, mit einem recht pragmatischen Ziel: die Verwirrung für neue Nutzer (insbesondere diejenigen, die von Home Assistant kommen) zu reduzieren, die nicht immer die Rolle dieser Integration heute verstehen.
Falls du dabei bist, können wir ein eigenes Thema eröffnen, um dein Problem vertieft zu diskutieren und zu sehen, welche Alternativen auf Seiten von Gladys möglich wären.
