Huawei Netzladen improvement - AC Charging Flag umschalten #17692

Hypo93 · 2024-12-11T21:32:51Z

Problembeschreibung:

Beim AC-Laden des Huawei LUNA2000-S0 wird das Modbus-Register 47087 ("Charge from grid") auf 1 gesetzt, sobald das Netzladen aktiviert ist. Nach Abschluss des Ladevorgangs wird dieses Register jedoch nicht automatisch auf 0 zurückgesetzt.

Dies führt dazu, dass der Akku und der Wechselrichter nicht in den Deep-Sleep-Modus wechseln, wenn der Akku den minimalen SoC erreicht hat. Stattdessen verbleiben sie in einem Zustand der AC-Ladebereitschaft und verbrauchen ca. 150 Watt aus dem Netz.

Vorgeschlagene Lösung:

Während des Netzladens sollte evcc das Modbus-Register 47087 auf 1 setzen, sobald der vom Nutzer definierte Zeitraum für das Netzladen beginnt.
Nach Abschluss des Netzladens (Verlassen des definierten Zeitfensters) sollte das Modbus-Register 47087 wieder auf 0 zurückgesetzt werden, um unnötigen Energieverbrauch zu vermeiden.

Alternative:

Eine alternative Lösung könnte sein, das Register 47087 auf 1 zu setzen, sobald ein Netzladeereignis innerhalb der nächsten 24 Stunden ansteht. Falls kein Zeitfenster für Netzladen definiert ist (z. B. weil der Strompreis nie unter die festgelegte Schwelle fällt), kann 47087 auf 0 gesetzt bleiben.

Zusätzlicher Kontext:

Dieses Verhalten betrifft das Template Huawei-sun2000.

andig · 2024-12-11T22:13:29Z

Magst du einfach einen PR machen? Die Änderung ist ja trivial.

Hypo93 · 2024-12-11T22:33:30Z

Dafür reich meine Expertise leider nicht. Ich kenne mich zwar gut mit den Huawei Komponenten und Modbus bzw Gebäudebussystemen aus, aber GO ist für mich Neuland. Könnte ihr das Implementieren? Ich Teste die Funktionalität dann gerne und gebe Feedback.

andig · 2024-12-12T06:38:39Z

Das hat mit Go zum Glück nichts zu tun. Register wird hier verwendet: https://github.com/evcc-io/evcc/blob/master/templates/definition/meter/huawei-sun2000.yaml#L248

andig · 2024-12-12T07:52:20Z

Ich vermute Du hast Dir das so vorgestellt? 57f3fb4

andig · 2024-12-12T07:54:16Z

Für mich sieht das wie ein Fehler in der Firmware aus wenn

address: 47100 # Forcible charge/discharge

schon auf 0 ist und trotzdem

address: 47087 # Charge from grid

noch das Standbyverhalten beeinflussen kann.

This PR enhances battery control by deactivating Modbus register 47087 when stopping the charge process (case 1). This allows the inverter/battery to enter deep sleep mode and prevents standby losses. evcc-io#17692

Hypo93 · 2024-12-12T08:08:08Z

Ich habe den Code angepasst und einen PR erstellt.

Hintergrund: Die Funktion

address: 47087 # Charge from grid

wird bei Huawei zusätzlich verwendet, um bei einer Kaskade mit mehreren Wechselrichtern sicherzustellen, dass die Wechselrichter ohne Batterie den "Master"-Wechselrichter, an dem die Batterie gekoppelt ist, über AC versorgen können.

Trotz der RS485-Bus-Verbindung untereinander wechseln alle Wechselrichter in den Deep-Sleep-Modus, mit Ausnahme des Masters, der mit der Batterie verbunden ist.

Hypo93 · 2024-12-12T19:25:31Z

So, ich hab das aufwecken durch Register 47087 getestet. Die Anpassung funktioniert, allerdings dauert das aufwecken aus dem Standby ab Write auf das Register ziemlich genau 30 Minuten, dies ist aber der Firmware von Huawei zuzuschreiben.

vielen Dank für die Unterstützung @andig

LotharWoman · 2024-12-13T09:37:00Z

Ja, die 30min sind bei jeglicher Ladestrategie zu beachten. Sind WR und Luna im Standby dauert es mit jeder Firmwareversion recht genau 30min ehe die Anlage hochgefahren und bereit zum Laden ist. Auch zu beachten, die Luna beginnt nicht gleich mit voller Leistung zu laden, sondern es dauert je nach minSoc und Temperatur der Batterie nochmals eine halbe Stunde eh volle Ladeleistung erreicht wird.

Daher mein Tip, ist absehbar, dass die Luna zur Ladezeit im Standby sein wird, das Ladezeitfenster besser eine Stunde früher beginnen, so dass die Hauptladung dann wirklich im günstigsten Zeitfenster erfolgt.

MucheteWO · 2024-12-13T14:45:55Z

Hallo. Sorry aber das funktioniert so nicht. Bei mir muss AC Laden an bleiben wegen einer Kaskade (2.WR) und einem externen Balkonkraftwerk. Seit der Version 131.11 tooglet nun mein Main Wechselrichter an dem die Batterie hängt in einer Dauerschleife zwischen Starten und Standby. Ich gehe vorerst auf die Version 131.10 zurück.
Gruß

Hypo93 · 2024-12-13T14:58:08Z

Kann ich nachvollziehen. Dein WR und Batterie sollten sich dann aber einfach in den Tiefschlaf begeben und nicht ständig booten. Ich habe 3 Kundenanlagen, wo wir bei WR Kaskade gezielt das AC-Laden deaktiviert haben, weil die 24/7 Bereitschaft mit rund 150 Watt Verlusten zu buche schlägt, die sich der laufende WR aus dem Netz genehmig. Bei den Anlagen gehen die WR auch ganz normal schlafen.

