Werte per MQTT setzen

[TomLee]

Achso und wenn man kein jsonMap verwendet dann sehen die Readings so aus und nicht wie in den 3 angesprochenen Templates:

Code Auswählen Erweitern

defmod MQTT2_ebusd_bai2 MQTT2_DEVICE ebusd_bai
attr MQTT2_ebusd_bai2 IODev MQTT2_Server
attr MQTT2_ebusd_bai2 event-on-change-reading .*
attr MQTT2_ebusd_bai2 group Ebus
attr MQTT2_ebusd_bai2 icon message_tendency_steady
attr MQTT2_ebusd_bai2 model E_09_eBus_Hc1HeatCurve+HwcTempDesired
attr MQTT2_ebusd_bai2 periodicCmd test:1
attr MQTT2_ebusd_bai2 readingList ebusd/700/HwcTempDesired:.* { json2nameValue($EVENT, 'HwcTempDesired_', $JSONMAP) }\
ebusd/700/Hc1HeatCurve:.* { json2nameValue($EVENT, 'Hc1HeatCurve_', $JSONMAP) }
attr MQTT2_ebusd_bai2 setList test:noArg { fhem "set MQTT2_Server publish ebusd/700/Hc1HeatCurve/get;;set MQTT2_Server publish ebusd/700/HwcTempDesired/get;;";;}\
Hc1HeatCurve_0_value:0.20,0.70,0.85,0.90,1.00,1.10,1.20,1.30,1.40,1.50,1.60,1.70 ebusd/700/Hc1HeatCurve/set $EVTPART1\
HwcTempDesired_tempv_value:50.0,51.0,52.0,53.0,54.0,55.0,56.0,57.0,58.0,59.0,60.0 ebusd/700/HwcTempDesired/set $EVTPART1
attr MQTT2_ebusd_bai2 webCmd Hc1HeatCurve_0_value:HwcTempDesired_tempv_value
attr MQTT2_ebusd_bai2 webCmdLabel Hc1HeatCurve:HwcTempDesired

setstate MQTT2_ebusd_bai2 HwcTempDesired_tempv_value
setstate MQTT2_ebusd_bai2 2020-04-01 15:15:21 Hc1HeatCurve_0_name
setstate MQTT2_ebusd_bai2 2020-04-01 15:15:21 Hc1HeatCurve_0_value 0.85
setstate MQTT2_ebusd_bai2 2020-04-01 15:15:22 HwcTempDesired_tempv_value 51

[Beta-User]

Der Spur nach paßt die Richtung, ich würde aber etwas anders "schreiben":
Das publish sollte m.E. nicht als direktes publish über das IO gehen, sondern via setList oder getList mit entsprechendem Eintrag dort, ich meine, dazu auch irgendwann mal Vorschläge im ebus-template-Thread gemacht zu haben (als getList, was aber mangels Rückmeldung wohl FHEM-technisch nicht der richtige Weg wäre).
Aus dem Kopf eher z.B. nach aktuellem Stand der Dinge so:

Code Auswählen Erweitern

attr DEVICE periodicCmd Z_request_Hc1_HC:10 Z_request_Hwc_desTemp:3attr DEVICE setList \
  [was auch immer da schon stand]
  Z_request_Hc1_HC:noArg ebusd/DEVNAME/Hc1HeatCurve/get\
  Z_request_Hwc_desTemp:noArg ebusd/DEVNAME/HwcTempDesired/getOb das in der Form technisch Sinn macht, wäre mit dein Thema - die Heizkurve ändert man vermutlich nicht ständig, da reicht eigentlich auch z.B 1xpro h/ bzw. im Nachgang zu Änderungsanweisungen - ansonsten ist es m.E. eher eine Kleinigkeit und wir können das ggf. auch hier mit Damian finalisieren, wenn er mag und andere Gerätschaften am Bus hängen hat oder eben den Ebus-template-thread aufwärmen...

Hier sinnvolle Vorschläge/defaults festzulegen, geht halt nach meinen Erfahrungen mit dem ebus nicht, wenn man keine Vorstellung davon hat, was da eigentlich passiert (=alleine kann ich das nicht, es ist eigentlich weniger ein template- denn ein echtes Funktionsthema...)

