Läuft: Heizung mit eBus-Schnittstelle

Begonnen von Prof. Dr. Peter Henning, 29 November 2014, 13:36:59

Vorheriges Thema - Nächstes Thema

pc1246

Zitat von: cs-online am 30 Oktober 2020, 19:28:34
Ich hab die Ecotec Exclusiv und die 470er Steuerung, seit Jahren Speicherladung über EBUSd, keine Probleme. Aber wir haben hier festgestellt, dass es unterschiedliche SW-Versionen gibt und nicht alle das unterstützen.

Du musst mal in die 470er CSV und schauen, ob bei HwcOPMode r;w oder nur r vorsteht, das muss r;w sein. Wenn du Ändern musst, dann einmal EbusD neustarten oder reload senden, dann mal probieren, ob mit
ebusctl w -c 470 HwcOPMode 6

die Speicherladung gestartet wird, kann ein paar Sekunden dauern, bis das im Display der 470er erscheint... Dann schauen wir weiter ;-)

Grüße Christian
Moin zusammen
Koennt Ihr in HwcOPMode sehen, wenn Ihr manuell eine Speicherladung anstosst? Bei mir aendert sich das nie, und das waere eigentlich mein groesster Traum dies von fhem anstossen zu koennen!
Danke und Gruss Christoph
HP T610
Onkyo_AVR;3 Enigma2; SB_Server ; SB_Player; HM-USB mit 15 HM-CC-RT-DN, 3 HM_WDS10_TH_O, 6 HM-Sec-SCo, 4 HM-Sec-MDIR-2, 1 HM-Sen-MDIR-O-2, 8 Ferion 5000 OW ; PhilipsTV; 4 harmony hub; Jeelink mit 9 PCA301; Somfy; S7-300; 3 LGW; HUE; HM-IP auf Charly

Reinhart

@fhempi

wie hast du ihn jetzt auf 0 gesetzt, mit Reset oder das Register mit 0 beschrieben, interessiert sicher auch andere wie das geht

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

cs-online

Zitat von: pc1246 am 16 November 2020, 10:17:48
Moin zusammen
Koennt Ihr in HwcOPMode sehen, wenn Ihr manuell eine Speicherladung anstosst? Bei mir aendert sich das nie, und das waere eigentlich mein groesster Traum dies von fhem anstossen zu koennen!
Danke und Gruss Christoph

Wie meinst du das ? Wenn ich das mit FHEM setze, dann steht auch in meiner 470er Regelung z.B. "1x Speicherladung" und auch wenn ich an der Steuerung Speicherladung aktiviere, bekomme ich mit

ebusctl r -f hwcopmode

dann eine 6 zurück, nach Abbruch dann wieder die 2. So kann ich z.B. auch ermitteln, wann Warmwasser fertig ist und über Alexa "Warmwasser ist fertig" ausgeben lassen...
FHEM auf RPI 4 4GB, HM-WLAN-Gateway, einige HM-Aktoren,2x EBUSD an Heizung+Solar, ESP8266 am Strom-,Gas-,Wasserzähler, in WLAN-Steckdosen und Relaisleisten, Sonoff S20, Shelly1,2 und 2.5,Lacrosse-Gateway und Sensoren,Sduino,Alexa-Fhem,Huawei PV mit Speicher, alles auf einem RPI und da geht noch mehr

pc1246

Moin
Bei mir steht da immer eine "2", deshalb meine Frage ob Du das am Regler anforderst und in fhem siehst.
So ganz nebenbei, hast Du keinen Schichtspeicher? Wenn ich Speicherladung anfordere, steht das warme Wasser zur Verfuegung, wenn ich die Treppe hoch bin mich ausgezogen habe und in die Dusche gehe!
Gruss Christoph
HP T610
Onkyo_AVR;3 Enigma2; SB_Server ; SB_Player; HM-USB mit 15 HM-CC-RT-DN, 3 HM_WDS10_TH_O, 6 HM-Sec-SCo, 4 HM-Sec-MDIR-2, 1 HM-Sen-MDIR-O-2, 8 Ferion 5000 OW ; PhilipsTV; 4 harmony hub; Jeelink mit 9 PCA301; Somfy; S7-300; 3 LGW; HUE; HM-IP auf Charly

blackmondeo