Das Use Case, dass jemand das AC-Laden dauerhaft aktiviert benötigt habe ich nicht bedacht. @andig wäre es möglich ein zweites Template zu erstellen (einmal für Stand Alone WR (mit Umschaltung von Register 47087) und einmal für WR-Kaskaden (hier sollte 47087 dauerhaft auf 1 bleiben)) oder diese Funktion über die evcc.yaml konfigurierbar?

MucheteWO · 2024-12-13T15:05:44Z

Hallo. Und die Kunden verzichten dann auf Batterieladen vom 2. WR in der schlechteren Jahreshälfte? Ich glaube da wäre es mal interessant auszurechnen, ob der Verlust der AC-Ladung oder die 150W sich stärker auswirken. Ich bin hier froh das ich AC vom Balkon und vom 2. WR in den Akku bekomme. Klar wäre es schön, dass wenn der Akku leer abends/nachts ist, das ganze dann in den Deep Stand By geht, das kann Huawei aber nicht, da er ja jederzeit AC Ladung erwarten könnte. Aber das Ganze ist ja nur für Technikexperten. Aber die sind wir ja hier ;-) Aber so wie du es beschreibst, eigenes Template oder konfigurierbar würde hier helfen, dann kann man selbst entscheiden.

Hypo93 · 2024-12-13T16:05:28Z

@MucheteWO die Erzeugung aus den Kaskaden WR landen i.d.r gleich in der Grundlast des Hauses (teilweise bis zu 1kW durch z.b. IT Homelabs) und im Sommer reicht das DC Laden ohne Probleme um den Speicher zu füllen.

Ich hab mir eben die Struktur des Templates nochmal angeschaut und habe meine ich verstanden, wie man über die evcc.yaml Konfigurierbare Optionen im Template programmiert. Ich setzte mich mal heut Abend dran und starte ggf. nen Pull Request für die Anpassung wenn ich erfolgreich bin.

MucheteWO · 2024-12-13T18:11:35Z

Naja, bei Süd Anlagen ja. Ich habe aber Ost/West jeweils 8kwp. Da macht es Sinn AC Laden an zu haben, da ansonsten der Akku nur in der einen Tageshälfte geladen wird. Aber ja, auch eine Milchmädchenrechnung. Glaube, das geht mit dem Verlust auf null auf. Zumindest im Dezember und Januar.
Aber danke schonmal fürs kümmern.

Hypo93 · 2024-12-13T21:45:21Z

@MucheteWO hab den PR gerade eingereicht. Standardmäßig wird das AC-Laden in dem PR nun deaktiviert. Über das Konfig-UI bzw. über die evcc.yaml kann man bei Battery die Variable "cascade: true" eingesetzt werden, damit bleibt das AC-Laden dauerhaft aktiv.

snookerap · 2024-12-17T06:40:15Z

Eine Frage hierzu:
Seit dem Update geht meine LUNA2000 (Speicher) wieder schön in den Standby.
Wenn ich aber nun versuche nachts günstigen Strom zu speichern (Einstellung über das UI) passiert nix, die LUNA schläft weiter.
Habt ihr ein ähnliches Phänomen?
Was kann ich einstellen?

Hypo93 · 2024-12-17T07:18:37Z

Moin, geht die Luna die ganze Nacht nicht mehr an trotz charging Mode? Huawei hat ein Delay von 30 Minuten in der Firmware bis der WR und Luna aufwacht. Das lässt sich leider nicht anpassen

snookerap · 2024-12-17T07:25:02Z

Moin, geht die Luna die ganze Nacht nicht mehr an trotz charging Mode? Huawei hat ein Delay von 30 Minuten in der Firmware bis der WR und Luna aufwacht. Das lässt sich leider nicht anpassen

hallo, ja, sie lädt überhaupt nicht trotz eingestellten peisgeführten Lademodus.
Habe es jetzt bereits den dritten Tag in Folge versucht, erfolglos.

Hypo93 · 2024-12-17T07:28:58Z

Das Wunder mich sehr. Bei mir läuft es seit dem commit ohne Probleme. Ich hab adhoc leider keinen Zugriff auf einen weiteren Wechselrichter/Luna zum Testen ... das folgt erst in den nächsten zwei Wochen.

snookerap · 2024-12-17T07:30:33Z

vielleicht liegt es an den Einstellungen in der Luna, welche müssen denn hier vorgenommen werden?

Nutzt du eventuell Home Assistant da kann man ja auch super alles einstellen?

Hypo93 · 2024-12-17T07:38:13Z

In der Luna bzw. im Fusion Solar ist bei mir alles auf Werkseinstellung.

Du kannst gerne mal testen, ob das AC-Laden vernünftig gesetzt wird. Hierzu einmal in der Fusion Solar App oder Web in den Parametern der Luna den Punkt "von AC-Seite laden" checken ob er auf deaktiviert steht, dann mittels evcc ein Ladevorgang planen zum aktuellen Zeitpunkt, nach ein paar Sekunden bis einer Minute sollte dann in der Fusion Solar App der Punkt "von AC-Seite laden" auf "Aktivieren" wechseln.

Ich hab nen Modbus Proxy dazwischen hängen um Daten mit dem ioBroker aufzuzeichnen. Schreibend wirkt aber ausschließlich evcc auf den WR/Luna

Hypo93 · 2024-12-17T07:51:55Z

meters:
- type: template
  template: huawei-sun2000
  modbus: tcpip
  id: 1
  host: 10.0.0.12
  port: 5021
  timeout: 15s
  usage: grid
  name: grid
- type: template
  template: huawei-sun2000
  id: 1
  host: 10.0.0.12
  port: 5021
  usage: pv
  modbus: tcpip
  timeout: 15s
  name: pv
- type: template
  template: huawei-sun2000
  id: 1
  host: 10.0.0.12
  port: 5021
  usage: battery
  modbus: tcpip
  timeout: 15s
  name: battery

Hier mal der code aus meiner /etc/evcc.yaml zum abgleich, wie es aktuell konfiguriert ist bei mir.