Ähnliches gilt betreffend jsonMap: auch damit haben wir ja zwischenzeitlich mehr Erfahrung und eventuell mehr User, die dazu was sagen wollen bzw. für sich was geändert haben. Da die templates sich ggf. einerseits an "Umsteiger", andererseits an Einsteiger wenden, wäre natürlich was, was für "neue" "lesbare" Readingnamen generiert besonders schön, wenn man zgleich für die "Alteingesessenen" (vom Readingnamen her gedachte) "kompatible" add-ons anbieten könnte (oder das mit regex löst - das wäre aber einigermaßen/zu aufwändig...).

Besonders für das Setzen von Ziel-Temperaturen finde ich z.B. "desired-Temp" zweckmäßig - daran (bzw. bei einigen alteingesessenen weiteren Namens-Varianten) erkennt dann z.B. auch ein WeekdayTimer automatisch, dass es sich um ein Heizungsgerät handelt und man kann das iVm. weekprofile nutzen... Will heißen: _Wenn_ man seine Heizungsgeräte über diesen Mechanismus steuern will, fügt es sich mit einer passenden jsonMap direkt ein, es fühlt sich direkt und "organisch" an, weil vieles "automatisch" klappt .

[TomLee]

Und wenn man das E_09_eBus_Hc1HeatCurve+HwcTempDesired um zwei Werte erweitert, das man beide Varianten als Beispiel hat ?

Code Auswählen Erweitern

defmod MQTT2_ebusd_bai2 MQTT2_DEVICE ebusd_bai
attr MQTT2_ebusd_bai2 IODev MQTT2_Server
attr MQTT2_ebusd_bai2 event-on-change-reading .*
attr MQTT2_ebusd_bai2 group Ebus
attr MQTT2_ebusd_bai2 icon message_tendency_steady
attr MQTT2_ebusd_bai2 model E_09_eBus_Hc1HeatCurve+HwcTempDesired
attr MQTT2_ebusd_bai2 periodicCmd test:10 Z_request_Hc1_HC:30 Z_request_Hwc_desTemp:15
attr MQTT2_ebusd_bai2 readingList ebusd/700/HwcTempDesired:.* { json2nameValue($EVENT, 'HwcTempDesired_', $JSONMAP) }\
ebusd/700/Hc1HeatCurve:.* { json2nameValue($EVENT, 'Hc1HeatCurve_', $JSONMAP) }\
ebusd/700/z1DayTemp:.* { json2nameValue($EVENT, 'z1DayTemp_', $JSONMAP) }\
ebusd/700/z1NightTemp:.* { json2nameValue($EVENT, 'z1NightTemp_', $JSONMAP) }
attr MQTT2_ebusd_bai2 setList test:noArg { fhem "set MQTT2_Server publish ebusd/700/Hc1HeatCurve/get;;set MQTT2_Server publish ebusd/700/HwcTempDesired/get;;";;}\
Z_request_Hc1_HC:noArg ebusd/700/Hc1HeatCurve/get\
Z_request_Hwc_desTemp:noArg ebusd/700/HwcTempDesired/get\
Hc1HeatCurve_0_value:0.20,0.70,0.85,0.90,1.00,1.10,1.20,1.30,1.40,1.50,1.60,1.70 ebusd/700/Hc1HeatCurve/set $EVTPART1\
HwcTempDesired_tempv_value:50,51,52,53,54,55,56,57,58,59,60 ebusd/700/HwcTempDesired/set $EVTPART1\
z1DayTemp_tempv_value:20,20.5,21,21.5,22,22.5,23,23.5,24 ebusd/700/z1DayTemp/set $EVTPART1\
z1NightTemp_tempv_value:20,20.5,21,21.5,22,22.5,23,23.5,24 ebusd/700/z1NightTemp/set $EVTPART1
attr MQTT2_ebusd_bai2 webCmd Hc1HeatCurve_0_value:HwcTempDesired_tempv_value:z1DayTemp_tempv_value:z1NightTemp_tempv_value
attr MQTT2_ebusd_bai2 webCmdLabel Hc1HeatCurve:HwcTempDesired\
:Tagestemperatur:Nachttemperatur

setstate MQTT2_ebusd_bai2 HwcTempDesired_tempv_value
setstate MQTT2_ebusd_bai2 2020-04-01 18:02:38 Hc1HeatCurve_0_name
setstate MQTT2_ebusd_bai2 2020-04-01 18:02:38 Hc1HeatCurve_0_value 0.85
setstate MQTT2_ebusd_bai2 2020-04-01 18:02:39 HwcTempDesired_tempv_value 51
setstate MQTT2_ebusd_bai2 2020-04-01 18:02:37 z1DayTemp_tempv_value 21
setstate MQTT2_ebusd_bai2 2020-04-01 18:02:37 z1NightTemp_tempv_value 20

