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