Einbinden der Lambda / Zewotherm Wärmepumpen in evcc

[TRON4R]

Die Diskussion hat in #18812 begonnen, soll aber hier fortgesetzt werden.

----------EDIT vom 14.11.2025:----------
Die nachfolgenden Infos sind inzwischen teilweise überholt. Die Lambda wurde inzwischen mit einem vollständigen eigenen Template in evcc integriert, von daher ist vieles, was hier beschrieben wurde, nicht mehr aktuell.

Des Weiteren gibt es leider keinen Konsens, was die beste Steuerung der Lambda angeht. Einige Besitzer einer Lambda-Wärmepumpe, darunter auch @thecem und ich sind der Meinung, dass Lambda eigentlich nur will, dass man in Register 102 laufend den aktuellen PV-Überschuss (in evcc im gelben Balken im GUI und bei "Einspeisung" angezeigt) schreibt und den Rest dann die Lambda selbst machen lässt.

Diese Meinung wird nicht von allen geteilt, weswegen die originale Ansteuerung in evcc nicht einfach nur den gerade verfügbaren PV-Überschuss an die Lambda meldet, sondern die Lambda mehr wie eine Wallbox behandelt. Hier ist zu beachten, dass die Lambda auf E-Eintrag eingestellt werden muss, damit sie die von evcc übermittelten Werte nicht für PV-Überschuss hält.

Falls Dich die originale Doku von Lambda zum Thema ModBus-Ansteuerung interessiert, um Dir selbst eigene Meinung zu bilden, so findest Du diese u.a. hier: #20179 (reply in thread)

Sofern Du es daraufhin (oder weil sich Deine Wärmepumpe mit dem Standard-Template nicht so verhält, wie Du es erwartest) besser finden solltest, wenn die Lambda einfach nur den verfügbaren Überschuss gemeldet bekommt, dann schau bitte hier nach, wo @thecem ein Script in die YAML-Definition integriert hat, welches die Standard-Steuerung von evcc nur für diesen Lambda-Loadpoint ersetzt: #22652

Es gibt übrigens auch Hinweise, dass die Erwartung von simplen Überschuss-Werten nicht nur die Wärmepumpen von Lambda, sondern auch die Wärmepumpen von IDM und Kermi betrifft.
----------EDIT-Ende----------

Laut den devs ist soweit alles code-seitig implementiert, dass die Lambda jetzt von evcc mit den Infos zum PV-Überschuss versorgt werden kann.

Ein offizielles Template für die yaml findet sich in der evcc Doku für die Lambda hier und für die (absolut baugleiche) Zewotherm hier.

In den Einstellungen der Lambda-Wärmepumpe muss man zunächst die folgenden drei Settings aktivieren:
(für das zweite Setting ist ein User mit mindestens Level 3 erforderlich, wie z.B. "Experte", für die beiden anderen reicht auch Level 2. Der Support von Lambda ist nach meiner Erfahrung sehr gut zu erreichen und erledigt Umstellungswünsche zudem sehr schnell):

1. Home → Energie Management (Icon mit Hand und Blitz in der Kugel) → Betriebsart → auf "Automatik" stellen

2. Home → Energie Management → Konfiguration E-Manager (Icon mit Blitz in der Kugel und einem Zahnrad) → E-Meter Kommunikationsart → auf "Modbus Client" stellen

3. Home → Energie Management → Konfiguration E-Manager → E-Meter Messpunkt → auf "Pos. E-Überschuss" stellen

Die nachfolgenden Infos stammen u.a. aus der evcc Doku zum Thema Wärmepumpe, den yaml-Templates von premultiply und den yaml-Templates von jannisif und weiteren Stellen im Thread #18812 sowie der offiziellen Modbus Beschreibung von Lambda selbst).

Die allermeisten Dinge sind mir inzwischen dank der Hilfe von anderen auch klar (ich liste sie nur noch einmal hier auf, damit sich andere, die diese Wärmepumpe einbinden möchten, nicht die Infos aus zahlreichen verschiedenen Stellen zusammensuchen müssen):

Wenden wir uns also nun dem Aufbau der yaml-Definitionen für die Lambda zu:

A. Die Erfassung des Stromverbrauchs der Lambda durch evcc erfolgt wie gewohnt über die Definition als meter:

meters:
- name: lambda_power
  type: custom
  power:
    source: modbus
    id: 1
    uri: 192.168.2.6:502 # IP anpassen
    register:
      address: 103 # Register für die aktuelle Aufnahmeleistung der WP
      type: holding
      decode: int16

Achtung! Wie ich durch Testen herausgefunden habe, braucht man diese Definition als meter nicht!
Die Einbindung der Lambda als charger reicht vollkommen aus, um in einem loadpoint zu funktionieren und auch den aktuellen Verbrauchswert anzuzeigen. (D.h. die Abfrage von Register 103 für die Messung des aktuellen Verbrauchs ist bereits in der Template-Definition des charger enthalten)
Ich erwähne die Definition als meter daher hier nur noch, falls man den Verbrauchswert der Lambda einzeln ermitteln und als meter irgendeinem anderen Geräte im Rahmen einer yaml-Definition hinzufügen möchte. Das kann man dort dann mit meter: lambda_power tun.

B. Als nächstes erfolgt die Definition der Lambda als charger, um eine Steuerung zu ermöglichen:

Diese Definition basiert auf dem offiziellen Template der evcc-Doku:

chargers:
  - name: lambda_charger
    type: template
    template: lambda-zewotherm
    modbus: tcpip
    id: 1
    host: 192.168.2.6 # IP anpassen
    port: 502 # Port
    tempsource: warmwater_top # obere Brauchwasserfühler-Temperatur
#  tempsource: warmwater_bottom # untere Brauchwasserfühler-Temperatur (alternativ)
#  tempsource: buffer_top # obere Pufferfühler-Temperatur (alternativ)
#  tempsource: buffer_bottom # untere Pufferfühler-Temperatur (alternativ)
#  watchdog: 60s # optional

Hier wäre schon meine erste Frage, dass bei der Verwendung von der nachfolgenden charger Definition, welche jannisif hier vorgeschlagen hatte, vermutlich die automatische Steuerung nicht funktioniert würde, sondern lediglich der Verbrauch der Lambda am Ende im GUI als Loadpoint nur angezeigt würde, richtig?
(Und das dann natürlich auch nur, wenn man dort entsprechend den meter Eintrag im loadpoint eingebunden hat)

chargers:
  - name: lambda_charger
     type: template
     template: demo-charger
     status: C
     enabled: true

Da das obige Template für die Lambda/Zewotherm aus der Doku allerdings in der 0.200.8 und 0.200.9 aufgrund eines falschen Parameters im Template zum Beschreiben von Register 102 bei der Ansteuerung der Lambda noch Fehlermeldungen produziert, ist stattdessen erstmal das nachfolgende custom Template basierend auf dem allgemeinen type: heatpump zu benutzen:

chargers:
- name: lambda_wp
  type: heatpump
  setmaxpower: # report excess PV power to heatpump
    source: watchdog # to avoid triggering the 5 min timeout of λ leading to Error 00506 ("Alarm: E-Manager ungültiger Wert")
    timeout: 60s # any value sufficiently lower than 300 seconds should work to write to register 102 within the 5 min timeout
    set:
      source: modbus
      id: 1
      uri: 192.168.2.6:502
      register:
        address: 102 # input register for excess PV power in Watt
        type: writemultiple # λ expects single value as FC16
        decode: int16
  power: # read actual power consumption from heatpump
    source: modbus
    id: 1
    uri: Your-WP-IP:502
    register:
      address: 103 # actual power consumption [E / Watt] of λ
      type: holding
      decode: int16
  energy: # read accumulated electrical energy from heatpump (or accumulated energy output)
    source: modbus
    id: 1
    uri: Your-WP-IP:502
    register:
      address: 1020 # accumulated electrical energy [E / Wh] since last reset
#      address: 1022 # accumulated thermal energy output [Q / Wh] since last reset - instead of 1020
      type: holding
      decode: int32
    scale: 0.001
  temp: # measure the current temperature of your choice (boiler high or low, or buffer high or low)
    source: modbus
    id: 1
    uri: Your-WP-IP:502
    register:
      address: 2002 # actual temperature boiler high sensor in 0,1 °C
#      address: 2003 # actual temperature boiler low sensor in 0,1 °C - instead of 2002
#      address: 3002 # actual temperature buffer high sensor in 0,1 °C - instead of 2002
#      address: 3003 # actual temperature buffer low sensor in 0,1 °C - instead of 2002
      type: holding
      decode: int16
    scale: 0.1

