MQTT best current practice

[DasQ]

Ich stell jetzt mal saublöd die Frage

Was wollt ihr eigentlich? (Wert befreit das Ziel des Ganzen?)

Und zitiere den ersten Treffer zu mqtt Discovery in Google.

,,MQTT Discovery allows smart home systems like Home Assistant MQTT Integration to automatically detect and set up devices without manual YAML coding"

Ich will jetzt nicht vom 5. Rad am Wagen sprechen, bemerke aber das wir die Verwirrung an anderer Stelle schon haben. (Mqtt <-> Mqtt2)
War der Meinung, das Problem ist mit autocreate und den Templates erschlagen.
Das Discovery in HA in allen Ehren (ich nutz HA nicht) die vollkommene atomisierung, und jeder spuckt in den Topf hat mir nicht geschmeckt.
Will Fhem DAU freundlich werden wie HA, könnte es etwas HA vertragen. (Wegen mir nicht, wegen useability schon)


Und nun zurück zum Thema

Baut des Discovery als fallback oder primär ins autocreate ein. Eine Entmündigung des User ird zu dummen fragen führen, in wie weit man den Löffel dem User in den Mund steckt, schlucken muß er selber

[Guybrush]

MQTT2_DISCOVERY ist ja gerade so gebaut, dass es nichts vorschreibt. Wir diskutieren hier u.a., ob man das noch einfacher halten kann für diejenigen, die mit setlist/readinglist Definitionen überfordert sind. Wenn man alles nur noch über MQTT2_DISCOVERY laufen lässt, dann sind die Angaben in reading/setlist halt nicht so entscheidend. Wichtig ist vielmehr, dass man problemlos es anpassen kann, wenn man andere Vorstellungen hat. Ich selbst nutz nur noch Discovery. Ich bin jetzt erstmal dabei die Fehler glatt zu ziehen.

[Beta-User]

Wir diskutieren hier u.a., ob man das noch einfacher halten kann für diejenigen, die mit setlist/readinglist Definitionen überfordert sind.

Mir geht es weniger um Überforderung, sondern um Effizienz und Eleganz. Immer wieder denselben redundanten Code an den compiler zur Laufzeit zu übergeben, ist für einige wenige Devices "das Problem erschlagen", aber eben nicht unbedingt übersichtlich, und schon gleich nicht effizient.

Ich will jetzt nicht vom 5. Rad am Wagen sprechen, bemerke aber das wir die Verwirrung an anderer Stelle schon haben. (Mqtt <-> Mqtt2)

Mein persönliches Ziel wäre, meine zigbee2mqtt-Welt neu zu strukturieren, und ich hatte vor Martins Anstoß zu diesem Thread bereits einige Zeit daran rumüberlegt, wie man manche Einschränkungen aus der bisherigen Welt denn wohl am besten überwinden könnte. Sonst wäre ich (Hobbyist!) vermutlich auch nicht auf den Gedanken gekommen, wie man das "discovery" (das mir in seiner gefühlten non-Persistenz der Daten bei Homeassistant ebenfalls befremdlich vorkommt) mit Martins Ansätzen so kombinieren könnte, dass man am Ende sehr viel schneller das hat, was man mit attrTemplate zwar auch bekommt, aber eben ohne zentrale Verwaltung der Funktionalität.

Wenn man es "richtig" macht, ist der "MQTT2_Utils-Weg" (wie ich ihn mir im Moment vorstelle) übrigens sehr viel schneller erklärt wie attrTemplate und die dortigen Auswahlmöglichkeiten, und es sollte auch möglich sein, mehr Hilfe für Helfer anzubieten.

Das ganze immer mit der Option, das Beste aus allen Welten so zusammenzustellen, wie der User das am Ende haben mag.

Das hat wenig mit Bevormundung zu tun, sondern eher mit einer besseren Benutzerführung, auch und gerade hin zu "fhemischeren" Devices wie denen, die "DISCOVERY" im Moment bietet.

Ad "fhemisch" und der Frage, welche "Namensgebung" denn für Readings sinnvoll ist: https://forum.fhem.de/index.php?topic=117933.0 und https://wiki.fhem.de/wiki/DevelopmentGuidelinesReadings