Switch off Sonnenbatterie discharging on "start", re-enable on "stop" messaging events.

[markusjnagel]

Based on what @GrimmiMeloni did for his Powerwall, I created a similar script for the Sonnenbatterie.
Much simpler, since the Sonnenbatterie has a very straightforward JSON API (and is in general less sophisticated than a Powerwall 😉 ).

So, first of all, thanks @GrimmiMeloni for the inspiration and sharing it ❤️ .

Here's the repo for evcc & Sonnenbatterie: https://github.com/sonnen-tools/scripts (I didn't fork https://github.com/GrimmiMeloni/powerwall-backupCtrl since the SB use case is much simpler).

Cheers,

Markus

[markusjnagel]

Oh, just one thing that came to my mind - "yeah, cool - but why the heck didn't you just create an evcc PR and contribute it yourself, bugger?!?!?"
Well, yeah - but my Golang - fu is weak. That's why. 🖖

[andig]

@markusjnagel wenn du mir verrätst, wie Du die 3 Modi schaltest ohne dass ich es reverse-engineeren muss kann ich das gerne einbauen.

[markusjnagel]

Gern, @andig - und: 1000 Dank für Eure unermüdliche Arbeit!!!!!

1) Bei start charge:

• Batterie in den manuellen/API Modus versetzen: (HTTP PUT)

curl -sS -X PUT -d EM_OperatingMode=1 --header "Auth-Token: $SONNEN_API_TOKEN" "http://$SONNEN_API_IP/api/v2/configurations" 

• Sie merkt sich das letzte Kommando, dass man ihr im manuellen Modus mitgegeben hat (z.B. Laden mit x kW), deshalb explizit "Laden mit 0" und "Entladen mit 0" setzen - damit ist sie effektiv "passiv".

curl -sS -X POST --header "Auth-Token: $SONNEN_API_TOKEN" -d "" "http://$SONNEN_API_IP/api/v2/setpoint/charge/0"

curl -sS -X POST --header "Auth-Token: $SONNEN_API_TOKEN" -d "" "http://$SONNEN_API_IP/api/v2/setpoint/discharge/0"

Achtung, es sind POST Requests mit leerem Body (also content-length=0, deshalb das -d "" in curl, sonst hustet der API-Webserver der Batterie)

2) Bei stop charge:

Batterie einfach in den "Normalmodus" (self-consumption, "OperatingMode = 2") zurücksetzen

curl -sS -X PUT -d EM_OperatingMode=2 --header "Auth-Token: $SONNEN_API_TOKEN" "http://$SONNEN_API_IP/api/v2/configurations" 

---

Rückgabewerte:

$ echo $SONNEN_API_IP $SONNEN_API_TOKEN 
192.168.2.108 215ddea7-dff9-421b-8744-ee2504f9ec0e

$ curl -sS -X PUT -d EM_OperatingMode=1 --header "Auth-Token: $SONNEN_API_TOKEN" "http://$SONNEN_API_IP/api/v2/configurations" 
{"EM_OperatingMode":"1"}

$ curl -sS -X POST --header "Auth-Token: $SONNEN_API_TOKEN" -d "" "http://$SONNEN_API_IP/api/v2/setpoint/charge/0"
true


$ curl -sS -X POST --header "Auth-Token: $SONNEN_API_TOKEN" -d "" "http://$SONNEN_API_IP/api/v2/setpoint/discharge/0"
true

$ curl -sS -X PUT -d EM_OperatingMode=2 --header "Auth-Token: $SONNEN_API_TOKEN" "http://$SONNEN_API_IP/api/v2/configurations" 
{"EM_OperatingMode":"2"}

---

Ich nutze für alle Meter in evcc das "sonnenbatterie" Template - da aber dort nur gelesen wird, braucht es das API Token nicht. Um Werte zu setzen, muss das mitgegeben werden. Das holt sich der SB-Nutzer von der Batterie (nicht aus der Sonnen-App oder der Sonnen-Website). Ist auch nicht mit dem Sonnen-Account verknüpft, deshalb unkritisch solange niemand Zugriff auf das Heimnetzwerk hat.