C. Kommen wir zur Definition der Lambda als vehicle.
Achtung! Auch hier haben Tests bestätigt, dass eine Definition der Lambda als vehicle nicht erforderlich ist!
Das Template für die Ansteuerung von Wärmepumpen über sg-ready enthält jedenfalls keine vehicle-Definition. Und ich kann auch keinen Unterschied in der Anzeige erkennen, wenn ich die Zeile vehicle: lambda einfach weglasse in der Loadpoint-Definition weiter unten.
Aber @jannisif hatte eine vehicle-Definition eingebaut, daher liste ich sie hier mal der Vollständigkeit halber noch mit auf.

Update vom 11.03.2025: Ich habe in Tests herausgefunden, dass die vehicle-Definition doch einen Effekt hat!
Und zwar werden aktuell noch alle durch evcc ausgelösten Überschuss-Ladungen der Lambda wie eine Fahrzeugladung protokolliert und in der Übersicht der Ladevorgänge in evcc angezeigt.

Hat man keine vehicle Definition angelegt, erscheinen sie entsprechend in der Ladevorgänge-Übersicht von evcc als "Gastfahrzeug".
Hat man jedoch eine vehicle Definition angelegt und im Loadpoint als vehicle fest zugeordnet, erscheinen die Ladungen entsprechend mit dem Namen, den man unter title dem vehicle gegeben hat.

Daher tendiere ich jetzt doch wieder dazu, eine vehicle-Definition einzubauen. In meiner yaml ist sie jedenfalls drin:

- name: lambda
  type: template
  template: offline
  title: Lambda EU20L # mit diesem Namen taucht die Wärmepumpe am Ende als Fahrzeug in der Anzeige der Ladevorgänge auf
  icon: heater
  mode: pv # optional - mögliche charge modes: off, pv, minpv oder now

Mir ist auch nicht ganz klar, wieso hier für template "offline" verwendet wird.
Ggf. könnte man doch hier auch Werte von der Lambda noch abfragen, oder?
(Leider hat mir immer noch niemand diese Frage beantwortet)

D. Last but not least brauchen wir noch die Definition als loadpoint:

loadpoints:
- title: Lambda Wärmepumpe
  mode: pv # optional - mögliche charge modes: off, pv, minpv oder now
  charger: lambda_charger
#  meter: lambda_power # kann man machen, ist aber nicht notwendig. Erfordert dann die Definition unter A.
  vehicle: lambda # nur notwendig, wenn man einen Namen für die Ladeübersicht vergeben möchte. Erfordert dann die Definition unter C.
  priority: 1 # optional, wenn man den PV-Überschuss priorisiert der Lambda zukommen lassen will

Überraschend hierbei war noch, dass bei Verwendung des in den Beispiel-Templates angegebenen Eintrags
integrateddevice: true # Fahrzeugauswahl deaktivieren
evcc immer eine Fehlermeldung geschmissen hat.

Daher habe ich diesen Parameter einfach weggelassen. Eine Fahrzeugauswahl wird mir auch ohne diesen Eintrag im GUI bei diesem Loadpoint nicht angezeigt. Daher wird er vermutlich wirklich nicht gebraucht und die Doku ist hier ggf. nicht ganz aktuell oder eindeutig?

Die aktive Steuerung der Wärmepumpen von Lambda bzw. Zewotherm über das Register 102 ist ab der evcc Version 0.200.8 im Code enthalten. Ältere Versionen werden nicht bzw. nicht korrekt funktionieren.

Wäre super, wenn vielleicht noch jemand die zwei letzten offenen Fragen oben im Text beantworten könnte. 😄

Ich hoffe, dieser Thread hilft auch anderen Lambda / Zewotherm Besitzern, die über eine Steuerung durch evcc nachdenken.

Danke noch einmal an alle, die bei der Implementierung in evcc und der Erstellung von möglichen yaml-Definitionen mitgewirkt haben und an alle, die hoffentlich noch meine offenen Fragen beantworten werden.

Ein großes Dankeschön geht vor allem an @thecem, der viel Zeit ins Debuggen des noch nicht ganz perfekten Lambda-Templates gesteckt hat und ohne den ich entsprechend niemals an diesen Punkt gekommen wäre.

[andreas-bulling]

Wenn man sich die Modbus Dokumentation von Lambda ansieht stellt man fest, dass der Großteil der Register read-only (RO) ist. Einzig diverse Temperaturen (z.B. Vor- und Rücklauf, Temperaturedifferenz VL-RL, WW-Temperatur) kann man auch schreiben (RW). Insbesondere kann man per Modbus keine Leistungserhöhung/-werte konfigurieren.

Darf ich insofern nochmal nachfragen (auch auf die Gefahr hin, dass ich nerve), welche weiterführende Steuerung euch vorschwebt?

Man schreibt einfach den PV Überschuss in Register 102. Den Rest macht die Lambda mit den über die Steuereinheit eingestellten Werten. Sobald EVCC das Setzen dieses Registers unterstützt (würde vermutlich schon jetzt über einen entsprechenden Modbus Eintrag gehen) ist die Sache doch erledigt...

[TRON4R]

Kein Thema, ich dachte zwar, ich hätte Dir schon in #18812 erkennbar zugestimmt, dass es vermutlich der effizientest und sinnvollste Weg ist, der Lambda in Register 102 den PV-Überschuss mitzuteilen und dann die Automatik der Lambda den Rest übernehmen zu lassen.
Aber gerne bestätige ich auch hier noch einmal, dass mir keine weiterführende Steuerung vorschwebt. Eben weil, wie Du ja auch sagst, die Lambda zum einen zu wenige Register anbietet und zum anderen dann in evcc noch eine Menge Logik implementiert werden müsste, was mir vom Aufwand her nicht wirklich sinnvoll erscheint.

Der Lambda daher einfach regelmäßig den aktuellen Überschuss mitzuteilen, scheint mir daher der effektivste Weg zu sein und die Implementation dafür wurde ja auch bereits mit #19008 abgeschlossen, wenn ich andig richtig verstanden habe. Mehr brauche ich persönlich aktuell nicht und ich vermute mal, die allermeisten anderen Lambda-Besitzer wohl auch nicht.

Was mich aber noch interessiert:

• Ist das Interval, mit dem evcc das Register 102 beschreibt, identisch mit dem Interval, welches man in der GUI unter Konfiguration Regelverhalten → Aktualisierungsintervall einstellt (default 30 Sekunden)?
• Kommt die Lambda mit dieser Häufigkeit an Updates inklusive möglicherweise auch mal stark schwankender Werte (z.B. wenn jemand im Haus gerade einen Wasserkocher aktiviert hat) gut klar?
• Was ist mit dem Thema integrateddevice: true # Fahrzeugauswahl deaktivieren in der Loadpoint-Definition?

Vielleicht hast Du da ja noch die Antworten dazu?

[andreas-bulling]

Ich schreibe das Register bei mir über HomeAssistant - und zwar alle 5 Sekunden. Damit kommt die Lambda ohne Probleme klar. Es muss ja eine (einstellbare) Zeit lang ein bestimmter, minimaler Überschuss vorhanden sein, bevor sie auf den PV-Modus schaltet. Genau um das Regelverhalten zu "beruhigen".

[czam70]

Ist zwar für eine Kermi Wärmepumpe, aber realisiert für mich das gewünschte, also PV-Überschuss in Watt von EVCC an die Wärmepumpe übermitteln. Die geht dann gemäß der in der WP eingestellten Werte damit um. Ein Fahrzeug braucht man nicht zu definieren. Du kannst natürlich das bereits existierende Template für den Lambda Charger nutzen. Vielleicht hilft es:
#19214 (comment)

[TRON4R]

Danke für die Antwort, dass man wohl keine vehicle-Definition braucht.
In Deiner yaml-Definition nutzt Du noch bei chargers: die Einträge

  type: heatpump
  setmaxpower:
  ...

Was genau sollen die bewirken? Brauchst Du das "setmaxpower", weil das Template für die Lambda das schon beinhaltet, es aber noch kein fertiges Template für die Kermi Wärmepumpe gibt?

Und was genau bewirkt "type: heatpump" an dieser Stelle? Wird das für die Lambda auch nicht gebraucht, weil die schon laut Doku mit einem eigenen Template-Type namens "lambda-zewotherm" implementiert wurde?

Wenn ich alle Antworten zusammen habe, werde ich dann am Ende nochmal alles kompakt in einem Post auf das Wesentliche eingedampft zusammenfassen.

[czam70]

Was genau sollen die bewirken? Brauchst Du das "setmaxpower", weil das Template für die Lambda das schon beinhaltet, es aber noch kein fertiges Template für die Kermi Wärmepumpe gibt?

Genau. Ich bin der Template-Definition der Lambda gefolgt aber musste das eben manuell so definieren, weil es kein Kermi-Template gibt, aber seit kurzem den generellen Charger Type heatpump hier https://github.com/evcc-io/evcc/blob/master/charger/heatpump.go. Und der definiert, welche Parameter bzw. Keys genutzt werden können, darunter der für mich entscheidende setmaxpower. andig hat mich dabei angeleitet. Eine Dokumentation gibt es ja noch nicht. Wenigstens keine, die ich gefunden hätte.

