Die von evcc an die Lambda gemeldeten PV-Überschuss-Werte sind zu hoch

[TRON4R]

Gerade eben habe ich die 0202.1 getestet.
Nachdem im ersten Schritt der in Register 102 der Lambda angezeigte Wert mit 0,35 kW auch Sinn machte (3x230Vx0,5A = 345 Watt), konnte ich das für die danach geschriebenen Werte leider nicht mehr sagen.

Denn der nächste in Register 102 angezeigte Wert war dann 4,96 kW (den bekomme ich weder durch 3 Phasen noch durch 230 V sauber geteilt und außerdem betrug der von evcc im GUI angezeigte Überschuss zu dem Zeitpunkt nur 4,8 kW):

Noch seltsamer wurde es dann danach, denn dann stieg der Wert in Register 102 sogar auf 6,90 kW. Das entspricht zwar dem im λ-Loadpoint eingestellten Max. Ladestrom Wert von 10 A (3x 230 V * 10 A = 6.900 W), aber der λ-Loadpoint steht im PV-Modus und nicht auf Schnell und der tatsächliche Überschuss lag nur bei 4,7 kW:

Wenn ich dann den Max. Ladestrom Wert im GUI runtergesetzt habe, sank der Wert in Register 102 auch entsprechend mit. Aber der tatsächliche Überschuss war weiterhin darunter, d.h. scheint bei der Berechnung keine (ausreichende) Rolle zu spielen. Das hier kam bei 6 A Max. Ladestrom im λ-Loadpoint raus:

Das entspricht zwar rechnerisch wieder dem Maximalwert, lag aber auch weiterhin über dem zwischenzeitlich gesunkenen Überschuss.

Anbei noch das debug.log
evcc-20250327-162204-debug.log

Das trace.log habe ich auch gespeichert und lade ich bei Bedarf gerne noch hoch.

Dasselbe Problem wurde ebenfalls von @softservicegit und @LutzDi berichtet.
Siehe in #19384 ab diesem Punkt im Thread.

[VolkerK62]

Was würdest du erwarten?
Du hast die ganze Zeit massiven Überschuss. Also wird immer weiter erhöht.

[LutzDi]

