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...

[Beta-User]

Leider habe ich das mit den Abhängigkeiten selbst nach mehrfachem Lesen immer noch nicht verstanden.

So oder so: MQTT2_DEVICE wird imo doch immer geladen, egal, ob MQTT2_(DISCOVERY|Utils) geladen wird oder nicht. Und unabhängig davon, wie man den Aufruf der Funktionen aus letzterem technisch umsetzt: Es kann nichts sinnvoll ausgeführt werden, wenn nicht am Ende beide Module geladen sind. Was übersehe ich?

Zum Ablauf: irgendwas erst per Attribut in jedem Einzelfall aktivieren zu müssen, was man mit der Entscheidung für eine bestimmte Technik (= define von MQTT2_(DISCOVERY|Utils)) allgemein entschieden hat, halte ich für wider die Erwartung des Konfigurators.

Die eigentlichen Probleme liegen imo woanders:
- Wer pflegt welche Teile des Codes?
- Wer "entscheidet" über defaults und "gute Praxis"?
- Wie verstetigt man das, wenn es (noch) keine discovery-Meldungen gab?

Das wird man ernsthaft diskutieren müssen.

[Guybrush]

So oder so: MQTT2_DEVICE wird imo doch immer geladen, egal, ob MQTT2_(DISCOVERY|Utils) geladen wird oder nicht. Und unabhängig davon, wie man den Aufruf der Funktionen aus letzterem technisch umsetzt: Es kann nichts sinnvoll ausgeführt werden, wenn nicht am Ende beide Module geladen sind. Was übersehe ich?

Genau das sind meine Bedenken. Die zusätzliche Abhängigkeit von MQTT2_DISCOVERY. Thematisch gehört das meiner meinung nach in MQTT2_DEVICE. Das muss eh geladen sein und funktionieren und das was da passiert betrifft auch dessen namespace. MQTT2_DISCOVERY kann die Funktionen dort ja aufrufen zum anlegen. Die Verarbeitung usw sollte aber im Modul selbst bleiben. MQTT2_DEVICE wird ja ohnehin benötigt, wenn man das device öffnet und es wäre meiner Meinung nach nicht gut, wenn aus dem Modul eine Funktion aus einem anderen Modul zur Laufzeit aufgerufen werden muss. Es gibt jedenfalls keinen Grund es in DISCOVERY zu integrieren. Je mehr Abhängigkeiten es gibt umso eher treten Fehler auf.

Zum Ablauf: irgendwas erst per Attribut in jedem Einzelfall aktivieren zu müssen, was man mit der Entscheidung für eine bestimmte Technik (= define von MQTT2_(DISCOVERY|Utils)) allgemein entschieden hat, halte ich für wider die Erwartung des Konfigurators.

Deswegen ja per Attribut abschaltbar, nicht anschaltbar Ich bin kein Freund von Legacy Code, aber wenn etwas so lange standard war geht es nicht anders, wenn man alle mitnehmen möchte.

Die eigentlichen Probleme liegen imo woanders:
- Wer pflegt welche Teile des Codes?
- Wer "entscheidet" über defaults und "gute Praxis"?
- Wie verstetigt man das, wenn es (noch) keine discovery-Meldungen gab?

DISCOVERY mach ich ja auf absehbare Zeit auf jeden Fall weiter. Wenn das rund ist wird es da auch nicht mehr so viel Pflege benötigen. Die Schnittstelle in MQTT2_DEVICE (oder auch woanders, wenn das da nicht rein soll) müsste man halt schauen. Ich will das gerade nicht leisten. Ich hab noch ein paar andere Sachen, die ich erst fertig machen will. Discovery Messages werden default von den allermeisten devices als retain verschickt. Dafür ist das auch da. Es gibt dummerweise Konfigurationen, wo man das retained flag deaktivieren kann. Auch haben sicherlich einige FHEM User die Discovery Topics auf ihren Devices deaktiviert. So hatte ich das früher auch, weil die ständig FHEM zugemüllt haben. Das muss natürlich mit DISCOVERY rückgängig gemacht werden. DISCOVERY verschluckt/filtert die, so dass diese kein "Problem" mehr darstellen. Am Ende ist der sicherste Weg, dass nach AKtivierung von DISCOVERY jedes MQTT fähige device einmal geprüft wird, dass discovery aktiviert ist und dann restartet wird. Solang solche Devices nicht verändert wurden, sollte das beim Start von FHEM aber automatisch aus dessen retained cache abgeholt und verarbeitet werden.

