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 

[martinp876]

was ich mache und warum:
mir geht es um ein einfaches und übersichtliches Interface für den Anwender (nach einer Implementierung werde ich zum Anwender und will alles vergessen). Komplizierter wird es nicht - für den Anwender. Ob es für den Programmierer "etwas" komplizierter wird ist mir wurscht. Programmierer bin ich einmal, Anwender ständig. Ich komme aus der Systemtechnik - da geht "Repository" meist schief - ordentlich (auch wenn anstrengender) ist Library.

Und für alle, die Interessiert sind - es handelt sich im einen alernativen Ansatz. Den ziehe ich gerade durch - was ich schon bei ein paar Modulen tat. Ich ändere nichts am bestehenden Repository, alles nur bei mir. Also keine Angst - und evtl die eine oder andere Idee mitnehmen - oder auch ablehnen. Zuhören wäre schön.

Wie ich schon sagte, es gibt für mich no-gos - einige sind einfach zu umgehen, wenn ich schon dabei bin mache ich es natürlich komplett.
Zu "Kompliziert" habe ich zu sagen: Ich sehe es als absolute Pflicht, wenn man Attribute anderer Entites auswertet, sich über entsprechende Änderungen am Laufenden zu halten. Also "Notify global" auswerten. Weiter ist ein Suchen "über alles" IMMER möglich - aber uncool. Rudi hat daher seinen notify-hash eingebaut - absolut sinnvoll.
So als highlight von mir: DBlog war masslos zu komplex, aufwändig, unübersichtlich und unbedienbar (meine Ansicht). Ich habe ein Modul vorgebaut, werte die notwendigen Attribute beim Setzen aus und kann performat meine Standart-auswertungen ausführen ohne SQL zu tippen. Ausgabe des letzen Zeitabschnitt oder der letzten x Einträge. Sogar die Grafik mit Anfangs und Endwert der Interfvalle funktioniert nun reibungslos und korrekt. Das war vorher eben nicht auf "userniveau".

Da will ich auch hin - und es sieht schon gut aus. Wenn kompliziert bedeutet, dass man bei der Erstellung etwas hirnen muss dann nehme ich das gerne in kauf.

Noch einmal die highlights welche ich für mich sehe:
Model:
wenn ich ein model beschreiben will ich es einfach wieder nutzen können. Definitiv als Library, nicht als Repository.
Ich befasse mich also einmal mit einen Device - z.B. "Shelly2PM als Cover" und überlege/evaluiere was ich steuern, abfragen und sehen will. Dann erstelle ich die Filter und sortierungen, ähnlich wie es auch jetzt geschieht. Diese werden als template abgelegt - auch ähnlich dem aktuelle Ansatz.
Der Abstract ist also gleich, die Implementierung macht den Unterschied.
- um eine Entity nun funktional zu "definieren" weise ich dies mit einem Attribut "model = cover" zu. Einfacher geht es nicht mehr. Optional kann ich nun die funktion des "cover" auswählen, welche dargestellt werden soll. Beim Cover mit nur einem Aktor ist das wenig notwendig. Allerdings hat auch dieser 2 Eingänge "sensoren" welche ich darstellen möchte oder nicht, getrennt oder nicht.
- Die Funktion wird also über ein 2. Attribut zugewiesen.

Nachdem ich nun das Model definiert habe (oder jemand anders hat hierzu ein Template erstellt) kann ich "in die Produktion" gehen und meine 20 Aktoren Cover schnell und übersichtlich einrichten. Habe ich einen Bug oder eine Erweiterung ändere ich die Library.
So funktionieren systeme.
Aktuell wird eine Kopie des Template erstellt, welche sowieso unvollständig ist und nachgearbeitet werden muss um die Readings an fhem defaults auzupassen. Schon klar, dass die basis-Readings meines Shelly dem der Homematic entsprechen werden - ebenso wie die basis-Kommandos und Aufrufe.
Die ausufernden Listen in den Attributen sind ungenügend, müssen über weiter Subroutinen vervollständigt werden, versauen die Webdarstellung und sind alles andere als übersichtlich. Wie ich langfristig meine 20+ Rollos und noch mehr Lichtschalter auf sabere Konfiguration prüfen will ist mir schleierhaft.


