firestorm

Also eigentlich suche ich die Files von dem EVSE v3 Bricklet. Die habe ich nämlich im github nicht gefunden. Wenn ich den Link von dir zum Repo (https://github.com/Tinkerforge/evse-v3-bricklet/) benutze bekomme ich einen 404er Error. Kann es sein, dass das Repo vllt auf privat steht?

@borg ab wann sind denn die ganzen Files zu WARP 3 auf Github verfügbar? Fände das vor allem für ein Upgrade von WARP 2 zu 3 interessant, wenn die Bricklets etc im GitHub liegen, so dass man es sich schon mal alles ansehen kann

Deshalb hatte ich ja vorgeschlagen nicht die 248€ Platine zu implementieren sondern das Bauteil für knapp 30€, wo allerdings kein ISO15118 Stack mit dabei ist. Das wäre dann halt nur die Hardware für ISO15118 ohne jegliche Software, so dass man es zu einem späteren Zeitpunkt, wenn es denn mal einen ISO15118 Stack Open Source gibt in Betrieb nehmen kann. Das ist das Bauteil: -> Dafür bräuchtest du aber wiederum die ISO 15118. Plug&Charge läuft so weit ich das weiß nämlich genau darüber. Also entweder 30€ Bauteil und später vllt nutzen können oder 248€ Bauteil, dass man ggf direkt mit einigen Anpassungen nutzen könnte

Das hätte ich auch durchaus getan, wenn es da gute Möglichkeiten/Lösungen gäbe, da ich für solche Serveranwendungen den Pi als sehr geeignete Basis halte ergänzend zu "Edge Devices" mit ESP32, zum Wallbox steuern. Das Problem ist, dass es am Open Source Markt keine Lösungen gibt, die Lastmanagement wirklich gut können. Habe mich da ja umgesehen. Und die Lösungen auf dem "kommerziellen" Markt sind alle alles andere als Bezahlbar (ich fand z.B. den cFos Charging Manager ganz schick nur ist das Teil echt teuer, da ich pro Wallbox/Endpunkt da Lizenzen kaufen muss) Das fängt schon bei einem vernünftigen OCPP Server an. EVCC hat da ja nur eine sehr rudimentäre Unterstützung für so weit ich weiß. Die einzige wirkliche Lösung hier wäre SteVe. Nur ist da laut meinem letzten Stand auch kein Lastmanagement mit dabei (mal abgesehen davon, dass die UI davon alles andere als schön ist 😅). Bei der Administration leider halt auch nur Basic Funktionalitäten.

Ich hatte hier eher die Idee, dass man einen WARP Energy Manager auf Basis eines Raspberry Pis entwickelt, damit dort genug Power für einen OCPP Server und andere Sachen zur Verfügung stehen. Dann könnte man ja eure Software als Docker Container ausliefern und auf dem Gerät z.B. dann EVCC auch als Container laufen lassen oder einen OCPP Server, der dann mit dem WEM Container kommuniziert. Wie ist denn das Lastmanagement zwischen den WARP2 umgesetzt? Ich hätte (ohne einen Blick in die Software geworfen zu haben) gedacht, dass ich das auch per OCPP macht einfach weil es eine generische/standardisierte Schnittstelle ist, die auch alle anderen Hersteller nutzen.

Das wäre ja kein Problem habe da schon mal nach geguckt. Die Frage ist nur, wie man das dann mit dem Lastmanagement macht. Gibt es da irgendwelche gute Möglichkeiten eine fremde wallbox anzubinden? Ansonsten müsste ich ja ein komplett neues Lastmanagement anschaffen… Was die Limitierung des ESP32 angeht: Wäre es nicht evtl sinnvoll, dass man dann mal über eine Variante nachdenkt, die statt dem ESP32 mit einem Pi4/5 ausgestattet ist? Der ist ja mittlerweile wieder sehr gut lieferbar (zu vernünftigen Preisen) und bietet ja dann doch schon einiges mehr an Leistung als der ESP32.

Hallo zusammen, ist es denn geplant, dass der WARP Energy Manager einen OCPP Server anbietet, um auch Wallboxen von Drittherstellern anzubinden? Für mich wäre das ein sehr nützliches Feature, da ich zusätzlich zu meinen beiden privaten 22kw WARP2 Pro Chargern jetzt noch eine Wallbox von der Firma dazu bekomme (ich wollte da eigentlich gerne meine eigenen Boxen nehmen aber das geht von unserem Flottenverband, wohl eher nicht… die setzen da auf die Innogy eBox Professional bzw jetzt ja compleo), welche man mit OCPP 1.6 JSON anbinden kann. Relevant wäre eine Anbindung an den WARP Energy Manager für mich, da ich ein statisches Lastmanagement im Einsatz habe (sobald der Support da ist dann dynamisches), da ich ansonsten die Boxen nicht von meinem Netzbetreiber genehmigt bekomme (das Lastmanagement ist eine Auflage). Viele Grüße emobility_technische-beschreibung_ebox_professional_en_10.2019.pdf DE_Datenblatt_eBOX_i00021945_20230911.pdf

Die openwb pro hat halt dann den Vorteil, dass sie nicht mehr modifiziert werden muss. Das ist aus meiner Sicht schon ein Vorteil, wenn die nötige Hardware schon komplett eingebaut ist und man nur noch die Software nachrüsten muss. Machen ja viele Autohersteller ähnlich. Die verbauen die Extras schon/Hardware dafür und man kann es sich dann nachkaufen. Ist ja besser als dass man dann Teile in der Box austauschen muss oder eine komplett neue kaufen muss finde ich. Auch aus Gründen der Nachhaltigkeit

Was müsste man denn eigentlich rein technisch gesehen am WARP2 anpassen, um AC V2G/V2H (wobei V2H meiner Meinung nach die deutlich interessantere Variante ist) zu unterstützen? Sehe ich das richtig, dass man lediglich an dem EVSE 2 Bricklet Änderungen vornehmen müsste (vermutlich in erster Linie ISO 15118 support mit z.B. dem Bauteil hier https://www.codico.com/de/red-beet-e-2-0-evse-module)? Hab mir mal die Komponenten von der openwb Pro angeguckt die sind ja im großen und ganzen sehr ähnlich zum WARP2 bis auf dass die dort einen FI Typ B verbauen, was die Geschichte unnötig teuer macht…