Losgelöst davon fänd ich es aber gut, wenn man mal einen Standard verbindlich(!) vorgeben würde. Mir ging es auch oft genug so, dass ich kreativ sein musste, weil ich mir mangels Verbindlichkeit was ausdenken durfte. Damit meine ich nicht, dass Module nicht mehr lauffähig sein sollen, wenn sie sich nicht daran halten. Aber dass man diese dann z.b. als validiert anzeigt, was dann hoffentlich Motiviation genug ist für Entwickler ihr Modul entsprechend anzupassen. Dafür müssen ja ansich nur die Rückgabewerte der Standardfunktionen passen. Das könnte man gut mit Perl Test2::V0 abbilden, so dass es einen Test geben könnte, der ein Modul daraufhin testet. Wird ja leider ohnehin von den wenigsten verwendet, dabei hilft das ungemein verborgene Fehler zu finden.

[Beta-User]

Ich will das gerade nicht leisten.

Das ist eine faire Ansage, und imo auch völlig verständlich.

Dementsprechend kann es hier auch "nur" darum gehen, das Feld abzustecken und ggf. zu klären, wie man die Puzzleteile überhaupt zuschneiden könnte, und wer welche Teile beisteuern könnte und (v.a.!) möchte, und ggf. auch den Kopf dafür hinhält.

Rudi hat die Voraussetzungen dafür geschaffen, dass man im Prinzip beide "Plugins" (MQTT2_DISCOVERY und MQTT2_Utils ohne diese Funktionalität (?)) trennen könnte, von letzterem ggf. auch nur den Teil, der nicht (so oder so?) nach MQTT2_DEVICE "sollte". Imo hätte eine Auftrennung allerdings mehrere Nachteile, angefangen damit, dass der geneigte User vermutlich nicht versteht, warum er überhaupt mehrere braucht...

Genau das sind meine Bedenken. Die zusätzliche Abhängigkeit von MQTT2_DISCOVERY.

Sorry, ich verstehe die Bedenken immer noch nicht:
Entweder, man verwendet MQTT2_DEVICE "pur". Dann können auch im bisherigen Modell keine Funktionen aus MQTT2_DISCOVERY aufgerufen werden, obwohl sie in setList/readingList verdrahtet sind, wenn dieses weitere Modul nicht geladen ist.
Welchen Unterschied macht das dazu, dass MQTT2_(DISCOVERY|Utils) sich vor SetExtensions registriert bzw. die eingehenden messages parst, außer, dass andere "geht-nicht"-Rückmeldungen für set-Kommandos kommen bzw. eventuell andere Readings (bzw. "geht-nicht"-Rückmeldungen für set-Kommandos) entstehen, wenn autocreate noch aktiv ist und eingehender traffic wider Erwarten nicht (vorher dort) verarbeitet wird.

Deswegen ja per Attribut abschaltbar, nicht anschaltbar Ich bin kein Freund von Legacy Code, aber wenn etwas so lange standard war geht es nicht anders, wenn man alle mitnehmen möchte.

Imo ist es eine Frage der Sichtweise: MQTT2_DEVICE in der heutigen Form (ggf. mit kleinen "Extras") darf gerne weiter das "allgemeine Arbeitspferd" bleiben für alle Anwendungsfälle, in denen "wir" keine sinnvolle Automatik anbieten können und/oder die Zahl der Duplizierungen gering wäre, oder der User das schlicht nicht möchte. Das "fancy aufzubohren" und die User mit neuer unerwarteten Automatiken zu "beglücken", hielte ich für einen großen Fehler.

Losgelöst davon fänd ich es aber gut, wenn man mal einen Standard verbindlich(!) vorgeben würde.

FHEM ist "irgendwie basisdemokratisch" organisiert, ich sehe (leider?) keinen, der dazu willens oder in der Lage wäre, und anscheinend sind z.B. aktuell auch meine (mehrfach direkt oder indirekt zitierten) Argumente für "on/off" für den Hauptkanal nicht ausreichend, um dich davon zu überzeugen, dass es eine gute Idee wäre, den Aufwand zu treiben (Du kannst ja "legacy" auch deine Kommandos "on the fly" weiter zulassen!).

Was Testen und Code-Standards an sich angeht, wäre das übrigens ein wirklich großes Projekt, in dem man das alles auch an eventuelle Mitmacher vermitteln könnte . Und zwar, ohne alles selber machen zu müssen .