Hallo zusammen,
ich habe heute meinen ebus-Adapter bekommen. Inzwischen funktioniert auch alles so weit. Was mir noch fehlt ist die Syntax zum Setzen von Werten.
mit
ebusctl w -c 700 z1NightTemp 18
Kann ich die Nachtabsenkung setzen.
Das Auslesen des Wertes mit
set MQTT2_FHEM_Server publish ebusd/bai/z1NightTemp/get z1NightTemp
klappt.
Der Versuch:
set MQTT2_FHEM_Server publish ebusd/bai/z1NightTemp/set -c 700 z1NightTemp 18
scheint aber nicht erfolgreich zu sein.
ebusd/700/z1NightTemp/set 18
Wenn das sonstwie noch weiterhilft, hier meine bisherige MQTT2_DEVICE Definition:
defmod MQTT2_ebusd_bai MQTT2_DEVICE ebusd_bai
attr MQTT2_ebusd_bai IODev MQTT2_Server
attr MQTT2_ebusd_bai devStateIcon {"<div> <span>Vorlauf:</span><br><span>".FW_makeImage('sani_supply_temp@#'.substr(Color::pahColor(30,55,80,ReadingsVal($name,"1_Vorlauf",0),0),0,6).'')."</span> <span> ;".sprintf("%.2f \°C",ReadingsNum($name,'1_Vorlauf',0))."</span> <span>(Soll ; ;".sprintf("%.2f \°C",ReadingsNum($name,'SetMode_flowtempdesired_value',0)).")</span><br> <span>Warmwasser:</span><br> <span>".FW_makeImage('sani_water_hot@#'.substr(Color::pahColor(45,48,55,ReadingsVal($name,"1_Warmwassertemperatur",0),0),0,6).'')."</span> <span> ;".sprintf("%.2f \°C",ReadingsNum($name,'1_Warmwassertemperatur',0))."</span> <span>(Soll ;" .sprintf("%.2f \°C",ReadingsNum($name,'SetMode_hwctempdesired_value',0)).")</span> <br> <span>Aussen:</span><br> <span>".FW_makeImage('temp_outside@#'.substr(Color::pahColor(-10,15,40,ReadingsVal($name,"corrected_OutsideTemp",0),0),0,6).'')."</span> <span> ;".sprintf("%.2f \°C",ReadingsNum($name,'corrected_OutsideTemp',0))."</span><br> <span>Druck:</span><br><span>".FW_makeImage('weather_barometric_pressure@#'.substr(Color::pahColor(1.6,2.1,2.6,ReadingsVal($name,"WaterPressure",0),0),0,6).'')."</span> <span> ;".sprintf("%.2f \ bar",ReadingsNum($name,'WaterPressure',0))."</span></div>"}
attr MQTT2_ebusd_bai devStateStyle style="text-align:left"
attr MQTT2_ebusd_bai event-on-change-reading .*
attr MQTT2_ebusd_bai group Ebus
attr MQTT2_ebusd_bai jsonMap Status01_0_value:1_Vorlauf Status01_0_name:0 Status01_1_value:1_Ruecklauf Status01_1_name:0 Status01_2_value:1_Aussentemperatur Status01_2_name:0 Status01_3_value:0 Status01_3_name:0 Status01_4_value:1_Warmwassertemperatur Status01_4_name:0 Status01_5_value:1_Pumpe Status01_5_name:0 HwcStarts_0_name:0 HwcStarts_0_value:HwcStarts FanSpeed_0_name:0 FanSpeed_0_value:FanSpeed WaterPressure_press_value:WaterPressure WaterPressure_sensor_value:0 DateTime_bdate_value:0 DateTime_btime_value:0 DateTime_dcfstate_value:0 DateTime_temp2_value:0 outsidetemp_temp2_value:0\
HwcTempDesired_tempv_value:HwcTempDesired\
z1DayTemp_tempv_value:z1DayTemp\
z1NightTemp_tempv_value:z1NightTemp\
ccTimer.Saturday_0_name:0 ccTimer.Saturday_0_value:ccTimer.Saturday_from\
ccTimer.Saturday_1_name:0 ccTimer.Saturday_1_value:ccTimer.Saturday_to\
error_error_value:error\
DisplayedOutsideTemp_tempv_value:corrected_OutsideTemp\
CounterStartAttempts3_temp0_value:Zuendfehler_3\
Hc1HeatCurve_0_name:0 Hc1HeatCurve_0_value:Hc1Heizkurve\
CounterStartAttempts4_temp0_value:Zuendfehler_4\
CounterStartattempts1_temp0_value:Zuendfehler_1\
CounterStartattempts2_temp0_value:Zuendfehler_2\
FlowHysteresisON_temp_value:FlowHysteresisON\
FlowHysteresisOff_temp_value:FlowHysteresisOff
attr MQTT2_ebusd_bai readingList ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }\
ebusd/bai/WaterPressure:.* { json2nameValue($EVENT, 'WaterPressure_', $JSONMAP) }\
ebusd/bai/FlowTemp:.* { json2nameValue($EVENT, 'FlowTemp_', $JSONMAP) }\
ebusd/bai/FanSpeed:.* { json2nameValue($EVENT, 'FanSpeed_', $JSONMAP) }\
ebusd/bai/Status02:.* { json2nameValue($EVENT, 'Status02_', $JSONMAP) }\
ebusd/bai/FanHours:.* { json2nameValue($EVENT, 'FanHours_', $JSONMAP) }\
ebusd/bai/HcHours:.* { json2nameValue($EVENT, 'HcHours_', $JSONMAP) }\
ebusd/bai/HwcHours:.* { json2nameValue($EVENT, 'HwcHours_', $JSONMAP) }\
ebusd/bai/HwcStarts:.* { json2nameValue($EVENT, 'HwcStarts_', $JSONMAP) }\
ebusd/bai/SetMode:.* { json2nameValue($EVENT, 'SetMode_', $JSONMAP) }\
ebusd/broadcast/vdatetime:.* { json2nameValue($EVENT, 'vdatetime_', $JSONMAP) }\
ebusd/bai/DateTime:.* { json2nameValue($EVENT, 'DateTime_', $JSONMAP) }\
ebusd/broadcast/outsidetemp:.* { json2nameValue($EVENT, 'outsidetemp_', $JSONMAP) }\
ebusd/700/Hc1HeatCurve:.* { json2nameValue($EVENT, 'Hc1HeatCurve_', $JSONMAP) }\
ebusd/700/HwcTempDesired:.* { json2nameValue($EVENT, 'HwcTempDesired_', $JSONMAP) }\
ebusd/bai/RemainingBoilerblocktime:.* { json2nameValue($EVENT, 'RemainingBoilerblocktime_', $JSONMAP) }\
ebusd/bai/HcStarts:.* { json2nameValue($EVENT, 'HcStarts_', $JSONMAP) }\
ebusd/700/ccTimer\.Saturday:.* { json2nameValue($EVENT, 'ccTimer.Saturday_', $JSONMAP) }\
ebusd/700/z1DayTemp:.* { json2nameValue($EVENT, 'z1DayTemp_', $JSONMAP) }\
ebusd/700/z1NightTemp:.* { json2nameValue($EVENT, 'z1NightTemp_', $JSONMAP) }\
ebusd/broadcast/error:.* { json2nameValue($EVENT, 'error_', $JSONMAP) }\
ebusd/bai/StorageTempDesired:.* { json2nameValue($EVENT, 'StorageTempDesired_', $JSONMAP) }\
ebusd/700/DisplayedOutsideTemp:.* { json2nameValue($EVENT, 'DisplayedOutsideTemp_', $JSONMAP) }\
ebusd/bai/CounterStartattempts1:.* { json2nameValue($EVENT, 'CounterStartattempts1_', $JSONMAP) }\
ebusd/bai/CounterStartattempts2:.* { json2nameValue($EVENT, 'CounterStartattempts2_', $JSONMAP) }\
ebusd/bai/CounterStartAttempts3:.* { json2nameValue($EVENT, 'CounterStartAttempts3_', $JSONMAP) }\
ebusd/bai/CounterStartAttempts4:.* { json2nameValue($EVENT, 'CounterStartAttempts4_', $JSONMAP) }\
ebusd/bai/StatusCirPump:.* { json2nameValue($EVENT, 'StatusCirPump_', $JSONMAP) }\
ebusd/bai/FlowHysteresisON:.* { json2nameValue($EVENT, 'FlowHysteresisON_', $JSONMAP) }\
ebusd/bai/FlowHysteresisOff:.* { json2nameValue($EVENT, 'FlowHysteresisOff_', $JSONMAP) }
attr MQTT2_ebusd_bai room Ebus,MQTT2_DEVICE
attr MQTT2_ebusd_bai setList Hc1Heizkurve:0.7,0.75,0.8,0.85,0.9,0.95,1,1.05,1.1,1.15,1.2,1.25,1.3,1.35,1.4,1.45,1.5,1.55,1.6,1.65,1.7,1.75,1.8,1.85,1.9,1.95,2.0,2.05,2.1,2.15,2.2,2.3,2,45,2,5 ebusd/700/Hc1HeatCurve/set $EVTPART1\
HwcTempDesired:50,51,52,53,54,55,56,57,58,59,60 ebusd/700/HwcTempDesired/set $EVTPART1\
z1DayTemp:20,20.5,21,21.5,22,22.5,23,23.5,24 ebusd/700/z1DayTemp/set $EVTPART1\
z1NightTemp:20,20.5,21,21.5,22,22.5,23,23.5,24 ebusd/700/z1NightTemp/set $EVTPART1\
Hc1MinFlowTempDesired:25,26,27,28,29,30 ebusd/700/Hc1MinFlowTempDesired/set $EVTPART1\
FlowHysteresisON:-1.00,-2.00,-3.00,-4.00,-5.00,-6.00,-7.00,-8.00,-9.00,-10.00 ebusd/700/FlowHysteresisON/set $EVTPART1\
FlowHysteresisOff:1.00,2.00,3.00,4.00,5.00,6.00,7.00,8.00,9.00,10.00 ebusd/700/FlowHysteresisOff/set $EVTPART1
attr MQTT2_ebusd_bai webCmd Hc1Heizkurve:HwcTempDesired:z1DayTemp:z1NightTemp:FlowHysteresisON:FlowHysteresisOff
attr MQTT2_ebusd_bai webCmdLabel Heizkurve :;:Warmwasser\
:Tagestemperatur:Nachttemperatur\
:FlowHysteresisON:FlowHysteresisOff
Gruß
Thomas
Im mqtt2.attrtemplate gibt es ein ebusd bridge. Nachdem man dieses Template anwendet, kriegt man weitere ebus-spezifische Templates heruntergeladen, samt Hilfscode verpackt in einem 99_attrTmqtt2_ebus_Utils.pm
Sonst: beim Setzen der Werte kann man etwas "schummeln", indem man die subscribe Internals anschaut: "list TYPE=MQTT2_SERVER subscriptions"
Danke euch für die schnellen Antworten.
Der Fehler war tatsächlich der Pfad.
mit
ebusd/700/z1NightTemp/set 18
klappt es schon, da es ein vcr 700-Register und kein bai-Register ist.
Auch die MQTT_Device Definition funktioniert bei mir.
Da wir offensichtlich die gleiche Therme haben, können wir uns hier gut austauschen. Meine Vaillant ecoCOMPACT läuft erst seit einer Woche und ist schon in FHEM integriert, bei meiner alten hat es 10 Jahre gedauert ;)
An die ReadingList gar nicht erst gewöhnen und gleich mit hashKeyRename (https://forum.fhem.de/index.php/topic,109430.msg1034185.html#msg1034185) definieren.
Hat bisher nur keinen interessiert, die Templates sind vor dieser Zeit
Zitat von: TomLee am 30 März 2020, 22:34:55
An die ReadingList gar nicht erst gewöhnen und gleich mit hashKeyRename (https://forum.fhem.de/index.php/topic,109430.msg1034185.html#msg1034185) definieren.
Hat bisher nur keinen interessiert, die Templates sind vor dieser Zeit
ja, ich werde ohnehin für mich was basteln, da die Templates nicht so richtig zu meiner Therme passen. Auch die Visualisierung will ich selbst gestalten.
@rudi Ich frage mich, ob es nicht sinnvoll wäre im mqtt-Device eine zyklische Abfrage optional einzubauen.
Wenn das ein "common problem" ist, wieso nicht.
Sobald aber mehr als ein Zyklus oder mehr als ein Befehl ist, was man absetzen will, dann wird mir das zu bunt, dafuer gibt es extra Module.
Zitat von: rudolfkoenig am 30 März 2020, 22:47:53
Wenn das ein "common problem" ist, wieso nicht.
Sobald aber mehr als ein Zyklus oder mehr als ein Befehl ist, was man absetzen will, dann wird mir das zu bunt, dafuer gibt es extra Module.
Klar gibt es dafür Module (ich kennen mindesten zwei, die häufig benutzt werden ;) ). Es fiel mir gerade auf, dass beim ebus Abfragen vonnöten sind sowie beim verlinken corona-Beispiel.
z. B. attr cycle 300:.*
Was genau soll das senden? Alle moeglichen set Befehle?
Corona zaehlt nicht, ist kein MQTT, da ist ein at, was die Untat produziert.
Zitat von: rudolfkoenig am 30 März 2020, 23:04:42
Was genau soll das senden? Alle moeglichen set Befehle?
Corona zaehlt nicht, ist kein MQTT, da ist ein at, was die Untat produziert.
OK. So genau habe ich mir das Corona-Beispiel nicht angeschaut.
Für ebus als mqtt-Device würde es bedeuten:
alle 300 Sekunden get-Befehl an alle zu Regex passenden Readinglist-Einträgen des mqtt-Devices senden.
Ob das allerdings sinnvoll ist oder überhaupt allgemein gültig, kann ich nicht beurteilen, dafür habe ich zu wenig mqtt-Devices - war nur eine Blitz-Idee.
Kurzfassung:
Fände sowas gut. "getPeriodic"?
Abfragbar, was in getList steht, Syntax z.B. Readingname1:Periode1 Readingname2:Periode2
Hätte z.B. auch für das abgebrochene BT-Thermostat Sinn gemacht...
Weiss nicht, warum wir es auf get begrenzen sollten, und mit Readingname konnte ich nichts anfangen, sorry.
Deswegen habe ich Folgendes eingebaut, hoffentlich nicht sinnlos :)
ZitatperiodicCmd <cmd1>:<period1> <cmd2>:<period2>...
periodically execute the get or set command. The command will not take any arguments, create a new command without argument, if necessary. period is measured in minutes, and it must be an integer.
:) ;D Da hast du meine unsortierten Gedanken aber schneller erraten als ich selbst, chapeau...
Vielleicht noch eine Anmerkung zu den "minutes": Mir kommt das "an sich" minutenweise ok, aber ich bin gespannt, wann der erste Anwender aufschlägt, der einfach mal davon ausgegangen ist, dass es "wie überall sonst üblich" ein Sekundenwert hätte sein sein müssen und er unbedingt 30 Sek. (oder 90) "braucht" ;D ...
Zwei Aspekte dazu noch:
- Irgendwie war mein gedanklicher Ausgangspunkt die Abfrage von Werten vom Bus (weniger vom Setzen der Uhrzeit wie in dem anderen Thread), und daher war ich geneigt, sowas nach "get" zu verlagern. Das ist - zugegebenermaßen mal wieder eher aus Anwenderperspektive gedacht - eher was, was dahin gehört. Nachdem ich zufällig gestern wieder über diese alten Diskussionen zu hm "gestolpert" bin, verstehe ich zwar von Entwicklerseite her etwas besser, warum das grade bei HM, aber auch anderswo tendenziell (gefühlt) sehr "krude" ist, was in Readings, Attributen und Internals wiederzufinden ist - das ist aber wohl nicht ganz auf HM beschränkt.
- Unter technischen Gesichtspunkten scheint es so zu sein, dass auf "get" modulseitig eine Antwort folgen sollte, die dann auch für den caller als solche erkennbar ist und zu einer entsprechenden Anzeige, z.B. in FHEMWEB führen kann. Habe ich zwar jetzt etwas besser "verstanden", aber "erklären" könnte ich das keinem "normalen User" so richtig...
Aber da wir grade in dem Zusammenhang bei MQTT2_DEVICE und InternalTimer&Co sind: Der zigbee2mqtt-Dienst braucht (nach meinen länger zurückliegenden Erfahrungen) etwas länger als FHEM warten will, man bekommt also "verfrüht" die Meldung, dass die Anforderung nicht geklappt hätte. Ist nur ein Schönheitsfehlerchen, aber evtl. ist der Timeout konfigurierbar? (z.B. mit einer ":Sekunden"-Angabe hinter der Angabe des Readingnamens, auf das die Antwort passen soll, (falls ich die Code-Zusammenhänge jetzt aus dem Kopf richtig und verständlich zusammengebastelt habe)).
@TomLee:
Da es hier sowieso um ebus zu gehen scheint und das auch "der" momentane Paradeanwendungsfall für "periodicCmd" wäre: Magst du das in die betr. attrTemplate einarbeiten? Damit müßten wir doch eigentlich wesentlich "trennschärfer" sein können wie mit dem Muster-"at", weil man die jeweiligen Anfragen direkt zu den Subsystemen auf dem Bus "pappen" könnte...
Wenn die Antwort auf get lange dauert, dann sollte es als "set requestXXX" implementiert werden.
Und wem Minuten zu ungenau sind, der darf ein at/DOIF/etc aufsetzen.
Ich will das Ding einfach halten, und es nicht zu einem zweiten at ausbauen.
Hab mich ehrlich gesagt ewig nicht mehr mit den ebus-Templates beschäftigt und mag ich zur Zeit auch gar nicht, sonst wäre meine erste Frage dazu wie ich die ReadingList nun mit hashKeyRename korrekt anpasse. Interessiert mich aktuell aber nicht.
Hab mir die mqtt2.ebus.template unter trunk/fhem/contrib/AttrTemplate aber mal angeschaut.
Das betrifft eigentlich ja nur:
eBus_4xx_devStateIcon_HeatCurve_HwcTemp
eBus_430_devStateIcon_Pump_Fan_HeatCurve_HwcTemp
eBus_Hc1HeatCurve+HwcTempDesired
Alle anderen beziehen sich doch auf Broadcast Werte .
In den 3 Templates sind nur Beispiele zu HwcTempDesired und Hc1HeatCurve.
Diese müsste man dann doch eigentlich nur erweitern um so was in der Art:
par:IODEVNAME;Name of the IO-Device; { AttrVal("DEVICE","IODev",undef) }
attr DEVICE periodicCmd test:3
attr DEVICE setList test:noArg { fhem "set IODEVNAME publish ebusd/700/Hc1HeatCurve/get;set IODEVNAME publish ebusd/700/HwcTempDesired/get;";}
Oder versteh ich was falsch ?
Achso und wenn man kein jsonMap verwendet dann sehen die Readings so aus und nicht wie in den 3 angesprochenen Templates:
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
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:
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 :) .
Und wenn man das E_09_eBus_Hc1HeatCurve+HwcTempDesired um zwei Werte erweitert, das man beide Varianten als Beispiel hat ?
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?
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:
set MQTT2_FHEM_Server publish ebusd/bai/DCFTimeDate/get
attr MQTT2_ebusd_3.4_7328 periodicCmd set MQTT2_FHEM_Server publish ebusd/bai/DCFTimeDate/get:1
wird bemängelt.
Das was du vor hast müsste so klappen:
attr MQTT2_ebusd_3.4_7328 periodicCmd DCFTimeDate:1
attr MQTT2_ebusd_3.4_7328 setList DCFTimeDate:noArg ebusd/bai/DCFTimeDate/get
Zitat von: TomLee am 01 April 2020, 20:53:32
Das was du vor hast müsste so klappen:
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:
attr MQTT2_ebusd_3.4_7328 periodicCmd irgendwas:1
attr MQTT2_ebusd_3.4_7328 setList irgendwas:noArg ebusd/bai/DCFTimeDate/get
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:
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.
@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:
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 ;) .
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.
Klar, mach ruhig, Konkurrenz belebt das Geschäft... ;D .
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*).
Zitat von: Beta-User am 01 April 2020, 22:21:26
Klar, mach ruhig, Konkurrenz belebt das Geschäft... ;D .
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 ;)
;D 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?
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:
{fhem"set MQTT2_FHEM_Server publish ebusd/700/z1Timer.Monday/set 05:30;09:00;13:00;22:00;-:-;-:-"}
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?
So, die erste Visualisierung der Temperaturen aus der Therme, sieht bei mir jetzt so aus.
looks nice!
Btw.: verwendest du eigentlich auch eine generalisierte Fassung des Color-Farbverlaufs aus dem Wiki?
(in dem attrTemplate-Paket ist sowas auch in einer myUtils versteckt). Ist zwar nix großes, aber wir könnten justme1968 fragen, ob er das in Color.pm reinbasteln kann...
Die Farbverläufe habe ich selbst gebastelt. Ich habe mich dabei an Windy.com etwas orientiert.
Hier mal eine kompakte Darstellung.