i.d.R. wird man ja mehrere Werte zum gleichen Zeitpunkt abfragen, da bläht dein Vorschlag die ReadingList doch unnötig auf ?

Wie macht man denn zwei oder mehrere publish im selben Gerät in einem ReadingList Eintrag?

[Damian]

Ich wollte im ebus-Device (MQTT2_ebusd_3.4_7328) das neue Attribut ausprobieren.

Was ist denn unter cmd gemeint?

Der Befehl zum holen von DCF-Time lautet:

Code Auswählen Erweitern

set MQTT2_FHEM_Server publish ebusd/bai/DCFTimeDate/get

Code Auswählen Erweitern

attr MQTT2_ebusd_3.4_7328 periodicCmd set MQTT2_FHEM_Server publish ebusd/bai/DCFTimeDate/get:1

wird bemängelt.

[TomLee]

Das was du vor hast müsste so klappen:

Code Auswählen Erweitern

attr MQTT2_ebusd_3.4_7328 periodicCmd DCFTimeDate:1
attr MQTT2_ebusd_3.4_7328 setList DCFTimeDate:noArg ebusd/bai/DCFTimeDate/get

[TomLee]

Das was du vor hast müsste so klappen:

Code Auswählen Erweitern

attr MQTT2_ebusd_3.4_7328 periodicCmd DCFTimeDate:1
attr MQTT2_ebusd_3.4_7328 setList DCFTimeDate:noArg ebusd/bai/DCFTimeDate/get

Zum besseren Verständnis, du kannst den setter nennen wie du willst:

Code Auswählen Erweitern

attr MQTT2_ebusd_3.4_7328 periodicCmd irgendwas:1
attr MQTT2_ebusd_3.4_7328 setList irgendwas:noArg ebusd/bai/DCFTimeDate/get

[Damian]

OK. Danke, das funktioniert zwar, ist mir ehrlich gesagt zu umständlich. Das Register muss man an drei Stellen angeben. Dann mache ich es lieber auf meine Art:

Code Auswählen Erweitern

defmod di_getebus DOIF {[+00:01];;foreach (qw(DCFTimeDate FanSpeed Flame PumpPower)) {fhem_set("MQTT2_FHEM_Server publish ebusd/bai/$_/get")}}

Hier kann ich die Liste der zu pollenden Register am Stück angeben.

[Beta-User]

@TomLee: gut erklärt!

Was die Frage angeht, wie man mehrere Publishes in einer Zeile unterbringt: Indem man es in Perl-Anweisungen verpackt und schon "zwischendurch" publisht und erst das letzte publish in die Form einer "ordentlichen Rückgabe" an MQTT2_DEVICE packt... Will sagen: ist m.E. eine Lösung, die vermutlich (fast) kein user versteht. Was spricht gegen lange Abfragelisten? (das mit diesem z-Präfix war, damit das nach hinten rutscht und nicht in den vorrangig gebrauchten optisch stört. Läuft ja automatisch, wir brauchen nur einen "Aufhänger"...)

Man könnte auch mit Wildcards (insbesondere "+") arbeiten, aber da ist der ebus "empfindlich..." Würde ich in diesem speziellen Fall nur mit "Bauchweh" gehen wollen. (@Damian: Falls dich das näher interessiert, gibt es einen Thread zu den Templates, die den ebus betreffen, an dem auch der Autor von ebusd ein paar technische Hintergründe erläutert hat, was man so machen sollte und was nicht. Das ist alles "etwas speziell", aber das DOIF sollte ok sein).

@TomLee:
Was aber m.E. die Übersichtlichkeit verbessern würde, wären evtl. Widgets und "lesbare" Readingnamen:

Code Auswählen Erweitern


dayTemp:selectnumbers:20,0.5,24,1,lin ebusd/700/z1DayTemp/set $EVTPART1\desired-Temp:selectnumbers:50,1,70,1,lin...
Wenn man dann dazu nur das via webCmd anzeigt, was wirklich durch den user zu bedienen sein soll, ist doch gut, oder?