Und was genau bewirkt "type: heatpump" an dieser Stelle? Wird das für die Lambda auch nicht gebraucht, weil die schon laut Doku mit einem eigenen Template-Type namens "lambda-zewotherm" implementiert wurde?

Ja, denn da sind setmaxpower (Überschuss mitteilen) und power (aktuelle Leistungsaufnahme) bereits definiert: https://github.com/evcc-io/evcc/blob/master/templates/definition/charger/lambda-zewotherm.yaml. Und das war dann meine Vorlage. Power brauche ich nicht weil ich ein separates Shelly-Meter nutze. Die Kermi lässt nämlich den Bezug weg, den sie nicht für Wärmeerzeugung zieht, also z. Bsp. die Abtauvorgänge. Mein Shelly misst natürlich alles. Hab dann zur Vereinfachung power weggelassen, und siehe da, es geht... Hätte ich aber natürlich auch definieren können, denn das Modbus Register kenne ich ja. Da ich aber als Meter das Shelly nutze habe ich es weggelassen. Aber ich bin auch nur Benutzer, keiner der Entwicklern und habe mir das nun so angelesen.

[TRON4R]

Eine weitere Frage habe ich noch zum Einsatz von Loadpoints zur Steuerung einer Wärmepumpe wie die Lambda.
Welchen Einfluss hat es auf die Wärmepumpen-Steuerung, wenn ich die diversen Modi wie z.B. PV oder Schnell auswähle?
Ich liste mal meine Vermutungen, aber es wäre super, wenn das auch noch jemand bestätigen könnte:

Aus = die Wärmepumpe wird von evcc aus nicht angesteuert, aber der aktuelle Verbrauchswert wird trotzdem weiterhin laufend angezeigt?

PV = der Wärmepumpe wird nur dann ein Überschuss gemeldet, wenn auch tatsächlich Überschuss vorhanden ist?
Kann man dann hier eigentlich auch in der yaml mit

enable:
      # einschalten, wenn 1 Minute lang mindestens 2000 W Überschuss vorhanden ist
      delay: 1m
      threshold: -2000

analog zu einer Wallbox den Wert definieren, ab dem die Wärmepumpe überhaupt erst einen Überschuss gemeldet bekommen soll?

Min+PV = der Wärmepumpe wird permanent ein Überschuss von mindestens der Wattzahl gemeldet, die sich aus der Einstellung von "Min. Ladestrom" ergibt? Also wenn man z.B. 1 A bei "Min. Ladestrom" eingestellt hat, wären das dann 690 Watt?

Schnell = der Wärmepumpe wird permanent ein Überschuss in Höhe des Wertes für "Max. Ladestrom" gemeldet? Also wenn man im Loadpoint 16 A eingestellt hat, wären das dann 11 kW?

Kommt das hin?
Das würde in letzter Konsequenz auch bedeuten, dass man hier schon sehr gut aufpassen muss, was man klickt. Denn wenn man den Loadpoint z.B. mal aus Versehen auf Min+PV oder Schnell stehen lässt, würde die Wärmepumpe auch noch nachts hindurch auf erhöhter Leistung arbeiten.

[czam70]

Ja ist für alle Optionen so wie du es oben beschreibst.
Auch ich spiele noch mit dem Threshold, aber prinzipiell ist es genau so und geht.

Für Min+PV ist es daher evtl ratsam, die WP in EVCC als Einphasig mit 1A Mindeststrom zu konfigurieren, auch wenn sie Dreiphasig angeschlossen ist. Spielt ja keine Rolle, geht nur um die Steuerung der Wattzahl, die EVCC dann zur Berechnung nutzt. Sonst hast du ja immer 690 W- Sprünge, auch für PV.
Bin noch nicht ganz dahinter gestiegen, wie EVCC den Überschuss genau berechnet, aber wird schon stimmen.

Und wenn Du das Template nutzen willst, solltest du die neueste Version installieren: e371969
Hatte mich bei meinen Recherchen schon gewundert, warum da für setmaxpower und power dasselbe Register drin stand.

[TRON4R]

Danke. Deine Bestätigung ist sehr hilfreich!
Und auf einphasig und 1A zu gehen, hatte ich auch schon überlegt. Warum man überhaupt die Zahl der Phasen für eine nicht über Phasen gesteuerte Wärmepumpe definieren kann, habe ich eh nicht ganz verstanden. Aber das klärt es jetzt teilweise.

Und wenn Du das Template nutzen willst, solltest du die neueste Version installieren: e371969

Das beantwortet dann gleich auch noch eine andere Frage/Vermutung, die ich hatte. Die Nightlies im Docker-Container zu installieren ist allerdings immer ein Extra-Aufwand, daher werde ich noch bis zum Release der 0.200.6 warten. Den Hinweis mit dem falschen Register hatte ich andig in dem Thread gegeben, daraufhin hat er es direkt geändert.

Jetzt sind nur noch meine ursprünglichen Fragen im ersten Post oben zu den yaml-Definitionen offen, dann wäre eigentlich alles geklärt.

[TRON4R]

Kann mir vielleicht noch irgendjemand kurz bestätigen, dass die Lambda bei ihm jetzt einwandfrei mit evcc funktioniert?

Ich bekomme leider - selbst mit ausgeschaltetem evcc(!) - in der Lambda nach kurzer Zeit die folgende rote Fehlermeldung im Fenster meiner Lambda Steuereinheit: "Alarm: E-Manager ungültiger Wert", sobald ich in der Konfiguration der Lambda im Bereich Energie Management → Konfiguration E-Manager die E-Meter Kommunikationsart auf ModBus Client umschalte.
Obwohl eigentlich nichts und niemand im meinem Netzwerk die Lambda ansprechen sollte (es gibt noch ein ModBus-Kabel vom Zählerschrank von einem Smartmeter dort, aber das sollte ja eigentlich nur im Setting ModBus EM300 eine Rolle spielen, oder?)

Anzeigeseitig klappt alles in evcc, aber sobald ich der Wärmepumpe sage, sie soll jetzt auf Modbus-Befehle horchen, schmeißt sie den Fehler. Selbst wenn von evcc wie gesagt nichts kommen kann, weil ich den evcc-Prozess abgeschaltet habe. 😞

[jannisif]

Zuerst mal, läuft eventuell eine andere Instanz von evcc?
Was sagt denn das Log? Ansonsten mal einen Wert (0) manuell in das Register schreiben? Oder den E-Manger neustarten, leider sehr versteckt...
Siehst du denn eventuell, was die Lambda im E-Manger anzeigt? also steht etwas dort, wo bei mir -0,04 angezeigt wird

[TRON4R]

Ja, siehe meinen Kommentar etwas weiter unten. Wenn ich mit modpoll einen Wert in das Register schreibe, taucht er sofort an der von Dir genannten Stelle auf. evcc hingegen hat keinen Einfluss auf diesen Wert.

