ebusd.mqtt2.template: Fragen, Anregungen

[Beta-User]

Moin,

dass ".../global/list" nichts liefert, ist m.E. ok so, das war von meiner Seite zu kurz gedacht.

Das "list" allg. ohne request ist an sich auch ok, wir wollten ja eine größere Belastung des Bus vermeiden.

Wenn dann aber jetzt die Situation die ist, dass wir doch erst spezifisch abfragen müssen, bevor überhaupt irgendwas via MQTT gepublisht wird, stehen wir eigentlich wieder am Anfang.
Oder anders gewendet: weiß jemand, der den ebusd einsetzt "sowieso", was da ist und kann dann die Abfragen auch ohne "unsere" Hilfe bei MQTT2 erstellen? Beispielsweise, weil er den Dämon nur sinnvoll konfiguriert bekommt, wenn er das passende csv wählt? Aus der csv-Benennung ergibt sich dann der Topic-Pfad, oder? Und aus den Angaben im csv dann die Reading-Benennung? Dann müßte man ggf. nur die Doku anpassen bzw. entsprechend ergänzen (jedenfalls, soweit mir das im Kopf ist)?

Vorläufig habe ich mal beide Abfragen in die setList eingebaut.

[Reinhart]

Oder anders gewendet: weiß jemand, der den ebusd einsetzt "sowieso", was da ist und kann dann die Abfragen auch ohne "unsere" Hilfe bei MQTT2 erstellen? Beispielsweise, weil er den Dämon nur sinnvoll konfiguriert bekommt, wenn er das passende csv wählt? Aus der csv-Benennung ergibt sich dann der Topic-Pfad, oder? Und aus den Angaben im csv dann die Reading-Benennung? Dann müßte man ggf. nur die Doku anpassen bzw. entsprechend ergänzen (jedenfalls, soweit mir das im Kopf ist)?

Vorläufig habe ich mal beide Abfragen in die setList eingebaut.

Bei der Konfiguration hat der Anwender mit der CSV normalerweise nichts zu tun, außer bei Exoten. Der Dämon wählt die CSV aus der Information die er aus der Scan bekommt selbst aus. Aber die "List" die uns John jetzt eingebaut hat den großen Vorteil, das sie erstens den Bus nicht belastet und der Anwender alle für ihn in frage kommenden Messwerte auf einen Blick sieht. Man braucht dann nur den Namen kopieren und in die Abfrage den get Befehl dazu hängen.
Wenn dass über die Gui funktionieren würde, wäre es der Überhammer. So was ähnliches hat "jamesgo" schon mit dem Modul "98_GAEBUS" realisiert, aber auf Basis Telnet. Im Prinzip könnte man das Modul modifizieren und mit diesem den "Set" Eintrag für die Abfrage automatisch vornehmen lassen.
Eine andere Möglichkeit wäre, man läßt GAEBUS so wie er ist und dient zur Abfrage der gewünschten Messwerte (hier kann man auch die Zeit einstellen wie oft er abfragen soll) , aber dann müsste uns John zusätzlich eine MQTT Antwort einbauen wenn eine Telnet Abfrage erfolgt. Mit dieser Maßnahme würde dann über autocreate ebenfalls das Reading angelegt. Da ich aber die interne Struktur vom Dämon nicht kenne, weiß ich nicht ob das so einfach ist.
Ganz sauber ist beides nicht, aber machbar wäre es. Der Wissenstand der User die den eBus benutzen ist außerdem auch sehr unterschiedlich, Einsteiger tun sich in der Regel etwas schwerer, aber es gibt auch Leute die viel lesen und die kennen den Umgang damit perfekt. Die Templates sind aber für beide Zielgruppen ideal geeignet.

Damit du siehst wie das funktioniert, habe ich am Testserver GAEBUS installiert.

LG

[john30]

Wenn dass über die Gui funktionieren würde, wäre es der Überhammer. So was ähnliches hat "jamesgo" schon mit dem Modul "98_GAEBUS" realisiert, aber auf Basis Telnet. Im Prinzip könnte man das Modul modifizieren und mit diesem den "Set" Eintrag für die Abfrage automatisch vornehmen lassen.

ich dachte der Plan ist, ohne GAEBUS auszukommen?