Aber wie an anderer Stelle schon gesagt: letztlich kann man viel machen, die Frage ist, was "sinnvoll" ist, was man direkt im MQTT2-Device abbilden will, und was an anderer Stelle. Ich habe da nur ein sehr grobes Gefühl von der damaligen "Spielwiese" mitgenommen und will "euch" da letztlich nicht reinreden, sondern nur meine zwischenzeitlichen Erfahrung aus anderen Baustellen mitteilen...

@Damian: Das Ziel sollte eigentlich sein, dass man direkt via attrTemplate ein MQTT2_DEVICE konfiguriert erhält, über das man gar nicht mehr groß nachdenken muß, weil es schon die Basisfunktionalität _des jeweiligen Teilbereichs, den man tatsächlich hat_ "automatisch" mit abbildet...

Sonst kann man auch einfach nur das at nehmen, das wir bisher hatten...

Aber wie immer: viele Wege im FHEM es gibt .

[Damian]

Ja, die Sache mit den Templates habe ich schon studiert. Bevor ich aber Templates erstelle, will ich mir erst mal klar machen, was mit meiner neuen Therme geht und was nicht. Ich werde allerdings das untere DOIF-Device erweitern, denn es soll nicht nur pollen, sondern auch die Therme steuern und entsprechende Informationen der Therme mit den neuen SVG-Widgets (https://forum.fhem.de/index.php/topic,106059.msg1037209.html#msg1037209) visualisieren.

[Beta-User]

Klar, mach ruhig, Konkurrenz belebt das Geschäft... .

Wollte nur auch mit dem Hinweis auf die technischen Restriktionen verhindern, dass du dir allzu oft den Bus abschießt oder Unmengen an unnützen/leeren Daten abfragst; das geht nämlich auf dem MQTT-Weg schneller, als man denkt . (Jedenfalls, wenn ich John (?) da (noch) richtig verstanden habe *lach*).

[Damian]

Klar, mach ruhig, Konkurrenz belebt das Geschäft... .

Wollte nur auch mit dem Hinweis auf die technischen Restriktionen verhindern, dass du dir allzu oft den Bus abschießt oder Unmengen an unnützen/leeren Daten abfragst; das geht nämlich auf dem MQTT-Weg schneller, als man denkt . (Jedenfalls, wenn ich John (?) da (noch) richtig verstanden habe *lach*).

ja, da muss ich schauen was und wie oft ich etwas abfragen will. Ich will auch die Zeitprofile der Therme anhand der holiday-Datei setzen, denn die kann gerade mal Wochentage unterscheiden

[Beta-User]

  Das mit den starren Wochenprofilen und die ungenaue Uhr sind auch zwei so Themen, die mir bei meiner Therme sauer aufstoßen - aber für die ich bekomme nicht mal die Hardwareschnittstelle gebacken (Junkers Heatronic) ...

Was das Thema Übersteuern des "harten" Wochenprofils bei $we angeht, hätte ich ein paar Ideen. Interesse?

[Damian]

Danke für´s Angebot, aber ich habe schon meine Lösungen für Wochentagprofile und das Setzen eines Profils ist bei meiner Therme, wie ich gestern herausgefunden habe, auch ganz einfach:

Code Auswählen Erweitern

{fhem"set MQTT2_FHEM_Server publish ebusd/700/z1Timer.Monday/set 05:30;09:00;13:00;22:00;-:-;-:-"}

[Beta-User]

Klar ist der Teil - dieses winzige Bausteinchen - einfach, aber das war gar nicht die Frage...

Die eigentliche Frage ist mMn.: wie bindet man das auf einfache Weise ins Gesamtsystem ein, denn auch die Thermostate sollten dazu ja synchron laufen (was kein Thema ist, wenn man eine FB-Heizung hat, aber eben sonst...)

Klar kann da auch wieder jeder "seine" Lösung basteln, aber das empfinde ich als suboptimal.

Vielleicht sollte ich meine eigentliche Frage an dich anders formulieren:
Wollen wir zu viert (neben TomLee bräuchten wir mind. noch einen weiteren konkreten Maintainer) eine Lösung entwickeln, die generischer Natur ist, (möglichst auch für andere MQTT2_DEVICE-Geräte als speziell das Ebus-Ding funktioniert) und im Ergebnis für alle User simple Mechanismen bereitstellt, alles synchron zu halten?

[Damian]

So, die erste Visualisierung der Temperaturen aus der Therme, sieht bei mir jetzt so aus.