rnndchsrl · 2024-12-17T07:52:51Z

Hallo, ich habe zwei Fragen dazu:

Könnte man die halbe Stunde nicht mit einplanen und AC-Laden entsprechend früher aktivieren?
In v0.131.11 ist der PR drin oder? Bei mir schaltet sich das AC-Laden nicht ab, wenn die Luna fertig ist, sie ist so eingebunden:

name: my_battery
type: template
template: huawei-dongle-powersensor
usage: battery

@Hypo93 okay, du nutzt huawei-sun2000 - somit wird der PR auch nur das Template angepasst haben oder?

Hypo93 · 2024-12-17T07:54:16Z

Richtig ich habe ausschließlich das huawei-sun2000 Template angepasst

@rnndchsrl die halbe Stunde einplanen würde denke ich was grundlegendes an der ladelogik in evcc ändern, da hab ich keine Aktien drin

LotharWoman · 2024-12-17T22:20:23Z

Danke schon mal ich bin momentan unterwegs. Ich werde das heute Nachmittag mal direkt probieren. Ich nutze den Modus Proxy von evcc. ich melde mich. Viele Grüße, Christian

Ich habs gerade an meiner Anlage nochmal beobachtet und mein Nachbar hat mich auch mal kurz nen Raspberry mit evcc ins Netz hängen lassen. Also ... mit der Version v0.131.11 läuft die Sequenz wie folgt ab
1. WR + Luna sind im deep sleep (Register 37762 -> Wert 4 (sleep mode)) -> alle Lichter an der Luna aus

2. Preislimit in evcc auf <= 50cent/kWh gestellt zum Testen

3. nach 28min leuchten die Lichter an der Luna auf (Statusregister 37762 -> Wert 1 (standby))

4. Luna + WR booten und der WR Synchronisiert sich aufs Netz

5. nach 30min seit Punkt 2. -> Laden beginnt mit 2,5kW (Statusregister 37762 -> Wert 2 (running))
Hier also an zwei Anlagen fehlerfrei.

Genau so soll es sein und genau so läuft es auch bei mir ab.
Allerdings mit einer Ausnahme. Die Firmware hat aktuell einen Fehler, so dass die Luna nicht immer fehlerfrei in den Standby geht. Passiert der Fehler beim abschalten der Luna, so blinkt ein rotes Lichtlein am WR und die Anlage wirft Fehler 2068. In diesem Zustand kann evcc die Luna auch nicht mehr "wecken".
Kurioserweise stört der Fehler HA nicht. Stellt man dort um auf ForceCharge/TOU, so wacht das System trotzdem nach 30min auf.
evcc scheint also irgend etwas anders zu machen. Wird evtl. erst "deep sleep (Register 37762 -> Wert 4 (sleep mode))" ausgelesen und erst danach mit der Ladelogic begonnen?

LotharWoman · 2024-12-18T21:05:00Z

Hallo, heute mal etwas probiert. Ladeslot eingestellt für die günstigsten drei Stunden und zusätzlich mit einem "Fake-Charger" bis 08:00Uhr das Entladen verhindert.
Im Endeffekt hat es funktioniert. Allerdings arbeiten wohl beide eine Zeitlang gegeneinander, so das es am Übergang zu heftigen Wechsel zwischen Laden/Entladen kam. Ich denke ich belasse es bei dem einmaligen Versuch, da es auf Dauer wohl der Batterie nicht zuträglich sein dürfte.

Meiner Meinung nach ist bei Huawei der Weg über ForceCharge ungeeignet. Ich favorisiere daher weiter meine alte Lösung in HA mit dem Weg über TOU. Einmal den Ladezeitraum täglich 00:00-23:59Uhr setzen und schon muss nur noch zwischen max. Eigenverbrauch und TOU gewechselt werden. Je nachdem wie lang man nach erreichen des gewünschten Soc den TOU Modus weiter aktiv lässt, ist so auch einfach zu bestimmen ab wann wieder entladen werden darf.

andig · 2024-12-18T21:08:19Z

Laden/Entladen sollte nicht passieren. Gibts ein Logfile?

LotharWoman · 2024-12-18T21:11:45Z

Nein, evcc läuft als HA Addon. So viel ich weiss gibts da keine Logs, oder?

Hypo93 · 2024-12-18T21:23:39Z

Hallo, heute mal etwas probiert. Ladeslot eingestellt für die günstigsten drei Stunden und zusätzlich mit einem "Fake-Charger" bis 08:00Uhr das Entladen verhindert. Im Endeffekt hat es funktioniert. Allerdings arbeiten wohl beide eine Zeitlang gegeneinander, so das es am Übergang zu heftigen Wechsel zwischen Laden/Entladen kam. Ich denke ich belasse es bei dem einmaligen Versuch, da es auf Dauer wohl der Batterie nicht zuträglich sein dürfte. !

Meiner Meinung nach ist bei Huawei der Weg über ForceCharge ungeeignet. Ich favorisiere daher weiter meine alte Lösung in HA mit dem Weg über TOU. Einmal den Ladezeitraum täglich 00:00-23:59Uhr setzen und schon muss nur noch zwischen max. Eigenverbrauch und TOU gewechselt werden. Je nachdem wie lang man nach erreichen des gewünschten Soc den TOU Modus weiter aktiv lässt, ist so auch einfach zu bestimmen ab wann wieder entladen werden darf.

Das ist, glaube ich, ein guter Hinweis. Das Template in evcc nutzt die Zwangsladen-Funktion und setzt, wenn ich es richtig sehe, immer wieder die Dauer auf 1 Minute. Viel besser wäre es wohl, wie du sagst, die TOU-Funktion vom sDongle zu verwenden und dann nur zwischen den Arbeitsmodi zu wechseln. Das AC-Laden muss natürlich trotzdem ein- und ausgeschaltet werden.