Eine andere Möglichkeit wäre, man läßt GAEBUS so wie er ist und dient zur Abfrage der gewünschten Messwerte (hier kann man auch die Zeit einstellen wie oft er abfragen soll) , aber dann müsste uns John zusätzlich eine MQTT Antwort einbauen wenn eine Telnet Abfrage erfolgt. Mit dieser Maßnahme würde dann über autocreate ebenfalls das Reading angelegt. Da ich aber die interne Struktur vom Dämon nicht kenne, weiß ich nicht ob das so einfach ist.
Ganz sauber ist beides nicht, aber machbar wäre es. Der Wissenstand der User die den eBus benutzen ist außerdem auch sehr unterschiedlich, Einsteiger tun sich in der Regel etwas schwerer, aber es gibt auch Leute die viel lesen und die kennen den Umgang damit perfekt. Die Templates sind aber für beide Zielgruppen ideal geeignet.

also ein Hybrid von ebusd client Port und MQTT macht aus meiner Perspektive nun wirklich keinen Sinn. Ziel sollte es doch sein, nur via MQTT auszukommen, oder nicht?
Und mit dem /list kommen ja dann auch alle Elemente vorbei, womit die Liste dann definitiv vollständig wird. Kann höchstens sein, dass das nicht sofort nach ebusd Neustart komplett ist weil der Scan noch nicht abgeschlossen ist. Das lässt sich aber auch an eingehenden Topics mit scan. Präfix erkennen, so dass eigentlich kein User Eingriff oder zeitbasiertes erneutes Nachfragen des /list notwendig ist.

Aber vielleicht habe ich auch eure Ziele nicht richtig verstanden

[Beta-User]

Sehe das auch so, dass es zukünftig reichen soll, nur MQTT einzusetzen.

Und wenn alle mit /list übermittelten Datenelemente potentiell (nach einer entsprechenden Abfrage) mit Leben gefüllt sein können, dann ist es auch ok, wenn die Liste lang ist; ich würde nur vermeiden wollen, dass der unbedarfte user sich mit unnötigem Ballast rumschlagen muß, den er definitiv nie benötigt.

Damit würde es Sinn machen, die automatische Abfrage durch das template ohne payload zu machen, oder? Danach würde sich das Spielfeld auf die setList und getList-Gestaltung bei den einzelnen Busteilnehmern verlagern?

Da sollten dann (via template) die häufig benötigten Infos rein, und m.E. sollte man auch das at so gestalten, dass dort keine IO-Publish-Anweisungen drinstehen, sondern die "get"-Anwfragen. Ist zwar im Prinzip dasselbe wie IO-Publish, aber zum einen scheint mir das für die User nicht so verständlich zu sein wie eine Werteabfrage mit "get", zum anderen hatten wir jedenfalls früher den Effekt, dass die readingList damit unnötig lang wurde (weil auch die get-Anfragen drin waren).

Also für den 430 die Elemente "Hc1HeatCurve_curve_value", "HwcTempDesired_temp1_value", und eventuell "Date_date_value"+"Time_time_value", für den bai die Dinge, die jetzt in dem at stehen.

Braucht ihr da Hilfe?


@Reinhart: Auf dem Testsystem ist jetzt ein Gerät MQTT2_ebusd_3.3_15145 vorhanden, das es mit dieser readingList eigentlich nicht geben dürfte:

Code Auswählen Erweitern

attr MQTT2_ebusd_3.3_15145 readingList ebusd_3.3_15145:ebusd/430/Hc1NightTemp:.* { json2nameValue($EVENT, 'Hc1NightTemp_', $JSONMAP) }
Funktioniert die bridgeRegexp des splitters nicht ordnungsgemäß oder gibt es eine andere Erklärung?

[Reinhart]

Nein, die bridgeregexp passt schon, da habe ich mit GAEBUS experimentiert und dort das Gerät aktiviert, somit wurde es durch autocreate sofort erfasst. Warum es ursprünglich nach ... 3.3.. gewandert ist weiß ich auch nicht, habe es dort gelöscht und dann wurde es ordnungsgemäß im ebusd/430 angelegt.