Zitat von: Reinhart am 15 November 2020, 11:21:47
Also deine jsonMaps auf die Readings funktionieren nicht so wie du sie brauchst. Als Beispiel hänge ich dir unten meine an damit du vergleichen kannst.

Ich vermute, deine bridgeRegexp am Device "MQTT2_ebusd" passt nicht ganz oder du hast "autocreate" nicht auf "1" gesetzt. Vergleiche deine Readings mit meinen! Versuche einmal in diese Richtung den Fehler einzugrenzen, wenn die Regexp im übergeordneten Device passen, dann sollten die Readings auch im "bai" richtig gefüllt werden.

Hallo Reinhard,
danke erstmal für die Informationen wie es aussehen sollte. Ich habe jetzt alles mögliche probiert und verglichen und mit deinen Einstellungen ersetzt. Hat leider nichts gebracht.
Ich habe alle Devices's gelöscht und nochmal neu erstellt bzw. erstellen lassen. Ich habe mit Templates gearbeitet und auch mal ohne.
Ebenso habe ich auf einem meines Windows System zum testen ein komplett frisches FHEM eingerichtet welches auf den MQTT von RPI zugreift, auch dort das gleiche Problem das jsonmap nicht trennen will.

Ich hab keine Ahnung warum das bei mir nicht funktioniert.

Hier mal die List vom FHEM MQTT Server (Autocreate steht auf Complex)

Internals:
   CONNECTS   4
   DEF        1883 global
   FD         18
   FUUID      5fb19b72-f33f-7689-742b-70dbe0138f524fd8
   NAME       ebusMQTT
   NR         87
   PORT       1883
   STATE      Initialized
   TYPE       MQTT2_SERVER
   READINGS:
     2020-11-15 22:28:58   RETAIN          {"ebusd/global/running":"true","ebusd/global/signal":"true","ebusd/global/version":"ebusd 3.4.v3.3-51-g57eae05"}
     2020-11-16 12:39:28   nrclients       2
     2020-11-15 22:28:50   state           Initialized
   clients:
     ebusMQTT_127.0.0.1_60382 1
     ebusMQTT_192.168.1.27_56468 1
   retain:
     ebusd/global/running:
       ts         1605475738.08554
       val        true
     ebusd/global/signal:
       ts         1605475738.0423
       val        true
     ebusd/global/version:
       ts         1605475738.08403
       val        ebusd 3.4.v3.3-51-g57eae05
Attributes:
   autocreate complex
   room       MQTT2_SERVER


Hier die List vom ebusd mit dem Template als Splitter und autocreate = 1

Internals:
   CID        ebusd
   DEF        ebusd
   DEVICETOPIC MQTT2_ebusd
   FUUID      5fb19b8f-f33f-7689-3e2b-54e83d3cdeb4826f
   IODev      ebusMQTT
   LASTInputDev ebusMQTT
   MSGCNT     7367
   NAME       MQTT2_ebusd
   NR         88
   STATE      Status:
1:running
Signal:
2:signal
<br>Uptime: 0 003 22:14
   TYPE       MQTT2_DEVICE
   ebusMQTT_MSGCNT 7367
   ebusMQTT_TIME 2020-11-16 21:24:29
   OLDREADINGS:
   READINGS:
     2020-11-16 09:08:00   associatedWith  MQTT2_ebusd
     2020-11-16 21:24:27   formatedUptime  0 003 22:14
     2020-11-16 21:23:49   outsidetemp     8.625
     2020-11-16 21:24:27   uptime          339279
     2020-11-16 21:24:29   vdatetime       21:24:24;16.11.2020
Attributes:
   IODev      ebusMQTT
   autocreate 1
   bridgeRegexp (ebus.)[^/]*/(bai|[\d]+|cc|e7f|ehp|f[\d][\d]|hc|he.|hmu|hwc|mc|mc.[\d]|omu|omu.[\d]|pms|rcc|rcc.[\d]|sc|sdr_p|ui|uih|v[\d][\d]|v81|v81.[\d]|vd[\d]|vl[\d]|vr_[\d][\d]|zeo)/.*:.* "$1_$2"