Die Frage ist nur: Wie realisiert man dann den "Hold"-Modus, um zu verhindern, dass die gespeicherte Energie aus der Luna in das KFZ bzw. die Wallbox fließt? Oder – zukunftsgerichtet gedacht – wie kann man die Energie netzdienlich in entsprechende Hochzeiten verlagern? Der gewünschte SoC lässt sich ja leider nicht direkt schreiben, da man hier beim maximalen SoC nur einen Wertebereich von 90–100 % zur Verfügung hat.

Ein Beispiel: 10 kWh Speicher, ich lade 1 h mit 2,5 kW und will die theoretisch geladenen 2,5 kWh "sichern" und nicht entladen. Mir fällt für diesen Zustand gerade keine Lösung ein. Wie könnte man das lösen?

LotharWoman · 2024-12-18T21:24:11Z

Sehe gerade, hatte es auch schon Tags zuvor so probiert. Hier sind die Ausschläge noch viel länger andauernd. Wahrscheinlich weil das Ladefenster per ForceCharge länger gesetzt war.

Und hier mal wie es ausschaut wenn ich es per HA und Wechsel zwischen TOU/max.Eigenverbrauch laufen lasse. Sieht deutlich sauberer aus.

Ich denke der Unterschied kommt daher, dass evcc mit ForceCharge versucht bis zum Ende des Slots 100% Soc zu halten, das Huawei System aber ForceCharge bei 100% automatisch beendet. Huawei schaltet also zurück auf max. Eigenverbrauch, Batterie entlädt sich auf 99% und nun aktiviert evcc wieder neu Force Charge. Und so schwingt es hin und her bis zum Ende der Ladezeit.

LotharWoman · 2024-12-18T21:44:18Z

Das AC-Laden muss natürlich trotzdem ein- und ausgeschaltet werden.

Einschalten geht automatisch wenn auf TOU gewechselt wird, aber auch hier mit den 30min Wartezeit.

Ein Beispiel: 10 kWh Speicher, ich lade 1 h mit 2,5 kW und will die theoretisch geladenen 2,5 kWh "sichern" und nicht entladen. Mir fällt für diesen Zustand gerade keine Lösung ein. Wie könnte man das lösen?

Du lässt deine Luna einfach per TOU bis 25% laden und stellst erst auf max. Eigenverbrauch zurück wenn du die 25% nutzen möchtest.

Die Frage ist nur: Wie realisiert man dann den "Hold"-Modus, um zu verhindern, dass die gespeicherte Energie aus der Luna in das KFZ bzw. die Wallbox fließt? Oder – zukunftsgerichtet gedacht – wie kann man die Energie netzdienlich in entsprechende Hochzeiten verlagern? Der gewünschte SoC lässt sich ja leider nicht direkt schreiben, da man hier beim maximalen SoC nur einen Wertebereich von 90–100 % zur Verfügung hat.

Vorausgesetzt das TOU Ladezeitfenster "tägl. 00:00-23:59" ist einmal gesetzt im Huawei System ist dies ja gleichzeitig der Hold-Modus, da es sich um ein Ladezeitfenster handelt und somit die Batterie nicht entlädt.
Der gewünschte Soc für die AC-Seite ist dabei auch frei wählbar. Die von dir genannte Beschränkung gilt nur für die DC-Seite. Das sollte uns aber egal sein, da wir trotz ladendem Auto evtl. anfallenden Überschuss ja eh in der Batterie haben möchten.

andig · 2024-12-18T21:51:43Z

Was wäre daran schlimm? Der Akuu sollte ja kn der billigen Zeit voll bleiben!

Hypo93 · 2024-12-19T09:40:18Z

@LotharWoman Ich glaube, du hast da einen generellen Bug im Template aufgedeckt. Ich habe das Ganze mal mit der alten v0.131.10 getestet, sprich vor meiner Anpassung mit dem AC-Charging-Flag, und dort taucht das ständige Nachladen auch auf.

@andig Im Batterymode wird der Case 2 ja verwendet zum "Halten" des SoC. Für mein Verständnis betrifft das die Funktion im UI: "Hausbatterie -> Verhindere Entladung im Schnell-Modus und bei geplantem Laden".

Den ToU-Modus habe ich über Case 1 und 3 mal "quick and dirty" abgebildet, und wie im Bild zu sehen, lädt, hält und entlädt er wie gewollt. Nur kann ich über diese Funktion die Entladung nicht anhalten.

batterymode:
  source: watchdog
  timeout: 30s
  reset: 1 # reset watchdog on normal
  set:
    source: switch
    switch:
      - case: 1 # normal
        set:
          source: sequence
          set:
            - source: const
              value: 2 # stop
              set:
                source: modbus
                {{- include "modbus". | indent 12 }}
                register:
                  address: 47086 # Battery Working Mode "Maximaler Eigenverbrauch"
                  type: writesingle
                  encoding: uint16
            - source: const
              value: 0 # Disable
              set:
                source: modbus
                {{- include "modbus". | indent 12 }}
                register:
                  address: 47087 # Charge from grid
                  type: writesingle
                  encoding: uint16
      - case: 3 # charge
        set:
          source: sequence
          set:
            - source: const
              value: 5 # charge
              set:
                source: modbus
                {{- include "modbus". | indent 12 }}
                register:
                  address: 47086 # battery working mode "zeitgesteuertes Laden"
                  type: writesingle
                  encoding: uint16
            - source: const
              value: {{ .maxacchargepower }} # W
              set:
                source: modbus
                {{- include "modbus". | indent 12 }}
                register:
                  address: 47242 # maximum ac charging power
                  type: writemultiple
                  encoding: uint32

Theoretisch könnte man den Workaround aus Case 2 beibehalten und in Case 1 und 3 zurücksetzen. Das bedeutet aber, dass 6 Modbus-Register in jedem Case beschrieben werden müssten. Ich denke da an die Buslast, weil der sDongle ohnehin sehr, sehr träge ist und nur einen Befehl zur Zeit annimmt.

