ebusd.mqtt2.template: Fragen, Anregungen

TomLee · 28 Februar 2019, 17:04:14

Hallo,

mit Reinharts Beispiel-Templates hatte ich vor 2 Wochen gespielt und konnte auch die WW-Temperatur setzen.

Jetzt versuche ich das in meinem u.a. Device umzusetzen, das temp1_value wie in Reinharts Beispiel mein ich ist bei mir das
SetMode_hwctempdesired_value, das setzen klappt aber nicht.

Kann mir da wer weiterhelfen ?

Zitatdefmod MQTT2_Test_Ebusd MQTT2_DEVICE
attr MQTT2_Test_Ebusd IODev MQTT2_CLIENT
attr MQTT2_Test_Ebusd bridgeRegexp ([A-Za-z0-9]*)/([A-Za-z0-9]*).*:.* "$1_$2"
attr MQTT2_Test_Ebusd devStateStyle style="text-align:right"
attr MQTT2_Test_Ebusd event-on-change-reading .*
attr MQTT2_Test_Ebusd icon icoTempHeizung
attr MQTT2_Test_Ebusd jsonMap Status01_0_value:1_Vorlauf Status01_0_name:0 Status01_1_value:1_Ruecklauf Status01_1_name:0 Status01_2_value:1_OutdoorstempSensor Status01_2_name:0 Status01_3_value:Fragez Status01_3_name:0 Status01_4_value:1_HwctempSensor Status01_4_name:0 Status01_5_value:1_Pumpe Status01_5_name:0 WaterPressure_press_value:WaterPressure WaterPressure_sensor_value:0 FlowTempDesired_temp_value:FlowTempDesired CirPump_onoff_value:CirPump Hc1HeatCurve_0_name:0 Hc1HeatCurve_0_value:HeatCurve z1DayTemp_tempv_value:z1DayTemp
attr MQTT2_Test_Ebusd model E_04a_eBus_Test_Status01+SetMode+WaterPressure+CirPump+Hc1HeatCurve+z1DayTemp
attr MQTT2_Test_Ebusd readingList ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }\
ebusd/bai/SetMode:.* { json2nameValue($EVENT, 'SetMode_', $JSONMAP) }\
ebusd/bai/WaterPressure:.* { json2nameValue($EVENT, 'WaterPressure_', $JSONMAP) }\
ebusd/700/Hc1HeatCurve:.* { json2nameValue($EVENT, 'Hc1HeatCurve_', $JSONMAP) }\
ebusd/700/z1DayTemp:.* { json2nameValue($EVENT, 'z1DayTemp_', $JSONMAP) }\
ebusd/bai/CirPump:.* { json2nameValue($EVENT, 'CirPump_', $JSONMAP) }
attr MQTT2_Test_Ebusd setList SetMode_hwctempdesired_value:50.0,51.0,52.0,53.0,54.0,55.0,56.0,57.0,58.0,59.0,60.0 ebusd/bai/HwcTempDesired/set $EVTPART1
attr MQTT2_Test_Ebusd stateFormat {sprintf("Vorlauf: %.1f Ruecklauf: %.1f WW-Temperatur: %.1f Aussentemperatur.: %.1f Pumpe: %s Fragez: %.1f Druck: %.1f WW-Set: %s Zirk.pumpe: %s", ReadingsVal($name,"1_Vorlauf",0), ReadingsVal($name,"1_Ruecklauf",0), ReadingsVal($name,"1_HwctempSensor",0),ReadingsVal($name,"1_OutdoorstempSensor",0), ReadingsVal($name,"1_Pumpe",0), ReadingsVal($name,"Fragez",0), ReadingsVal($name,"WaterPressure",0), ReadingsVal($name,"FlowTempDesired",0), ReadingsVal($name,"CirPump",0))}
attr MQTT2_Test_Ebusd webCmd SetMode_hwctempdesired_value
attr MQTT2_Test_Ebusd webCmdLabel WW-Set

setstate MQTT2_Test_Ebusd Vorlauf: 66.0 Ruecklauf: 0.0 WW-Temperatur: 51.0 Aussentemperatur.: 20.4 Pumpe: off Fragez: 0.0 Druck: 2.4 WW-Set: 0 Zirk.pumpe: off
setstate MQTT2_Test_Ebusd 2019-02-28 16:33:26 1_HwctempSensor 51.0
setstate MQTT2_Test_Ebusd 2019-02-28 16:33:26 1_OutdoorstempSensor 20.438
setstate MQTT2_Test_Ebusd 2019-02-28 16:33:26 1_Pumpe off
setstate MQTT2_Test_Ebusd 2019-02-28 16:33:26 1_Vorlauf 66.0
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:42 CirPump off
setstate MQTT2_Test_Ebusd 2019-02-28 16:33:26 Fragez 0.0
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 HeatCurve 2.05
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 SetMode_disablehc_value 1
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 SetMode_disablehwcload_value 0
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 SetMode_disablehwctapping_value 0
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 SetMode_flowtempdesired_value 0.0
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 SetMode_hcmode_value auto
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 SetMode_hwctempdesired_value 55.0
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 SetMode_releaseBackup_value 0
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 SetMode_releaseCooling_value 0
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 SetMode_remoteControlHcPump_value 0
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 WaterPressure 2.372
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 z1DayTemp 22

Gruß

Thomas

Beta-User · 28 Februar 2019, 17:35:00

Hi Thomas,

