Lösung: Heizstab über ESP32 mit ESPEasy und Kemo M240

[skymaster64]

Hallo

Ich möchte hier mal meine Lösung für die Ansteuerung eines Heizstab über einenen ESP32 mit ESPEasy vorstellen.
Im Prinzip funktioniert es jetzt.
Es war allerdings eine Suche von vielen Stunden nötig um sich die speziellen Config-Detail zusammenzusuchen.
Leider sind in der evcc-Doku viele Stellen nur Bruchstückhaft beschrieben. Von funktionsfähigen Bruchstücken oder gar lauffähigen Beispielen ganz zu schweigen.
So bleibt nur die stundenlange Suche hier in den Diskussionen, wo auch vielen Beispiele nur unzureichend übernommen werden konnten, Kommentare teilweise falsch oder irreführend sind (und so falsch von anderen übernommen werden)
Auf Grund der (erfreulichen!) Weiterentwicklung von evcc sind nicht wenige Parameter aus älteren Beiträgen inzwischen veraltet, erzeugen Warnungen oder verhindern gar den Start.
Eine gepflegte Rubrik mit funktionsfähigen Beispielen würde vielen Usern sicher helfen.
Nicht jeder hat einen ausreichenden IT-Hintergrund (ich habe über 40 Jahre IT- und Elektronik-Erfahrung).
Nun genug des Meckerns, deshalb auch die Darstellung.
Meine restlichen Fragen am Ende.

Aufgabe/Zielstellung:

• Freigabe einer autonomen Heizstabsteuerung, die per PWM zwischen ca. 40-2000W stufenlos regelt.
• Priorisierung hinter der PV-Akku und vor allem Auto-Akku-Ladung
• Anrechnung des verwendeten Überschuss als verfügbare Leistung fürs Autoladen
  Komponennten:
• Fronius-Gen24-PV mit 6kW-WR und 6,7kWp (süd).
• 7,7kWh HVS HausBatterie
• ESP32 mit ESPeasy und Kemo-M240 Phasenanschnitt-Steuerung
  Autonome Regelung per ESPeasy-Script, Daten des Überschuss kommen per MQTT vom Volkszähler
• Tasmota-Steckdose für eBike-Laden
• KEBA-C-Serie Wallbox , Auto kommt leider (hoffentlich) erst im Sept.

Evcc soll wie gesagt die Freigabe (über ein entsprechendes Freigabe-Flag) setzten.
Hier meine evcc.yaml.

- type: template
#  template: fronius-gen24
  template: fronius-solarapi-v1
  usage: grid
  host: 192.168.xx.xx
  name: grid1
  user: customer
  password: xxxxxxxx

- type: template
#  template: fronius-gen24
  template: fronius-solarapi-v1
  usage: pv
  host: 192.168.xx.xx
  name: pv2
  user: customer
  password: xxxxxxxx

- type: template
#  template: fronius-gen24
  template: fronius-solarapi-v1
  usage: battery
  host: 192.168.xx.xx
  name: battery3
  user: customer
  password: xxxxxxxxx

- name: WW-Speicher
  type: custom
  power:
# die Leistung ist im espeasy nur berechnet und nicht gemessen
# der PWM-Bereich geht von 1 bis 1024
# der Heizstab hat 2kW, zur Vereinfachung wird einfach der PWM-Wert * 2 geliefert.
# die Ansteuerung mit dem Kemo M240 ist ausreichend linear
    source: http
    uri: http://192.168.xx.yy/json?view=sensorupdate&tasknr=12
    method: GET 
    headers:
     - content-type: application/json
    jq: .TaskValues[3] | select(.Value ) | .Value
    timeout: 5s
  soc:
# Temperatur des Speicher
    source: http
    uri: http://192.168.xx.yy/json?view=sensorupdate&tasknr=4
    method: GET # default HTTP method
    headers:
     - content-type: application/json
    jq: .TaskValues[0] | select(.Value ) | .Value
    timeout: 5s


site:
  title: Mein Zuhause
  residualPower: 100
  meters:
    grid: grid1
    pv:
    - pv2
    battery:
    - battery3
    aux:    # Leistung des Heizstab soll auch fürs Auto zur Verfügung stehen.
    - WW-Speicher

chargers:
- name: KEBA
  type: template
  template: keba-modbus
  modbus: tcpip
  host: 192.168.xx.ab
  port: 502

- name: ESP_WW
  type: custom
  features:
    - integrateddevice
    - heating
  icon: waterheater
  status:
   source: http
   uri: http://192.168.xx.yy/json?view=sensorupdate&tasknr=12
   method: GET 
   headers:
    - content-type: application/json
   jq: if .TaskValues[0] | select(.Value ) | .Value == 0 then "B" else "C" end