Daher die Frage an dich: Schreibt EVCC den Wert nur einmal in die Register beim Ändern des Modus (Laden/Halten/Entladen) oder zyklisch?

LotharWoman · 2024-12-19T10:11:21Z

Ich glaube, du hast da einen generellen Bug im Template aufgedeckt.

Danke. Leider stecke ich da zu wenig in dahinter stehendem Code und Registern um euch bei einer Verbesserung helfen zu können. 🤷‍♂️

Nur kann ich über diese Funktion die Entladung nicht anhalten.

Das sollte aber über mehrere Wege auch möglich sein. Hier mal grafisch anhand der Begrenzung des min.GridChargeSoc, welcher 20-100% frei wählbar ist. Entladen in den Verbraucher wird verhindert und weiterhin vorhandener PV-Überschuss geht in die Batterie. Schlägt also gegenüber der ForceCharge Methode 2 Fliegen mit einer Klappe, da nicht nur das Entladen verhindert wird, sondern zu Sperrzeiten evtl. anfallender Überschuss weiter in die Batterie geladen wird.

Ein anderer Weg für Hold wäre einfach nur die Begrenzung der Entladeleistung, in HA "luna_maximum_discharging_power" genannt.

Hypo93 · 2024-12-19T11:16:05Z

Ein anderer Weg für Hold wäre einfach nur die Begrenzung der Entladeleistung, in HA "luna_maximum_discharging_power" genannt.

Finde ich eine sehr gute Idee. Habe ich gerade über ein modbus Tool mal eben aus der ferne getestet ... ist das Register 47077 als uint32 ... Für 5kWh Akkus 2500W und für Stacks mit mehr als einem Bat. Modul 5000W, wenn man den Wert auf 0W setzt wird das Entladen tatsächlich verhindert, geladen wird aber weiter bei PV-Überschuss ... Das ließe sich ja über die evcc.yaml bzw. UI konfigurierbar und als erforderlich einstellbar machen. Ich bastle da morgen mal was zusammen, früher komme ich da leider nicht zu.

Ich baue dann denke ich auch gleich eine Option ein, dass man fest konfigurieren kann, bis wohin der Speicher via AC geladen werden soll... das ist nämlich über Register 47088 lösbar ... dann lässt sich zumindest einstellen, ob immer via AC auf 100% geladen werden soll oder man einen Puffer lässt für ggf. vorhandenen PV Überschuss.

andig · 2024-12-19T11:37:35Z

Ich baue dann denke ich auch gleich eine Option ein, dass man fest konfigurieren kann, bis wohin der Speicher via AC geladen werden soll

Das macht als fester Parameter wenig Sinn- würde ich nicht umsetzen wollen.

LotharWoman · 2024-12-19T13:29:16Z

Da muss ich @andig zustimmen. Der Wert muss täglich leicht änderbar bleiben und gehört meiner Meinung nach mit in die GUI neben die Preisauswahl, so dass man ihn täglich an am Folgetag zu erwartenden Ertrag anpassen kann.
Im Endausbau sollte dann eine externe Lösung oder KI den Wert für Preissegment und AC-Ladegrenze passend setzen. 😉

andig · 2024-12-19T13:32:46Z

Siehe dazu auch #17806 (comment), ist hier aber völlig OT.

hstreitenberger · 2024-12-20T07:48:24Z

Habe hier einen Kommentar zum Ursprungsthema abgegeben: #17726 (comment)

Hypo93 · 2024-12-20T07:56:30Z

@hstreitenberger Mich stören die ständigen nachfragen gerade selber. Man sieht ja auch wie viele Kommentare es mittlerweile unter dem PR gibt, ich werde das verhalten im nächsten PR umkehren (AC-Laden immer aktiv, außer man setzt dafür ein Parameter), so wie du es vorschlägst.

Hypo93 · 2024-12-20T08:47:38Z

Auch hier mal zur Diskussion für die Mitleser:

#17726 (comment)

@mucki12 @hstreitenberger schau mal bitte ab dem Post abwärts ... #17692 (comment)

Wie machen wir hier weiter... mit der Force Charge Funktion (Zwangsladung eig. von Huawei zu Wartungszwecken gedacht) penetrieren wir den Akku. da er bei 100% Ladung automatisch den Modus verlässt, 1% SoC verliert und wieder ins Laden geht (da kann evcc nichts für, wir missbrauchen hier eine "Wartungsfunktion").

Eig. ist von Huawei hierzu die ToU Funktion implementiert. Das würde aber bedeuten:
Einmal das template anpassen auf die anderen modbus adressen... setzt aber bei jedem Nutzer voraus, dass er per FusionSolar App einmal den ToU Zeitplan erstellt von (00:00 - 23:59 - Täglich)

In der Fusion Solar App -> Geräte -> Dongle -> Parametereinstellungen -> Arbeitsmodus -> Zeitsteuerung -> Plan hinzufügen (00:00 - 23:59, Laden, täglich) -> bestätigen -> wieder auf Maximaler Energieverbrauch -> bestätigen

Ich hab aktuell noch nicht rausgefunden, ob und wie man diesen Zeitplan per ModBus erstellen kann.

Ich kann aber auch einfach das alte Template mit meinen bisherigen Änderung rückgängig machen (getreu dem Motto: für Energiesparen ist jeder selber verantwortlich und wenn er sein Akku schrottet) und ein neues unter einem anderen Namen erstellen + Doku?!

hstreitenberger · 2024-12-20T09:46:15Z

Weiß nicht, ob ich alles verstehe und ob ich beitragen kann, hier mal meine laienhafte Erfahrung:

Also bei mir funktioniert der Modus "Forcible Charge" bis zu einem definierten SoC (GridChargeSoc, im Bild 85%) in Home Assistant sehr gut.