Nachteil ist die Definition der Templates im Code - schon klar. Für mich taugt es - allerdings könnte man hierzu auch einen template-generator erstellen - habe ich bei Homematic ja auch schon gemacht. Kein grundsätzliches Problem also.

Selbstredend gibt es bei mir auch immer "info" kommandos. So wird man über ein "get modelInfo" die eigenschaften und einstellungen des Templates einsehen können.

Nervig war bei MQTT auch die Evaluierung des Device und des Protokolls. Eigentlich wollte ich mich damit garnicht befassen, aber es war alles unvollständig und es blieb mir ncihts anders übrig. Damti ich es beim nächsten mal leichter habe, habe ich schon eine eval-attribut vorgehalten. Hier kann ich die rohnachrichten aufzeichnen - aber nur die meines Device, vollständig und "häßlich". Damit kann ich mein model erstellen oder anpassen.

Eigentlich ist mir vollkommen unklar, was an einer struturierten Lösung mit einfachem Frontend "kompliziert" sein soll - es ist doch straight forward.
Btw.: kompiziert ist json2reading - da gibt es keine vollständige Beschreibung, trenner sind leider "_" was mit Datenpunkten kollodiert und hinreichend ist die Ausgabe für mich sowieso nicht.

Entscheidend wird für mich die Bedienbarkeit sein, nicht der Kodieraufwand. Kriterium ist, dass  ich es aus dem Sofa an Tablet bedeinen kann, noch nach 2 Monaten, wenn 70% vergessen sein. Kein SQL wissen, kein MQTT wissen notwendig. Ich muss das gefühl haben das Interface einfach erklären zu können. So muss das - bei mir.

Aktuell werden die Kommandos in meinen kommand-parser eingefügt. Auch so ein Ding welches mir viel Spass macht PAH aber sicher zu komplex ist.
Anforderung war, dass man die Kommandsyntax "wie üblich" definiert: anzahl Argumente, reihenfolge, namen, Wertebereiche, kennzeichnung ob optional, wenn optional dann welcher default. Und das zu 100%.
Das läuft bei mir seit jahren problemlos.
Jedes Kommando wird in genau einer Zeile umfänglich und nach üblicher nomenklatur spezifiert. Als Anwender sehe ich nun endlich, wenn ein Kommando optional ist, was als default genutzt wird (hat mich schon oft aufgeregt,...). Das wird dann auch gleich bei der Eingabe genutzt, diese zuprüfen. Das schöne: in der Bearbeitung kann ich mich darauf verlassen, dass die Argumente zulässig sind. Als Anwender bekomme ich fehlerlemdungen exakt nach dem gleichen Verfahren. So muss das. Noch ein paar weitere Feature welche es erträglicher machen, damit zu arbeiten.
Nichts für Automone, etwas für Systematiker. Bin mir nicht sicher, wo ich mich hier befinde - beides hat vorteile, ich tendiere immer zur Systematic bei SW.

hoffentlich habe ich jetzt nicht alle abgeschreckt

[Beta-User]

Ein paar Anmerkungen und Hinweise für manche hier Mitlesende.
 
Es gibt ein paar Threads von dir, die man zum besseren Verständnis des hier geschriebenen imo kennen sollte, bitte verbessern oder ergänzen, falls das ein Missverständnis meinerseits wäre:
- FHEM implement strategy
- command parser als library function

Die damalige Entscheindung, Änderungen an den attrTemplate nicht automatisiert in die Devices zu übernehmen, die damit (vor-) konfiguriert worden sind, mag man kritisieren, war aber bewußt getroffen. Wer es anders haben will, kann das z.B. auch über "archetype" erreichen, das sowohl beim Systemstart wie auch bei Änderungen im laufenden Betrieb den jeweils letzten Stand der attrTemplate "drüberklatschen" könnte.