Die Fehlermeldung tritt auf, wenn einen gewissen Zeitraum lang kein Wert geschrieben wird. Dann "kippt" das Register auf -32768 und dann gibt es den roten Warnbalken im Display der Pumpensteuerung. Schreibe ich dann einen Wert (wie z.B. 0) verschwindet die Warnung. Mache ich dann wieder nichts, tritt die Fehlermeldung irgendwann wieder (allerdings nach einer etwas längeren Zeit als direkt nach dem Aktivieren des Settings E-Meter Kommunikations auf ModBus Client.

Könnte das ein gewollter Timeout der Lambda sein, der melden soll, wenn ModBus-Kommunikation aktiviert wurde, aber dann keine Werte kommen?

[andreas-bulling]

Hast du in den Einstellungen "Neg. E-Überschuss" oder "Pos. E-Überschuss" ausgewählt? Das könnte ggf. noch das Problem sein. Ich schreibe den Wert jedoch nicht per evcc, sondern HomeAssistant. Aber ich hatte damals auch diese Fehlermeldung, als die obige Option noch falsch gesetzt war.

[TRON4R]

Die Idee hatte ich natürlich auch, dass es daran liegen könnte und habe entsprechend alle drei Settings durchprobiert: "Neg. E-Überschuss", "Pos. E-Überschuss" und "E-Eintrag".

Der Fehler poppte leider weiterhin auf (und ja, ich habe jedesmal die Fehlermeldung erstmal wieder gelöscht, indem ich die E-Meter Kommunikationsart von ModBus Client zurück auf Keine gestellt habe.

Ich würde erwarten, dass "Pos. E-Überschuss" das richtige Setting für evcc ist, oder? Weil evcc doch den vorhandenen PV-Überschuss als positiven Wert in Watt an die Charger meldet, oder?

[jannisif]

Hallo, ich melde mich mal wieder nach etwas längerer Abwesenheit.
Also erstmal stark, dass @SolarPowerEV dass nochmal alles zusammengefasst hast, vielen Dank dafür. Ich habe mir nun alles durchgelesen gehabt, aber irgendwie verstehe ich das von vorne bis hinten nicht.

Ich habe die 200.8 installiert, und wollte auf das Template umstellen: habe also den charger mit dem Template ersetzt und das Meter entfernt. Das Vehicle brauch ich vermutlich auch nicht mehr?!

Nun bekomme ich, egal in welchem Modus ich mich befinde, folgende Fehler angezeigt:
Wärmepumpe: max charge current 1A: invalid func code: 3 (pv Modus)
Wärmepumpe: max charge current 16A: invalid func code: 3 (schnell Modus)
...
Der WP soll doch nur Überschuss gemeldet werden und in keiner Weise gesteuert werden. Liegt das vielleicht daran, dass der Modbus-Zähler von Lambda dran ist? (den können wir noch nicht entfernen)

 loadpoints:

- title: W  rmepumpe
  charger: lambda_charger

chargers:
- name: lambda_charger
  type: template
  template: lambda-zewotherm
  # Modbus TCP
  modbus: tcpip
  id: 1
  host: 10.0.0.96 # Hostname
  port: 502 # Port

Und dazu kommt, dass mit der Version auch keine Energie angezeigt wird, also die "geladene" Energie (und auch die Zeit) fehlt.

[thecem]

Neg. E -Überschuss ist das Richtige wenn der Wert auch negativ werden kann.

Dann werden wir das Template mal schärfen, vervollständigen und dann in einer der nächsten Versionen geht es dann für alle.

[thecem]

@SolarPowerEV Dank Dir!

[TRON4R]

Ok, die Antwort ist easy:
Ich hatte als Untergrenze 2 A eingestellt. 2 A * 230 V = 460 Watt bei Min+PV
Und als Obergrenze 7 A eingestellt. 7 A * 230 V = 1.610 Watt bei Schnell

Anscheinend werden die Werte defaultmäßig einphasig berechnet, auch wenn der Loadpoint im GUI auf dreiphasig eingestellt ist

und die Anzeige im UI es auch dreiphasig darstellt:

Aber das ist jetzt "Jammern" auf höchstem Niveau. 😅

[thecem]

Ja die Lambda ist halt ne bitch!

[TRON4R]

Neg. E -Überschuss ist das Richtige wenn der Wert auch negativ werden kann.

Kann der Wert denn auch negativ werden? Also schickt evcc auch negative Werte an die Lambda?
In welchem Szenario würde ein PV-Überschuss denn negativ werden? Wenn der Hausakku einspringen muss, weil eine Wolke vor die Anlage gezogen ist?

Dann werden wir das Template mal schärfen, vervollständigen und dann in einer der nächsten Versionen geht es dann für alle.

Super. Ich bin schon gespannt auf das entsprechende Release.
Bitte beim Überarbeiten des Lambda-Templates drauf achten, dass Register 1011 auch noch ein scale: 0.1 braucht!

Eine letzte Frage noch:
Ich habe über Dein Template unten jetzt auch die Abfrage für das Register 1011 als Wert für energy in meiner Konfig hinterlegt:

 energy:
    source: modbus
    id: 1
    uri: Your-WP-IP:502
    register:
      address: 1011 # aktuelle Erzeugungsleistung (Q) der WP
      type: holding
      decode: in16

Wird dieser Wert dann in evcc ausschließlich im Beta-Bereich der Konfiguration angezeigt?

oder gibt es noch irgendeinen Weg, die Erzeugungsleistung auch im Loadpoint anzeigen zu lassen?

[thecem]

bitte mal wie hier eine config erstellen (allerdings mit template): #19214 (comment)
Wenn das nicht geht bitte mal:

chargers:
- name: lambda_wp
  type: heatpump
  setmaxpower:
    # PV Überschuss an WP übermitteln
    source: modbus
    id: 1
    uri: Your-WP-IP:502
    register:
      address: 102 # PV Überschussleistung
      type: writeholding # ist im template nur als holding hinterlegt
      decode: int16
  power:
    source: modbus
    id: 1
    uri: Your-WP-IP:502
    register:
      address: 103 # aktuelle Aufnahmeleistung der WP
      type: holding
      decode: int16

[TRON4R]

Wenn man anstelle von writeholding ein writemultiple im obrigen Template einsetzt, dann klappt alles!

Das vollständige korrekte Template lautet also:

chargers:
- name: lambda_wp
  type: heatpump
  setmaxpower:
    # PV Überschuss an WP übermitteln
    source: modbus
    id: 1
    uri: Your-WP-IP:502
    register:
      address: 102 # PV Überschussleistung
      type: writemultiple # ist im template nur als holding hinterlegt, deswegen klappt das V0.200.9 template nicht
      decode: int16
  power:
    source: modbus
    id: 1
    uri: Your-WP-IP:502
    register:
      address: 103 # aktuelle Aufnahmeleistung der WP
      type: holding
      decode: int16

[thecem]

Und wer mehr will testet das bitte noch:

Screenshots und feedback wäre nice!

chargers:
- name: lambda_wp
  type: heatpump
  setmaxpower:
    # PV Überschuss an WP übermitteln
    source: modbus
    id: 1
    uri: Your-WP-IP:502
    register:
      address: 102 # PV Überschussleistung
      type: writeholding # ist im template nur als holding hinterlegt
      decode: int16
  power:
    source: modbus
    id: 1
    uri: Your-WP-IP:502
    register:
      address: 103 # aktuelle Aufnahmeleistung (E) der WP
      type: holding
      decode: int16
  energy:
    source: modbus
    id: 1
    uri: Your-WP-IP:502
    register:
      address: 1011 # aktuelle Erzeugungsleistung (Q) der WP
      type: holding
      decode: in16
  temp:
    source: modbus
    id: 1
    uri: Your-WP-IP:502
    register:
      address: 2002 # aktuelle obere Warmwasserspeciher Temp
      type: holding
      decode: int16
    scale: 0.1

[TRON4R]

thecem:

Energy: Bei IDM wird die kumulierte Wärme angezeigt.

andig:

Wir sollten immer bei elektrischer Leistung bleiben

Sollte dann nicht das Template für die IDM auch entsprechend umgestellt werden?

[andig]

Und zumindest im Zusammenspiel mit meinen Alfen-Wallboxen gab es auch nie ein Problem.

Exakt. Die hat auch eine Phasenumschaltung. Das Thema ist durch.

[andig]

Sollte dann nicht das Template für die IDM auch entsprechend umgestellt werden?

kann nix schaden.

[TRON4R]

Exakt. Die hat auch eine Phasenumschaltung.

Ok, jetzt habe ich verstanden, wieso sich evcc bei meiner Alfen-Wallbox anscheinend anders verhält als bei meiner Wärmepumpe. Wenn man den Code nicht kennt, weiß man diese Details jedoch schlichtweg nicht.

Nachdem ich in der yaml den charger als 3-phasig definiert hatte, den Loadpoint auf 3-phasig umgestellt und den evcc-Dienst neu gestartet hatte, hat evcc in der Tat 1,38 kW bei Min+PV und 6,90 kW bei Schnell an die Lambda gemeldet, also 3-phasig berechnete Werte für 2 A und 10 A. Danke für den Hinweis.

Ich habe den Phasen-Eintrag in der YAML im allerersten Post entsprechend wieder gelöscht.

Aus Nutzersicht ist es jedoch m.E. unerwartetes Verhalten, wenn eine Änderung am Loadpoint einen Neustart erfordert, diese Notwendigkeit einem aber von evcc nicht kommuniziert wird.

Insbesondere, wenn es an anderen Stellen, wie z.B. bei einer Änderung des Aktualisierungsintervalls, durchaus kommuniziert wird:

Ist natürlich nicht tragisch, aber vielleicht kann man diesen Hinweis ja noch irgendwann auch für den Loadpoint einführen?

[andig]

Das ist wirklich nicht schön, deshalb #19706

[GuiHue]

Hallo zusammen,
Bisher mache ich PV Überschuss aus Home Assistant direkt. Ich glaube, dass dies soweit richtig eingerichtet ist. Ich kann einen Wert übertragen und er wird auch direkt angezeigt. Eingestellt ist POS E-Überschuss.
Ich habe eher Fragen zum Verhalten der Steuerung der WP:
Ich habe als Grundprinzip verstanden, dass die WP bei Vorhandensein eines Überschusses über dem Schwellwert (Leistungsanforderung Min) eine neue Vorgabetemp für den Puffer setzt. Anschließend versucht die Steuerung dieser Vorgabe gerecht zu werden. Soweit korrekt?
Ja ch beobachte folgendes: sobald der Modus Automatik im EManager gesetzt ist, geht die Temperaturvorgabe um den eingestellten Wert hoch. Und das bei einem übertragenen und angezeigten Wert von 0kW. Das passiert sofort, trotz Einschaltverzögerung von 5‘.

Habe ich einen Denkfehler?

[TRON4R]

wie kommst du eigentlich von 6,9kW auf PSoll 11kW, das kann keine Lambda Psoll ist E nicht Q.

Eine gute Frage. Ich habe mich auch über den hohen Psoll gewundert. Das scheint meist grob die Summe aus aktuellem Verbrauch und Register 102 zu sein. Wenn man also 6,9 kW in Register 102 schreibt zu einem Zeitpunkt, wo die WP schon mit >4 kW fährt, dann kommt das ungefähr in.
Ich habe jedenfalls da nichts manuell reingeschrieben. Das hat die Lambda selbständig gemacht basierend auf den Werten von evcc als ich mal 40 Minuten nicht vor dem Monitor gesessen habe.

Deinen anderen Kommentar beantworte ich voraussichtlich morgen, jetzt habe ich leider keine Zeit mehr.

[TRON4R]

1. timeout / 2 ist der write interval somit musst du 480 sec einstellen um einen alarm zu provozieren.

Ok. Danke. Dann weiß ich Bescheid.

2. Interessanterweise ist die Wärmepumpe dann allerdings nach dem Stellen von evcc auf Aus und dem Erreichen des Wertes von 0 in Psoll dann auch ganz aus gegangen. D.h. weil die Werte im Brauchwasserspeicher (der wird immer als Erstes von der Lambda aufgeheizt) und im Pufferspeicher dann nach so einer Überladung deutlich erhöht sind, geht die Lambda nach dem Ende ihres PV-Überschussprogrammes davon aus, dass sie erstmal gar nicht mehr gebraucht wird und schaltet sich ab statt weiter normal durchzuheizen (was sie bei der aktuellen Außentemperatur von 9 °C getan hätte, wenn ich kein Überschussprogramm gestartet hätte und auch tun würde, wenn man den Loadpoint nicht auf Aus gestellt hätte).

Hierzu gibt es im Forum eine genaue erklärung von mir was einzustellen ist, damit genau das nicht passiert. (Umschalteventil > 300sec && Vorlauf Max Temp in jeden HK 65 Grad). Bevor du fragst, teste es, alle bedenken sind haltlos!

Kannst Du die Stelle im Forum(?) nochmal bitte verlinken. Ich weiß nicht genau, welchen Post Du genau meinst.
Umschalteventil > 300 sec sagt mir auch nichts. Davon, alle Heizkreise bis auf 65 Grad aufzuheizen, hatte mir mein SHK-Installateur schon letzte Woche abgeraten als ich mit ihm die diversen Tests gefahren hatte. Er meinte, so hart an die Grenze zu gehen, stresst die Mechanik unnötig und sorgt vor allem auch für immer geringere COPs, je höher die Temperatur geht. Er schlug Temperaturen etwas über 60 Grad als Zielwerte vor.

Funktioniert denn das, was Du sagst, wirklich erst bei einer Überladung der Pufferspeicher auf 65 Grad?

Ich habe jedenfalls heute nochmal einen Test gefahren, und bei 57 Grad Zieltemperatur (eingestellt in evcc) ist evcc dann auch hingegangen und hat den Ladeprozess durch Schreiben von 0 ins Register 102 wie erwartet beendet. 10 Minuten später ist dann allerdings auch Psoll (ebenfalls erwartungsgemäß) auf 0 gegangen und daraufhin hat sich die Lambda dann - wie gestern schon - direkt abgeschaltet. Auch 25 Minuten später geht sie nicht wieder an, weil "Keine Anforderung" vorliegt, weil ja der Puffer überheizt ist:

Insofern sind meine Bedenken noch nicht so richtig zerstreut. Aber vielleicht liegt es ja noch an irgendwelche suboptimalen Settings in meiner Lambda-Steuerung.

3. Einschränkung:

• Warum muss das umgestellt werden?

Na um die Lambda bereit zu machen für die Fernsteuerung durch evcc. Das ist aber nicht die Ursache für das Problem.

• Wie lange hast du gewartet?

Ca. 10 Minuten gestern. ca. 8 Minuten heute.

• Warum muss evcc gebootet werden?

Z.B. weil ich die yaml editiert habe. Oder weil ich den Wert für das Aktualisierungsinterval im GUI umgestellt habe. Gründe für einen Neustart von evcc gibt es aktuell (leider) durchaus noch einige. Außerdem kann evcc ja auch mal abstürzen, weil der Docker Probleme macht oder neu gestartet werden, weil ich die ganze Synology neu booten musste.

• Ein Alarm wird es immer geben wenn kein Wert geschrieben wird, also auch wenn evcc oder der host zu lange bootet.

Das lange Booten oder ähnliches ist nicht das Problem. Das Problem ist, dass auch 10 Minuten nach dem Start evcc keinerlei Werte an die Lambda schickt, wenn der Loadpoint auf "Aus" steht.
Man muss nach einem Reboot von evcc wenigstens einmal kurz den Loadpoint auf etwas anderes als "Aus" stellen, damit wieder Werte in Register 102 geschrieben werden.

Ich kann das mit Logfiles unterstützen, wenn Du magst. Entweder hier oder aber in einem Bug-Report. Was auch immer Du bevorzugst.

[thecem]

Teste das bitte dann beim nächsten Release.
Lambda: Das sind nur Begrenzungswerte die keinerlei zusätzliche Belastung, höhere Temperaturen oder Schaden verursachen, aber das abschalten verhindern, da die Totzeit und die Temperatur Begrenzung erhöht. Es ist sogar insgesamt gesehen bessert als jetzt, da der Kompressor nicht abgeschaltet wird und die hohen Temperaturen beim umschalten (vom BW nach HK) nicht 20min anliegen sondern eben nur unter ca 2min. Das kannst du aber auch selbst messen.
Vorausgesetzt du hast das Mess Equipment . (ESPhome & ds18b20)

https://www.haustechnikdialog.de/Forum/t/256921/Lambda-Waermepumpe-Erfahrungen-und-Tipps?PostSort=0&page=35 FF

[TRON4R]

Ich habe mangels Überschuss (ich muss erstmal mein Auto aufladen) den λ-Loadpoint noch nicht auf PV gestellt, aber eines kann ich jetzt nach 14 Minuten Laufzeit definitiv sagen:

evcc schreibt auch mit der 0.201.1 und der Verwendung der Lambda-Definition aus der Doku keine Werte (in diesem Fall eine 0 wegen Loadpoint Aus) in Register 102 der Wärmepumpe:

Ich vermute weiterhin, dass der Watchdog erst dann startet, wenn man den Loadpoint wenigstens einmal kurz auf aktiv gestellt hat.

Bisher steht er seit dem Neustart halt so:

Und um Deine Frage zu beantworten, warum evcc "gebootet" werden musste:
Durch das Update auf die 0.200.1 hat der Docker-Container automatisch einen Neustart durchgeführt.
Außerdem wäre auch aufgrund des Hinzufügens der tempsource: in meiner yaml-Definition ebenfalls ein manueller Neustart erforderlich gewesen.

[TRON4R]

Einmal kurz im Loadpoint auf Min+PV geklickt, gewartet, bis der Alarm in der λ verschwunden ist, und dann wieder zurück auf Aus gestellt und jetzt scheint der Watchdog aktiv zu sein. Denn auch 6 Minuten später ist selbst bei ausgeschaltetem Loadpoint kein λ-Alarm mehr aufgetaucht.

Ich denke, das Problem könnte dadurch gelöst werden, dass der Watchdog immer direkt zusammen mit dem Start von evcc gestartet wird und nicht erst nach Aktivieren des Loadpoints.

[jannisif]

So, ich habe das Template eingesetzt und bekomme keine Fehlermeldungen, das ist schon mal super. Ich wiederhole mich: vielen Dank für eure Arbeit!
Demnächst lasse ich den Modbus-Zähler(erstmal nur softwaremäßig) entfernen und teste dann nochmal.

Jetzt habe ich eine Frage:
Was bewirken nun die Modi (Aus, PV, MinPV und Schnell)? Also wird bei 'Aus' einfach '0' geschrieben, bei 'PV' der tatsächliche Überschuss, was wird bei den anderen Modi geschrieben? Das ist mir aus den Beiträgen nicht ganz klar geworden.

[TRON4R]

Das hatte ich zwar schon in einem Post weiter oben beschrieben, aber hier nochmal mein aktueller Stand:

Aus → Es wird kein PV-Überschussprogramm gefahren. Der Watchdog schreibt aber brav 0 Watt in Register 102, um die Fehlermeldung in der λ-Steuerung zu vermeiden (sofern der λ-Loadpoint nach dem letzten evcc-Reboot wenigstens einmal kurz gestartet wurde)

PV → Programm startet nur, wenn Überschuss da ist und schreibt eine 0 in Register 102 sobald entweder kein Überschuss mehr da ist oder aber der im GUI am Heizregler eingestellte Zielwert erreicht wurde.

Min+PV → evcc legt direkt los und schreibt den Wert, den Du bei Min. Ladestrom eingestellt hast, in Register 102. (Also bei 3phasig und 1 A entsprechend 0,69 kW [3 * 230V * 1A] und bei 2 A entsprechend 1,38 kW). Höher geht der Wert dann nur, wenn es Überschuss gibt.

Schnell → evcc legt direkt los und schreibt den Wert, der bei Max. Ladestrom eingestellt ist, in Register 102. Also bei 8 A entsprechend dann 5,52 kW. Viel höher als 10 A würde ich bei der Lambda ehrlich gesagt nicht gehen. 6,9 kW sind schon eine Hausnummer und da Psoll dann auch noch immer den laufenden Strom mit einrechnet, ist man da schnell auf Psoll-Werten von deutlich über 8 kW.

Und lass uns bitte mal wissen, wie Deine Lambda sich verhält, wenn das PV-Überschuss-Programm komplett durchgelaufen ist (der Zielwert im GUI oder in der Lamba-Steuerung erreicht wurde).

[thecem]

@jannisif kannst du den Ladestrom auf min pv und 0.5 A stellen und mal schauen was die Lambda anzeigt? Und auch mal 10 min warten?

[LutzDi]

Guten Morgen in die Runde,

zuerst möchte ich mich bei allen beteiligten bedanken, die hier Ihre Zeit investieren, danke für Eure Unterstützung und Mühe.

Ich möchte mich gerne kurz hier einklinken, weil ich eine Verständnisfrage habe. Ich bin neu in EVCC eingestiegen, habe recht neu eine PV-Anlage, jetzt kommt noch ein EV dazu und ne Wärmepumpe ist auch schon da, nämlich hier benannte EU13-L von Lambda. Da ist die Zeit gekommen, sich mal mit PV-Überschuss zu beschäftigen und über das WE ist EVCC als HA Add-On eingezogen. Soweit habe ich auch alles am Laufen, muss EVCCs Denkweise noch etwas besser verstehen.

Danke Eurer Hilfe hier, habe ich die Lambda auch aus Ladepunkt/Fahrzeug im EVCC drin, die Kommunikation über Modbus funktioniert auch. Ich kämpfe allerdings ein bisschen mit dem Register 102 und dem Verhalten von EVCC. Wenn Überschuss vorhanden ist, wird dieser auch an die Lambda gesendet. Ist kein Überschuss da, führt das zu einem Registerwert von -32768, was die Lambda dazu bewegt, den roten Balken mit der Fehlermeldung anzuzeigen. Das ist ja auch hinlänglich bekannt. Ich mein mich zu erinnern, dass ich in einer früheren Diskussion mit dem Lambda-Support herausgefunden habe, dass der Wert für Register 102 dauerhaft geschrieben werden muss, damit er gültig bleibt. Wenn nichts mehr geschrieben wird, fällt der Wert auf Default = -32768 zurück, dann haben wir wieder die Fehlermeldung mit dem roten Balken. Ich habe dazu aber nix schriftliches mehr, nur in meiner Erinnerung.

Long story short: Ich sehe auch im Modbus-Tester, dass das Register 102 bei mir immer wieder auf -32768 fällt, wenn EVCC keinen Überschuss feststellt. Folgende Fragen habe ich:

• Könnt Ihr meine Erinnerung mit dem dauerhaften Schreiben von Register 102 bestätigen?
• Wenn ja, schreibt EVCC das Register dauerhaft, also auch wenn der Überschuss 0 ist?
• Wenn nein, wie schafft ihr es, dass der rote Balken nicht kommt?

Ich bin hier gerade etwas ideenlos, wie das Problem mit dem falschen Registerwert herkommt, vielleicht könnt Ihr mir auf die Sprünge helfen... Schon mal herzlichen Dank Euch allen..

Happy day.
L.

[andig]

[lp-1  ] DEBUG 2025/03/28 13:20:53 pv enable timer elapsed
heatpump: setting max current millis: 6.00 A

Eingeschaltet wird immer mit minA:

			elapsed := lp.clock.Since(lp.pvTimer)
			if elapsed >= lp.GetEnableDelay() {
				lp.log.DEBUG.Println("pv enable timer elapsed")
				return minCurrent
			}

Und im nächsten Zyklus bist Du schon bei maxA:

[lp-1  ] DEBUG 2025/03/28 13:21:12 pv charge current: 17.5A = 6A + 11.5A (-7968W @ 3p)
[lp-1  ] DEBUG 2025/03/28 13:21:12 pv timer reset
[lp-1  ] DEBUG 2025/03/28 13:21:12 pv timer inactive
heatpump: setting max current millis: 16.00 A
heatpump: calculated power: 11040 W (phases: 3)
heatpump: setting max power: 11040 W
[lambda_charger] TRACE 2025/03/28 13:21:12 modbus: send 00 04 00 00 00 09 01 10 00 66 00 01 02 2b 20
[lambda_charger] TRACE 2025/03/28 13:21:12 modbus: recv 00 04 00 00 00 06 01 10 00 66 00 01
heatpump: max power set successfully to 11040 W
[lp-1  ] DEBUG 2025/03/28 13:21:12 max charge current: 16A

Ich sehe kein Problem.

Deshalb meine Frage wie bekommen wir es hin der WP den Überschuss ins grid zu übergeben wenn der LP auf PV steht.

Genau das tut es.

[thecem]

Ok ich formuliere mal um:

Wie kann ich den Leistungswert am Grid Meter bei LP auf PV der Wärmepumpe übergeben?

[andig]

Du kannst gar nichts übergeben. Der Ladepunkt übergibt im PV-Modus den berechneten und priorisierten Überschuss an den Charger. Und genau das passiert hier.

Schließ einfach die WP hinter dem Zähler an, dann verschwindet dein vermutetes Problem. Oder: bau Dir einen "custom" Netzzähler der den richtigen Überschuss einschl. der WP zeigt. "Richtiger" Überschuss ist der, der auch die Leistung der WP enthält.

So wie Du Dir das vorstellst funktioniert es einfach nicht...

[thecem]

@TRON4R Entschuldige, aber euer Problem wird nicht gelöst werden können. Somit, müsst ihr die Pumpe weiter über Home Assistant mit dem Überschuss versorgen. Ich hatte es versucht.

[TRON4R]

Ich danke Dir für Deinen Einsatz @thecem .

Vielleicht kann @andig einfach mal einen Blick auf meinen extra zu diesem Zweck eröffneten Thread #20179 werfen?

Denn da findet sich eigentlich alles, wonach hier gefragt wurde:

• Ein über viele Minuten gehendes Logfile auf debug-level.
• Das Angebot, dieses um ein Logfile auf trace-Level zu ergänzen (das habe ich nur noch nicht hochgeladen, weil es zeitaufwendig ist, meine ganzen privaten Tokens da alle händisch rauszulöschen und die Arbeit wollte ich mir nicht antun, wenn nicht klar ist, ob es gebraucht und auch angeschaut werden wird)
• Meine Lambda-Wärmepumpe hängt auch ganz normal hinter dem Zähler. Auch das kann als Fehlerquelle damit ausgeschlossen werden.

Trotzdem ist die aktuelle Ansteuerung der Lambda unerwartet und unbrauchbar, weil die Werte sich extrem hochschaukeln. Für mich und zwei andere Lambda-Besitzer (ebenfalls in dem Thread verlinkt).

Vielleicht können wir in diesem Thread nochmal sauber starten? Ich bin gerne bereit, für @andig weitere Tests zu fahren und Logfiles zu liefern.

[andig]

Fürs Protokoll: "Überschuss" ermittelt evcc am Netzzähler. Verbraucher die vor diesem Zähler hängen sind für evcc nicht sichtbar. Dabei ist unerheblich ob es sich um Wärmepumpen, Wallboxen oder sonstwas handelt.

[thecem]

Wie auch immer, du schiebst gerade ein "Problem" vor, welches keines ist, da bei den Usern hier die WP so hängt wie du es beschreibst, nur mein Test system ist etwas anders, tut aber nichts zur Sache.

Die Lambda braucht bei PV den Überschuss am Netzzähler und das kann hier nicht zur Verfügung gestellt werden.

[andig]

Die Lambda braucht bei PV den Überschuss am Netzzähler und das kann hier nicht zur Verfügung gestellt werden.

Mit Verlaub, Du hast es nicht verstanden.

Wie auch immer, du schiebst gerade ein "Problem" vor, welches keines ist, da bei den Usern hier die WP so hängt wie du es beschreibst, nur mein Test system ist etwas anders, tut aber nichts zur Sache.

Ich kann nur mit den Logs arbeiten die ich kenne.

[andig]

Mit Verlaub, Du hast es nicht verstanden.

Ich versuche es nochmal: wenn evcc Überschuss sieht verteilt es den. Wenn danach immer noch Überschuss da ist verteilt es den zusätzlich, da alle Verbraucher mit dem aktuell zugewiesenen Budget ja schon aktiv unterwegs sind. Und genau das geht hier nicht weil der Verbraucher nicht sichtbar ist. Deshalb verschwindet der Überschuss nicht obwohl der WP Verbraucher hoch gefahren wird. Und deshalb wird er immer weiter hoch gefahren. Und weil dann immer noch Überschuss da ist noch weiter. Usw. Usf.

[TRON4R]

Bitte meinen Kommentar dazu etwas weiter oben lesen. Danke.

[gvonhof]

Hallo an alle Betreiber einer Lambda-WP.
Kann ich auch in den Sonnenlosen Monaten die Wp mit einem dynamischen Stromtarif steuern. Bei der Wallbox funktioniert es ja(Sofort laden), nur wie mache ich dies bei einer WP?

[1nv4d34]

Das würde mich auch brennend interessieren!

[thecem]

Nutze einfach Home Assistant und die evcc Integration, dann kannst fu über die Automatisierungen noch viel mehr machen.
Oder zusätzlich EOS mit EOS_Connect dann wird das ganze sogar über einen Optimierer gelöst.
Allerdings ist der Zeitraum pro Tag mit 120% nur 5,7h von Nov24 bis Mar25, hast du denn einen so großen (Puffer-)Speicher?

[TRON4R]

Braucht man dafür wirklich Home Assistant? evcc unterstützt doch das Einbinden der Tibber-Strompreise und dann kann man doch ganz einfach dem Loadpoint sagen, dass er immer dann starten soll, wenn ein bestimmter Strompreis unterschritten ist. Das sollte doch schon völlig ausreichen. Oder übersehe ich hier etwas?

Allerdings muss ich sagen, dass ich das Aufladen meines Pufferspeichers durch die Lambda mittels evcc erstmal auf Eis gelegt habe. Der auf dumme, aber schnell reagierende Wallboxen ausgelegte Algorithmus von evcc passt einfach nicht zur intelligenten und deutlich langsameren Steuerung der Lambda. Da schaukelt sich dann der gemeldete Überschuss-Wert solange hoch, bis er in die manuell eingestellte Ampere-Begrenzung des Loadpoints reinläuft. Und da bleibt er dann hängen, selbst wenn der Überschuss gegen Abend wieder runtergegangen ist.

Da zahlreiche Versuche von diversen Nutzern (inkl. @thecem und mir), die evcc-Kernentwickler davon zu überzeugen, für die Lambda, IDM und Kermi, einfach nur stumpf den freien Überschuss an die Wärepumpe zu melden, leider bislang alle fehlgeschlagen sind, habe ich das Thema erstmal drangegeben. In der Hoffnung, dass bis zum Herbst, wenn ich die Heizung wieder anstellen muss, vielleicht sich irgendwann die Erkenntnis weit genug durchgesetzt haben könnte, dass mindestens die Lambda, Kermi und IDM eine andere (simplere!) Ansteuerung brauchen als eine Wallbox.

[jomuench]

@gvonhof
hi, ich hab kürzlich eine lambda eu13l bekommen und möchte die mit evcc steuern, insbesondere das Thema dynamischer Stromtarif interessiert mich. Hast Du das bei Dir schon am Laufen, und magst Du die Konfig teilen?

[gvonhof]

Ich bin nicht weitergekommen.

Ende des Jahres will ja Lambda eine eigene Regelung anbieten
Jede Regelung im Netz arbeitet mit Temperaturerhöhung, ist im Winter aber uninteressant.
Habe bisher noch keine Regelung gefunden, welche alles über Modbus regelt. Wie die vorherige Diskussion gezeigt hat, hat auch EVCC noch keine auf Wärmepumpen angepasste Regelung
Also abwarten, oder einen festen Tarif verwenden.
Gruß

[andreas0maurer]

Ich habe das Thema Lambda in evcc jetzt schon eine Weile laufen und alles funktioniert wie es soll. Die Überschuss Meldungen sind alle nachvollziehbar und die Lambda reagiert.

Was jetzt noch schön wäre wäre die Erfassung der „Ladevorgänge“ bei normaler Benutzung in der Statistik.
Ohne PV Überschuss bleibt die Lambda für evcc im Standby und es wird kein Ladevorgang erfasst.
Wäre es möglich da eine Leistungsschwelle zu definieren ab der der Standby verlassen wird?

so sieht es bei mir gade aus:

[TRON4R]

Das dann aber bitte nur als abschaltbares Feature, weil wenn die Statistik wirklich jeden normalen Heizvorgang erfasst, ich am Ende meine echten E-Auto-Ladevorgänge in der dann endlos langen Liste an Lambda-Ladevorgängen kaum noch finden kann.

[TRON4R]

Was mich als Besitzer einer EU20L allerdings interessiert:
Sind die 1,3 kW Verbrauch bei Dir der typische "Dauer"-Wert? Also der Strom, den die Lambda zieht, wenn sie sich eingependelt hat und der höhere Verbrauch unmittelbar nach dem Start des Verdichters vorbei ist?
Und was ist der niedrigste Verbrauch, den Dir Deine Lambda jemals angezeigt hat?

Ich frage, weil ich gerne wüsste, ob ich in der Übergangszeit mit der EU15L vielleicht doch etwas Strom gespart hätte, weil die weiter runter modulieren kann als die EU20L oder ob das nicht der Fall ist.

[andreas0maurer]

Moin, das ust eine EU15. Unter 700 watt komme ich nicht. Die 1,3 kw waren vom Start.
Die 700 sind die Angabe der WP. Ich erfasse aber eigenlich den kompletten verbrauch per Zähler davor und liege da bei minimal 830 watt.

umd die ladevorgänge liste kannst einfach per klick auf den Spaltenkopf filtern :)

[TRON4R]

Spannend. Mein niedrigster jemals in der Anzeige gesehener Wert für meine EU20L lag bei 0,8 kW. Das war aber nur genau einmal an einem kühlen Augusttag und der COP hatte da sensationelle 10,49. Ein anderes Mal hatte ich 0,9 kW bei einem COP von 8,49.

Was ich häufiger sehe sind Werte um die 1,1 kW bei COPs von 6 bis 7. Aktuell zum Beispiel. D.h. weiter runtermodulieren kann sie dann nicht mehr und geht irgendwann für eine gewisse Zeit aus, bis der Puffer dann wieder zu kühl wird.

Meine Angaben stammen auch alle aus der Anzeige der Lambda. Ich habe allerdings auch einen separaten Stromzähler, der den Verbrauch der gesamten Anlage inkl. Heizkreislaufpumpe, Ladepumpe, Displays und anderer heizungsbezogener Verbraucher wie z.B. der FriWa-Station. Aber das in den Stromverbrauch reinzurechnen, finde ich je nach Umständen nicht ganz fair, denn eine Öl- oder Gasheizung benötigt diese Geräte ja auch alle und da berechnen die meisten nur den Öl- oder Gasverbrauch und vergessen den Stromverbrauch in den Vergleich einzubringen.

Und ja, natürlich hat evcc Filterfunktionen. Aber die ganzen Statistiken laufen dann schon aus dem Ruder, wenn dann zu den jährlichen 2.500 kWh Autostrom plötzlich noch >6.000 kWh Heizungsstrom dazu kommen. Ich möchte das jedenfalls nicht in evcc erfassen, wenn es kein PV-Überschuss-Boost war. Denn meine Lambda erfasst ja auch alle Verbräuche.

[vonHyne]

Quote TRON4R :Des Weiteren gibt es leider keinen Konsens, was die beste Steuerung der Lambda angeht. Einige Besitzer einer Lambda-Wärmepumpe, darunter auch @thecem und ich sind der Meinung, dass Lambda eigentlich nur will, dass man in Register 102 laufend den aktuellen PV-Überschuss (in evcc im gelben Balken im GUI und bei "Einspeisung" angezeigt) schreibt und den Rest dann die Lambda selbst machen lässt.

Zu diesem Thema möchte ich meinen letzten Austausch mit dem LAMBDA-support beitragen. Es geht darum, wie der E-Manager der Betriebsmodus in welchem Fall zu konfigurieren ist:
'wenn Sie die Regelung mittels E-Überschuss (ob positiv oder negativ ist nur eine Frage der Flussrichtung) nutzen wollen, wäre es ideal, wenn Sie den rohen Wert des Smart-Meters ohne weitere Filterung oder Verzögerung in einem Intervall von ca. 2-10 Sekunden übermitteln. In dem Fall ist es auch erforderlich die Option "Batteriespeicher vorhanden" zu aktivieren, für die jetzige Steuerung mittels E-Eintrag ist sie gleichgültig. '

Ursprünglich hatte der Support 'E-Eintrag' konfiguriert. Ich hatte in Register 102 (PV-Überschuss) alle 4 Minuten einen selbst gemittelten PV-Überschuss - Wert geschrieben, den die Lambda verbrauchen sollte und das hat aufs erste Draufschauen so funktioniert
Jetzt warte ich auf PV-Überschuss, ob die Lambda die direkte Eingabe vom E_-Meter sinnvoll bearbeitet.

Ich hole die Werte von der SMA-Integration in Home-assistant.
Da ich gerade dabei bin, eine wallbox auszusuchen, ist meine Fragestellung, ob ich die übergreifende PV Überschusskontrolle mit den Verbrauchern Lambda, Heizstab und dann eben wallbox weiterhin in home-assistant realisiere oder, ob es Sinn macht, die evcc - Lösung zu wählen. Ich weiß im Moment nur, dass ich es nicht mit SMA- wallbox und Steuerung machen möchte. Ich bin für jegliche Anregung dankbar.

[TRON4R]

Zu dem besseren Funktionieren der einen oder anderen Methode kann ich nichts sagen, da ich noch nicht beide parallel betrieben und verglichen habe. Aber interessant, dass Lambda neben dem positiven Überschuss auch die Meldung von negativen Überschüssen (sprich Netzbezug) haben will. Ich weiß gar nicht, ob das Skript von @thecem das auch unterstützt. Ich vermute fast, dass das nicht der Fall ist, weil er ja beide Einstellungen "pos. E-Überschuss" und "neg. E-Überschuss" supportet.

Wallboxen sind ein schwieriges Thema. Ich habe Alfen genommen. Die sind grundsätzlich sehr robust und tun jetzt seit 2021 klaglos ihren Dienst. Die Firmware wird 3 bis 4x im Jahr geupdatet und da waren auch schon ganz gute neue Features dabei. Aber die Hardware ist nicht gerade günstig.

Von vielen evcc-Usern werden ein oder zwei Wallboxen empfohlen, weil die gut und günstig sind. Irgendwo auf evcc.io gibt es auch eine Liste, wo Nutzer einfach ihre Wallboxen eingetragen und ihre Meinung dazu geschrieben haben, das ist bestimmt auch hilfreich.

Am Ende würde ich eine lokal über Modbus via TCP anzusteuernde Wallbox für evcc immer gegenüber OCPP oder anderen Cloudbasierten Systemen vorziehen.

Und rückblickend ein günstiges Modell und vor allem ein Modell mit 22 kW Support nehmen. Weil bis zu 32A, selbst wenn Dein Auto heute nur 11 kW kann, auch beim einphasigen Laden Vorteile hat und fast alle Autos einphasig bis zu 7,2 kW unterstützen.

evcc statt der SMA-Steuerung für das Auffüllen der Batterie würde ich nicht empfehlen. Nichts steuert so schnell wie ein guter Wechselrichter. Ich glaube auch nicht, dass SMA Strom verschenkt. Die reagieren normalerweise wie alle Wechselrichter im Millisekunden-Bereich. Nur weil die App vielleicht 30 Sekunden lang eine Netzeinspeisung anzeigt, heißt das nicht, dass Du 30 Sekunden lang Strom an die Stadt verschenkt hast!

[tr8hippo]

Erstmal ist es ja der Wahnsinn, wie intensiv ihr euch mit den guten Geräten auseinandersetzt.
Nun wollte ich einen neuen Anlauf nehmen und die Lambda über das Template von TRON4R einbinden.
Leider komme ich nicht mehr wie früher in die Konfiguration. Irgendwie ist in der Doku von evcc einiges geändert worden. Scheinbar ist es nun eher gewollt, dass wir es über den Browser machen. Mein Problem ist dann aber, dass zwar die WP angezeigt wird, auch eine "Buffer-Top" Temperatur und der Gesamtverbrauch des Gerätes in kWh - der Momentanverbrauch und das Symbol oben in der Leiste werden aber nicht angezeigt. Zählt dann alles als "Hausverbrauch".
Hättet ihr da aktuell nen Tipp, wie ich das angehen könnte?
PV Überschussladen und co ist mir eigentlich egal. So detailliert brauche ich es nicht. Wäre zwar nett. Aber ist auch nicht dramatisch. Wenn genug Überschuss da ist, ist auch die Batterie voll und hält die WP nachts am laufen. Wenn nicht genug Überschuss da ist, genügt es auch nicht für meine Batterie (wie aktuell) und der Bums kommt halt ausm Netz.

Danke und schönen Abend :-)