Ich muss nur zuvor die Batterieentladesperre in evcc über Home Assistant deaktivieren, da diese Funktion nach meinem Verständnis das Ladeverhalten mit "Forcible Discharge at 0W for 1 minutes" falsch behandelt und im Weg für die Ladung steht. Nach dem Ladevorgang aktiviere ich über HA wieder die Entladesperre (siehe Bild -> Discharging at 0W for 1 minutes, da gleichzeitig ein evcc-Auto-Ladevorgang aktiv ist).

Die Entladesperre sollte m.M. wie schon oben angedeutet über die Reduzierung der Entladeleistung auf 0W realisiert werden und nicht über das "Forcible Discharge".

Um ein Entladen und neues Laden nach 1% Verlust über evcc zu unterbinden, könnte man auch für den Zeitraum der Batterieladung (=Unterschreitung des Preises) die Entladeleistung auf 0W setzen, dann wird Batterie geladen und pauschal in dieser Zeit aus dem Netz gezogen (was ja ebenfalls wünschenswert ist).

Ich sehe das "Forible Charge" auch nicht als Wartungsfunktion, da diese Funktion auch ganz offiziell in der FusionSolar-App angeboten wird: Laden/Energie/Ziel SOC.

LotharWoman · 2024-12-20T13:18:31Z

Ich sehe das "Forible Charge" auch nicht als Wartungsfunktion, da diese Funktion auch ganz offiziell in der FusionSolar-App angeboten wird: Laden/Energie/Ziel SOC.

Nur dass dort der Modus bei erreichen der Zielwerte verlassen wird und die Batterie in ihren normalen Arbeitsmodus zurückkehrt. Genau dies lässt aber das "Zwangs" force charge in evcc nicht zu, sondern hindert den Akku bis Ende des Zeitraums daran zurück zu wechseln. In der Folge kommt es dann zu ständigem Laden/Entladen.

Ich hab aktuell noch nicht rausgefunden, ob und wie man diesen Zeitplan per ModBus erstellen kann.

Schaut mal ob hier Infos dazu entnehmen könnt: https://github.com/wlcrs/huawei_solar/wiki/Time-of-Use-control

Hypo93 · 2024-12-20T20:38:08Z

Um hier nochmal klarzustellen, dass die Funktion forced charge/discharge eine Wartungsfunktion ist (ja, sie ist für jeden zugänglich)

Im Handbuch der Luna wird Sie auf Seite 141 erklärt. Auf meinem Zertifizierungslehrgang bei Huawei wurde uns dieser Modus genau so erklärt, er ist nur dafür da um die Luna auf einen definierten Ladezustand zu bringen, sei es zur Lagerung damit sie nicht tiefentlädt, für den Wiederverkauf oder zu Wartungszwecken um die Funktion des Akkus zu testen.

Im SUN2000-Handbuch wird auch nochmal erklärt auf Seite 327 und 328, dass der ToU Modus dafür da ist, um die Lade und Entladestunden festzulegen. Forced charge/discharge wird nicht weiter beschrieben, aber es wird der Hinweis gegeben, was wir ja durchs logging gesehen haben, dass der "charge" modus beim erreichen des eingestellten SoC (default 100%) verlassen wird und der Akku automatisch wieder in den entlademodus geht.

Über das Register 47255 kann man wohl die ToU Pläne erstellen ... Ich muss mir nur das Datenformat nochmal anschauen und es testen... dann bringe ich es in code form für ein template

snookerap · 2024-12-26T08:25:00Z

Danke schon mal ich bin momentan unterwegs. Ich werde das heute Nachmittag mal direkt probieren. Ich nutze den Modus Proxy von evcc. ich melde mich. Viele Grüße, Christian

Ich habs gerade an meiner Anlage nochmal beobachtet und mein Nachbar hat mich auch mal kurz nen Raspberry mit evcc ins Netz hängen lassen. Also ... mit der Version v0.131.11 läuft die Sequenz wie folgt ab
1. WR + Luna sind im deep sleep (Register 37762 -> Wert 4 (sleep mode)) -> alle Lichter an der Luna aus

2. Preislimit in evcc auf <= 50cent/kWh gestellt zum Testen

3. nach 28min leuchten die Lichter an der Luna auf (Statusregister 37762 -> Wert 1 (standby))

4. Luna + WR booten und der WR Synchronisiert sich aufs Netz

5. nach 30min seit Punkt 2. -> Laden beginnt mit 2,5kW (Statusregister 37762 -> Wert 2 (running))
Hier also an zwei Anlagen fehlerfrei.
Genau so soll es sein und genau so läuft es auch bei mir ab. Allerdings mit einer Ausnahme. Die Firmware hat aktuell einen Fehler, so dass die Luna nicht immer fehlerfrei in den Standby geht. Passiert der Fehler beim abschalten der Luna, so blinkt ein rotes Lichtlein am WR und die Anlage wirft Fehler 2068. In diesem Zustand kann evcc die Luna auch nicht mehr "wecken". Kurioserweise stört der Fehler HA nicht. Stellt man dort um auf ForceCharge/TOU, so wacht das System trotzdem nach 30min auf. evcc scheint also irgend etwas anders zu machen. Wird evtl. erst "deep sleep (Register 37762 -> Wert 4 (sleep mode))" ausgelesen und erst danach mit der Ladelogic begonnen?

Selbiges passiert bei mir immer. Seit dem Update des Template geht meine LUNA in den Standby, die rote LED bilnkt am WR und der Fehler 2068 wird gemeldet.
Ein Wecken aus diesem Zustand mit preisgünstigen Netzladen funktioniert nicht.

Hypo93 · 2024-12-26T08:49:30Z

Ich hab mir letzte Woche noch nen neues Template geschrieben für die ToU Funktion. Bedarf aber ein wenig mehr an Konfiguration (einmaliges Zeitplan anlegen + Festlegen der Entladeleistung)

https://github.com/Hypo93/evcc/blob/huawei-fix-v2/templates/definition/meter/huawei-sun2000-luna-sdongle.yaml