(ebus.)[^/]*/(global|broadcast|general|scan|)/.*:.* "$1"
   comment    NOTE: additional templates and code have been downloaded from svn (contrib).
   devStateIcon 1.true:it_net 1.false:it_net@red  2.true:lan_rs485 2.false:lan_rs485@red
   icon       sani_boiler_temp
   model      eBus_daemon_splitter
   readingList ebusd/global/uptime:.* uptime
ebusd/broadcast/outsidetemp:.* outsidetemp
ebusd/broadcast/vdatetime:.* vdatetime
   room       MQTT2_DEVICE
   setList    getKnown:noArg ebusd/list onlyknown
  getAll:noArg ebusd/list
   stateFormat Status:
1:running
Signal:
2:signal
<br>Uptime: formatedUptime
   userReadings formatedUptime:uptime.* {my $m = ReadingsVal($name,"uptime",0)/60;; return sprintf "0 000 00:%02d", $m if $m < 60;; my $h = $m / 60;; $m %= 60;; return sprintf "0 000 %02d:%02d", $h, $m if $h < 24;; my $d = $h / 24;; $h %= 24;; return sprintf "0 %03d %02d:%02d", $d, $h, $m if $d <365;; my $y = $d / 365;; $d %= 365;; return sprintf "%d %03d %02d:%02d", $y, $d, $h, $m}


Und hier die List vom BAI Device. Ich habe mich jetzt auf Status01 beschränkt, aber auch dieser wird nicht in seine Bestandteile aufgetrennt.

Internals:
   CFGFN     
   CID        ebusd_bai
   DEF        ebusd_bai
   DEVICETOPIC MQTT2_ebusd_bai
   FUUID      5fb2dd7d-f33f-7689-4ef6-53ef9c199782f28e
   IODev      ebusMQTT
   LASTInputDev ebusMQTT
   MSGCNT     147
   NAME       MQTT2_ebusd_bai
   NR         376
   STATE      ???
   TYPE       MQTT2_DEVICE
   ebusMQTT_MSGCNT 147
   ebusMQTT_TIME 2020-11-16 21:25:09
   JSONMAP:
     Status01_0_value _Vorlauf
     Status01_1_value _Ruecklauf
     Status01_2_value _Aussentemp
     Status01_3_value _Warmwasser
     Status01_4_value _WWSpeicher
     Status01_5_value _Pumpenstatus
   READINGS:
     2020-11-16 21:25:09   DateTime        valid;21:25:05;16.11.2020;8.625
     2020-11-16 21:25:09   SetMode         auto;36.5;50.0;-;0;0;1;0;0;0
     2020-11-16 21:16:24   Status01        35.0;-;8.625;0.0;45.0;on
     2020-11-16 21:25:04   Status01_       32.0
     2020-11-16 21:24:59   Status02        auto;60;50.0;80;65.0
     2020-11-16 21:19:39   associatedWith  MQTT2_ebusd
Attributes:
   IODev      ebusMQTT
   jsonMap    Status01_0_value:_Vorlauf
Status01_1_value:_Ruecklauf
Status01_2_value:_Aussentemp
Status01_3_value:_Warmwasser
Status01_4_value:_WWSpeicher
Status01_5_value:_Pumpenstatus
   readingList ebusd/bai/SetMode:.* SetMode
ebusd/bai/DateTime:.* DateTime
ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }
ebusd/bai/Status02:.* Status02
   room       MQTT2_DEVICE
FHEM auf Raspberry 4, Homematic, Homebrew wired, MPD, eBus

Reinhart

ich kann jetzt so beim durchsehen auch nix besonderes feststellen was falsch sein sollte. Bei den Clients vom Server ist mir aufgefallen, dass du den eBus Dämon auf diesem Raspi laufen hast, ist das richtig? Das müsste der Localhost mit 127.0.0.1_60382 sein.

Setzte bitte einmal am MQTT2_Server das Attribut rawEvents auf .*  und verbose auf 5, dann wird alles auch ins Log geschrieben.
Ich hänge dir jetzt hier unten so ein Log an wo der Status01 empfangen wird. Siehst du da jetzt gravierende Unterschiede zu deinen Werten und vor allem zieht die regExp? Wichtig ist hier die Trennung der 6 Namen mit 0 beginnend.