[TRON4R]

Also ich habe jetzt leider nicht die Zeit, mich hier im Detail mit allen potentiellen Details auseinanderzusetzen, an welcher Stelle meine Doku vielleicht veraltet sein könnte und deswegen nicht läuft, weil sich iterativ immer wieder irgendetwas bei einem der beteiligten Elemente verändert hat. Und ich fahre auch weiterhin evcc mit meiner evcc.yaml, weil ich keine dringende Veranlassung gesehen habe, alle meine Geräte noch einmal neu einzugeben, nur um dann am Ende irgendwelche exotischeren Einstellungen doch weiterhin über die YAML fahren zu müssen. Daher warte ich mit dem Umzug lieber noch etwas ab, denn aktuell läuft auch alles und solange die YAML offiziell noch voll unterstützt wird, halte ich mich an den Spruch "never change a running system".
(Wenn sich evcc den einen oder anderen Neustart ersparen würde (z.B. beim Eintragen oder Löschen der PIN für den Fiat 500e oder beim Ändern des Wertes des Aktualisierungsintervalls), dann wäre das für mich noch ein Grund, den Aufwand zu machen. Aber bis dahin nutze ich das, was funktioniert.)

Um Dir aber vielleicht ein bisschen helfen zu können:
Das ist der Auszug aus meiner aktuellen YAML, der alle (potentiellen) Definitionen für die Lambda enthält samt Kommentaren, was funktioniert und was nicht funktioniert (Abweichungen der Doku von der Realität):
evcc_nur_lambda_definitionen.yaml

