MQTT best current practice

[DasQ]

Ich stell jetzt mal saublöd die Frage

Was wollt ihr eigentlich? (wertbefreit 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 .

[Beta-User]

Wie könnte man also vorgehen?
Alleine habe ich vermutlich nicht die Zeit, "MQTT2_Utils" anzugehen, obwohl mir das im Moment nicht als soooo furchtbar viel Aufwand vorkommt. Das wäre dann so zu basteln, dass die Vorarbeit, die in MQTT2_DISCOVERY und der Dikussion hier steckt, (erst mal ohne dessen eigentlicher Kernaufgabe) ǘbernommen werden kann, also die "Standardparser" für die jeweilige Gadget-Familie.

Beginnen würde ich mit zigbee2mqtt, das scheint Guybrush nicht im Einsatz zu haben.

@TomLee: Interesse, das eine oder andere zu prompten, und mit zu überlegen und zu testen?
Die Idee dabei wäre (auch), eventuell dann in den attrTemplate das eine oder andere (dazu passend) aufzuräumen, gerade der z2m-Teil kommt mir nicht in allen Details gut strukturiert vor. Das wäre aber eher eine (automatisierbarer?) Nebenaspekt...

[TomLee]

Auf so ein Abenteuer mit Dir würde ich mich gerne mal wieder einlassen, da gäbe es für den einen oder anderen bestimmt auch wieder mal was zu knabbern.

Ich habe mich die Tage mit allen angesprochenen Punkten beschäftigt und ins    Modul einbauen lassen.
Jetzt einfach mal einen Cut gemacht und so, wie der Stand halt ist, gepusht:

Das mit dem Bauen lassen hat halt seine Grenzen, wenn man zu wenig Hintergrund hat.
Ich verzettele mich jetzt schon hier und da, darum wäre es cool, wenn Du über meine Bastelei mal drüberschaust und mir sagst, ob die Kryptanalyse bisher die gewünschte war und ob sich die Bausteine daraus in ein neues Modul einbauen lassen.

Getestet habe ich nur mit dem Shelly Mini und einem Tasmota-Stecker, einmal als Ein- und einmal als Zweikanaler.
Mit z2m zu beschäftigen hat es bisher nicht gereicht.

Was dazugekommen ist, steht im Anhang anleitung-neue-funktionen.md, die neuen Setter und Getter, der Schlüsselraum mit seinen Ebenen und Vorgaben, die Sache mit lwt und availability und die Kanalaufteilung.
Das Kurze davon: Mit den Vorgaben steht am Zielgerät weder readingList noch setList.
Das Modul wertet die Nutzdaten in seiner ParseFn selbst aus und bietet die Schaltbefehle über die SetExtensions-Kette an. Wer die Attributzeilen will, bekommt sie weiter, über den Schlüsselraum, je Gerät, je Familie oder global.

An 10_MQTT2_DEVICE.pm oder einem anderen Kernmodul ist nichts geändert.

Zum Nachvollziehen bei Dir hängen dran:

- mqtt2_discovery_dateien.tar.gz - 10_MQTT2_DISCOVERY.pm plus die 15 Dateien
  unter lib/FHEM/MQTT2_Discovery/. Die Moduldatei allein reicht nicht.
- payloads-tasmota-1kanal.txt,payloads-tasmota-2kanal.txt und payloads-shelly-mini-gen3.txt, die
  Discovery-Nachrichten meiner beiden Testgeräte, so wie sie get <name>
  payloads <device> ausgibt. Mit set <name> replayPayloads
  (im Dialogfeld einfügen) entstehen die Geräte bei Dir, ohne dass Du die
  Hardware brauchst. Geschwärzt sind Passwörter, Hostname, SSID und Adressen;
  Topics und Kennungen stehen drin, sonst beschreibt der Block nicht mehr
  dasselbe Gerät.


Der Rest ist im Repo dokumentiert: README.md für die Bedienung, docs/canonical-model.md für das Modell zwischen Adapter und Mapper, das ist die Stelle, die für einen eigenen Standardparser interessant wäre und docs/mqtt2-device-hook.md für den Set-Pfad samt der zwei Fallen, die in SE_Next stecken.

Die Tests laufen ohne FHEM-Installation: `prove -l tests`, 580 Stück, in der CI auf Perl 5.16 bis 5.42 mit warnings=FATAL.

[Guybrush]

Beginnen würde ich mit zigbee2mqtt, das scheint Guybrush nicht im Einsatz zu haben.

ich hab das bei mir am laufen und das funktioniert auch mit zigbee2mqtt.


Bzgl. der hier diskutierten Erweiterungen - ich möchte die nicht in MQTT2_DISCOVERY drin haben. Das kann ich - so wie es konzipiert war - auch in zukunft supporten und maintainen. Wenn da jetzt mit Agenten irgendwelche Codeerweiterungen passieren bin ich da aber raus. Das übersteigt die mir zur Verfügung stehende Zeit, die ich für sowas aufbringen möchte. Zumal noch einiges im Modul selbst fehlt was ich integrieren will, da weder Jinja komplett unterstützt ist noch alle Backends drin sind, die relevant sein könnten.

Wir sollten sowas wirklich dann in einem seperaten Modul umsetzen - oder am besten direkt in MQTT2_DEVICE, wo es meiner meinung nach thematisch auch richtig aufgehoben wäre. Von mir aus kann man auch ein Meta Modul drüber setzen. Aber es muss wartbar bleiben. Ich find die Idee ansich wirklich gut und würde die Funktionalität in Form von API Calls auch integrieren. Ich will nur nicht noch mehr Code vortragen, der nicht unmittelbar was mit der Verarbeitung von discovery messages zu tun hat. Ich würde aber auch schauen wollen, ob man sowas nicht globaler hinbekommt, also ohne es nur auf MQTT zu beschränken.