2020.11.17 09:40:43 5: in:  PUBLISH: 0(162)(2)(0)(18)ebusd/bai/Status01{(10)     "0": {"name": "temp1", "value": 48.0},(10)     "1": {"name": "temp1", "value": 41.0},(10)     "2": {"name": "temp2", "value": 7.562},(10)     "3": {"name": "temp1", "value": 38.0},(10)     "4": {"name": "temp1", "value": 41.0},(10)     "5": {"name": "pumpstate", "value": "on"}}
2020.11.17 09:40:43 4:   ebusMQTT_10.0.0.6_50000 ebusd_3.3_15662 PUBLISH ebusd/bai/Status01:{
     "0": {"name": "temp1", "value": 48.0},
     "1": {"name": "temp1", "value": 41.0},
     "2": {"name": "temp2", "value": 7.562},
     "3": {"name": "temp1", "value": 38.0},
     "4": {"name": "temp1", "value": 41.0},
     "5": {"name": "pumpstate", "value": "on"}}
2020.11.17 09:40:43 5:   ebusMQTT_10.0.0.6_50000 ebusd_3.3_15662 => ebusd/bai/Status01:{
     "0": {"name": "temp1", "value": 48.0},
     "1": {"name": "temp1", "value": 41.0},
     "2": {"name": "temp2", "value": 7.562},
     "3": {"name": "temp1", "value": 38.0},
     "4": {"name": "temp1", "value": 41.0},
     "5": {"name": "pumpstate", "value": "on"}}
2020.11.17 09:40:43 5: out: PUBLISH: 0(162)(2)(0)(18)ebusd/bai/Status01{(10)     "0": {"name": "temp1", "value": 48.0},(10)     "1": {"name": "temp1", "value": 41.0},(10)     "2": {"name": "temp2", "value": 7.562},(10)     "3": {"name": "temp1", "value": 38.0},(10)     "4": {"name": "temp1", "value": 41.0},(10)     "5": {"name": "pumpstate", "value": "on"}}
2020.11.17 09:40:43 5: ebusMQTT: dispatch autocreate=complex\000ebusd_3.3_15662\000ebusd/bai/Status01\000{\n     "0": {"name": "temp1", "value": 48.0},\n     "1": {"name": "temp1", "value": 41.0},\n     "2": {"name": "temp2", "value": 7.562},\n     "3": {"name": "temp1", "value": 38.0},\n     "4": {"name": "temp1", "value": 41.0},\n     "5": {"name": "pumpstate", "value": "on"}}


Ach ja, in der Config vom Dämon sollte unbedingt diese Einträge vor allem bei der Topic vorhanden sein, IP mit deiner ersetzen.
--mqttport=1883 --mqttjson --mqtthost=10.0.0.5 --mqtttopic=ebusd/%circuit/%name

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

blackmondeo

Zitat von: Reinhart am 17 November 2020, 09:53:25
Setzte bitte einmal am MQTT2_Server das Attribut rawEvents auf .*  und verbose auf 5, dann wird alles auch ins Log geschrieben.
Ich hänge dir jetzt hier unten so ein Log an wo der Status01 empfangen wird. Siehst du da jetzt gravierende Unterschiede zu deinen Werten und vor allem zieht die regExp? Wichtig ist hier die Trennung der 6 Namen mit 0 beginnend.


Hallo Reinhart,
ja der ebusd läuft auf dem gleichen Raspi. Beim abgleich habe ich jetzt festgestellt das in meiner ebusd config der Eintrag "--mqttjson" fehlte. Warum auch immer, denn die anderen MQTT Einträge hatte ich so drin stehen. Auf jeden Fall habe ich das jetzt ergänzt und nun funktiert das auch so wie es soll.

Zum Vergleich (eventuell hat ja jemand den gleichen Fehler gemacht) hier die LOG Einträge wie sie nicht aussehen sollten.
2020.11.17 13:41:51 5: in:  PUBLISH: 0-(0)(18)ebusd/bai/Status0141.0;-;9.938;0.0;51.0;off
2020.11.17 13:41:51 4:   ebusMQTT_127.0.0.1_60382 ebusd_3.4_562 PUBLISH ebusd/bai/Status01:41.0;-;9.938;0.0;51.0;off
2020.11.17 13:41:51 5:   ebusMQTT_127.0.0.1_60382 ebusd_3.4_562 => ebusd/bai/Status01:41.0;-;9.938;0.0;51.0;off
2020.11.17 13:41:51 5: out: PUBLISH: 0-(0)(18)ebusd/bai/Status0141.0;-;9.938;0.0;51.0;off
2020.11.17 13:41:51 5: ebusMQTT: dispatch autocreate=complex\000ebusd_3.4_562\000ebusd/bai/Status01\00041.0;-;9.938;0.0;51.0;off