Da ist jetzt auch das besagte Script von @thecem zur PV-Überschussregelung nach Vorgabe von Lambda (also das simple regelmäßige Melden des PV-Überschusses an Register 102 der Lambda) mit drin enthalten, aber das kannst Du Dir ja zur Not auch wieder ausbauen oder einfach ignorieren und nicht benutzen. Es wird sowieso nur aktiv, wenn man den Loadpoint auf etwas anderes als Aus stellt.

Ich hoffe, Dir damit etwas weitergeholfen zu haben. Nur bei der Frage, wie man das über das GUI eingegeben bekommt, kann ich Dir wie gesagt mangels eigener Erfahrung nicht weiterhelfen. Ich würd's einfach in die evcc.yaml klatschen, wenn ich Du wäre.
Wo es bei Dir genau hakt, ist ohne Kenntnisse der Umgebung schwer zu sagen. Aber wenn Du es in Home Assistant als Addon installiert hast, dann haben sich einfach nur die Pfade für den Ort der evcc.yaml geändert. Da sollte Googlen schnell weiterhelfen.

Aber es muss auch über die UI gehen, denn @thecem hat ja auf seiner Seite für das Lambda-Überschusssteuerungs-Script auch Varianten für die Nutzer der UI bereitgestellt:
Lambda Konfiguration evcc UI (linux based images)
und
Lambda Konfiguration evcc UI (linux based images & Auto-Install Dependencies in Docker)