Und noch eine prinzipbedingte Anmerkung: selbst wenn evcc nur den exakten Überschuss schreiben würde (#20286) wäre das im Allgemeinen immer noch nicht "richtig". Denn es kann durchaus >1 Gerät geben das träge ist und Überschuss konsumieren möchte. Es gibt aktuell keinen Balancing Algorithmus der Überschuss aufteilen würde sondern nur first come, first serve.

Ich denke, das ist auch vollkommen i.O. Die Lambda zumindest rechnet sich daraus einen Durchschnitt aus und regelt passend nach. Ja, das ist deutlich träger als eine WB, aber das passt schon. Heute z.B. war es bei uns fast im Minutenwechsel bewölkt und sonnig und wir sind in 2-min-Rhythmen von 300W auf 4000W gesprungen. Das muss die WP glätten, da kommt sie nie hinterher. Insofern gar nicht so einen großen Kopf machen, stumpf liefern, was da ist (ich würde das alle 5s oder 10s machen) und den Rest die WP machen lassen. Das passt schon, denn nichts andere liefert der Smart-Meter, wenn ich den direkt anschließe. Über diesen Punkt sollten wir gepflegt drüber weggehen und einfach liefern, was der Zähler misst..

Dann muss du mir bitte sagen wo konkret. Auch auf den zweiten Blick zeigt dein (debug) Logfile immer Einspeisung, es gibt also keinen Grund die WP runter zu regeln. In das trace muss man eigentlich nicht schauen- der gesetzte Strom findet sich hinter max charge current: x.yA auch im debug log.

Noch ne Frage: kann es sein, dass das der Wert charge power im Log ist und nicht max charge current?

Zu meinen Ergebnissen heute komme ich noch, heute war wegen wechselnder Bewölkung und Arbeit kein guter Tag, um zu "spielen". Ich mach jetzt Tests mit meiner individuellen Konfig und auch mit dem Standard-Template, um es vergleichbar zu machen. Ich hoffe, ich finde dann das Passende auch im LOG. Melde mich dazu wieder.

[andig]

Noch ne Frage: kann es sein, dass das der Wert charge power im Log ist und nicht max charge current?

Charge power ist die gemessene Leistung der WP. Max charge current ist der von Ladepunkt gesetzte Strom (evcc tickt aktuell nur in "Strom"). Neuer Strom wird nur gesetzt wenn er sich ändert.

[LutzDi]

Kurzer Zwischenstand: Ich habe leider wieder keine optimale Wettersituation heute gehabt, ich hoffe weiter. Bisher ist das Problem nicht weiter aufgetreten. Ich prüfe weiter.

Darf ich Euch noch eine Frage stellen? @thecem, Du hast mir eine evcc.yaml gegeben, über die wir schon mal diskutiert habe und ich eine gewisse Idee geäußert habe. Wo genau kann ich denn mal den "echten" Code nachsehen, welche Logik evcc nutzt, um das Thema Überschuss für die Heatpump zu berechnen. Ist das der Code-Snipsel, den Du @thecem mir gegeben hast? Ich will einfach ein bisschen besser verstehen, wie evcc funktionieren soll, um ggf. meinen Test passend daran auszurichten... Freue mich über ein bisschen Input... Thx.

[mathiasmora]

@LutzDi: Es gibt jetzt einen PR der den realen Verbrauch der WP miteinbezieht. Dadurch wird die Berechnung des PV Überschuss für Heatpumps angepasst. Bin zuversichtlich das damit die Berechnung des PV Überschuss korrekt ist. Auch gerne mit der neusten Nightly testen. Da sollte der PR schon drin sein. Ich werde es morgen mal mit meiner IDM WP testen. #20286

[andig]

Es gibt jetzt einen PR der den realen Verbrauch der WP miteinbezieht. Dadurch wird die Berechnung des PV Überschuss für Heatpumps angepasst.

Gibts hier noch was zu tun? Was?

[LutzDi]

@LutzDi gerne mal ne PM über slack

@thecem, mache ich gerne, wenn Du mir verrätst, wie ich Dich auf Slack finde? Ich habe heute an Lambda geschrieben, da das Verhalten bez. der Temp. Erhöhung nicht ok ist... Erzähle ich Dir dann auf Slack... L.

[TRON4R]

Ja, klar. Meine größere Wärmepumpe (EU20L) und der dicke Puffer sorgen sicher für andere Umgebungsbedingungen.

Trotzdem finde ich die Aussagen von Hr. J etwas fragwürdig, weil die Behauptung, dass ein Nullwert nicht ausreichen würde, um ein Überschussprogramm zu verhindern, weder logisch Sinn macht noch mit meiner oft wiederholten Erfahrung übereinstimmt (wo die 0 sogar bereits aktive Programme beendet. Auch lange bevor irgendwelche in der Lambda gesetzten Schwellwerte erreicht wurden!). Und das auch nicht zur offiziellen Doku passt, die gerade erst vor wenigen Tagen von der 1.1.6 auf die 1.1.7 geupdatet wurde.

Deswegen habe die gerade noch ein paar Zweifel. Ich werde aber auf jeden Fall morgen mal mit der Einstellung E-Eintrag etwas herumtesten und berichten.

[LutzDi]

Wenn J. mich morgen zurückruft, werde ich ihn quizzen... Wenn ich mich morgen beim Duschen nicht mehr verbrühe, dann bin ich schon einen Schritt weiter... 😃

[LutzDi]

@TRON4R, welche Werte für min. und max. Ladestrom hast Du bei Dir im EVCC eingestellt?

[TRON4R]

Nichts Dauerhaftes. Ich bin noch am Testen. Eigentlich macht es ja wenig Sinn, dort einen Wert einzustellen, der höher ist als der Wert "Leistungsanforderung Maximum:" in der Lambda.

Aber aktuell muss ich leider den Max. Ladestrom auch dazu nutzen, um evcc davon abzuhalten, viel zu hohe Werte an die Lambda zu melden die mit dem tatsächlich vorhandenen Überschuss nichts mehr zu tun haben. Wenn ich da z.B. 16 A einstellen würde, dann würde evcc nach ein paar Minuten auch 11 kW an die Lambda melden, selbst wenn gerade nur 4 kW Überschuss vorhanden sind. Daher steht es bei mir eigentlich meist auf 8 A.

Aber ich hoffe ja mal, dass wir mit einem der nächsten Releases vielleicht doch evcc dazu bekommen, den tatsächlichen Überschuss in Register 102 zu schreiben und nicht irgendwelche anderen (viel zu hohen) Werte.

[TRON4R]

Übrigens hat das OpenWB-Projekt schon vor 2 Jahren dieselbe Diskussion geführt:
https://forum.openwb.de/viewtopic.php?t=5380&start=150

Die kommen zu demselben Ergebnis: es reicht völlig, wenn man der Lambda immer nur den aktuellen Überschuss meldet und die Lambda dann entsprechend auf Pos. E-Überschuss einstellt. Alle zusätzlichen Optionen (E-Eintrag oder Neg. E-Überschuss) gehen alternativ natürlich auch, machen es aber nicht besser.

[LutzDi]

Gute Tag zusammen,

erste positive Nachricht. Mein WW-Problem ist gelöst. Alles ruhig und die Temp bleibt wie sie sein soll über Nacht. Einstellung wie gesagt E-Eintrag.

Ich habe auch nochmal mit Lambda telefoniert: Die Grundidee ist einfach, sie bieten einfach beides an. Du kannst entweder stumpf die Daten eines Zählers übergeben und dann mittels E-Überschuss den Rest die WP machen lassen. Dann rechnet Sie Ihren eigenen Verbrauch und auch Residual Power selbst mit ein und um. Wenn Du eine "fremde Intelligenz" wie evcc hast, die das berücksichtigt, dann stellst Du einfach auf E-Eintrag um und die Lambda bekommt wirklich nur den verfügbaren Überschuss und arbeitet danach. Du hast einfach nur 2 Möglichkeiten.

Nun aber zurück zu unserem eigentlichen Thema, den Werten, die evcc übergibt und da habe ich bei dem Traumwetter heute schon Ergebnisse produzieren können.

Und ich kann sagen: Des funktioniert nicht. Was ich jetzt gesehen habe, ist Folgendes:

• Ich nutze das Standard-Template für Lambda, über die UI eingerichtet. Wenn Ihr bestimmte Settings braucht, lasst es mich bitte wissen
• Zur Info vorab, ich habe Max. Ladeleistung von 8A eingestellt = 5.520 W
• Es gibt viel Sonne im Moment, dennoch kam bisher max. ca. 4.200 W vom Dach. Also können 5.520 W niemals eingetreten sein als Überschuss. Meine Anlage ist auch zu klein dafür.
• Dennoch hat EVCC der WP z.B. um 09.13 Uhr max charge current: 8A geliefert. Zu diesem Zeitpunkt lag die Leistung vom Dach bei ca. 1800 W, der Überschuss ins Netz lag bei ca. -1.300 W. Das wurde auch so im HA aufgezeichnet. Siehe Log von EVCC:

[site ] DEBUG 2025/04/03 09:13:43 ----
[lp-1 ] DEBUG 2025/04/03 09:13:43 charge power: 0W
[site ] DEBUG 2025/04/03 09:13:43 grid power: -1230W
[site ] DEBUG 2025/04/03 09:13:44 pv 1 power: 1800W
[site ] DEBUG 2025/04/03 09:13:46 grid currents: [-3.11 -2.86 -3.33]A
[site ] DEBUG 2025/04/03 09:13:47 site power: -680W
[lp-1 ] DEBUG 2025/04/03 09:13:47 charge total import: 37.068kWh
[lp-1 ] DEBUG 2025/04/03 09:13:47 charger status: C
[lp-1 ] DEBUG 2025/04/03 09:13:47 pv charge current: 8.19A = 7.21A + 0.986A (-680W @ 3p)
[lp-1 ] DEBUG 2025/04/03 09:13:47 max charge current: 8A
[site ] DEBUG 2025/04/03 09:13:47 solar forecast: accumulated 5.091kWh, produced 4.115kWh, scale 0.808

• Das gleiche habe ich so nochmal um 10.13 Uhr, selbes Schema, andere Werte, denn da lief z.B. die WP bereits im Überschussmodus
• Hier nochmal eine paar Screenshots vom 11:48 Uhr, ähnliches Thema. Bitte entschuldigt die Screenshots, kann aktuell nur vom Smartphone arbeiten. EVCC = Werte von EVCC, Huawei WR + SM = Werte vom Wechselrichter und SmartMeter, Wärmepumpe = Werte von der Lambda

Es gibt in den Screenshots 1.162 W Überschuss, der ins Netz geht, die WP bekommt aber 5.520 auf Register 102 geliefert. Gerne dazu auch nochmal den Verlauf des Registers 102 über den heutigen Morgen.

Interessant ist, dass es ab einer gewissen Uhrzeit so gut wie keine Stufen gibt und dann fest auf 5.520 W stehen bleibt, dann wieder auf 0 und dann wieder auf 5.520, wo es jetzt aktuell wieder steht.

Ich hoffe, das hilft weiter. Wenn Ihr mehr braucht, lasst es mich bitte gerne wissen.

[premultiply]

Bei "Max" gibt es ohnehin nix zu glätten und der echte Bereich der Regelung (also wenn PV-Überschuss vorhanden aber nicht ausreichend um alle aktiven Ladepunkte mit maximaler Leistung zu bedienen) bedürfte eines aussagekräftigen Logs dass es dann nicht richtig funktioniert.

Gut möglich, dass die tatsächlich so ist (z.B. auf Grund der Trägheit des Systems) aber bisher her gibt es hier für mich vor allem viele Fehlinterpretationen und Theorien die den Blick auf die Realität vernebeln.

[LutzDi]

Dann mag es an mir liegen, von daher freue ich mich, wenn Ihr Wissenden ein bisschen zur Lösungsfindung beitragen würdet, anstatt das Problem zu negieren. Das ist nicht hilfreich. Viele Teilnehmer hier geben ihr Bestes, aber werden immer wieder abgewiegelt. Wenn Du kannst, dann löse den Nebel auf.

[LutzDi]

Guten Tag zusammen, gibt es eine Idee, wie wir hier weitermachen? Oder beerdigen wir die Diskussion? Ich biete gerne nochmal an, alles zu liefern und zu testen, was ich kann, um unterstützende Klarheit zu liefern, wäre um konkrete Ideen dankbar, wie wir gemeinsam zu einer Lösung kommen. Thx for info...

[premultiply]

Steht ja oben.
Gibt es nachweislich ein echtes Problem in der Steuerung oder irritiert nur dass bei genügend Überschuss der Maximalwert irgendwo im WP-System angezeigt wird?

[LutzDi]

@premultiply, wenn ich darf, dann mache ich Dir mal kurz meine Situation klar, ggf. kannst Du Dich etwas mehr in meine Lage versetzen. Ich habe über alle diese Dinge ein recht gutes Grundverständnis und glaube auch, dass ich recht gut darin bin, Dinge in Abhängigkeit zu bringen und Ursachenforschung voranzutreiben - das nicht zuletzt aus meinem Job als Projekt-Manager im IT-Bereich. Was ich nicht habe, sind a. tiefe Programmierkenntnisse, da gibt es deutlich bessere als mich und b. keine Kenntnis über die Logik von EVCC - sei es in Ermangelung von Dokumentation an sich oder aber auch, weil ich (!) die richtige Stelle nicht gefunden habe.

Wenn ich jetzt in einem meiner Projekte wäre, würde ich Dich als Entwickler fragen, was genau die Logik Deines Codes ist - einfach nur um Deine Seite besser zu verstehen. Es ist absolut möglich, dass ich in Unkenntnis fehlinterpretiere, ich sehe aber ja auch nur den Outcome auf meiner Seite. Eine dieser Logiken hast Du oben mal Kund getan: "Die max. Leistungsvorgabe läuft immer auf Maximum wenn mehr Überschuss verfügbar ist als alle Ladepunkte zusammen verbrauchen können." Da kann ich sagen "aha, verstanden, so funktioniert das also". Ggf. wirst Du aber verstehen, dass es in Unkenntnis dieser Logik für zumindest mich unlogisch erscheint, warum das Max geliefert wird, wenn weniger vom Dach kommt. Dann kann ich darüber nachdenken und sagen: OK, das kann so funktionieren.

Long story short: Wenn Du/Ihr mir und ggf. auch den anderen helfen würdet mit Details, wie EVCC die Wärmepumpe(n) steuert in den verschiedenen Status/Situationen, dann kann ich besser beurteilen, ob und ggf. welches Problem ist damit mit meiner Lambda habe. Dann können wir zusammen nach passenden Logs schauen und Lösungen finden. Wenn ich das irgendwo nachlesen kann, dann her mit der Doku, ich lese das gerne, aber so auf der grünen Wiese kann ich das nicht erraten, meine Glaskugel ist gerade kaputt.

Vielleicht können wir dort beginnen, dass Du zumindest mir einmal Quellen nennst, bei denen ich nachlesen kann, wie EVCC WP steuert. Wenn es die nicht gibt, dann wäre eine kurze Zusammenfassung von Dir hilfreich. Ansonsten liefere ich Dir wieder und wieder die Dinge, die Du aus Deiner Profi-Sicht nicht gebrauchen kannst. Vielleich ergibt sich dann auch ein Verständnis auf meiner Seite, warum es unlogisch wäre, der WP einfach und flach den Überschuss zu melden und die Steuerung der WP entscheiden zu lassen (denn die kann das alleine!). Bisher verneint Ihr das beharrlich, aber ohne den Kontext zu liefern, damit es nachvollziehbar ist.

Ich danke Dir für Dein Verständnis und Deine/Eure Unterstützung.

[LutzDi]

Auf ein Neues!

Nachdem niemand mehr gezuckt hat, habe ich jetzt einen eigenen Test gemacht. Ich habe das Verhalten der WP in den verschiedenen Situation überprüft und aufgezeichnet. Gerne lasse ich Euch wissen, was rausgekommen ist, ggf. möchte die Besitzer anderer Modelle ähnlich verfahren. Aktuell kann ich in Ermangelung von Wissen und Info nicht sagen, wie dies zu EVCC passt, ich kann nur erkennen, was auf der WP falsch läuft.

1. Erklärung der Funktion der Lambda WP
Die Lambda hat zwei Modi, um PV-ÜS auszuwerten.

• Einmal den Zähler hinter dem WR. Sie bekommt in diesem Fall den gesamte PV-ÜS vom Dach geliefert, bevor dieser von anderen Verbrauchern verbraucht wird. Dieses Szenario ist dafür gedacht, wenn WP und Zähler alleine unter sich sind. Ich kann dazu auch den resid. Power in der WP einstellen. Das scheidet für uns aus, da wir ja am Netzabschluss nach dem Verbrauch messen.
• Die zweite Möglichkeit ist, den PV-ÜS am Netzabschluss zu messen und der WP mitzuteilen. Dies kann als neg. ÜS oder auch als pos. Überschuss (je nach Vorzeichen des Zählers) gemeldet werde und passend eingestellt werden. Wichtig ist hier zu wissen, dass die WP korrekterweise Ihre eigene Leistung mit berücksichtigt und beim gemeldeten PV-ÜS zur Anwendung bringt. Das führt auch zum u.s. Problem. Der 2. Modus ist unser Modus, den es zu verwenden gilt
• Wesentlich ist noch, dass die WP von einer Zählermeldung ausgeht und nicht von einem gepimptem PV-ÜS. Sie kennt nur die Meldung des Zählers, der auch bei Netzbezug negativ (in meinem Fall) werden kann!!
• Ebenso gilt es zu beachten, dass eine WP ein sehr träges System ist, das weder umgehend anlaufen kann, noch kann sie einfach mal so von einer auf die andere Sekunde rauf- und runtermodulieren. Sie wird dies immer glätten und sanft die Leistung ändern. Da Lambda hat dazu einen Wert namens Psoll und der wird in Abhängigkeit vom gelieferten Zählerwert gleitend angepasst. Dies ist die Leistungsvorgabe der WP an sich, steigt langsam, wenn PV-Überschuss gleitend steigt, singt langsam, wenn PV-Überschuss gleitend sinkt. Leider kann ich den nicht auslesen, sondern nur auf der Konsole einsehen.
• Ebenso muss berücksichtigt werden, dass die WP eine Einschalt- und Ausschaltverzögerung hat, die bei mir auf jeweils 10 min stehen, das ist schon kürzer als die Herstellerempfehlung von 15 min. Auch dies zahlt auf das träge Verhalten der WP ein und um die WP schonend zu betreiben. An/Aus sind tödlich für WP über die Laufzeit, sie sind nun mal keine Wallboxen.

2. Problem mit dem 2. Modus iVm. EVCC bei Meldung von 0 kW Überschuss
EVCC meldet bei negativem Überschuss, also Netzbezug einen PV-ÜS von 0 kW. Das ist grundsätzlich korrekt. Da sich dieser Wert aber solange nicht mehr ändert, bis wieder PV-ÜS vom Dach kommt, als z.B. am näschten Morgen, und die WP natürlich wechselnde Leistungsaufnahme hat, führt dies zu folgende Situation: Die WP ändert ihre Leistungsaufnahme nach Ihrer Steuerung z.B. im Laufe der Nacht, der PV-ÜS bleibt aber bei Null, egal, was die WP macht. Da sie aber ihren eigenen Verbrauch immer mit berechnet, kommt sie immer wieder in die Situation, dass sie denkt "trotz meiner Leistungs-Änderung verändert sich der PV-ÜS nicht, daher muss PV-Überschuss noch da sein". Mit diesem Wissen z.B. fährt sie über Nacht das Boost-Programm z.B. für WW. Das habe ich jetzt mehrfach nachgestellt. Die Ursache liegt meiner Meinung nach hier, dass die WP einen Zählerwert gleichermaßen für Lieferung und Bezug erwartet und nicht einen reinen PV-ÜS, der bei Netzbezug 0 ist.

Lösung: EVCC liefert den realen Wert des Zählers an die WP, das beinhaltet Lieferung (pos.) genauso wie Bezug (neg.). Die Steuerung der WP ist darauf ausgelegt, dann zu entscheiden, welches Programm sie wann fährt. Das überlassen wir der Steuerung und nicht EVCC.

3. Problem mit der Lieferung von Max. Ladestrom
Folgender Test dazu vom heutigen Tag, alles ca. Werte, weil die sich ja alle 30s ändern, kann nicht alles direkt abschreiben:

---

18:00 Uhr

• EVCC gestartet
• PV vom Dach = 1,3 kW
• PV-ÜS = 760W
• WP aus
• EVCC meldet PV-ÜS 4,6 kW an Register 102
• WP meldet "PV-ÜS erkannt"

---

18:15 Uhr

• WP gestartet, WW-Boost. Ich habe hier mal auf 65°C Ziel-Temp eingestellt, damit sie länger läuft
• Leistung der WP geht direkt auf ca. 2.2 kW Bezug

• Der Verbrauch der WP ist direkt höher als der aktuell realen PV-ÜS
• Psoll ist auf > 4kW angestiegen, sprich die Steuerung sagt der WP, soll mit >4 kW laufen
• EVCC stellt den erhöhten Verbrauch fest und regelt Register 102 nach unten, siehe Bild als Beispiel auf 0,46 kW

• Psoll bleibt auf >4kW

---

18:19 Uhr

• EVCC meldet 0 kW PV-ÜS
• Psoll ist auf 3,81 kW gesunken, immer noch viel zu viel!

---

18:56 Uhr

• WP schaltet sich ab, weil 65°C WW-Temp erreicht ist
• EVCC meldet 0 kW PV-ÜS
• Psoll ist gesunken, aber immer noch bei 2,09 kW. Wenn noch Bedarf da wäre, würde die WP weiterhin mit >2 kW laufen

Erstes Zwischenfazit: Die Meldung des Max. Ladestroms führt dazu, dass Psoll als Leistungsanforderung der WP so stark hochgeschraubt wird und dies über einen langen Zeitraum erhalten bleibt, dass viel zu viel Leistung aus dem Netz gezogen wird. Bei mir waren dies 45 min und es wäre weitergegangen, wenn das WW nicht heiß genug gewesen wäre. Wie oben erwähnt wartet die WP und beobachtet, ob ein Start sich lohnt oder nicht. Und wenn in dieser Zeit der Max. Ladestrom geliefert wird, dann rechnet sie mit diesem Wert. Und das ist nicht sinnvoll.

Lösung: EVCC liefert den realen Wert des Zählers an die WP, das beinhaltet Lieferung (pos.) genauso wie Bezug (neg.). Die Steuerung der WP ist darauf ausgelegt, dann zu entscheiden, welches Programm sie wann fährt. Das überlassen wir der Steuerung und nicht EVCC.

---

18:10 Uhr

• Die WP ist aus und läuft nicht
• EVCC meldet "ladebereit" und "lädt"

• Das ist nicht korrekt, denn die WP läuft nicht. Damit ist der Status "lädt" falsch
• Damit gehen auch Statistiken in die falsche Richtung

Lösung: EVCC Sollte die aktuelle Leistungsaufnahme berücksichtigen, wenn die 0 ist, dann "lädt" die WP nicht. Das Register für den PV-ÜS wird zwar geschrieben, aber es erfolgt kein Verbrauch von PV-ÜS und damit kein Laden.

---

Ich hoffe, jetzt wird ein wenig klarer, dass es aktuell nicht korrekt funktioniert. gerne lade ich Euch auch noch mein Debug-Log hoch, in der Hoffnung, dass Ihr die richtigen Stellen dort findet.
49686a9f_evcc_2025-04-07T17-19-51.049Z.log

Neben dem kleinen Bug, aus der Messung um 18:10 Uhr, bleibe ich bei meiner Meinung, dass Folgendes korrigiert werden sollte:

• Status "lädt" soll berücksichtigen, ob die WP Leistung zieht oder nicht
• Es wird der vom Zähler am Netzabschluss gelieferte Wert an die WP geliefert, nicht der Max. Ladestrom, egal ob die WP aktuell weniger verbraucht oder nicht
• Bei neg. Leistung am Zähler (= Bezug) wird nicht 0 kW geliefert, sondern der Wert des Zählers. Das wäre auch
• Zusammengefasst sind die beiden letzten Punkte > einfach den Wert des Zählers unverändert ans Register liefern. Den Rest macht die WP selbst, das kann sie gut. Nur als Proof: ich habe auch einen Tag die WP direkt mit den Zählerwerten aus HA gefüttert, so wie von mir beschrieben und dies lief fehlerfrei und präzise. Wir haben auch ungefähr das gleich gute Wetter seit Tage, so dass es durchaus vergleichbar ist. Der Beweis wäre also angetreten.

Als letzten Punkt kann überlegt werden, ob EVCC die Ziel-Temperatur als Maßstab ignoriert. Auch das weiß die WP selbst und ist in Ihrer Steuerung eingebaut. Sie weiß, was sie boosten soll und zusammen mit dem realen Zählerwert bekommt sie das auch gut hin...

Ich hoffe, ich habe ausreichend Input geliefert, wie zumindest die Lambda funktioniert und warum es noch nicht ganz zu der Logik von EVCC passt. Ich freue mich auf passenden und konstruktives Feedback. Ggf. können ja auch die anderen WP-Besitzer mit anderen Modellen mal Ihre Meinung abgeben...

Schönen Abend Euch.

[premultiply]

Gut.

Fazit: Eigenen Zähler (oder die Modbus-Proxy-Funktion oder eigenes Script) für die WP verwenden und dann als aux-Meter in evcc einbinden?
Die Regelung macht diese WP komplett selbstständig. Da gibt es für einen Ladepunkt absolut nix zu tun.
Wie bei My-PV-Heizstäben usw.

/cc @andig

[LutzDi]

Danke für Deine Antwort. Zumindest für die Lambda ist es so, dass sie das alleine kann und macht. Ich vermute auch, dass andere WP ähnlich bis gleich funktionieren. Vielleicht können die anderen bez. IDM, Kemi etc. IDM da nochmal Input liefern.

Wenn ich mir das Konzept der Aux-Meters ansehen, dann passt das schon ziemlich gut zu meiner o.g. Idee. Was ich dahingehen vermissen würden, wäre Priorisierung und preissensitives "Laden" bei dynamischen Strompreisen. Das finde ich schon schick. Die Prio könnte man noch ausklammern, für mich wäre es ok, wenn die WP als letzte Prio "den Rest" bekommt. Aber was machen wir mit Tibber oder anderen dyn. Anbietern?

Gegenidee:
Korrigiert mich gerne, aber grundsätzlich ist doch bisher die Idee von der WP-Integration, nur den Überschuss zu steuern und ggf. dynamische Stromtarife. Ein z.B. komplettes Abschalten der WP z.B. zu Zeiten hoher Strompreise ist doch nicht implementiert, oder? Oder wie war das mit dem Stromtarifen bei der WP gedacht? Falls doch, freue ich mich über ne Info. Aktuell müsste ich nochmal checken, ob die Lambda via Modbus zum Pausieren zwingen kann... Keine Ahnung aktuell. @TRON4R, weißt Du ggf. mehr? Ich habe mal versucht, Register 1015 zu schreiben, ohne Erfolg. Thx for info.

Wenn dem so ist, dann Folgendes:

• Wir richten die WP wie gehabt als Ladepunkt ein
• In allen Modi liefert EVCC der WP den Überschuss vom Netzabschlusszähler, pos. und negativ. Die WP entscheidet selbst, was die damit macht. Aber kein Max. Ladestrom liefern. Die WP entscheidet allein
• Für die Steuerung zu Zeiten von dynamischen guten Strompreisen wird der PV-ÜS auf Min. Ladeleistung von EVCC unabhängig vom Zählerwert erhöht und die WP boostet mit billigerem Strom. Wäre ein bisschen wie das präventive Laden von Batterien nachts
• Optimal wäre natürlich, wenn ich auch ein Pausieren der WP über Modbus zu Zeiten hohen Stroms auch ausschalten könnte - so sie dies unterstützt. Wenn das dann individuell über die evcc.yaml machbar wäre, wäre das perfekt

Bitte sagt gerne Bescheid, wenn ich die Idee falsch verstanden habe, ich lerne gerne...

[TRON4R]

Ich finde es ja toll, dass Ihr Euch auch nochmal alle intensiv bemüht, die Lambda-Implementation noch irgendwie brauchbar zu machen. Aber es scheint leider recht offensichtlich zu sein, dass die zentralen Entwickler keine Motivation haben, das Thema ernsthaft weiter zu verfolgen.

Daten wurden nun wirklich genug und in hoher Detailtiefe von diversen Nutzern geliefert. Aber entweder kommt als Antwort zurück, dass man kein Problem erkennen könne oder eben wie jetzt, dass ein evcc-Loadpoint für so einen Fall gar nicht zuständig sei.

Wirklich schade, denn ich denke schon, dass es absolut Sinn machen würde, evcc die Meldung des PV-Überschuss via Loadpoint zu überlassen. Zum einen sollte das doch nun wirklich nur eine Kleinigkeit sein, den verbleibenden Überschusswert, der einem sowie ständig aktualisiert im GUI angezeigt wird, einfach noch zusätzlich ganz stumpf in Register 102 der Lambda zu melden.

Zum anderen kann es doch nicht sinnvoll sein, dass ich mir einen zweiten Zähler oder Aux-Meter einrichte, wenn die Werte schon in evcc alle vorhanden sind und die Loadpoints extra um eine Wärmepumpenfunktionalität erweitert wurden.

Mein Lambda-Loadpoint zeigt mir z.B. laufend den aktuellen Stromverbrauch, die momentane Pufferspeicher-Temperatur und das in der WP gesetzte Temp-Limit an, was alleine wirklich schon sehr praktisch ist. Denn sonst müsste ich immer VNC anwerfen, um auf meine Lambda-Oberfläche zu gelangen. Ich glaube nicht, dass ein Aux-Meter das genauso gut hinbekommen würde.

Außerdem erlaubt mir der Loadpoint z.B. im Winter das nächtliche Überladen des Pufferspeichers, wenn mein Stromanbieter (Octopus Energy) den Strompreis nachts von 0:00 bis 5:00 halbiert. Auch da ist mir nicht klar, wie ein Aux-Meter das hinbekommen sollte.

Wieso kann man nicht einfach in den Loadpoint eine Logik einbauen, dass bei intelligenten Wärmepumpen wie Lambda, Fermi und IDM (und es gibt sicher noch einige mehr, die genauso intelligent sind) einfach der für Wallboxen gedachte Steuerungscode ignoriert und stattdessen einfach nur stumpf der momentane PV-Überschuss an die Wärmepumpe gemeldet wird?

Eine template-basierte Logik-Verzweigung und dann eine ganz simple Meldung eines im GUI vorhandenen Wertes an das im Template definierte Register der Wärmepumpe und zahlreiche Nutzer hier wären absolut zufrieden und evcc eine richtig runde Sache.

Wenn das zuviel verlangt oder irgendwie unmöglich sein sollte, dann gebt uns doch bitte wenigstens eine kurze Begründung und dann beerdigen wir die Sache eben. Aber uns hier alle so hängen zu lassen, nachdem viele wirklich viel Zeit und Energie in das Thema gesteckt und gute Vorschläge gemacht haben, ist nicht wirklich schön.

[premultiply]

Weil ein Loadpoint eben eine komplexe eigene Regellogik hat, die zudem primär auf Fahrzeuge an IEC-Ladesystemen ausgelegt ist.

Die Lambda-WP hingegen hat eine eigene interne Steuerung (wie ein Batteriespeicher). Sie arbeitet autark und wäre ggf. wie viele andere WPs per SG-Ready anzubinden.

[andig]

Aufgrund Feedbacks über die Stickerbestellung greife ich das Thema nochmal auf. Wir nehmen Feedback ernst, danke!

Erstmal habe ich #20179 (comment) nochmal gelesen:

1. Erklärung der Funktion der Lambda WP

Die WP regelt sich selbst, das spricht für ein aux Gerät. Dann leider ohne boosten nach Netzpreis.

Da sich dieser Wert aber solange nicht mehr ändert, bis wieder PV-ÜS vom Dach kommt, als z.B. am näschten Morgen, und die WP natürlich wechselnde Leistungsaufnahme hat, führt dies zu folgende Situation: Die WP ändert ihre Leistungsaufnahme nach Ihrer Steuerung z.B. im Laufe der Nacht, der PV-ÜS bleibt aber bei Null, egal, was die WP macht. Da sie aber ihren eigenen Verbrauch immer mit berechnet, kommt sie immer wieder in die Situation, dass sie denkt "trotz meiner Leistungs-Änderung verändert sich der PV-ÜS nicht, daher muss PV-Überschuss noch da sein". Mit diesem Wissen z.B. fährt sie über Nacht das Boost-Programm z.B. für WW.

Das ist m.E. ein Bug in der Steuerung der WP. Bei NULL Überschuss (eigene Leistung hin oder her) zu Boosten ist einfach falsch! Dazu sollte es ein Ticket beim Hersteller geben.

Lösung: EVCC liefert den realen Wert des Zählers an die WP

@premultiply hat es ja schon erklärt. evcc funktioniert immer und überall gleich. Es gibt keine Sonderlogik für irgendwelche Geräte und damit auch keinen Workaround für das Fehlverhalten eines spezifischen Gerätes. Am Ende des Tages kann evcc nicht alle Probleme der Welt lösen.

Wieso kann man nicht einfach in den Loadpoint eine Logik einbauen, dass bei intelligenten Wärmepumpen wie Lambda, Fermi und IDM (und es gibt sicher noch einige mehr, die genauso intelligent sind) einfach der für Wallboxen gedachte Steuerungscode ignoriert und stattdessen einfach nur stumpf der momentane PV-Überschuss an die Wärmepumpe gemeldet wird?

Dito. Interessanterweise gibts bei keiner der anderen WP diese Probleme soweit mir bekannt. Falls jemand das "einfach" kann freuen wir uns immer über Contributions!

PS.:

Aber uns hier alle so hängen zu lassen, nachdem viele wirklich viel Zeit und Energie in das Thema gesteckt und gute Vorschläge gemacht haben, ist nicht wirklich schön.

@TRON4R du tust so als hätte @premultiply sich nicht durch Eure Postings gekämpft und seine Zeit investiert, oder wir die Implementierung nachgebessert hätten. Ich persönlich finde das absolut unmöglich. Und selbst wenn dem so wäre können wir unsere Zeit nur einmal investieren und es gibt viele andere Themen die bearbeitet werden müssen.

Denk bitte nochmal drüber nach.

[6thGuest]

Hallo zusammen,

ich bin auch Besitzer einer Lambda EU10L und habe bei mir HomeAssistant am Laufen.

Kurzentschlossen habe ich evcc als AddOn installiert und die Lambda sowie die Zähler dazu eingerichtet.
Die Darstellung, Auswertung etc. fand (finde) ich super!

Allerdings bin ich dann - wie einige User hier - auch über die (für mich nicht nachvollziehbaren) Werte gestolpert, die der WP gemeldet werden.
Meine (vielleicht zu einfache) Vorstellung war, dass ich per evcc die Wärmepumpe so ansteuern bzw die Werte übermitteln kann, dass entweder freier PV-Überschuss oder, wenn nötig, billiger Strom (Tibber) verwendet wird.

Derzeit habe ich evcc zwar noch aktiviert, habe aber darin die Steuerung der Lambda ausgeschaltet.

Ich übergebe ganz einfach den Wert, den mein Zähler (Shelly pro 3EM) am Netzanschlusspunkt misst, per HomeAssistant Modbus an das Register 102 der Lambda (bei mir ist negativ = Überschuss) und lasse den Rest derzeit die Pumpe machen. Das funktioniert auch gut!

Leider kann ich damit dann nicht auf "intelligentes Laden" bei günstigem Tibber-Preis zurückgreifen, wenn mal keine Sonne da ist.

Wie gesagt - mir geht es hier wie anderen Usern auch - ich blicke die Logik der evcc-Steuerung nicht und die Werte, die in Register 102 geschrieben werden, sind ja nicht die wirklichen Überschuss-Werte?!

Achso, folgendes Setup ist bei mir:

PV-Anlage 6kWp
Shelly pro 3EM am Netzanschlusspunkt (Bezug = positiv / Einspeisung = negativ)
Shelly pro 3EM an dem NUR das Wärmepumpensystem (WP, Zirkulationspumpe, Heizkreispumpen...) hängt

[6thGuest]

Kann ich in Zeile 3 den "Namen" ändern oder verweist das auf ein Template oder so?

[thecem]

Bestimmt kannst du das, EU10L ist auch schön, oder λ.

[6thGuest]

Ich denke, das funktioniert soweit.
Ich habe bei evcc in den Einstellungen der Lambda auf

• einphasig
• Max Ladestrom 16A
• Min Ladestrom 2A

gestellt. Ist das denn so richtig?
Die Werte habe ich aus dem Energiemanager der Lambda - dort steht "Leistungsanforderung min" = 0,5 und "Leistungsanforderung max" 4,0.

In der Regelung der Lambda selbst steht bei mir bei "Brauchwasser" > "PV-Betrieb Temperaturerhöhung" 10K.

Wird dieser Wert von dem Skript oben überschrieben? (Dort steht ja derzeit auch 10K)
Überschreibt diesen Wert ggf. auch der Schieberegler im UI?

[thecem]

Nein, der wird nicht überschrieben sondern nur dargestellt, die Lambda regelt das selber über den PV-Überschuus der ihr durch das Script mitgeteilt wird.

[6thGuest]

Ich habe jetzt noch etwas herumprobiert.

Die Stellung des Schiebereglers hat sehr wohl einen Einfluss.
Sobald die max. Temperatur, die ich dort eingestellt habe, erreicht ist, übermittelt evcc "0" Überschuss an die Lambda und provoziert damit ein Ausschalten.
(Stelle ich den Regler auf 50 °C, wird bei 50 °C sofort "0" Überschuss gemeldet)

Allerdings ist es in meinem Fall so, dass nach der Brauchwasserbereitung noch die Heizkreise etwas überheizt werden (sofern nötig).

Das macht die Lambda nun nicht mehr, weil evcc sagt, dass die 55 °C als Brauchwassertemperatur erreicht sind und kein Überschuss mehr gemeldet wird.

Gegenteiliger Fall:

Ich stelle den Schieberegler in evcc auf einen Wert größer als 55 °C...
Dann übermittelt evcc auch den Überschuss weiter an die Lambda.
Allerdings werden dann die ca. 20 Watt Grundverbrauch der Wärmepumpe als "Laden" gewertet.
Die Lambda lädt ja aber nicht, sondern der Grundverbrauch liegt an.

Damit wäre sicher der 2. Fall die bessere Einstellung - dann sind aber die Statistiken in evcc unbrauchbar bzw falsch.

[czam70]

Zur Info: #22453 "Kermi Wärmepumpe PV-Überschuss nutzen: wahlweise Verdichter oder Heizstäbe - Anleitung"
Ist zwar für Kermi, funktioniert für mich aber gut.
So wie EVCC den Überschuss aktuell berechnet und in die Modbus-Register schreibt klappt es bei mir nun einwandfrei (auch ohne ein externes Script). Ich bin auf v0.205.0.
Die Temperatursteuerung von EVCC nutze ich nicht, das überlasse ich der Kermi. Ist für mich in EVCC nur Anzeige, den Temperatur-Schieber lasse ich also immer ganz rechts auf 100 ° C.

Und ja, die EVCC-Ladehistorie stimmt für Heizungen wie Wärmepumpen und Heizstäbe aktuell nicht.
Mir persönlich ist das nicht wichtig, da ich durch die Integration in den SMA SHM bzw. das SunnyPortal und Nutzung von Shellys als separate Meter korrekte Verbrauchsstatistiken habe.

[andig]

Vielleicht ist die Lösung ein praktikabler Workaround,

@TRON4R wie evcc funktioniert steht ja in #20179 (reply in thread). Das ist kein Workaround sondern funktioniert so.

Aber einfacher ist es jedenfalls nicht.

Einfacher ggü. was? So funktioniert halt evcc.

[TRON4R]

Ich meinte das unabhängig von irgendwelchen bestehenden Funktionsweisen. Ganz generell ist m.E. nichts einfacher, als nur stumpf den aktuell gerade vorhandenen PV-Überschuss in regelmäßigen Abständen in Register 102 der Lambda (oder das entsprechende Register der Kermi oder IDM) zu schreiben und den Rest die WP machen zu lassen.

Und da dieser Wert ja auch in evcc laufend errechnet und im gelben Balken angezeigt wird, bin ich naiverweise davon ausgegangen, dass es auch in evcc machbar sein sollte, das für solche Wärmepumpen entsprechend umzusetzen.

[premultiply]

@fzahn Magst du einen PR für die notwendigen Änderungen bzgl. "E-Eintrag" im Template machen?

Die aktuelle Lösung ist einfach nur unnötig kompliziert und offensichtlich mehrfach missverständlich.

Hier geht leider vieles durcheinander.

Wer einfach Zählerwerte in der WP haben will sollte am besten eben so einen einfach anschließen und die WP-Steuerung ihr Ding machen lassen.

[TRON4R]

Wenn man die Steuerung der WP an einen externen Zähler übergibt, hat das aber mehrere Nachteile:

• zusätzliche Kosten für den Zähler (im Falle der Lambda/Zewotherm rund 300 EUR)
• zwei EMS im Haus zu haben, die unabhängig voneinander arbeiten, macht Dinge im Zweifel für den Anweder nur komplizierter und nicht einfacher.
• die Lambda (und vermutlich auch die anderen WPs) kann nur mit einer Entität über ModBus kommunizieren. Wenn das der externe Zähler ist, muss der Loadpoint in evcc gelöscht werden. Dann sind aber die Werte in evcc (Temperatur des Speichers, aktueller Verbrauch etc.) auch nicht mehr sichtbar. Das wäre sehr schade, denn so wie es aktuell ist, ist es anzeigenseitig sehr praktisch.

Bisher hat hier auch niemand mal wirklich begründet, warum das Entwicklerteam einer Umsetzung der Meldung des PV-Überschusses an intelligente Wärmepumpen so ablehnend gegenüber steht. Wäre es wirklich so kompliziert umzusetzen?

Wenn das erläutert würde, dann hätten wenigstens die zahlreichen User (@LutzDi, @czam70 @mathiasmora, @thecem, @6thGuest, @softservicegit, @jannisif, @chriz77, @andreas-bulling uvm.), die hier ebenfalls bereits alle viel Zeit und Energie in das Thema gesteckt haben, Klarheit. Und zukünftige User könnten es sich sparen, entsprechende ähnliche Vorschläge immer wieder zu machen bzw. man könnte sie dann einfach auf diesen Post hineweisen, der erklärt, warum evcc zur Umsetzung dieses Bedarfs nicht in der Lage ist.

[fzahn]

@premultiply Ich habe den PR erstellt und in diesem das Template angepasst.
Ich habe das Template bei mir so manuell getestet, schien zu passen.

@TRON4R welchen Vorteil versprichst du dir technisch davon, der Lambda den Zählerwert zu melden und nicht den verfügbaren Überschuss, der ja genau richtig ist für das Setting "E-Eintrag" ? Dann entspricht doch die Lambda der Funktionsweise von EVCC und ich sehe keinen Nachteil?
Ich habe nicht verstanden, warum die Übermittlung des EVU-Zählerwertes und die Einstellung E-Überschuss besser sein soll

Bei mir läuft die Lambda seit ein paar Tagen mit dem E-Eintrag und das sieht soweit sehr gut aus. Ich steuere die Lambda mit EVCC and und nicht mehr mit Openhab

Gruß fzahn

[thecem]

Wer schon immer mal wissen wollte was PSoll in dem E-Manager der Lambda anzeigt:

Hier sollte klar werden, das der E-Manager der Lambda nicht stumpf einen Wert addiert oder abzieht (Anlagengrundlast/ Leistungsanforderung min oder max). Sondern eine eigene interne Logik den Wert "PSoll" berechnet.

• Power Actual -> Wert am Netzzähler (- Einspeisung ins Netz / + Bezug aus dem Netz // Lambda Einstellung "Neg. E-Überschuss" und Batteriespeicher vorhanden)
• Consumption Actual -> Was die WP denkt zu verbrauchen
• Consumption Setpoint -> von der WP berechneter Wert "PSoll"