Also vielen Dank für Eure(Deine) Hilfe und Geduld bei der Fehlersuche.

Sollte ich mir Gedanken machen das beim Rücklauf kein Wert angezeigt wird?

Viele Grüße Torsten
FHEM auf Raspberry 4, Homematic, Homebrew wired, MPD, eBus

Reinhart

Zitat von: blackmondeo am 17 November 2020, 14:16:18
Hallo Reinhart,
ja der ebusd läuft auf dem gleichen Raspi. Beim abgleich habe ich jetzt festgestellt das in meiner ebusd config der Eintrag "--mqttjson" fehlte. Warum auch immer, denn die anderen MQTT Einträge hatte ich so drin stehen. Auf jeden Fall habe ich das jetzt ergänzt und nun funktiert das auch so wie es soll.

Sollte ich mir Gedanken machen das beim Rücklauf kein Wert angezeigt wird?

Viele Grüße Torsten

frag doch mal den Rücklauf mit ebusctl direkt ab ob er da vorhanden ist. Wenn der Rücklaufsensor defekt wäre, dann müsste die Therme auf Störung gehen, sonst wäre ja keine Steuerung nach der Heizkurve möglich und immer auf Vollgas laufen. Je größer die Differenz zwischen Vor und Rücklauf, desto mehr Leistung des Brenners wird ja eingestellt und umgekehrt.

Hätte ich eigentlich früher drauf kommen könnnen, das in deiner config was nicht stimmt, aber Hauptsache du hast es jetzt gefunden.

LG
Reinhart
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

blackmondeo

Zitat von: Reinhart am 17 November 2020, 20:48:18
frag doch mal den Rücklauf mit ebusctl direkt ab ob er da vorhanden ist. Wenn der Rücklaufsensor defekt wäre, dann müsste die Therme auf Störung gehen, sonst wäre ja keine Steuerung nach der Heizkurve möglich und immer auf Vollgas laufen. Je größer die Differenz zwischen Vor und Rücklauf, desto mehr Leistung des Brenners wird ja eingestellt und umgekehrt.


Hallo Reinhard,
ich habe den test gemacht und es kommt dieses Ergebnis, die -13.50 bleiben auch konstant.


ebusctl r -f ReturnTemp
-13.50;215;cutoff

ebusctl r -f ReturnTempMax
0.00

ebusctl r -f expertlevelMain_ReturnTemp
-1.81;cutoff



Die Therme zeigt keine Störung an, und läuft m.E. auch normal. Es handelt sich um eine Öl-Brennwerttherme und ist mittlerweile fast 7 Jahre alt.
Aus eurer Erfahrung heraus, wäre es denkbar das die falsche CSV verwendet wird?

ebusctl info
version: ebusd 3.4.v3.3-51-g57eae05
update check: revision v3.4 available
access: *
signal: acquired
symbol rate: 22
max symbol rate: 171
min arbitration micros: 9
max arbitration micros: 698
min symbol latency: 0
max symbol latency: 30
reconnects: 0
masters: 3
messages: 483
conditional: 0
poll: 1
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0902;HW=7401", loaded "vaillant/bai.0010010674.inc" ([PROD='0010010676']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=47000;SW=0348;HW=9502", loaded "vaillant/15.470.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd


Viele Grüße Torsten
FHEM auf Raspberry 4, Homematic, Homebrew wired, MPD, eBus

Reinhart

ich kenne das Gerät nicht und kann dir daher auch nicht sagen ob die 08.bai da korrekt ist.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Rainer82

@blackmondeo: du fragst den falschen Wert ab  ;)

cs-online

...würde ich auch meinen, meine CSVs sind nicht mehr ganz aktuell, aber bei mir wird die Rücklauftemperatur mit

ebusctl r -f SDTRT