Wenn Du eine Lösung für Dich gefunden hast, sag hier bitte kurz Bescheid, was zur Anpassung nötig war, damit dann wiederum andere nach Dir davon auch profitieren können. Dann ergänze ich das auch gerne noch oben im Eingangspost.

[vonHyne]

Nur ganz kurz, nachdem es gerade trotz Schnee und kurzer Tage auch viel Sonnenschein hier in Tübingen hatte, konnte ich verfolgen, wie die Einstellung Betriebsart 'pos. E-Überschuss' in der Lambda funktioniert. Dabei ist mir auch klar geworden, warum man auch negative Werte (also Defizit) kurzzyklisch in das Register 102 schreiben muss. Bei 0 macht die Lambda einfach mit den höheren Soll-Temperaturen weiter erst bei Negativwerten regelt er mit seiner eigenen Logik wieder herunter).

[premultiply]

Ja, das ist aber keine neue Erkenntnis.

Die Software erwartet die aktuelle Leistungsmessung eines dummen externen Zählers. Im Fall "Überschuss" der Netzzähler (grid meter), andernfalls die Erzeugungsleistung. "Pos" und "Neg" dreht das Vorzeichen um.
Soweit so sinnlos.

Am Ende tun es wie immer einfache logische Werte (ja/nein) für Boost und Dimmung (SG-Ready).

Es macht keinen Sinn einer WP irgendwelche aktuellen schnell schwankenden Messwerte vorzusetzen.
Die Maschine und die Senke ist langsam und träge.
Wenn viel Energie verfügbar ist braucht man sie am wenigsten.