SofarSolar: add battery control #10847
Conversation
|
Danke fürs Pingen. Ich muss mal sehen, ob ich auf der Installtion (HomeAssistant docker mit evcc als Plugin) auch einen Pull Request getestet bekomme -- habe ich bisher nicht versucht. |
|
Genau. In HA wirst Du das aber erst nach dem Release testen können. Spricht ja aber nix dagegen, das einfach mal auf dem PC zu probieren. |
|
Passive Mode aktivieren (Schreiben via Holdings - glaube den Writetype gibt es in EVCC noch nicht, ich sehe nur writeholding?) Danach muss dieses I32 Register auf 0 gesetzt werden:
|
|
Mehr infos dazu im SourceCode der HA Integration: https://github.com/wills106/homeassistant-solax-modbus/blob/main/custom_components/solax_modbus/plugin_sofar.py Vorgehen im Plugin:
|
|
Das würden wir dann erstmal nicht machen. Wenn es nicht wie hier mit dem minsoc geht dann würde ich vorerst die Finger davon lassen. Geht minsoc denn nicht? |
Auch nicht so einfach. Zunächst einmal gibt es bei Sofar keinen MinSoc, da gibt es eine maximale Entladetiefe. Ein Wert von 80 würde hier einem minSoc von 20 entsprechen. Dann gibt es hier die normale Entladetiefe und die EPS Entladetiefe. Beide Werte müssten angepasst werden. Ich sagte ja schon im anderen Thread: Nicht jeder Wechselrichter ist hier gleich und ich fürchte SofarSolar hat hier einen eher komplizierten Weg beschritten. Vielleicht könnt ihr für andere einfache Patterns finden, aber bei Sofar ist das eher ein Script, das abzuarbeiten ist - besonders mit den ModBus Eigenheiten. Die Idee, dass EVCC das von Haus aus kann ist ohne Frage super. Denke nur aus Eurer Sicht macht ein Support für Sofar nicht viel Sinn und es gibt ja den Workaround das über HomeAssistant zu machen. |
|
"BatConfig_Depth_of_Discharge", vgl. #10379 (comment) |
|
Register: Wechselrichter Docu: |
Die Umrechnung ist ja trivial. Spricht da was dagegen?
Warum? Es fehlt nur noch eine Addition sowie eine Multiplikation mit -1? Es fehlt einfach die Antwort auf die Frage obs damit geht- die scheint aber schwer zu bekommen zu sein ;) |
|
Hm, ein Versuch wäre es Wert. Theoretisch muss man in BatConfig_Depth_of_Discharge eigentlich nur eine 0 reinschreiben um den minSoc auf 100% zu stellen. Und vorher den alten Wert auslesen, speichern, und später wiederherstellen. Bleibt nur noch der write type Holdings, den EVCC noch nicht unterstützt. |
Auch das ist ein Gerücht. Du meinst weil der Sofar kein WriteSingle kann? |
Auch nicht nötig, der wird per minsoc/maxsoc konfiguriert oder es gilt 20-95. |
Genau. Ich bin schon dran verzweifelt. Erst schreiben mit Holdings geht. Falls das ein Gerücht ist, sorry. In Eurer ModBus Dokumentation sehe ich nur writecoil und writeholding: https://docs.evcc.io/docs/reference/modbus#schreiben-von-registern writeholdings vermisse ich in der Dokumentation. |
|
Sehr cool! Ihr seid also weiter als die Docu :) Ich werde das gerne testen, sobald es im Nightly drin ist. |
Immerhin gibts das schon seit 4 Tagen, also uralt (#10753) grin Von meiner Seite erstmal fertig und wäre einen Test wert. Mergen würde ich es gerne erst wenns mal verprobt ist. |
Wie teste ich das am besten? Einfach hinzugefügte Zeilen mal zu meiner Config hinzufügen? Oder kann man die Templates an eine bestimmte Stelle kopieren? |
|
Die Template-Änderung alleine reichen nicht, Du benötigst auch all die Änderungen rund um battery control, die ich den letzten Tagen in den Entwicklungszweig eingepflegt wurden. Insofern --> diesen Branch auschecken und evcc kompilieren. Nicht trivial, aber von vielen praktiziert (von mir bisher auch nicht). |
Phew... das wird jetzt kompliziert... |
|
Eigentlich nicht, siehe README :) |
|
Oh, ich merke gerade, dass das (für mich) falsche Template verändert wurde. Da stimmen sicher auch die ganzen Register nicht, da im 'sofarsolar.yaml' die älteren SofarSolar Modelle mit älterem Protokoll behandelt werden. Ich rede die ganze Zeit vom SofarSolar HYD xxKTL, welcher im sofarsolar-g3.yaml behandelt wird (https://github.com/evcc-io/evcc/blob/94d67ecf7526366f2656216cd10f2a4e9305656d/templates/definition/meter/sofarsolar-g3.yaml). Ist mir leider erst aufgefallen, als ich gemerkt hatte, dass in dem Template gar kein Delay as Parameter drin ist, welchen wir dort noch als Workaround für die unzuverlässige Kommunikation via RS485 Anschluss einbauen mussten. BTW: Aus diesem Grund würde ich Battery Management auch nur in ein LSE-3 Template einbauen, da das Template mit beliebigen RS485 Adapter nicht zuverlässig laufen wird. Siehe auch: #10723 (comment) |
|
Geändert. Wenn ne Info für den "alten" gibt können wir das analog machen |
|
@andig - Du bist zu schnell. War noch beim editieren meines Comments. |
|
Erstmal muss es getestet werden, dann kanns auch in andere Versionen mit rein. |
Helfe da gerne, aber bitte hab Verständnis, dass ich mit Compilieren das nicht mal eben schnell am Abend machen kann. Ich versuche das am Wochenende hinzubekommen. |
|
@cschlipf, ich war neugierig und das Kompilieren geht tatsächlich sehr einfach. evcc ist nach etwa einer Vierstelstunde mit der Demo-Konfiguration gestartet. Ich muss überlegen, wie ich den Test mit dem SofarSolar-Wechselrichter geschickt mit evcc vom Laptop testen kann -- heute nicht mehr. |
|
Es sollte reichen, Sofortladen zu aktivieren um den Akku zu sperren. |
|
@andig - Da es gemerged ist, findet man das morgen im Nightly Build? |
|
Ja |
|
Ich habe es soeben versucht zu testen. Leider hat es nicht funktioniert. Die Batterie war weiterhin aktiv und die Maximale Entladetiefe im Wechselrichter wurde nicht geändert. Config: # open evcc at http://evcc.local:7070
network:
schema: http
host: evcc.local # .local suffix announces the hostname on MDNS
port: 7070
log: debug
levels:
cache: error
# unique installation id
plant: b0fb7a14a96bede23a6f526915a02514ad9e5e7826d8fdfe74666cf7dd48ed5b
interval: 10s # control cycle interval
sponsortoken: XXXXXXXXXXXXXXXXX
# sponsors can set telemetry: true to enable anonymous data aggregation
# see https://github.com/evcc-io/evcc/discussions/4554
telemetry: false
meters:
- type: template
template: sofarsolar-g3
id: 1
host: 192.168.158.13
port: 8899
usage: grid
modbus: tcpip
delay: '0s'
name: grid1
- type: template
template: sofarsolar-g3
id: 1
host: 192.168.158.13
port: 8899
usage: pv
modbus: tcpip
delay: '0s'
name: pv2
- type: template
template: sofarsolar-g3
id: 1
host: 192.168.158.13
port: 8899
usage: battery
modbus: tcpip
delay: '0s'
name: battery3
chargers:
- type: template
template: easee
user: XXXXXXXXXXXXXXXXX
password: XXXXXXXXXXXXXXXXX
charger: XXXXXXXXXXXXXXXXX
timeout: 10s
name: wallbox5
vehicles:
- type: template
template: tesla
title: tesla
accessToken: XXXXXXXXXXXXXXXXX
refreshToken: XXXXXXXXXXXXXXXXX
capacity: 79
name: ev4
loadpoints:
- title: Garage
charger: wallbox5
mode: pv
phases: 3
mincurrent: 6
maxcurrent: 16
resetOnDisconnect: true
site:
title: Pirolweg
meters:
grid: grid1
pv:
- pv2
battery:
- battery3Debug log: |
|
OK, ich habe mir nochmal das Template angeschaut und bin drauf gekommen, dass ich noch ein paar Änderungen machen muss: - type: template
template: sofarsolar-g3
id: 1
host: 192.168.158.13
port: 8899
usage: battery
modbus: tcpip
delay: '0s'
name: battery3
capacity: 10
minsoc: 20
maxsoc: 100Damit getestet ist nun was merkwürdiges passiert: Im Wechselrichter hat sich die Entladetiefe immer noch nicht geändert. Jedoch wurde die Batterie nicht mehr voll zugeschaltet, sondern nur noch mit halber Leistung bei zwei Modulen. So als ob ein Batteriemodul deaktivert worden wäre. |
|
Ich werde jetzt erstmal ein kleines Kommando bauen um den Modus per Kommandozeile umzustellen. Damit sollte es sich leichter testen lassen. Für dein konkretes Problem wird es nur helfen auf die Register im Template zu schauen- sind die alle korrekt? Wird über Modbus das geschickt was du auch erwarten würdest? Gibts noch irgendeinen Keepalive? |
|
Das ist eine gute Idee. Meine Konfiguration da oben war grundsätzlich richtig? Ich habe gesehen, dass die Home Assistant Integration auch erlaubt die Entladetiefe zu verstellen. Ich werde heute abend damit mal herumspielen und schauen ob ich grundsätzlich das gewünschte Verhalten mit meinem Wechselrichter überhaupt erreichen kann. |
|
Weiter hier: #10901 |
| {{- include "modbus" . | indent 6 }} | ||
| delay: {{ .delay }} | ||
| register: | ||
| address: 0x104C # BatConfig_Current_Discharge_Limit |
There was a problem hiding this comment.
Falsches Register: Muss 0x104D sein
0x104C ist die maximale Stromstärke zum entladen, nicht der SoC. Und diese lässt sich nur im Passive Mode setzen.
Refs #10379