MQTT best current practice

[Beta-User]

dann ist das aber noch ein Schritt weiter

Nach meinem Verständnis geht es hier die ganze Zeit bereits eigentlich um diesen weiteren Schritt: Statt durch "Tonnen von (statisch gesetzten) Attributen" soll zumindest im Bereich von klar umrissenen "MQTT-Familien" ein framework _vorab_ die Aufgabe erledigen, anhand von wenigen Uservorgaben (Martins neue Attribute) "sinnvolle Standard-FHEM-Entities" (hier als MQTT2_DEVICE-Instanzen) zu bilden.

Was heute in attrTemplate (insbesondere, aber nicht nur (!) als "split"-Varianten) enthalten ist, verfolgt auch (allerdings in den heute möglichen Attributen statisch) den Ansatz: Das Ergebnis ist funktional identisch, egal, ob es z.B. ein schaltbarer Kanal aus einem Aktor mit vielen Relays ist, oder z.B. ein Thermostat, bei dem die Solltemperatur eben immer "desired-temp" als Readingnamen hat, egal, was dem "Übersetzer" aus der zigbee-, xy- oder z-Welt gerade eingefallen ist, wie das dort benannt werden könnte.

Ziel wäre es "nur", die Vorgehensweise zu ändern, und das ganze zu dynamisieren, damit man (automatisch) in einem Zug alles geändert bekommt, wenn sich z.B. bei zigbee2mqtt was grundlegendes ändern sollte.