abgefragt...
FHEM auf RPI 4 4GB, HM-WLAN-Gateway, einige HM-Aktoren,2x EBUSD an Heizung+Solar, ESP8266 am Strom-,Gas-,Wasserzähler, in WLAN-Steckdosen und Relaisleisten, Sonoff S20, Shelly1,2 und 2.5,Lacrosse-Gateway und Sensoren,Sduino,Alexa-Fhem,Huawei PV mit Speicher, alles auf einem RPI und da geht noch mehr

blackmondeo

Zitat von: cs-online am 20 November 2020, 19:33:40
...würde ich auch meinen, meine CSVs sind nicht mehr ganz aktuell, aber bei mir wird die Rücklauftemperatur mit

ebusctl r -f SDTRT

abgefragt...

Hallo,
das die Abfrage nicht korrekt ist das glaub ich ja, aber ich weiß halt nicht genau warum. Ich habe mir die csv heruntergeladen um zu schauen was dort zum Stichwort Rücklauf zu finden ist, nur leider komme ich so nicht an einen Wert.

SDTRT ist bei meiner Konfiguration nicht bekannt. Soweit ich das verstanden habe sucht der ebusd die passende bai und csv Datei. das scheint ja auch zu funktionieren. Kann man das manuell überprüfen ob die richtige Konfigurationsdatei gefunden wurde?

ebusctl r -f Returntemp
-13.50;215;cutoff

ebusctl r -f SDTRT
ERR: element not found


macht es Sinn in dem Fall in alten CSV Dateien zu stöbern um SDTRT zu finden?
FHEM auf Raspberry 4, Homematic, Homebrew wired, MPD, eBus

cs-online

#3208
...also bei meinen CSVs ist in der bai.0010010674.inc (Wie gesagt, meine sind schon etwas älter, kann sein, dass John das mal vereinheitlicht hat und deshalb nun nicht mehr SDTRT dort steht)

r,,SDTRT,d.41 Rücklauftemperatur,,,,"9800",,,tempmirrorsensor,,,Rücklauftemperatur

Also ist in meiner Therme unter D.41 die Rücklauftemperratur gespeichert. Nun könntest du in deiner Bedienungsanleitung mal schauen, ob das auch D.41 ist. Oder an der Therme selber mal schauen, was Rücklauftemperatur für ein D.xx ist. Dann vielleicht in deiner CSV schauen, was unter D.41 bzw. eben dem, was es bei deiner Therme ist, davor steht und damit solltest du dann passend die Rücklauftemperatur auslesen können, du kannst dann ja mal vergleichen, was deine Therme im Display ausgibt und was EBUSD ermittelt
FHEM auf RPI 4 4GB, HM-WLAN-Gateway, einige HM-Aktoren,2x EBUSD an Heizung+Solar, ESP8266 am Strom-,Gas-,Wasserzähler, in WLAN-Steckdosen und Relaisleisten, Sonoff S20, Shelly1,2 und 2.5,Lacrosse-Gateway und Sensoren,Sduino,Alexa-Fhem,Huawei PV mit Speicher, alles auf einem RPI und da geht noch mehr

blackmondeo

Zitat von: cs-online am 21 November 2020, 07:44:17
Also ist in meiner Therme unter D.41 die Rücklauftemperratur gespeichert. Nun könntest du in deiner Bedienungsanleitung mal schauen, ob das auch D.41 ist. Oder an der Therme selber mal schauen, was Rücklauftemperatur für ein D.xx ist. Dann vielleicht in deiner CSV schauen, was unter D.41 bzw. eben dem, was es bei deiner Therme ist, davor steht und damit solltest du dann passend die Rücklauftemperatur auslesen können, du kannst dann ja mal vergleichen, was deine Therme im Display ausgibt und was EBUSD ermittelt

Hallo,
in der aktuellen Configurationsdatei steht d.41 als "ReturnTemp" drin. Soweit alles klar. Am Display meiner Therme bekomme ich die einzelnen Werte irgendwie nicht angezeigt. Aber beim stöbern in der Anleitung meiner Therme habe ich gesehen das der Rücklauftemperatursensor (als d.41) als optionales Zubehör erhältlich ist. Also habe ich aktuell gar keinen Sensor eingebaut. Damit hätte sich das auch geklärt.
Danke für die Hinweise.
FHEM auf Raspberry 4, Homematic, Homebrew wired, MPD, eBus