leider habe ich nicht die große Ahnung vom ebusd und von den templates dafür, würde aber gerne auch ein oder zwei Beispiele aus eurem template-file in die allgemeinen Templates übernehmen; der ebusd scheint im Moment der einzige Fall zu sein, bei dem das JSONMAP seine volle Wirkung zeigen kann

.

Vielleicht vorab zwei Dinge:
- ich verstehe nicht ganz, für was die bridgeRegexp in dem ebus-Device sinnvoll ist. M.E. macht eine solche zwar großen Sinn, wenn man einen externen Broker nutzt, aber dann als separates Device (ein template dafür habe ich vor nicht allzu langer Zeit aufgenommen und die Praxisbeispiele entsprechend ergänzt. Das ist m.E. aber gar nicht erforderlich, wenn man den MQTT2_SERVER nutzt und sollte daher nicht Teil eines Geräts oder templates für ebusd sein).
Vorschlag (bitte config vorher mal zur Sicherheit als Kopie wegspeichern): Ein beliebiges MQTT2_DEVICE kopieren, und auf das dann das allg. Bridge-template anwenden (für Nutzer des MQTT2_CLIENT). Und dann diesen Teil aus dem ebusd-Gerät entfernen.

- v.a. wenn einzelne Dinge nicht erwartungsgemäß funktionieren, macht es m.E. immer Sinn, die Optionen im IO-Device zu nutzen.
Konkret hieße das hier:
-- An deinem MQTT2_CLIENT-Gerät das rawEvents-Attribut setzen und dann mal den Verkehr in einem separaten EVENT-Monitor mit Begrenzung auf dieses IO beobachten.
-- Darüber kann man dann auch den set-Befehl mit einem direkten publish mal testen. Geht der raus wie gedacht, hat aber keine Auswirkung, liegt es entweder am Zielgerät, dem Übertragungsweg dahin oder der Syntax. Damit würde ich hier mal anfangen.

Dann hätte ich noch eine Bitte: der ebusd-Thread ist ziemlich unübersichtlich. Ist das template von Reinhart in seinem ersten Thread jetzt eigentlich die beste Basis, oder hast du da noch weitere Anpassungen gemacht, die du gut findest?
Zunächst wäre es hilfreich, wenn wir eine Art Basis-Template hätten, das für alle Arten von ebusd-Nutzern hilfreich sein könnte.

Hoffe, das hilft erst mal weiter und ist (halbwegs) versändlich geschrieben.

Gruß, Beta-User

Reinhart · 28 Februar 2019, 21:56:05

Zunächst einmal danke das uns Beta-User seine Unterstützung zur Entwicklung von eBus Templates anbietet! Er hat auch schnell erkannt, das der eBus die ideale Spielwiese für diese von Rudi entwickelte Technologie ist.

Ich habe ja vor einigen Woche dieses Beispiel-Template in den eBus Thread gestellt und gehofft das Thema MQTT2 etwas zu forcieren weil ich glaube das MQTT generell hohes Potential hat. Was bei ESP8266 schon lange Standard ist kann auch eBusd schon lange, John hat dafür schon vorgesorgt. Mir ist schon klar, das gerade Neueinsteiger lieber alte Wiki Einträge benutzen als sich jetzt auch noch mit MQTT oder gar Mosquitto auseinander zu setzen. Wieder was installieren, ohjeh!
Aber eigentlich ist es das Gegenteil, hoher Komfort wie ihn sonst nur GAEBUS bietet ist damit möglich und das mit einem Protokoll das von vielen SmartHome Umgebungen gesprochen wir.

Aber ich glaube wir sollten bevor wir die Unterstützung von Beta-User benutzen wollen, zunächst das Ziel von eBusd Templates festlegen zu versuchen. Ich habe ja bei den ersten Beispielen bewusst nur jene Datenpunkte ausgewählt, wo ich glaube das diese Datenpunkte bei einer großen Anzahl von Geräten vorkommen.

Beispiel: wer nur ein Brennwertgerät hat wird auch keine Heizkurve setzen können. Wer eine reine Therme hat wird auch keinen Warmwasserkessel haben. Daher ergeben sich aus solchen Vorgaben schon die Art der einzeln benötigten Templates.

Ich finde wir sollten daher zuerst eine Art Bestandsaufnahme durchführen um überhaupt die Art und Menge der benötigten Templates einmal grob zu definieren. Bei den Templates geht es ja in erster Linie um die Ausgabe (printf) am Display und die kann sich aus verschiedenen Variablen zusammen setzen. Je mehr Variablen und mehr Automatismus enthalten ist, desto vielfältiger läßt sich so ein Template dann einsetzen.
Schön wäre ohnehin ein einziges Template das alles kann, doch wer will einen Wulst von Daten in einem Reading? Dann doch lieber eine Unterteilung die logisch Sinn macht und darüber sollten wir uns hier abstimmen zu versuchen.
Dazu ist natürlich die Mitarbeit von möglichst vielen Anwendern gefragt, jeder hat andere Wünsche oder Ideen.

Ich stelle daher einmal die generelle Frage, sollten wir die Templates nach dem Typ der Datenpunkte (Warmwasser, Heizkurve, Datum, Zeit etc.) oder eher nach der Art der Heizgeräte Hardware (zB: Calormatic, 430, 470, 350) unterteilen.

@TommLee

so richtig verstehe ich dein Problem nicht warum das nicht funktionieren sollte.