Die Lösung in CUL_HM mit der notifyFn für Attributänderungen erschlägt das Problem, aber wenn man sowieso ein "Konfigurations-Zwischen-Device" benötigt, kann man dazu auch ein eigenes Modul "schreiben", das den notify-Teil gleich mit erledigt, ohne dafür an bestehenden Modulen irgendwelche Zusatzbasteleien vorzunehmen.

Auch vor dem Hintergrund z.B. dieses Threads shelly duo bulb gen3 über mqtt schalten hielte ich es für hilfreich, wenn ihr beide euch ggf. zusammentut, um eine (je nach Einstellung automatisierte) direkte semantische Überleitung in gängige FHEM-Standards zu erreichen. Das wäre sicher für viele User hilfreich, und wer es anders mag, kann ja weiter "händisch" (oder per attrTemplate) konfigurieren.

[martinp876]

ok - es scheinen min über 90% mit dem Absatz des MQTT2_DEVICE hoch zufrieden zu sein. Ist vollkommen ok, auch wenn ich beim besten Willen diesem Weg nicht folgen kann. So etwas könnte ein Grund sein, warum alle meine Bekannten sich gegen FHEM entschieden haben - man muss zu viel selbst machen und die Variantionen sind üpig. Zu viel Handarbeit, zu wenig Übersicht. Kommt nicht von mir, habe ich auch in Vergleichen so gelesen. Ich kann es bestätigen.

Ich stelle noch einmal dar, wie sich diese Modul "abstract" für mich präsentiert und was "best current practice" ist:
1) man richtet eine MQTT2_DEVICE entity ein - dann wählt man in der Drop-down Liste ein möglicherweise passendes Device aus. Nun werden automatisch (?) (ok, nach Kommando) Attribute gefüllt.
2) die Attribute sind hilfreich, das Device zu konfigurieren - müssen aber bearbeitet werden.
2a) da der Code in den Attribute steht sind diese für mich I) unangemessen lang ,II) nur schwer zu formatieren ,III) schwer zu lesen und zu editieren
2b) um den Code an die Entity anzupassen (Filter für receive sowie Setlist) muss man manuell editieren
2c) durch die Länge allein wird die Web-Darstellung - zumindest bei mir - komplett unleserlich - das allein ist ein no-go für mich
3)wenn ich nun die Attribute zurechtgestutzt habe und meine nächsten Schalter, Rollos,... identisch haben will muss ich - nun, was eigentlich? Die Attribute kopieren UND editieren - das ist aus meiner Sicht maximal unpraktipabel
4) nun will ich eine Änderung/Verbesserunge am Schalter-Template vornehmen - nichts einfacher als das  - einfach alle Entites kurz editieren, schon fertig (?!)
5) Konsistenzcheck: ich will prüfen, welche Entites nun alle auf dem gleichen Stand sind - einfach alles schnell mal durchlesen, raus kopieren, in excel vergleichen - anderer Vorschlag?
6) ich sehe keine wirkliche Unterstützung - schon gar nicht für Anfänger bei MQTT - die MQTT Messages zu erfassen, auszuwerten um dann (s)ein Template zu gestalten
7) Processing (ist nun für den User transparent, leider habe ich es gesehen). Alle einkommenden Messages werden gegen ALLE regexp aller MQTT2_DEVICES geprüft. Das potenziert sich.

Die Vorteile dieser Implementierung sollten klar sein:
schnelle Änderung, Template sichtbar (wenn auch schwer zu lesen), gut für seltene Entites wie Rasenmäher (kein Duplizieren notwendig). Viel mehr kann ich nicht erkennen.

