steff393/wbec

Feature Request: PV-Überschuss laden mit mehreren Wallboxen

Closed this issue · 7 comments

jb-io commented

IST

Aktuell ist ein PV-Überschussladen nur mit Wallbox ID 1 möglich.

ZIEL

Überschussladen soll auch mit mehreren Wallboxen möglich sein

Umsetzungsvorschläge

1. Triviale Lösung

Wallbox ID ist aktuell fix im Code

wbec/src/pvAlgo.cpp

Line 18 in 9072486

#define BOXID 0 // only 1 box supported

Wenn diese per variabel wäre, und z.B. per GET request verändert werden könnte, wäre dies schon eine sehr simple aber hilfreiche Verbesserung:

Bsp:
Analog zu http://wbec.local/pv?pvWatt=-1234 wäre somit ein Request wie Folgt denbar: http://wbec.local/pv?pvWallboxId=1

2. Prioritätenbasierte Lösung

Wallboxen bekommen nacheinander die Leistung freigegeben.

Algorithmusvorschlag:

flowchart TD
    A[PV-Überschuss] --> A1[Set First Wallbox]
    A1 --> Loop{enough\n availPower?}
    Loop -- Yes --> Connected{Car Connected?}
    Loop -- NO --> END[END]
    Connected -- NO --> Next{has next\n Wallbox?}
    Next -- Yes --> Loop
    Next -- No --> END
    Connected -- Yes --> Requested{Anforderung?}
    Requested -- No --> B1[set 6A]
    B1 --> B2[Do NOT decrement remaining Power]
    B2 --> Next
    Requested -- Yes --> C[Regulate WB\nold Algorithmus]
    C --> D[decrement remaining Power\nby calculated target Power]
    D --> Next
Loading

Super, wäre wenn die Reihenfolge der Wallboxen noch in der Config-Datei vorgegeben (z.B. Komma-separiert) werden könnte, anstatt einfach nur über die ID's zu loopen.

Weitere Ausbaustufen:

Da Variante 2 meine Anforderungen vollkommen erfüllt, habe ich dies hier nicht weiters ausgearbeitet, wollte aber die Ideen einfach mal festhalten.

  • Verteilte Leistungsfreigabe
    • Sicherlich wäre es auch denkbar, die Leistung "gerecht" oder anhand einer Konfiguration zu verteilen.
  • Nur die wirklich verwendete Leistung der Wallbox von der für die nächsten Wallboxen verfügbaren Leistung abziehen
    • Würde den Algorithmus vmtl. aber wesentlich komplexer machen
steff393 commented

Danke für den PR.
Die ganze Thematik "optimale, faire Stromverteilung" ist leider noch so ein Thema, das bedingt durch alle möglichen Anforderungenquellen (MQTT, HTTP, PV, Zeitsteuerung, ...) und Standby/Fehlerfälle/Lastmanagement/§14a EnWG relativ schnell komplex wird.
Da muss ich mir mal noch eine generische Lösung überlegen.

abuesen commented

Moin!

Da muss ich mir mal noch eine generische Lösung überlegen.

Dazu habe ich mir auch bereits viele Gedanken gemacht. Vielleicht hilft es Dir etwas.

Unabhängig von der Daten-Quellen müssen die Werte der Steuerung in eine einzige Datenstruktur zusammengeführt werden. Welche Quelle dann Vorrang hat oder ob diese sich gegenseitig ausschließen ist mE als eignes Thema zu betrachten. Jedenfalls darf es nur einen einzigen 'Überschuss' im Steuerungs-Code geben, der für die Berechnung herangezogen wird. Unabhängig von der Quelle. Für andere relevante Werte das selbe Vorgehen.

Ich habe viel überlegt, was mir bei wbec fehlen würde und wie man eine Ladeverteilung realisieren könnte, um Dir konkrete Vorschläge zu machen. Viele viele Möglichkeiten...

Hab mich gleichzeitig nach Alternativen umgeschaut und bin ich bei evcc gelandet. wbec/MQTT macht die Übersetzung auf Modbus und steht bei Systemausfall als Backup bereit. Inzwischen habe ich eine komplexe Ladeautomatisierung und steuere zusätzlich per Home Assistant die Haus-Batterie. Viel mehr als ich je von wbec erwarten würde und vermutlich auch viel mehr als die meisten Nutzer benötigen.

Die Lösung zur Priorisierung von evcc ist in meinen Augen Ideal und würde super zu wbec passen:
Jeder Ladepunkt bekommt eine Priorität als Zahl. Gleiche Prio bedeutet, aufteilen der verfügbaren Energie. Unterschiedliche Prio bedeutet, der mit hoher Prio bekommt die fürs Laden eingestellten Werte, der niedrig Priorisierte den Rest. Damit kann man mE über 90% der Anwendungsfälle und mehr als 2 Ladepunkte abdecken.

Siehe: https://docs.evcc.io/docs/reference/configuration/loadpoints#priority

PS: Schade, dass die Heidelberg den SoC nicht verfügbar macht...

LG, Andre.

cbshopper commented

Hallo Steffen,
mit der neuen Funktion gibt es bei mit PlatFormIO folgende Meldung beim build:
src\pvAlgo.cpp:178:13: error: assignment of function 'uint8_t pv_getWbId()'
178 | pv_getWbId = val;
| ~~~~~~~~~~~^~~~~
*** [.pio\build\nodemcuv2\src\pvAlgo.cpp.o] Error 1

Kannst du mir helfen?

steff393 commented

@cbshopper
Sorry, kannst du's bitte jetzt nochmal probieren?

cbshopper commented

@steff393
Super - das Problem ist gelöst - habe ich mir auch schon selber so angepasst, aber es ist immer besser wenn du das machst!
Es gibt noch ein compiler problem:

.pio\libdeps\nodemcuv2\WebSockets\src\WebSocketsServer.cpp: In member function 'void WebSocketsServer::handleNewClients()':
.pio\libdeps\nodemcuv2\WebSockets\src\WebSocketsServer.cpp:658:86: error: 'class WiFiServer' has no member named 'accept'; did you mean '_accept'?
658 | WEBSOCKETS_NETWORK_CLASS * tcpClient = new WEBSOCKETS_NETWORK_CLASS(_server->accept());
| ^~~~~~
| _accept

steff393 commented

Der Fehler tritt bei mir leider nicht auf.

cbshopper commented

es liegt wohl am verwendeten Board (Einstellung in PlatformIO)
mir dieser Änderung funktioniert es bei mir:
WEBSOCKETS_NETWORK_CLASS * tcpClient = new WEBSOCKETS_NETWORK_CLASS(_server->available());
Vielen Dank für deine Unterstützung!