Sofar HYD: Battery Control

[premultiply]

https://www.photovoltaikforum.com/thread/221806-sofar-hyd-mit-evcc-akkuentladung-verhindern/?postID=3598510#post3598510

in Template übersetzen

[cschlipf]

@premultiply Lass mich wissen, wenn Du das angehst. Habe mittlerweile in der Integration einiges geändert. Siehe auch: https://homeassistant-solax-modbus.readthedocs.io/en/latest/sofar-energy-storage-modes/, insbesondere dieser Abschnitt: https://homeassistant-solax-modbus.readthedocs.io/en/latest/sofar-energy-storage-modes/#prevent-battery-discharging

Sofar erlaubt hier dann auch die Entladung zu verhindern - die Ladung aber weiterhin zuzulassen (falls jemand mehr vom Dach bekommt als in das Auto+Haus hineingeht)

[andig]

@cschlipf wäre es möglich hier kurz die relevanten Register und Werte zu beschreiben? Dann ist das schnell gemacht. Danke!

[cschlipf]

Gerne.

Um den Passive Mode zu setzen ist dieses Register zu schreiben:

Mit dem Wert 3 geht es in den Passive Mode. Wenn man die Batterie wieder aktiviert, sollte das Register wieder zurück auf 0 (Self-Use) gesetzt werden.

Nun könnte es noch sein, dass im Passive Mode die Werte nicht stimmen, weil sie zuvor auf irgendwas anderes gesetzt worden sind. Dazu müssen diese Register zusammen in einer Schreiboperation gesetzt werden:

• Passive_Manual_Gdes 1187/1188: auf 0 (das regelt den gewünschten Netzbezug - wir wollen den hier möglichst vermeiden, daher 0)
• Passive_Manual_Blo 1189/118A: auf 0 (um die Entladung zu verhindern)
• Passive_Manual_Bup 118B/118C: auf 2147483647 (um trotzdem eine Ladung zu ermöglichen, falls vom Dach doch mehr kommt als die Autos schlucken können)

[cschlipf]

SOFAR Modbus Protocol G3_2023-12-22_1.22_en-INT.xlsx

Bei der Gelegenheit hier die aktuellsten ModBus Register.

[andig]

Nun könnte es noch sein

Ich brauche bitte einfach die Liste der Register mit Wert je Modus. Keine Screenshots, keine Textaufgabe. Danke!

[cschlipf]

OK, ich dachte das hätte ich schon genau genug beschrieben.

• Batterieentladung deaktivieren:
  • Energystorage mode auf Passive setzen: U16 Register 1110 auf 3
  • Leistungen setzen zusammen in einer einzelnen Schreiboperation:
    • I32 Register 1187/1188 auf 0
    • I32 Register 1189/118A auf 0
    • I32 Register 118b/118C auf 2147483647
• Batterieentladung wieder deaktiveren/Normalbetrieb
  • Energystorage mode auf Self-Use setzen: U16 Register 1110 auf 0

Hoffe das war kurz und prägnant genug.

[andig]

Danke, das hilft dem Entwickler mit wenig Zeit- Netzladung gibts nicht?

[andig]

Gerne testen

[cschlipf]

Netzladung geht genauso, nur mit anderen Werten:

• Netzladung deaktivieren:
  • Energystorage mode auf Passive setzen: U16 Register 1110 auf 3
  • Leistungen setzen zusammen in einer einzelnen Schreiboperation:
    • I32 Register 1187/1188 auf 0
    • I32 Register 1189/118A auf <Ladeleistung>
    • I32 Register 118b/118C auf <Ladeleistung>

<Ladeleistung> ist hier der Wert in W mit der der Akku geladen werden soll. Beim BTS Speicher ist das die Hälfte der Kapazität (z.B. ein BTS Speicher mit 10 kWh Kapazität braucht hier einen Wert von 5000 für die maximale Ladeleistung)

• Zurück auf Normalbetrieb
  • Energystorage mode auf Self-Use setzen: U16 Register 1110 auf 0

[cschlipf]

Gerne testen

Muss leider warten: Morgen früh geht es in den Urlaub.