Das läuft seit dem ohne Fehler bei mir. Den Standby Fehler hatte ich aber im alten Template auch nicht... welche Firmware habt ihr installiert?

Hier
Dongle: V200R022C10SPC121
WR: V100R001C00SPC165
Luna: V100R002C00SPC629
MBUS: V100R001C00SPC335

LotharWoman · 2024-12-26T10:11:27Z

Standby Fehler hatte ich auch aller paar Tage mal seit 16x Wechselrichter und 6xx Batterie Firmware. Dies scheint mir aber mit aktuellen Updates nun endgültig behoben zu sein.
Dongle: V200R022C10SPC126
WR: V100R001C00SPC167
Luna: V100R002C00SPC629
MBUS: V100R001C00SPC335

mucki12 · 2024-12-27T18:03:50Z

Ich hab mir letzte Woche noch nen neues Template geschrieben für die ToU Funktion. Bedarf aber ein wenig mehr an Konfiguration (einmaliges Zeitplan anlegen + Festlegen der Entladeleistung)

https://github.com/Hypo93/evcc/blob/huawei-fix-v2/templates/definition/meter/huawei-sun2000-luna-sdongle.yaml

Liest sich erst einmal top! Kompliment und vielen Dank.

Muss ich unbedingt bei Gelegenheit ausprobieren. Dein Template lässt sich doch so ohne weiteres einbinden und jeder kann über den Parameter maxdischargepower seine Entladeleistung einstellen. Für ToU müsste mann doch nur noch den Plan einbinden (siehe unten) und mit dem Parameter holdaccharging wären auch alle Bedürfnisse an AC Laden on/off abgedeckt.

Edit:
War wohl ein Schnellschuss von mir - @Hypo93 habe ich noch nicht getestet, aber ich gehe mal davon aus, dass dein Template erst in ein Release aufgenommen werden muss, bevor das jeder testen/nutzen kann, oder irre ich mich?

Hypo93 · 2024-12-27T23:41:14Z

@mucki12 mein Ziel war es eig. den Zeitplan über ModBus zu erstellen, dafür gibt es auch ein ModBus Register (47255), allerdings habe ich es darüber nicht hinbekommen, weder über Anpassung im Template noch über eine ModBus Software.

Die Anpassung sind aktuell nur in meinem Fork/Branch gemacht und nicht in das Hauptprojekt übernommen... ich würde gerne erst eine Doku erstellen, bevor ich das anstoße damit beschrieben ist, was alles Eingestellt werden muss und wie man den Zeitplan erstellt.

Du könntest dir mein Fork aktuell nur selber kompilieren.

mucki12 · 2024-12-28T09:02:11Z

@Hypo93
Vielen Dank. Habe für einen ersten Schritt einfach deine Logik für die Batteriesteuerung direkt ohne Variablen (sondern mit festen Werten) direkt in meine evcc.yaml eingebaut (damit kann ich dann ja jeweils das aktuelle evcc Release nutzen).

Konnte bisher nur kurz das Netzladen des LUNA testen und das hat schon einmal wunderbar geklappt. Als nächstes teste ich mal das Schnellladen um auch den case 2: hold Fall zu testen.

snookerap · 2024-12-28T12:21:51Z

Könntest du eventuell diese Anpassungen der evcc.yaml posten?!

Bzgl. der Firmwares, da habe ich jetzt auf die aktuellesten Version geupdate. Der Sleep-Fehler und der Fehler-Code 2068 scheinen jetzt passé zu sein.

mucki12 · 2024-12-28T12:27:51Z

@snookerap
Klar warum nicht. Möchte mich aber nicht mit fremden Federn schmücken - der Dank dafür gilt @Hypo93

  - name: bat_custom
    type: custom
    power:
      source: modbus
      id: 1
      uri: 192.168.2.168:502
      timeout: 15s #{{.timeout}}
      connectdelay: 1s
      register:
        #{{- if eq .storageunit "1" }}
        address: 37001
        type: holding
        decode: int32nan
      scale: -1
    energy:
      source: modbus
      id: 1
      uri: 192.168.2.168:502
      timeout: 15s #{{.timeout}}
      register:
        address: 37068 # [Energy storage unit 1] Total discharge
        type: holding
        decode: uint32nan
      scale: 0.01
    soc:
      source: modbus
      id: 1
      uri: 192.168.2.168:502
      timeout: 15s #{{.timeout}}
      register:
        address: 37004
        type: holding
        decode: uint16nan
      scale: 0.1
    batterymode:
      source: watchdog
      timeout: 30s
      reset: 1 # reset watchdog on normal
      set:
        source: switch
        switch:
        - case: 1 # normal
          set:
            source: sequence
            set:
            - source: const
              value: 2 # stop
              set:
                source: modbus
                id: 1
                uri: 192.168.2.168:502
                register:
                  address: 47086 # battery working mode "Maximaler Eigenverbrauch"
                  type: writesingle
                  encoding: uint16
            - source: const
              value: 5000 # W
              set:
                source: modbus
                id: 1
                uri: 192.168.2.168:502
                register:
                  address: 47077 # maximum discharging power
                  type: writemultiple
                  encoding: uint32
        - case: 2 # hold
          set:
            source: sequence
            set:
            - source: const
              value: 0 # W
              set:
                source: modbus
                id: 1
                uri: 192.168.2.168:502
                register:
                  address: 47077 # maximum discharging power
                  type: writemultiple
                  encoding: uint32
            - source: const
              value: 2 # stop
              set:
                source: modbus
                id: 1
                uri: 192.168.2.168:502
                register:
                  address: 47086 # battery working mode "Maximaler Eigenverbrauch"
                  type: writesingle
                  encoding: uint16
        - case: 3 # charge
          set:
            source: sequence
            set:
            - source: const
              value: 5 # charge
              set:
                source: modbus
                id: 1
                uri: 192.168.2.168:502
                register:
                  address: 47086 # battery working mode "zeitgesteuertes Laden"
                  type: writesingle
                  encoding: uint16
            - source: const
              value: 5000 # W
              set:
                source: modbus
                id: 1
                uri: 192.168.2.168:502
                register:
                  address: 47077 # maximum discharging power
                  type: writemultiple
                  encoding: uint32
            - source: const
              value: 5000 # W
              set:
                source: modbus
                id: 1
                uri: 192.168.2.168:502
                register:
                  address: 47242 # maximum ac charging power
                  type: writemultiple
                  encoding: uint32
            - source: const
              value: 1 # enable
              set:
                source: modbus
                id: 1
                uri: 192.168.2.168:502
                register:
                  address: 47087 # charge from grid
                  type: writesingle
                  encoding: uint16
    capacity: 10 # Akkukapazität in kWh