meters:
- type: template
  template: sonnenbatterie 
  usage: grid  
  host: 192.168.2.108  
  port: 8080  
  name: grid1
- type: template
  template: sonnenbatterie 
  usage: pv  
  host: 192.168.2.108  
  port: 8080  
  name: pv2
- type: template
  template: sonnenbatterie 
  usage: battery  
  host: 192.168.2.108  
  port: 8080  
  name: battery3

---

Anmerkung: Ich sehe gerade, dass in meiner evcc.yaml beim "sonnenbatterie" Template der Port 8080 mitgegeben wird - es funktioniert aber prima, deshalb fummel ich da nicht dran rum.
Nur ist die API eigentlich über Port 80 (nicht 8080) erreichbar - bei Zugriff auf 8080 krieg ich ne Fehlermeldung... nur zur Info. evcc liest aber mit der Konfiguration prima die Daten aus und läuft wie ne eins 👍

Probiere ich per curl auf 8080 zu gehen, gibt's ne Fehlermeldung, auf 80 (bzw. ganz weggelassen) geht es - siehe "Rückgabewerte" oben und Beispiel unten... aber das nur am Rande.

$ curl -sS -X GET --header "Auth-Token: $SONNEN_API_TOKEN" "http://192.168.2.108/api/v2/status" 
{"Apparent_output":92,"BackupBuffer":"0","BatteryCharging":false,"BatteryDischarging":false,"Consumption_Avg":499,"Consumption_W":498,"Fac":49.9739990234375,"FlowConsumptionBattery":false,"FlowConsumptionGrid":true,"FlowConsumptionProduction":true,"FlowGridBattery":false,"FlowProductionBattery":false,"FlowProductionGrid":false,"GridFeedIn_W":-215,"IsSystemInstalled":1,"OperatingMode":"1","Pac_total_W":-2,"Production_W":285,"RSOC":73,"RemainingCapacity_Wh":15164,"Sac1":92,"Sac2":null,"Sac3":null,"SystemStatus":"OnGrid","Timestamp":"2024-01-15 11:07:26","USOC":71,"Uac":230,"Ubat":211,"dischargeNotAllowed":false,"generator_autostart":false}

curl -sS -X GET --header "Auth-Token: $SONNEN_API_TOKEN" "http://192.168.2.108:8080/api/v2/status" 
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>sonnenBatterie</title>
<meta charset="utf-8">
<meta content="IE=edge,chrome=1" http-equiv="X-UA-Compatible">
<meta content="width=device-width,initial-scale=1" name="viewport">
<link rel="stylesheet" type="text/css" href="/error.css">
</head>
<body>
<div class="wallpaper">
<div class="logo"></div>
<div class="error">
<h1>Something went wrong</h1>
<h3>Page not found</h3>
<h3><a href="/">Try again</a></h3>
</div>
</div>
</body>
</html>

[andig]

Wir brauchen:

• normal
• hold
• charge

Jeder Modus muss für sich die anderen wieder übersteuern.

evcc/templates/definition/meter/sonnenbatterie.yaml

Line 4 in 4fa0155

- brand: Sonnen

benutzt bereits das HTTP API, Du kannst die anderen Endpunkte also analog dazu basteln und noch viel wichtiger- wenn Du evcc selbst kompilierst- auch testen!

PR wäre Klasse :)

/cc @premultiply

[markusjnagel]

Eieiei - mein golang-fu ist schwach, Andi-wan. Aber ich probier's mal :)

[markusjnagel]

Anmerkung: Ich sehe gerade, dass in meiner evcc.yaml beim "sonnenbatterie" Template der Port 8080 mitgegeben wird - es funktioniert aber prima, deshalb fummel ich da nicht dran rum.
Nur ist die API eigentlich über Port 80 (nicht 8080) erreichbar - bei Zugriff auf 8080 krieg ich ne Fehlermeldung... nur zur Info. evcc liest aber mit der Konfiguration prima die Daten aus und läuft wie ne eins 👍

