MQTT best current practice

[betateilchen]

Dementsprechend kann (bis auf das "Dispatch"-Device) in allen Instanzen von MQTT2_DEVICE auf das Setzen des Attributs "readingList" verzichtet werden.

Das will ich gar nicht. Bei mir ist es sogar so, dass gleiche Gerätetypen in MQTT2_DEVICEs unterschiedliche readingList verwenden.

Grundsätzlich habe ich in vielen Jahren FHEM die Erfahrung gemacht, dass ALLES, was mir irgendwie "automatisch" das Selbst-Nachdenken abnehmen möchte, am Ende vorne und hinten nicht funktioniert (im Sinne von: liefert mir nicht die erwarteten Ergebnisse) und ich schneller ans Ziel komme, wenn ich mir devices selbst und von Hand einrichte.

Das fängt bei autocreate an und geht weiter über die Verwendung von eventTypes, attrTemplates und was es da alles noch im FHEM-Universum gibt.

Einzige positive Ausnahme: Das Erzeugen von SVG Definitionen aus FileLog oder DbLog liefert mir brauchbare Ergebnisse, die ich dann gerne als Basis für meine Anpassungen verwende.

Insofern unterstütze ich den Einwand von pah zu 100%. Aber vermutlich wird eine Umfrage selbst nicht aussagefähig, da nur ein begrenzter Teilnehmerkreis sich dafür interessieren und ggf. teilnehmen wird.
Viele Anwender haben jetzt schon Probleme damit, das eigentlich simple MQTT in FHEM einzurichten. Das wird mit dem hier angefangenen "Projekt" nicht besser oder gar leichter verständlich werden.

[Guybrush]

genau das ist das problem. Interessanter Ansatz, aber schon schwer zu verstehen. Ich hab das auch so beobachtet, dass es zu oft an den reinen basics scheitert. die readingList bekommt man dank autocreate noch hin, auch wenn dann die readings zugemüllt werden. die setLists machen dann aber bei zuvielen Probleme. Einer der Gründe für MQTT2_DISCOVERY