Ja, John hat schon recht rein bei MQTT zu bleiben und soviel Komfort kann man den Anwendern gar nicht anbieten. Wenn jemand ein Template für Sonoff installiert und gar kein Sonoff hat, dann funktioniert das logischerweise nicht und genau da hört der Komfort auf. Genau so verhält es sich beim eBus wenn jemand ein Template für die Calormatic installiert und gar keine hat wird es auch nicht klappen.

Der einzige Weg von Null weg zu installieren bleibt daher das Scan Ergebnis und das automatisch auszuwerten ist etwas komplex. Ich glaube aber, dass die meisten Anwender vom eBus schon wissen welche Geräte sie haben und auf das richtige Template klicken. Daher muss man halt im Wiki gezielt auf die richtige Reihenfolge der Installation hinweisen und das sie selbst dafür sorgen müssen das diese Readings auch abgefragt werden.

Mir fällt zumindest nichts ein wie man das "at" automatisch befüllen kann. Mann müsste bei Auswahl des Template, das bestehende "at" mit "add" ( an die letzte Zeile dazuhängen ) erweitern. Aber was tun wenn sich der Anwender geirrt hat, dann sollte es wieder verschwinden. Einfacher wäre es zu jedem Template ein eigenes "at" zu erzeugen. Bin mir daher nicht sicher ob man das Thema "at" weiter verfolgen soll.

LG

[Beta-User]

Danke mal für die Rückmeldung zur bridgeRegexp.

Was das at angeht, ist es schade, dass es nicht reicht, die "Ziel-Devices" jeweils mit einer getList zu versorgen und dann mit passenden Regex zu operieren. Also ins Unreine in etwa so:

Code Auswählen Erweitern

defmod EBUS.TIMER at +*00:30:00 get TYPE=MQTT2_DEVICE:FILTER=CID=ebus._.* .*
Es wäre sicher möglich, eine myUtils-Funktion zu bauen, die die verfügbaren get's vorab ermittelt und dann gezielt abruft. Allerdings ist das insgesamt nicht wirklich manipulationssicher, da ist es vermutlich wirklich besser, den Anwender auf das manuelle Editieren des einen at zu verweisen (aufteilen macht für mich nicht den großen Sinn, und auch als Helfer ist es dann schwieriger, gezielt rückzufragen).
Trotzdem würde ich das eher als get-Aufrufe in dem at gestalten und dann die getLists an den Devices entsprechend (per template) setzen.

[Beta-User]

Da es hier schon eine ganze Zeit ruhig ist:

Ist das ganze Thema jetzt eigentlich soweit auf Stand oder gibt es im Moment noch irgendwas, wo ich unterstützen könnte oder soll?

[TomLee]

War das nicht so das die mqtt2.ebus.template per update verteilt wurde ?

Auf einem Test-System mit heutigem update ist sie nicht in AttrTemplate

Gruß

Thomas

[Reinhart]

Nein, wurde noch nie per Update verteilt und du findest es als Attachment hier!


LG

[TomLee]

Wenn das deine aktuelle ist wäre die dann nicht besser im ersten Post angehängt wie im Wiki verlinkt ?

[Beta-User]

Hmm,

wir hatten das ja damals nicht in die "allgemeine" File aufgenommen, weil es nur für eine kleine Zahl von Usern relevant ist.
Zwischenzeitlich hat Rudi das "prereq:" eingebaut. Das würde es ziemlich sicher möglich machen, diese templates für die user "auszubauen", die kein ebus-Splitter-Device definiert haben. Mein Vorschlag wäre, das einzubauen und auch diese templates via svn direkt mit zu veröffentlichen.

Die weiteren Fragen wäre dann, ob
- die Verteilung im allgemeinen file (mqtt2.template) erfolgen soll oder weiter separat (durch einen anderen Maintainer ). Letzteres wäre mir lieber, denn diese templates sind soweit ich mich entsinne teilweise etwas "speziell" und es wäre sinnvoll, wenn jemand das betreuen würde, der auch passende Hardware hat. Andererseits ist  die Frequenz der updates zwischenzeitlich "gering"...
- weitere Software (myUtils) erforderlich ist, um (manches) sinnvoll zu nutzen. Dann könnte man auch den Teil (nach contrib ?) einchecken und eventuell über einen template-Befehl die File bei Bedarf ins Modulverzeichnis schieben und gleich laden.

