Werte per MQTT setzen

[Damian]

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

Code Auswählen Erweitern

ebusctl w -c 700 z1NightTemp 18

Kann ich die Nachtabsenkung setzen.

Das Auslesen des Wertes mit

Code Auswählen Erweitern

set MQTT2_FHEM_Server publish ebusd/bai/z1NightTemp/get z1NightTemp

klappt.

Der Versuch:

Code Auswählen Erweitern

set MQTT2_FHEM_Server publish ebusd/bai/z1NightTemp/set -c 700 z1NightTemp 18

scheint aber nicht erfolgreich zu sein.

[TomLee]

Code Auswählen Erweitern

ebusd/700/z1NightTemp/set 18

Wenn das sonstwie noch weiterhilft, hier meine bisherige MQTT2_DEVICE Definition:

Code Auswählen Erweitern

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>&nbsp;;".sprintf("%.2f \°C",ReadingsNum($name,'1_Vorlauf',0))."</span> <span>(Soll&nbsp;;&nbsp;;".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>&nbsp;;".sprintf("%.2f \°C",ReadingsNum($name,'1_Warmwassertemperatur',0))."</span> <span>(Soll&nbsp;;" .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>&nbsp;;".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>&nbsp;;".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

[rudolfkoenig]

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"

[Damian]

Danke euch für die schnellen Antworten.

Der Fehler war tatsächlich der Pfad.

mit

Code Auswählen Erweitern

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

[TomLee]

An die ReadingList gar nicht erst gewöhnen und gleich mit hashKeyRename definieren.

Hat bisher nur keinen interessiert, die Templates sind vor dieser Zeit

[Damian]

An die ReadingList gar nicht erst gewöhnen und gleich mit hashKeyRename 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.

[rudolfkoenig]

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.

[Damian]

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:.*

[rudolfkoenig]

Was genau soll das senden? Alle moeglichen set Befehle?
Corona zaehlt nicht, ist kein MQTT, da ist ein at, was die Untat produziert.

[Damian]

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.

[Beta-User]

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...

[rudolfkoenig]

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

periodicCmd <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.

[Beta-User]

  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" ...

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...

[rudolfkoenig]

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.

[TomLee]

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern


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 ?