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

[Guybrush]

Die Fehler im Modul, die hier thematisiert wurden, habe ich gefixed. Ist alles im neuen DEV Build auf Github enthalten. Das Problem mit dem .clientArray betrifft das Modul selbst nicht. Das müsste in fhem selbst gehärtet werden.

Wegen des Vorschlags das Modul zu erweitern hab ich aber inzwischen bedenken, dass direkt in MQTT2_DISCOVERY abzubilden. Das würde dann nämlich immer eine zusätzliche Abhängigkeit neben MQTT2_DEVICE bedeuten. Ich halte es für besser, wenn die Laufzeitintegration in MQTT2_DEVICE erfolgen würde. Dafür würde ich in MQTT2_DEVICE eine Schnittstelle integrieren, z.b.:

Code Auswählen Erweitern

MQTT2_DEVICE_SetBindings($deviceHash,'mqtt2Discovery',$descriptor);
MQTT2_DEVICE_DeleteBindings($deviceHash, 'mqtt2Discovery');
MQTT2_DEVICE_GetBindings($deviceHash, 'mqtt2Discovery');
MQTT2_DEVICE_ValidateBindings($descriptor);

mqtt2Discovery wäre in dem Fall nur der Owner, um die von Discovery erzeugten Teile ersetzen oder entfernen zu können. MQTT2_DEVICE führt das anschließend alles intern selbst aus. Das hätte den großen Vorteil, dass ein laufendes FHEM keine Abhängigkeit von MQTT2_DISCOVERY hätte und das das Modul - so wie ursprünglich auch angedacht - nur für das Anlegen der Devices anhand der Discovery Topics zuständig bleibt. Dabei müssten dann manuell gesetzte setList/readingList Regeln im MQTT2_DEVICE Device die generierten Bindings überschreiben können. Die müssten dann aber tatsächlich nicht mehr befüllt werden, da MQTT2_DISCOVERY die oben genannten Schnittstellen von MQTT2_DEVICE aufrufen kann (optional per Attribut zu deaktiveren). Das bedingt dann zwar MQTT2_DEVICE als Abhängigkeit, aber ich find die Abhängigkeit bei MQTT2_DISCOVERY von MQTT2_DEVICE nicht kritisch. Andersrum wärs jedenfalls problematischer. So mal als Idee zum weiter diskutieren...