Ah, ich sehe gerade (nur zur Info) - das Template geht auf die v1 API, deshalb läuft das problemlos mit Port 8080, während die neueren Sonnenbatterien auf ihrer internen Seite nur die v2 API (und zugehörige APIDoc) anzeigen.
Aber - auch mit meiner SB10 läuft das problemlos mit v1.

evcc/templates/definition/meter/sonnenbatterie.yaml

Line 20 in 4fa0155

uri: http://{{ .host }}:{{ .port }}/api/v1/status

[Nitrox912]

Hallo, das ist eine sehr schöne Funktion. Gibt es einen besonderen Grund, warum die Batterie nur im Schnelllademodus gesperrt wird und wäre es auch möglich nur eine Entladesperre zu setzen?

Zum Vergleich: Bei meinem Alpha Ess Hi10 Speicher setze ich per Modbus den MinSoc bei Ladestart auf 100%, damit die Wallbox den Speicher nicht leersaugen kann. Außerdem umgehen ich so im PV-Modus dieses lästige und unzuverlässige Ausregeln zwischen Wallbox und Speicher untereinander, auch wenn plötzlich andere Verbraucher im Haushalt dazu geschalten werden.

Anders als hier wir mein Alpha Ess Speicher aber weiterhin beladen und der noch vorhandene Überschuss nicht ins Netz gespeist.

[premultiply]

Zunächst wäre weiterhin zu klären wie interval und residualPower eingestellt und warum.

Speziell interval darf nicht kürzer als das Regelintervall des Speichers sein.

Immer wenn mehrere Regelungen am Werk sind (hier Speicher und evcc) muss es eine definierte zeitliche Priorität geben.
Der Speicher muss hier vor allem anderen die Chance bekommen den Netzanschluss auf 0 auszuregeln.
evcc regelt dann zeitlich nachrangig aber eben mit Kenntnis der aktuellen Speicherleistungs unter Berücksichtigung von residualPower gemäß der momentanen Prioritäten aus.

Heftige Schwingungen gibt es nur wenn interval zu kurz im Vergleich zur Speicherausregelungszeit ist oder sich zwei Regelungen (hier evcc und Speicher) um die Definition des Nullpunkts streiten.

[Nitrox912]

@andig
Ich kann dir gerne die Informationen zur Verfügung stellen, wenn du mir sagst, welche du genau aufbereitet haben möchtest.

@premultiply
Da ist was dran. interval wird in mein Fall (3-5 Sekunden) wahrscheinlich zu kurz gewesen sein, da mein damaliger Speicher (Alpha ESS T10) äußerst träge war. Mit residualPower habe ich einiges experimentiert (teilweise mit bis zu 1000W verbleibender Netzeinspeiseleistung).

Lange Rede kurzer Sinn: Im Sinne der Nutzerfreundlichkeit von evcc, an der ja erkennbar gearbeitet wird, erachte ich die aktive Speichersteuerung als zielführend. Umso weniger Systeme aufeinander reagieren müssen, umso stabiler läuft das Ganze ja schließlich. Insbesondere da so Unschärfen beim Ausregeln eliminiert werden können und der Nutzer eher nachvollziehen kann was da gerade passiert.

[andig]

Ich kann dir gerne die Informationen zur Verfügung stellen, wenn du mir sagst, welche du genau aufbereitet haben möchtest.

Ich glaub das hat sich grad erledigt ;). Darum gibts ja Warnungen im Logfile!

[Nitrox912]

Um jetzt auf das Thema zurückzukommen: Ist es denn für euch als Entwickler ein Thema die Entladesperre auch im PV-Modus zur Verfügung zu stellen? Soll ich hierzu ein Issue aufmachen, damit darüber entschieden werden kann?

[premultiply]

Für mich ist weiterhin kein praktischer, ökologischer oder wirtschaftlicher Nutzen erkennbar.

Die aufgezeigten Konfigurationsfehler kannst du leicht selbst beheben so dass der PV-Modus erwartungsgemäß funktionieren sollte.