# espeasy liefert hier die aktuell Stellung des PWM zurück, bei 0 ist der PWM eben aus, >0 fliesst Strom
   timeout: 5s
  soc:
   source: http
   uri: http://192.168.xx.yy/json?view=sensorupdate&tasknr=4
   method: GET 
   headers:
    - content-type: application/json
   jq: .TaskValues[0] | select(.Value ) | .Value
# espeasy liefert hier die aktuelle Temperatur des Speichers
   timeout: 5s
  enabled:
   source: http
   uri: http://192.168.30.118/json?view=sensorupdate&tasknr=13
   method: GET 
   headers:
    - content-type: application/json
   jq: .TaskValues[0] | select(.Value ) | .Value
# espeasy liefert hier den Status 0 oder 1 des enable-Flag zurück
   timeout: 5s
  enable:
   source: http
   uri: http://192.168.30.118/control?cmd=TaskValueset,13,1,{{if .enable}}1{{else}}0{{end}}
# das Flag im espeasy muss mit 0 oder 1 gesetzt werden, true/false wird nicht unterstützt!
   method: GET 
#   headers:
#    - content-type: application/json  # offenbar nicht notwendig. Die Antwort vom espeay ist "OK".
   timeout: 5s
  maxcurrent:
   source: http
   uri: http://192.168.30.118/control?cmd=TaskValueset,13,3,${maxcurrent}
# der maxcurrent ist hier uninteressant und wird nur in ein dummy geschrieben.
# die maximale Temperatur könnte man über MQTT ins espeasy bekommten
# sieht z.B. so aus "evcc/loadpoints/3/effectiveLimitSoc 70"
   method: GET 
   timeout: 5s
# alternative Methode und im espeasy entsprechend einen MQTT-Empfang bauen
#   source: mqtt
#   topic: ESP_WW/cmd
#   payload: TaskValueset,13,3,${maxcurrent}

- name: Steckdose-Garage
# Steckdose für das eBike-Ladegerät
  type: template
  template: tasmota
  host: 192.168.xx.ab # Steckdose-Fahrrad
  channel: 1 # Schaltkanal (1-8)
  standbypower: 2 # Leistung oberhalb des angegebenen Wertes wird als Ladeleistung gewertet
  integrateddevice: true
  icon: bike

loadpoints: 
-  title: Keba-WB     # alles ungetestet, da noch kein Auto
   charger: KEBA
   mode: pv
   guardDuration: 5m # externe Phasenumschaltung mind. 5min Pause
   enable: # pv mode enable behavior
    delay: 1m # threshold must be exceeded for this long
    threshold: 0 # grid power threshold (in Watts, negative=export). If zero, export must exceed minimum charge power to enable
   disable: # pv mode disable behavior
    delay: 3m # threshold must be exceeded for this long
    threshold: 0 # maximum import power (W)

- title: Steckdose-Fahrrad
  charger: Steckdose-Garage
  mode: pv

- title: WarmWasser
  charger: ESP_WW
  vehicle: WW
  meter: WW-Speicher
  priority: 0
  mode: minpv


tariffs:
  currency: EUR # (default EUR)
  grid:
    # static grid price
    type: fixed
    price: 0.27 # [currency]/kWh

  feedin:
    # rate for feeding excess (pv) energy to the grid
    type: fixed
    price: 0.084 # [currency]/kWh

  co2:
    type: grünstromindex
    zip: '12345'
  planner:
    type: grünstromindex
    zip: '12345'

# mqtt message broker
mqtt:
  broker: 192.168.xx.zz:1883
  topic: evcc # root topic for publishing, set empty to disable publishing

vehicles:
- name: WW
  type: custom
  title: WW
  icon: waterheater
  soc: 
   source: http
   uri: http://192.168.xx.yy/json?view=sensorupdate&tasknr=4
   method: GET # default HTTP method
   headers:
    - content-type: application/json
   jq: .TaskValues[0] | select(.Value ) | .Value
   timeout: 5s

Fragen:

1. Warum muss man den SOC (Temperatur) für den Heizstab 3x definieren, meter, loadpoint, vehicles?
2. Unter welchen Bedingungen schaltet der LP des Heizstab auf „enable“ wenn nur der Mode PV ausgewählt ist. Ich habe ab und an mal den Timer gesehen, der dann abbricht. Später bei ausreichend vorhandenem Überschuss startet der LP nur im Mode minpv. Ich kann damit leben, aber der Grund wäre interessant für das Verständnis und wie das dann beim Auto sein wird.
   Bei der Tasmota-Steckdose funktioniert es problemlos. Sobald Überschuss vorhanden ist geht sie auf EIN und damit auf „warten auf Ladung“.