[wardwygaerts]

Gerne testen

How can I test? Can I install this branch in Docker?

[Frintrop]

@cschlipf @andig

Gilt dies nicht auch für die anderen Wechselrichter von Sofar funktionieren, die das -g3 Template benutzen. Im Code von Solax_Modbus sehe ich keine anderen Register für die anderen Wechselrichter. ( Insbesonder HYD xKTL-3PH ) ?!?!

[Zwer2k]

Genau, sollte nicht eigentlich sofarsolar-g3.yaml angepasst werden?
Bei mir tauchen die Einstellungen nicht auf.
Ich glaube auch, dass mit der Anpassung die Register einzeln geschrieben werden, das wird vermutlich nicht funktionieren. Damit es funktioniert, sollten aber 3 Register gleichzeitig geschrieben werden.
Hier noch mein Diskussionsbeitrag als Querverweis #15722 (comment)

[Frintrop]

Sollen wir ein neues Ticket aufmachen für das sofarsolar-g3.yaml Template ? @andig @cschlipf ?

[andig]

Jetzt wäre es doch prima, diesen PR überhaupt mal zu testen. Dann können wir ihn ja einfach kopieren falls die Register identisch sind.

[sahomm]

Werde ich machen. Bin aber nicht vor Donnerstag am HYD

[Zwer2k]

Das sofarsolar.yaml Template scheint zu HYD 10KTL-3ph nicht zu passen