(Ist alles Neuland, erscheint mir aber nicht sooo schwierig; evtl. könnte man Rudi mal fragen, ob wir eine allgemeine Routine bekommen, um einzelne "subs" in eine "allgemeine" 99_attrTemplateFunctions.pm automatisiert einzufügen bzw. dort auszutauschen; das "Problem" taucht meinem Bauchgefühl nach zukünftig häufiger auf, aktuell wäre es heute schon z.B. bei Rockrobo vorhanden.).

[rudolfkoenig]

Ich schlage separate 99_XXX.pm Dateien vor, je nach Themengebiet separiert, damit kann man sie auch mit version auswerten.

Damit man sie im template einfacher vom SVN-Server herunterladen kann (contrib wird per update nicht aktualisiert), habe ich gerade in 99_Utils.pm eine Funktion eingebaut:

Code Auswählen Erweitern

{ Svn_GetFile("contrib/86_FS10.pm", "FHEM/86_FS10.pm") }

[Beta-User]

Das mit den separaten 99-ern klingt plausibel, dann kann man ggf. auch eine kleine Commandref dazu packen.

Wenn ich den commit im svn richtig lese, müßte man hinterher noch einen reload im template ausführen? (Wenn ja: wäre ein optionales drittes Argument möglich, damit die Datei nach dem Download gleich geladen wird? Wenn nein: Ist sichergestellt, dass bei einem reload-Befehl via template die Datei schon da ist?)

Mit dieser Option würde ich jetzt Folgendes vorschlagen:
- Das separate attrTemplate-File erhalten, Download aus dem svn nur bei Bedarf (=durch Anwenden des in der allg. File enthaltenen Basis-templates).
- die myUtils käme dann erst, wenn man auch eines der readingsGroup-Devices via attrTemplate generiert?
- für die attrTemplate-Sachen lege ich ein neues Verzeichnis in contrib (AttrTemplate) an und trage mich mal als Maintainer für das Verzeichnis ein. Wer einzelne Dateien darau "haben will", kann das gerne tun.
- Den Code aus dem Wiki (https://wiki.fhem.de/wiki/EBUS-MQTT2#myUtils-Code) übernehme ich in eine eigene myUtils-Datei, Namensschema tendenziell sowas wie "99_attrT_ebus_Utils.pm", der Funktionsname muß dann aber etwas "spezieller und generischer" werden, damit besser erkennbar ist, wo eine Funktion herkommt. Ich tendiere zu sowas wie "attrT_ebus_<Funktion>()", konkret also "attrT_ebus_createBarView".

(Zur Funktion selbst würde ich gerne noch zwei optionale Parameter sehen, nämlich $maxValue und die Farbe, rot wäre mir persönlich zu "signalig". Vielleicht mag sich das und das cref-Thema dazu noch jemand anderes ansehen?  ). Wenn das eine "allgemein wünschenswerte" Funktion ist, die auch woanders benötigt werden könnte, wäre es vermutlich auch kein Problem, zu fragen, ob das in einer generalisierten Variante (z.B. nach Color.pm => justme1968 ansprechen) eingecheckt werden könnte... (Macht evtl. Sinn, ich sehe grade, dass das im Prinzip eine 1:1 Kopie aus den Beispielen zu readingsGroup im Wiki ist...).

Rückmeldung erbeten...!

[rudolfkoenig]

Ich habe den dritten Parameter hinzugefuegt, damit schaut es so aus:

Code Auswählen Erweitern

{ Svn_GetFile("contrib/86_FS10.pm", "FHEM/86_FS10.pm", sub(){CommandReload(undef, "86_FS10")}) }

[Beta-User]

Ich habe den dritten Parameter hinzugefuegt

Herzlichen Dank!
Wie immer weiter gedacht als mein Vorschlag, damit bekommen wir auch die Initialisierung neuer Templates gleich erschlagen .

Um den Mechanismus mal zu testen, würde ich die beiden angehängten Files bei nächster Gelegenheit einchecken. Ggf. der letzten Version von Reinhart ist da nur der Name der Funktion auf die separate myUtils-File geändert und die Funktionsweise dynamisiert. Ist völlig ungetestet, und kann daher Fehler verursachen, kann nicht mehr sagen, als dass das Ding läd...
Dringende BITTE daher, das zu testen und Rückmeldung zu geben, was ggf. geändert werden soll.