Zu meinem Ansatz:
- hier werden keine Attribute automatisch gesetzt. FHEM bietet leider keine "system-Attribute", welche das Device "sichtbar" und non-volatil definieren. Sonst hätte man es in Internals machen können, geht leider nicht. Und die versteckten Attribute sind aus meiner Sicht ... unangemessen, weil "normal" nicht sichtbar (natürlich habe ich einen View systemweit in meiner Implementierung)
- Templates werden nicht in die Attributen geschmiert sondern im Code verwaltet - so wie es de facto bei allen anderen Systemfamilien auch ist, sogar noch weiter innen im Code und nikcht änderbar
- Änderungen an Templates sind durch die Referenzierung einfach über das ganze System auszurollen (einfacher geht es wirklich nicht)
- Mit dem Eval-Mode kann man die Messages einzelner Devices aufzeichnen und dann sein template gestalten. Ein Kommando zum aufräumen der Readings ist selbstredend einzubauen, um wieder Licht zu sehen - systemweit!.
- Empfangene Messages werden nur gegen die entsprechenden Entites geprüft und ausgewertet
- das Erstellen einer funktional identischen Entity sollte ein Kinderspiel sein - Definition und max 2 Attribute, fertig.
- Vielfalt der Darstellungsmöglichkeiten ist gegeben (model + function attribut - welche natürlich nicht automatisch gesetzt werden). Kanal-getrennt, kombiniert,...

Um ein effizientes Processing zu erreichen werden hash-tabellen genutzt. Das macht MQTT2_DEVICE bereits. Durch den zentraleren Ansatz allerdings - und weil ich es für deutlich effizienter halte  - werte ich relevante Attributsänderungen aller MQTT2 Devices aus und halte die Tabellen auf Stand - incl Device-rename/delete/incarnate.

Sollte der Ansatz interessenten finden würde eine dynamischere Erstellung von Templates keine Hürde sein. Aktuell allerdings ist es brotlose Kunst.

Die Anmerkung "komplex" zur Implementierung kann ich beim besten Willen nicht nachvollziehen. Das Ganze ich mit ein paar einfachen Routinen zu machen. Teile der aktuellen Implementierung sind mit Sicherheit min genauso komplex.

So weit könnte es für Interessierte noch passen.
Abhängen werde ich dann die Meisten, da ich bei den Kommandos eine systematische, zentralistische und vollkommen generische Lösung nutzen werden (welche schon erprobt ist). Eingebaut ist dies ein einziger Funktionsaufruf - wie ich finden ein Quantensprung mit etlichen Vorteilen. Entites aller Module, welche ich per Namen einbinde, bekommen u.a. systemweite Kommandos ins drop-down wie "clear readings" "list entity/entityHidden/modul" oder ein "peerlookup" welcher den Namen auch verdient und automatisch gefüllt wird. (Hier werden Attribute anderer Entites mitgelesen - bitte nicht verwechseln mit Modifiziert).

Ich hoffe, dass mein Ansatz sowie meine Beweggründe klar geworden sind. Mir ist klar, dass nicht jeder dem Folgen will - das ist logisch und vollkommen ok.
Was mich überracht sind manche Kommentare über Komplexität und Attribute welche ich hier überhaut nicht erkenne. Und noch mehr, dass scheinbar die übergroße Mehrheit aktuell hoch zufrieden ist.

Nun, da ich meinen Weg gefunden habe,zu 50% gegangen bin und sich keine Interessenten zeigen, werde ich meine Lösung "privat" vervollständigen. Es sieht aktuell ansprechen aus - gemäß meiner Vorstellung.

[Guybrush]

das Problem scheint eher zu sein, dass es sich zu kompliziert anhört - oder du es zu kompliziert erklärst. Eins von beiden trifft bestimmt zu  Das Problem von FHEM ist aber ganz klar, dass es für viele zuviel Freiheit bietet. Ich denke man sollte das eher mal global thematisieren, statt nur hier für MQTT zu diskutieren. Das Problem was du meinst betrifft ja nicht nur MQTT. HA macht deutlich mehr vorgaben, dafür kommen unerfahrene damit besser klar. ein zweites HA braucht aber auch niemand. Insofern stellt sich da eher die Frage, ob man für standardzeug nicht mehr "plug&play" braucht