[site  ] ERROR 2024/09/24 19:17:46 battery 1 power: read failed: modbus: exception '2' (illegal data address), function '3'
[site  ] ERROR 2024/09/24 19:17:55 pv 1 power: read failed: modbus: exception '2' (illegal data address), function '3'
[site  ] ERROR 2024/09/24 19:17:56 battery 1 power: read failed: modbus: exception '2' (illegal data address), function '3'
[site  ] ERROR 2024/09/24 19:18:06 pv 1 power: read failed: modbus: exception '2' (illegal data address), function '3'
[site  ] ERROR 2024/09/24 19:18:06 battery 1 power: read failed: modbus: exception '2' (illegal data address), function '3'
[site  ] ERROR 2024/09/24 19:18:15 pv 1 power: read failed: modbus: exception '2' (illegal data address), function '3'
[site  ] ERROR 2024/09/24 19:18:16 battery 1 power: read failed: modbus: exception '2' (illegal data address), function '3'```

[cschlipf]

Genau. Das wurde im falschen Template eingebaut. Der HYD braucht das G3 Template. Ich wurde empfehlen den PR zu reverten. Die Register der alten Wechselrichter sind komplett anders. So kann ich das auch leider nicht testen.

[andig]

Neues Nightly in 20min

[brandsb]

Hello, I'm trying to accomplish the same thing (first aid topic #15798) but for the HYD5000-ES inverter. The addresses don't match with those of the sofarsolar nor with the G3 template. I've posted the modbus comms documentation Here

I got the grid, pv & battery reads covered. Only the battery control is getting the better of me...

Anyone able to assist me on this? thx!

[sahomm]

Hier das versprochene Feedback...
Setup: HYD 15 KTL mit 20kw BTS Batterie
EVCC-Version: 0.130.12+1727247451

Szenario:

1. Fahrzeug anschließen im PV-Mode
2. Umschalten auf Schnell
3. nach ca 2 Minuten zurück auf PV

Ergebnis:

• Das Fahrzeug wurde erkannt und nicht geladen, da kein PV-Überschuss. >> OK
• Nach Umschaltung auf "Schnell" wurde das Fahrzeug geladen und der Akku abgeschaltet (HYD im Passive-Mode) >> OK
  Hier wird aber zyklisch folgende Fehlermeldung geworfen:

[site ] ERROR 2024/09/25 20:22:31 battery mode: modbus: response data size '18' does not match count '4'

• Die Umschaltung zurück auf PV wird von EVCC ordnungsgemäß durchgeführt, die Umschaltung des HYD auf "SelfUse" um die Akkunutzung wieder zu aktivieren jedoch nicht. >>notOK

Das Log hänge ich an, SKI.Keys wurden entfernt.

Vielen Dank für eure tolle Arbeit!

Saho
evcc-20240925-204241-debug-no-ski.log

[wardwygaerts]

I have a HYD 5000-EP, and getting this error when trying to charge my battery from the grid:

[site ] ERROR 2024/09/25 21:14:01 battery mode: modbus: response data size '18' does not match count '4'

[andig]

Der LSE-3 Stick wird nicht von Sofar hergestellt, sondern von einem dritten Hersteller (IGEN Tech, Solarman), welcher auch noch andere Wechselrichter unterstützt.

Das ändert nix dran, dass das Teil Schrott ist. Dann bei diesem Hersteller beschweren.

Die von Sofar unterstützte Schnittstelle ist RS 485.

...oder einfach auf eine funktionierende Schnittstelle umsteigen. Wir halten fest: evcc funktioniert wie erwartet.

In Case 1 wird zwar "pasive mode" mit dem Register 0x1110 gesetzt, die Leistungswerte werden aber nicht angepasst, d.h. Register 0x1187, 0x1189 und 0x118b bleiben unverändert und es wird eine Fehlermeldung im battery mode: modbus: exception '3' (illegal data value), function '16' geworfen. Wie gesagt, ich verwende Waveshare nicht LSE3
Es ist wichtig, dass die 3 Register mit einem Befehl an den WR geschickt wird und nicht mit 3 einzelnen aufrufen, anderer falls wird vom WR ein Fehler zurück gegeben.

@Zwer2k das ist spannend. Die Vorgabe war:

Energystorage mode auf Self-Use setzen: U16 Register 1110 auf 0

Du sagst das funktioniert so nicht? Was muss stattdessen geschrieben werden? Dann frage ich mich natürlich auch, warum es bei einigen Anwendern anscheinend funktioniert???

[Pitchen84]

@Pitchen84 Lse3? Laut #12220 (comment) geht das nicht, also bitte an den Hersteller wenden.

Und: gibts nur Fehler oder wird nicht umgeschaltet?

LSE3, HYD15 KTL mit 10 kWh BTS und 61er Firmware

[andig]

Der LSE-3 Stick wird nicht von Sofar hergestellt, sondern von einem dritten Hersteller (IGEN Tech, Solarman), welcher auch noch andere Wechselrichter unterstützt.

@cschlipf was mich jetzt wirklich irritiert ist der Text im Template:

Es wird empfohlen die Verbindung über einen LSE-3 Logger Stick mittels ModBus TCP herzustellen (LSW-3 WLAN Stick wird nicht unterstützt). Bei seriellem Anschluss via RS485 mit entsprechendem Adapter am COM Port ist zu beachten, dass wechselrichterseitig für eine Terminierung des RS485 Busses zu sorgen ist.

Wenn der LSE Schrott ist müssten wir das korrigieren?

[Zwer2k]

Case 1 (also zurückschalten auf "self use") funktioniert bei mir nicht. So wie ich es verstanden habe, auch bei anderen funktioniert es nicht.
Aus meiner Sicht liegt es so wie @cschlipf beschrieben hat an fehlenden - in Template

[cschlipf]

@andig Wie gesagt - es ist nur eine falsche Fehlermeldung. Es tut ja trotzdem.

Energystorage mode auf Self-Use setzen: U16 Register 1110 auf 0

Doch, das ist richtig. Und dieses eine Register kann auch alleine für sich geschrieben werden. Ich verstehe daher nicht, warum der Self-Use nicht wieder aktiviert wird. Wie gesagt: Meine Vermutung war die fehlende Liste.

Hier nochmal die Specs:

Was 0x1187, 0x1189 und 0x118b betrifft: Hier ist offensichtlich das Problem, dass diese nicht zusammen in einer Write Operations geschrieben werden:

(siehe letzte Spalte unter Remarks)

[cschlipf]

Der LSE-3 Stick wird nicht von Sofar hergestellt, sondern von einem dritten Hersteller (IGEN Tech, Solarman), welcher auch noch andere Wechselrichter unterstützt.

@cschlipf was mich jetzt wirklich irritiert ist der Text im Template:

Es wird empfohlen die Verbindung über einen LSE-3 Logger Stick mittels ModBus TCP herzustellen (LSW-3 WLAN Stick wird nicht unterstützt). Bei seriellem Anschluss via RS485 mit entsprechendem Adapter am COM Port ist zu beachten, dass wechselrichterseitig für eine Terminierung des RS485 Busses zu sorgen ist.

Wenn der LSE Schrott ist müssten wir das korrigieren?

Bisher haben wir nur ausgelesen. Da funktioniert der LSE-3 wunderbar und ist die einfachste Methode. Beim Schreibzugriff kommt eben der falsche Response Code zurück - das ist nicht schön. Aber nochmal: Das hat nun mit den Problemen hier nichts zu tun. In Home Asssistant ignoriere ich den fehlerhaften Return Code eben und es tut alles.

RS485 ware die sauberste Methode. Ja. Nur ist das eben für unbedarfte einiges an zusätzlicher Komplexität: Richtige Terminierung, richtige Verkabelung, kompatiblen Adapter finden (hier gibt es zig Forumspost dazu), korrekte Adaptereinstellungen,... wenn das alles passt, die bessere Lösung - nur kannst das halt nicht jedem zumuten.

[andig]

Wie gesagt: Meine Vermutung war die fehlende Liste.

Da gibts nix zu vermuten. Ob das passiert ist ja im Logfile zu sehen. Und es wird ja geschrieben denn sonst gäbe es den Fehler nicht.

Was 0x1187, 0x1189 und 0x118b betrifft: Hier ist offensichtlich das Problem, dass diese nicht zusammen in einer Write Operations geschrieben werden:

Verstehe ich- auch bei gutem Willen- nicht. Das mag so sein. Aber: Wollen wir jetzt diskutieren, dass das Feature gar nicht funktioniert? Das habe ich zumindest oben noch nicht raus hören können.

Long story short: ich hab keinen Überblick mehr, worum es hier eigentlich geht und würde mich daher ausklingen. Fehlerhafte Hardware/Firmware ist bitte beim Hersteller zu reklamieren.

In Home Asssistant ignoriere ich den fehlerhaften Return Code eben und es tut alles.

Prima. Dann ist das die Lösung. Die Alternative habe ich jetzt schon x-mal beschrieben und die besteht darin ein fehlerhaftes Produkt zu reklamieren.

[cschlipf]

Also ich sehe aktuell 2 Fehler:

• Self-Use wird nicht gesetzt um die Batterieladung wieder zu aktivieren. Warum das nicht tut, verstehe ich nicht. Register und Werte sind korrekt.
• Werte für 0x1187, 0x1189 und 0x118b werden nicht gesetzt. Dies ist in vielen Fällen kein Problem, da die Default Werte hier 0 sind (Batterie deaktiviert). Es ist aber ein Problem, wenn jemand diese Werte nicht auf Default gesetzt hat, weil er z.B. via HA damit den Speicher lädt oder weil EVCC auch mal den Speicher laden will. Dann werden beim Umschalten auf Passive eben die zuletzt gesetzten Werte genommen und diese können dann statt Speicher deaktivieren eben ganz andere Effekte haben.

[Zwer2k]

Wie gesagt: Meine Vermutung war die fehlende Liste.

Da gibts nix zu vermuten. Ob das passiert ist ja im Logfile zu sehen. Und es wird ja geschrieben denn sonst gäbe es den Fehler nicht.

Das ist es ja, in case 1 gibt es keine Fehlermeldung. Fehler Wird nur in case 2 geworfen, wegen der falschen Behandlung von den 3 Registern (0x1187, 0x1189 und 0x118b).

[andig]

@cschlipf @Zwer2k erlaubt die Doku auch die beiden letzten Register zusammen zu schreiben? Liest sich für mich so. Dann könnte auch #16509 helfen. Auch das müsste aber mal jemand probieren...

Drei Register zu schreiben gibt unsere Modbuslösung aktuell nicht her, dann müssten wir das Feature reverten.

[andig]

@Zwer2k du trägst leider auch nicht zur Klarheit bei. Erst hiess es:

Case 1 (also zurückschalten auf "self use") funktioniert bei mir nicht.

und jetzt:

Fehler Wird nur in case 2 geworfen, wegen der falschen Behandlung von den 3 Registern (0x1187, 0x1189 und 0x118b).

Das ist ein Supportalptraum!

[andig]

Letzte Variante: wir schmeissen die Register 0x1187, 0x1189, 0x118B einfach raus und verlassen uns auf die Defaults. Zur Not müsste man noch erklären wie die zu setzen sind.

[cschlipf]

@cschlipf @Zwer2k erlaubt die Doku auch die beiden letzten Register zusammen zu schreiben? Liest sich für mich so. Dann könnte auch #16509 helfen. Auch das müsste aber mal jemand probieren...

Drei Register zu schreiben gibt unsere Modbuslösung aktuell nicht her, dann müssten wir das Feature reverten.

Nein. Es müssen immer alle Register geschrieben werden. Ja das ist sehr nervig und glaub mir, das hier ist einer der harmlosesten Fälle

[andig]

Ok. Ich würde nochmal einen Versuch unternehmen, das Problem grundsätzlich zu lösen. Dafür bräuchte ich aber Remotezugang zu einem WR um das auch testen zu können. Wer helfen will schickt bitte VPN/SSH an [email protected].

[cschlipf]

Letzte Variante: wir schmeissen die Register 0x1187, 0x1189, 0x118B einfach raus und verlassen uns auf die Defaults. Zur Not müsste man noch erklären wie die zu setzen sind.

Denke sollte für die meisten eine gute Lösung sein. Wer die Register mit anderen Automationen ändert weiß auch wie er die wieder zurücksetzen kann. Sollte nur entsprechend dokumentiert werden, dass EVCC erwartet, dass diese Register alle auf 0 gesetzt sind.

[andig]

Sollte nur entsprechend dokumentiert werden, dass EVCC erwartet, dass diese Register alle auf 0 gesetzt sind.

Das wiederspricht #12220 (comment)

[Zwer2k]

@Zwer2k du trägst leider auch nicht zur Klarheit bei. Erst hiess es:

Case 1 (also zurückschalten auf "self use") funktioniert bei mir nicht.

und jetzt:

Fehler Wird nur in case 2 geworfen, wegen der falschen Behandlung von den 3 Registern (0x1187, 0x1189 und 0x118b).

Das ist ein Supportalptraum!

Ist aus meiner Sicht auch nichts falsch.

• Case 1 funktioniert nicht, wirft aus meiner Sicht aber auch kein Fehler. Ich glaube der wird aus irgend einem Grund einfach nicht ausgeführt.
• Case 2 funktioniert nur teilweise, wirft aber ganze Zeit Fehlermeldungen

Alle Fehlermeldungen scheinen vom Case 2 zu kommen. Kann ich aber nicht zu 100% zuordnen, da case 1 kurz nach dem case 2 ausgeführt wird, nach dem das Schnellladen deaktiviert worden ist.

Versuche aber in der Zukunft etwas präziser mit der Beschreibung zu sein :-)

[cschlipf]

Sollte nur entsprechend dokumentiert werden, dass EVCC erwartet, dass diese Register alle auf 0 gesetzt sind.

Das wiederspricht #12220 (comment)

Nun, 118b (upper limit) ist per default auf 0. Jemand, der nur EVCC einsetzt wird diesen nie ändern. Nutzt man hier den default von 0 hat es nur die Auswirkung, dass der Speicher nicht während des Schnellladens der Fahrzeuge mit Überschuss geladen wird, wenn vom Dach noch mehr Leistung als die maximale Ladeleistung der Wallboxen + Hausverbrauch kommt. Damit kann man vermutlich leben.

Alle Werte auf 0 heißt, dass der Speicher gar nichts mehr macht und praktisch deaktiviert ist.

[Zwer2k]

@cschlipf @Zwer2k erlaubt die Doku auch die beiden letzten Register zusammen zu schreiben? Liest sich für mich so. Dann könnte auch #16509 helfen. Auch das müsste aber mal jemand probieren...

Die Doku schein zu passen. Es lassen sich auch nur die 4 letztere Register beschreiben (eben getestet). Das mit dem 64bit blob sollte daher gehen.

Sollte nur entsprechend dokumentiert werden, dass EVCC erwartet, dass diese Register alle auf 0 gesetzt sind.

Das wiederspricht #12220 (comment)

Nun, 118b (upper limit) ist per default auf 0. Jemand, der nur EVCC einsetzt wird diesen nie ändern. Nutzt man hier den default von 0 hat es nur die Auswirkung, dass der Speicher nicht während des Schnellladens der Fahrzeuge mit Überschuss geladen wird, wenn vom Dach noch mehr Leistung als die maximale Ladeleistung der Wallboxen + Hausverbrauch kommt. Damit kann man vermutlich leben.

Alle Werte auf 0 heißt, dass der Speicher gar nichts mehr macht und praktisch deaktiviert ist.

Um hier Probleme zu vermeiden, würde es eher sinn machen die Einstellung für "Self use"/"passive mode" dem User zu überlassen und nur die Lade-/Entladeleistung durch EVCC zu beeinflussen. Dadurch wird zusätzlich vermieden, dass der EEPROM zu oft beschrieben wird und dadurch vorzeitig altert. Die Register 0x1187, 0x1189, 0x118b werde nur in RAM vorgehalten und dürfen beliebig oft überschrieben werden.
Würde heißen nur Register 0x1189 + 0x118B als 64bit Blob beschreiben:

• case 1: Register 0x1189 = 0xFFFFB1E0 (-20000W), Register 0x118B = 0x00004E20 (+20000W)
• case 2: Register 0x1189 = 0x00000000 (0W), Register 0x118B = 0x00004E20 (+20000W)

Vor dem Beschreiben sollte allerdings geprüft werden ob der "passive mode" schon gesetzt ist, anderenfalls würde der WR Fehlermeldung zurückgeben.

[cschlipf]

@Zwer2k Was Du vorschlägst macht keinen Sinn. Wenn man 0x1189 un 0x118b per 64Bit Blob schreiben kann und EVCC das unterstützt, dann kann man auch Case 1 mit 0x1110 weiterhin auf Self-Use machen und Case 2 mit 0x1110 auf Passive Mode beibehalten.

Case 1 würde dann weiterhin den Wechselrichter wieder auf Ausgangssituation bringen, so wie der Wechselrichter vom Solarteur und man müsste nicht im Default Fall mit einem Passive Mode arbeiten.

[Zwer2k]

Für mich macht es durchaus Sinn. Ich verwende “Passive: Desired Grid Power” (Register 0x1187), um die Netzentnahme durch das Überschwingen zu verhindern. Je mehr PV-Überschuss zur Verfügung steht, desto höhere negative Zahlen gebe ich hier an und desto weniger Netzentnahme gibt es. Das Setzen auf “Self use” durch EVCC würde mir diese Möglichkeit nehmen.

Ich weiß, dass der Wechselrichter “PCC power bias” hat, aber diese Funktion ist mir zu unflexibel und verfälscht zudem die Statistik. Mir ist klar, dass dies sehr spezifisch ist und außer mir vermutlich niemand so verwendet. Es sollte natürlich für die breite Masse der Nutzer funktionieren. Es wäre fein, wenn es hier eine Anpassungsmöglichkeit per evcc.conf gäbe.

[Frintrop]

Ok. Ich würde nochmal einen Versuch unternehmen, das Problem grundsätzlich zu lösen. Dafür bräuchte ich aber Remotezugang zu einem WR um das auch testen zu können. Wer helfen will schickt bitte VPN/SSH an [email protected].

Hast Du schon einen VPN Zugang ?

[andig]

Leider nein

[Frintrop]

Leider nein

Zugriff auf Wechselrichter reicht aus ?

[andig]

Ja

[Frintrop]

[email protected]
@andig Du hast eine Einladung von tailscale bekommen ?!