Edit:
Habe allerdings den Part mit dem optionalen AC Laden ein/aus rausgenommen. Bei mir bleibt AC Laden auf Grundlage eines Ladevorgangs von evcc grundsätzlich an und ein anderes System entscheidet anschließend dieses an- oder auszuschalten.

mucki12 · 2024-12-28T13:20:42Z

@Hypo93
Nur der vollständigkeitshalber - auch hold mit einer Entladeleistung von 0W funktioniert perfekt. Theoretisch könnte man da jetzt statt 0W auch die Grundlast des Hauses eintragen. Ist natürlich Geschmacksache und bedingt sinnvoll, aber so würde zB das Schnellladen bei günstigen Tarifen in der Nacht für den LUNA eine nahezu neutrale Nutzung darstellen.

andig added the devices Specific device support label Dec 11, 2024

andig self-assigned this Dec 11, 2024

andig mentioned this issue Dec 12, 2024

Fronius Gen24/ Huawei Sun2000: add max charge power/rate #17691

Merged

Hypo93 mentioned this issue Dec 12, 2024

Update huawei-sun2000.yaml #17695

Merged

andig closed this as completed in #17695 Dec 12, 2024

Hypo93 mentioned this issue Dec 13, 2024

Huawei SUN2000: handle cascading inverters #17726

Merged

Hypo93 mentioned this issue Dec 28, 2024

Template for Huawei SUN2000/LUNA for ToU AC-Charging #17936

Closed

Huawei Netzladen improvement - AC Charging Flag umschalten #17692

Huawei Netzladen improvement - AC Charging Flag umschalten #17692

Comments

Hypo93 commented Dec 11, 2024 • edited Loading

andig commented Dec 11, 2024

Hypo93 commented Dec 11, 2024

andig commented Dec 12, 2024

andig commented Dec 12, 2024

andig commented Dec 12, 2024

Hypo93 commented Dec 12, 2024

Hypo93 commented Dec 12, 2024

LotharWoman commented Dec 13, 2024

MucheteWO commented Dec 13, 2024

Hypo93 commented Dec 13, 2024

MucheteWO commented Dec 13, 2024

Hypo93 commented Dec 13, 2024

MucheteWO commented Dec 13, 2024

Hypo93 commented Dec 13, 2024

snookerap commented Dec 17, 2024

Hypo93 commented Dec 17, 2024

snookerap commented Dec 17, 2024

Hypo93 commented Dec 17, 2024

snookerap commented Dec 17, 2024

Hypo93 commented Dec 17, 2024

Hypo93 commented Dec 17, 2024 • edited Loading

rnndchsrl commented Dec 17, 2024 • edited Loading

Hypo93 commented Dec 17, 2024 • edited Loading

LotharWoman commented Dec 17, 2024

LotharWoman commented Dec 18, 2024 • edited Loading

andig commented Dec 18, 2024

LotharWoman commented Dec 18, 2024

Hypo93 commented Dec 18, 2024 • edited Loading

LotharWoman commented Dec 18, 2024 • edited Loading

LotharWoman commented Dec 18, 2024

andig commented Dec 18, 2024

Hypo93 commented Dec 19, 2024

LotharWoman commented Dec 19, 2024

Hypo93 commented Dec 19, 2024 • edited Loading

andig commented Dec 19, 2024

LotharWoman commented Dec 19, 2024

andig commented Dec 19, 2024

hstreitenberger commented Dec 20, 2024

Hypo93 commented Dec 20, 2024

Hypo93 commented Dec 20, 2024

hstreitenberger commented Dec 20, 2024 • edited Loading

LotharWoman commented Dec 20, 2024

Hypo93 commented Dec 20, 2024 • edited Loading

snookerap commented Dec 26, 2024

Hypo93 commented Dec 26, 2024

LotharWoman commented Dec 26, 2024 • edited Loading

mucki12 commented Dec 27, 2024 • edited Loading

Hypo93 commented Dec 27, 2024 • edited Loading

mucki12 commented Dec 28, 2024

snookerap commented Dec 28, 2024

mucki12 commented Dec 28, 2024 • edited Loading

mucki12 commented Dec 28, 2024

Hypo93 commented Dec 11, 2024 •

edited

Loading

Hypo93 commented Dec 17, 2024 •

edited

Loading

rnndchsrl commented Dec 17, 2024 •

edited

Loading

Hypo93 commented Dec 17, 2024 •

edited

Loading

LotharWoman commented Dec 18, 2024 •

edited

Loading

Hypo93 commented Dec 18, 2024 •

edited

Loading

LotharWoman commented Dec 18, 2024 •

edited

Loading

Hypo93 commented Dec 19, 2024 •

edited

Loading

hstreitenberger commented Dec 20, 2024 •

edited

Loading

Hypo93 commented Dec 20, 2024 •

edited

Loading

LotharWoman commented Dec 26, 2024 •

edited

Loading

mucki12 commented Dec 27, 2024 •

edited

Loading

Hypo93 commented Dec 27, 2024 •

edited

Loading

mucki12 commented Dec 28, 2024 •

edited

Loading