3. Wann wird der Zähler für die kWh des Heizstab zurückgesetzt? Bei der Tasmota-Steckdose ist es so, dass die immer auf PV steht und wenn man die auf AUS stellt wird der Zähler gelöscht und sie springt sofort wieder auf PV. Ich nahm an, dass es mit dem „integrateddevice“ zu tun hat, aber der Heizstab ist auch damit konfiguriert und da funktioniert der Trick nicht.
   Ergänzung: Offenbar wird er am nächsten Tage neu gestartet.

Speziell die Übergabe/Abfrage vom/zum ESP war sehr schwierig zu finden, da praktisch fast überhaupt nicht dokumentiert. Solche Sachen wie {.enable} oder ${maxcurrent} sind nicht dokumentiert und konnte ich nur durch Zufall in einem anderen Beitrag finden. Welche weiteren Strings existieren ... keine Anhnung.
Den ersten Versuch rein mit MQTT musste ich aufgeben weil ich nicht rausgefunden habe wie ich eine Umwandung von true/false in1/0 wie in der http-uri …,{{if .enable}}1{{else}}0{{end}} machen kann, bzw. so eine Umwandlung von "Strom >0" in "C".
In vielen Beispielen steht im Kommentar „# set charger enabled state (true/false or 0/1)“, was definitiv falsch ist, es kommt eben kein 0/1.
Auch die Dekodierung des json ist eine Sache für sich. Es gibt zwar den Link auf die Hilfsseite, aber ohne das dazugehörige json hilft der Beispielausdruck nicht weiter.
Bei mir kommt auf diese Abfrage im ESPEasy: http://192.168.xx.yy/json?view=sensorupdate&tasknr=12
diese json-Antwort:

{
"TaskValues": [
{"ValueNumber":1,
"Name":"PWM_GPIO16",
"NrDecimals":0,
"Value":0
},
{"ValueNumber":2,
"Name":"Ruecklauf_Soll",
"NrDecimals":0,
"Value":45
},
{"ValueNumber":3,
"Name":"Speicher_Soll",
"NrDecimals":1,
"Value":70.0
},
{"ValueNumber":4,
"Name":"Power",
"NrDecimals":0,
"Value":0
}],
"TTL":20000,
"TaskEnabled":"true",
"TaskNumber":12
}

Das muss man in https://jqplay.org/ unter „Output“ einfügen und dann kann man unter „Query“ einen Ausdruck mit trial&error suchen, der das gewünschte Feld selektiert.
Für die „Speicher_Soll“-Temperatur z.B. „.TaskValues[2] | select(.Value ) | .Value“ (Zähler fängt bei 0 an)

Zum ESPEasy ist nicht so viel zu sagen, da dass ein extra Bauprojekt ist und nur von jemanden nachgebaut werden kann der über entsprechende Fähigkieten incl. Netz-Strom verfügt.
Das Teil besteht aus einem ESP32-NodeMCU-Board, Netzteil, LCD-Display, dem erwähnten Kemo M240 incl. 2 Netzfiltern, Sicherungen usw.
Das Schöne am ESPEasy ist die Konfiguration diverser Sensoren, Aktoren usw. per Webinterface. Außerdem ist eine Skriptsprache (Rules) enthalten, die auf diverse Events reagiert und Aktionen ausführen kann.
So sieht das z.B. für die autonome Regelung aus:

On mqtt#Grid Do
   If  [mqtt#Grid] >= 10 or [mqtt#Batt] >= 100 or  [temperature#WW_Speicher]>=[Register#Speicher_Soll] Or [dButtons#Enable:Hz]=0
    TaskValueSet,Register,PWM_GPIO16,[Register#PWM_GPIO16]-80
    If [Register#PWM_GPIO16]<0
    TaskValueSet,Register,PWM_GPIO16,0
   Endif
  Else
   If [mqtt#Grid] <= -200
     TaskValueSet,Register,PWM_GPIO16,[Register#PWM_GPIO16]+20
   Endif
  Endif 
   If [Register#PWM_GPIO16]>1010 
    TaskValueSet,Register,PWM_GPIO16,1010
   Endif
   Event PowerUpdate
  pwm,16,[Register#PWM_GPIO16]
Endon

Das funktioniert rechts gut und sieht dann im Verbrauch so aus:

Dass die "Warmwasserheizung" so zackig aussieht liegt daran, dass ich das mit einem S0-Zähler für die Darstellung messe.
Man sieht aber auch, das er gut den verfügbaren Überschuss folgt (ich lassen absichtlich eine Mindesteinspeisung weil der Fronius-Gen24 nicht der schnellste in der Regelung ist. Um 12:15 Uhr ist die Zieltemperatur erreicht, da kommen also keine Impulse am S0 mehr.

Für das ESPEasy gibt es auch noch ein minimales Bedienfrontend mit Tasten und Schiebereglern (fetch.html.gz)

Der ESP32 macht also noch eine Steuerung der Umwälzpumpe und hat weitere Sensoren.