openWB Forum

Hallo,

da voraussichtlich nächstes Jahr die Anschaffung eines EVs ansteht fange ich an mich mit Wallboxen zu beschäftigen und bin auf openWB gestoßen (als studierter Informatiker und Physiker ein sehr reizvolles Produkt/Projekt), habe dazu aber noch einige Fragen, die ich nicht durch Recherche fier im Forum klären konnte.

Zunächst einmal ist es großartig, dass es ein System gibt, das offen ist an dem die Community mitwirken kann, aber dass es trotzdem fertig zu kaufen gibt, bei genau diesem Aspekt ergeben sich meine ersten Fragen:

1. Die nachträgliche Änderung der Leistung von 11kW auf 22kW (oder umgekehrt):
   "Die Einstellung der Ladeleistung kann nur durch uns erfolgen" und kostet 35€. Auch wenn ich das vermutlich nie brauche irritiert mich das stark, warum kann ich die Änderung nicht selber vornehmen? So wie ich das verstehe wird kein Widerstand getauscht sondern nur eine Einstellung in der Software vorgenommen. Es stellt sich mir auch die Frage, was ich noch nicht machen kann mit meinem Gerät, was mit quelloffener Software betrieben wird.
2. SSH-Zugang:
   Nach Stöbern im Forum bin ich auf einen Beitrag gestoßen, in dem es hieß es wird kein Standardpasswort mehr vergeben (sinnvoll) und das spezifische Passwort gibt es nur auf Anfrage mit Teilverfall (?) der Garantie, da wohl Benutzer Blödsinn gemacht haben und das auf Garantie behoben werden musste. Natürlich ein sehr nachvollziehbarer Schritt (auch wenn das Ändern des Passwortes, wenn man die SD-Karte hat, nicht weiter schwierig ist, hält aber manchen sicher ab), meine Fragen dazu wären:
   1. Kann man durch Fehlkonfiguration versehentlich* die Wallbox-Hardware und gar das Fahrzeug beschädigen?
   2. Wie genau wird die Garantie eingeschränkt?
   3. Ich habe gelesen, es gibt so keine fertigen Images zum Download (da die Hardware die Software mitfinanziert), gibt es als registrierter Käufer die Möglichkeit ein Image runterzuladen für den Fall, dass man die Wallbox-Software komplett zerschießt oder die Karte defekt ist? (ist mir bis jetzt bei meinen RasPi-Projekten zwar noch nie passiert, aber irgendwann ist immer das erste mal)
3. Die FI-Schalter-Option kostet 169€. Ein einzelner FI-Schalter kostet im Shop 239€. Handelt es sich um verschiedene FI-Schalter?
   Ich hätte den FI-Schalter bevorzugt in der Unterverteilung im Haus, damit das Kabel zur openWB auch durch einen FI-Schalter gesichert ist (in 15 Jahren hat jemand vergessen, dass da das Kabel liegt, will einen Baum pflanzen und ist dann mit dem Spaten im Kabel...). Ich konnte leider nirgendwo so etwas wie ein Blockschaltbild finden, indem die verbauten Komponenten genau dargestellt sind**, aber kann man den FI-Schalter einfach rausnehmen oder bei der Bestellung angeben "FI-Schalter bitte separat beilegen"?
4. Irgendwo stand, dass man die Box mit einem einfachen Handgriff öffnen kann. Sicher praktisch wenn man daran rumbastelt, aber wenn andere Personen die WallBox nutzen und man auch an Kindersicherheit denkt möchte ich auf keinen Fall eine Box, die man einfach öffnen kann, bitte nur mit Werkzeug. Muss man das irgendwo angeben oder sind fertig gekaufte immer nur mit Werkzeug zu öffnen?
5. Enphase-Support:
   Gibt es Erfahrungen mit Enphase-PV-Systemen? Das sind Modulwechselrichter, ein zentrales Gerät misst Erzeugung und Verbrauch bzw. Netzbezug. Das Gerät hat Wifi/Ethernet und eine JSON-API (vom Hersteller nur durch genau ein Beispiel dokumentiert [vermutlich weil dann eine Cloud-API eingeführt wurde, die zwar für Statisktik ok ist, aber nicht für Echtzeitregelung], aber von der Community sehr gut dokumentiert und es finden sich auch viele Projekte, die darauf zugreifen). Von Enphase habe ich die Auskunft, sie kennen keine Wallbox mit der aktuell PV-Überschuss-Laden untersützt wird, aber man arbeite mit Hochdruck daran und strebe herstellerunabhängige, offene Lösungen an (z.B. JSON und/oder Modbus/TCP).
6. Internet-Zugriff:
   Das Webinterface läuft wie ich das sehe einfach über Apache mit PHP. Spricht irgendwas dagegen das mit SSL abzusichern, mit einer ".htaccess-Datei" bzw. in der Apache-Konfiguration Benutzername/Passwort zu erzwingen, eine entsprechende Portweiterleitung im Router damit man auch von unterwegs darauf zugreifen kann? Wenn man dann noch eine Domain (dynamisches DNS) einrichtet kann man auch über letsencrypt kostenlos ein Zertifikat bekommen***, das in keinen Browser Probleme macht.

Ich hoffe, es ist ok das ich das alles so gesammelt hier unter Allgemein poste und nicht für jede Frage ein eigenes Thema eröffne.

Vielen Dank
Stefan


Anmerkungen:

• *) Vorsätzlich mit etwas Mühe z.B. irgendwo fehlerhafte Firmware einspielen um einen Defekt zu verursachen ist nicht gemeint.
• **) Ich vermute mal um den einfachen Nachbau zu erschweren, aber ist das mittlerweile nicht etwas kontraproduktiv?:
  Elektromobilität ist meiner Ansicht nach der Freaks-und-Bastler-Zeit (nicht negativ gemeint) entwachsen und ich vermute die meisten, die gerne eine WallBox selber bauen, haben es bereits getan, mal abgesehen davon das es mit der Förderung dann wohl ziemlich schlecht aussieht. Die Zielgruppe von openWB ist sicherlich technikaffin und weiß gerne auch vor dem Kauf, was sie sich anschaffen, da ist es vermutlich nicht unbedingt zielführend technische Details zurückzuhalten. Auch wenn ich das könnte, wäre es mir zu viel Arbeit das komplett selber zu bauen (mal abgesehen davon, dass es ein Elektriker absegnen müsste). Ich vermute da bin ich nicht der einzige. Und ein konkurrierendes Unternehmen kann einfach eine openWB kaufen und dann nachbauen.
• ***) Da für ACME (das Protokoll das letsencrypt für die Zertifikatserstellung nutzt) auf Port 80 ein HTTP-Server zugänglich sein muss, Bedarf es einer etwas spezielleren Konfiguration, damit intern das normale Web-Interface verfügbar ist, extern aber nicht und gleichzeitig ACME funktioniert, vermutlich ist es einfacher das Zertifikat über einen anderen Rechner zu holen und regelmäßig per Script auf die OpenWB zu übertragen. Falls jemand das hier liest und denkt das klingt gut: Ich würde auf keinen Fall das automatische letsencrypt-System auf der OpenWB installieren, dass die Konfiguration von Apache selber vornimmt! Das ist für öffentliche Webserver konzipiert und richtet mit großer Wahrscheinlichkeit mehr Schaden als Nutzen an!

Ich würde mit einigen Antworten anfangen:
Zu 1: für die KfW- Förderung ist es anfänglich besser, die 11 kW- Variante zu ordern und nach 12 Monaten auf 22 kW per Support zu upgraden. Dafür wird die SW erstmal auf 3x 16A begrenzt, später auf 3x 32A freigegeben. Vorausetzung ist natürlich die entspr. Auslegung des Einspeisekabels von min. 6 mm2, je nach Länge und Verlegeart.
Zu 2: SSH- Zugang könnte z. B. später nach Ablauf der Garantie mit Support geklärt werden.
Die künftige SW 2.0 wird als Image lieferbar/herunterladbar sein. Von akt. SW 1.9.2xx kann man sich auch selbst ein Image erstellen.
Zu 3: FI Typ B kann bei Bestellung durch zusätzl. Info auch beigelegt werden
Zu 4: ja, ist nur mit Werkzeug zu öffnen. Es gibt irgendwo ein Video hier im Forum.....
Zu 5: mit "Enphase" habe ich keine Erfahrung, ich lese meine Modul- WR von apSystems (ohne api) mit 2x SDM 120 (je 1p) ein. Geht auch über SDM 630 (3p) als Eigeninstallation oder PV- Kit aus dem Shop.
JSON ist auch machbar. "derNeueDet" kann da weiterhelfen.
Zu 6: .....keine Ahnung.....

Ich hoffe, es hilft schon etwas weiter.
VG

Zu 1. Der verbaute Laderegler ist eine Closed Source Lösung, der ebenfalls per Modbus angesprochen wird. Die maximale Leistung wird dort abgelegt. In der ooen Source ist ganz einfach nicht realisiert, wie dieser Wert zu ändern ist. Um die KfW Förderung zu erhalten muss eine solche, nicht User bedienbare Limitierung bestehen.

Zu 2a kenne ich zumindest ein Beispiel, bei dem ein Kunde seine Box durch die selbst initiierte Installation unter Buster beschädigt hat.
Weiteres Beispiel wäre z.B.ei e eigen implementierte 1p3p Umschaltung, die eine Zoe grillt...

Zu2 b kann nur openWB selbst etwas sagen.

Zu2 c Support anfunken und du bekommst eine neue SD Karte. Ich habs noch nicht gebraucht, aber so hab ich das hier schon gelesen. Vermute aber, dass es sich mit 2.0 ändert.

Zu5. JSON geht in den unterschiedlichen Modulen ganz gut, aber ob deine Anlage dann alles liefert was benötigt wird, muss man im Detail schauen. Am wichtigsten sind EVU Daten, da darauf der Überschuss berechnet wird. Also ein irgendwie gearteten Zähler am Hausübergabepunkt. Entweder den gibt es oder er muss verbaut werden. Stichwort EVU Kit.

Zu 6. Entweder die openWB Cloud nutzen oder besser ein VPN in dein Heimnetz einrichten oder du hängst dir einen entsprechend gesicherten Reverse Proxy vor die Box.
Ich brauch den Zugriff nur von zu Hause und zur Not hätte ich einen VPN Zugang in mein Netz.

VG
Det

Erstmal vielen Dank für die schnellen Antworten!

Das mit 11/22 kW hat sich geklärt. Das ich erstmal 11kW nehme war klar, nur die 35€ für eine Software-Änderung hatte mich irritiert.

Das mit der 1p3p Umschaltung des Zoe scheint ja ein allgemeines Problem zu sein, unabhängig von der Wallbox. Die Frage ist, wie doof muss man sich anstellen um die Hardware über SSH zu zerschießen. Meine Idee war die Karte direkt zu klonen, auf dem Klon kann ich den Zugang dann ja freischalten und ggf. Dinge anpassen. Wenn ich dann ein Problem habe einfach die Originalkarte zurück: Wenn Problem noch immer besteht => Garantiefall. Wenn ich natürlich die Hardware schnell zerschießen kann wäre das etwas doof.

VPN habe ich, wollte das aber nicht auf Smartphones einrichten (weil die dann auch Zugang zu allem anderen im Heimnetz hätten, wenn dann ein Handy verloren geht hat man direkt ein Datenschutzproblem oder ich müsste anfangen komplexe Firewall-Regeln für Wireguard zu erstellen, dass diese Clients nur Zugriff auf die openWB haben). Die Cloud ist natürlich eine Lösung, ich bin im Normalfall überhaupt kein Freund von Cloud-Lösungen, aber die dort verarbeiteten Daten (PV-Erzeugung/Verbrauch und Ladung) sind ja nicht sonderlich privat (meiner Meinung nach, andere sehen das vielleicht anders). Ich hatte hier gelesen, dass von direktem Zugriff aus dem Web dringend abgeraten wird, jedoch ohne Erklärung warum (ohne Passwort und ohne SSL ist es selbstverständlich, aber mit?).

Über JSON kann das "Enphase Envoy-S Metered" Wirk/Blind/Scheinleistung, sowie Spannung, Strom, Frequenz und Leistungsfaktor auf jeder Phase für Erzeugung und Netzbezug/einspeisung ausgeben, Daten werden sekündlich aktualisiert (das Gerät hat Drehstromanschluss und 6 induktive Messwandler, die einmal an die Leitung der PV-Anlage und einmal am Hausanschluss direkt hinterm Zähler "angeschlossen" werden (die einzelnen Phasen müssen nur je durch einen Wandler durchgeführt werden)). Um auf die Daten zugreifen zu können ist jedoch ein Passwort erforderlich, dass sich aus der Seriennummer des Gerätes errechnen lässt. Falls das nicht direkt zu konfigurieren geht, kann ich sicherlich ein entsprechendes Modul für openWB erstellen (dafür z.B. SSH Zugang). Hab mich nur gefragt ob das jemand anderes vielleicht schon gemacht hat (wen es interessiert, hier ein Beispiel wie die Daten aussehen). Einziger Haken ist, dass das Schnittstellen für herstellereigene Tools sind und sie nicht garantieren können, dass die nach einem Firmware-Upgrade noch so bestehen bleiben, sie arbeiten noch an einer Standard-Schnittstelle. Zumindest stört es sie nicht, dass die im herstellereigenem Forum von den Nutzern dokumentiert werden.

Viele Grüße
Stefan

Wenn du eh Raspis am Laufen hast, kannst du dir die Software ja mal auf einen installieren und mit den Modulen spielen. Basic Auth sollte sich on der URL der JSON Module eingeben lassen. Die Module sind nur für die Grunddaten ausgelegt, aber da sich JQ im Hintergrund befindet, kannst du auch aus z.B. Einzelleistung auch die benötigte Gesamtleistung rechnen.

Entwickeln würde ich auch eher auf einen Raspi. Dann PR ins Git und über die Nightly in die Box. Damit kann man den SSH Zugriff auch umgehen wenn man will.

VG
Det

stefan_o hat geschrieben: ↑Mi Okt 13, 2021 12:07 am Das mit der 1p3p Umschaltung des Zoe scheint ja ein allgemeines Problem zu sein, unabhängig von der Wallbox. Die Frage ist, wie doof muss man sich anstellen um die Hardware über SSH zu zerschießen.

Das hat was damit zu tun, dass die Software letzten Endes die 22kW schaltet. Problematisch bei der Zoe war wohl, dass sie - ohne das Ladekabel physisch zu trennen - mit einfach dazu geschalteten Phasen so schlecht klarkam, dass es den verbauten Chamäleon-Lader gehimmelt hat.

stefan_o hat geschrieben: ↑Mi Okt 13, 2021 12:07 am VPN habe ich, wollte das aber nicht auf Smartphones einrichten (weil die dann auch Zugang zu allem anderen im Heimnetz hätten, wenn dann ein Handy verloren geht hat man direkt ein Datenschutzproblem

Bei mir hat jedes Handy einen eigenen VPN-Zugang, den ich in der Fritzbox dementsprechend auch löschen oder das Passwort ändern kann. Das mit der Warnung vor dem Web-Zugriff gilt meiner Meinung nach hauptsächlich für einen MQTT- Broker im Internet.

stefan_o hat geschrieben: ↑Mi Okt 13, 2021 12:07 am Über JSON kann das "Enphase Envoy-S Metered" Wirk/Blind/Scheinleistung, sowie Spannung, Strom, Frequenz und Leistungsfaktor auf jeder Phase für Erzeugung und Netzbezug/einspeisung ausgeben, Daten werden sekündlich aktualisiert

Statt ein eigenes Modul zu bauen, kannst Du ja erst mal mit dem generischen http-Modul probieren. Die Software kannst Du Dir bei github herunterladen und mal probieren an die Daten des Wechselrichters zu kommen:

https://github.com/snaptec/openWB

Auch ohne Wallbox kann man damit schon ein bisschen was anfangen. smarthome2.0 ist das Stichwort. Mit Shelly und Ladeziegel bekommt man so PV-Überschussladen für Arme.

zu 1) sei auch noch anzumerken dass dies auch den Förderrichtlinien der KfW geschuldet ist. Diese schreiben vor dass die Limitierung 'nicht Laienbedienbar' auszuführen ist.
Kann man über Hardware lösen, im Sinne der KfW kann man einem Laien wohl nicht mal die unfallfreie Benutzung eines Schraubenziehers zumuten, oder wie hier eben über den Hersteller & Fernwartung. Die 35€ sind am Ende nichts weiter als die Aufwandspauschale um die Begrenzung per Fernwartung zu entfernen.

zu 6) nicht machen. Das System ist nicht darauf ausgelegt, verfügt womöglich nicht über die stets tagesaktuellsten Sicherheitsupdates und stellt direkt im Internet erreichbar ein sehr leichtes Angriffsziel dar. Nicht für den Hacker der es speziell auf Dich abgesehen hat, sondern für all diejenigen die auf Verdacht alles was erreichbar ist systematisch nach bekannten Sicherheitslücken abgrasen und automatisiert angreifen. Da hilft dann leider auch ein Reverseproxy kaum - sofern man nicht pre-auth macht. Aber dann hat man das gleiche Problem mit dem Proxy zu lösen.
Einmal auf einem System kann man sich von dort weiter ins eigene Netzwerk verbreiten und die nächsten Komponenten automatisiert angreifen und auch gleich als Quelle für weitere Angriffe, DDoS & co dienen.
Sicherheitslücken werden allerspätestens mit Verfügbarkeit des Patches aktiv ausgenutzt, über den Patch lässt sich häufig ein Angriffsvektor rekonstruieren und ausnutzen.

Für den Zugang von unterwegs nutze ich die openWB Cloud um mal zu schauen was gerade so los ist, ob die Sonne scheint und das Auto läd. Für meinen/unseren Anwendungsfall muss ich in 99% der Fälle nichts an der Box konfigurieren/starten/anpassen sondern die Box regelt das alles für mich so wie ich das will. Scheint die Sonne? Auto wird geladen. Scheint die Sonne nicht? Nachts wird auf den vorgegebenen SoC geladen.

Gero hat geschrieben: ↑Mi Okt 13, 2021 9:33 am Statt ein eigenes Modul zu bauen, kannst Du ja erst mal mit dem generischen http-Modul probieren. Die Software kannst Du Dir bei github herunterladen und mal probieren an die Daten des Wechselrichters zu kommen:

https://github.com/snaptec/openWB

Auch ohne Wallbox kann man damit schon ein bisschen was anfangen. smarthome2.0 ist das Stichwort. Mit Shelly und Ladeziegel bekommt man so PV-Überschussladen für Arme.

Werde ich machen, die PV Anlage ist zwar auch noch nicht auf dem Dach, aber im Moment sieht es so aus, als ob das deutlich vor der Ankunft einer OpenWB passiert. Hab schonmal kurz in den Code geschaut, das scheint ja sehr simpel zu sein ein Modul zu schreiben, nur auslesen und die Werte entsprechend in die Ramdisk schreiben. Einzig die Konfiguration ist mir noch schleierhaft, geht das alles über Umgebungsvariablen die manuell gesetzt werden müssen? Für mich ist das ok, meiner Ansicht nach aber nicht sehr benutzerfreundlich.

Nachtrag: Habe den Code jetzt auf meinem lokalen Rechner, ganz so einfach ist es nicht, es ist nicht so modular wie es zuerst aussah, die Module haben noch Code in anderen Dateien (z.B. der modulconfigpv.php), es ist also nicht nur Dateien ergänzen, sondern auch verändern/anpassen.
Was mir als Vorlage noch fehlt: Gibt es ein Modul für EVU und WR das man als Beispiel nehmen kann? Bei dem Enphase ist das eine Abfrage, das wäre nicht sinnvoll das aufzuteilen.

mrinas hat geschrieben: ↑Mi Okt 13, 2021 7:06 pm zu 1) sei auch noch anzumerken dass dies auch den Förderrichtlinien der KfW geschuldet ist. Diese schreiben vor dass die Limitierung 'nicht Laienbedienbar' auszuführen ist.
Kann man über Hardware lösen, im Sinne der KfW kann man einem Laien wohl nicht mal die unfallfreie Benutzung eines Schraubenziehers zumuten, oder wie hier eben über den Hersteller & Fernwartung. Die 35€ sind am Ende nichts weiter als die Aufwandspauschale um die Begrenzung per Fernwartung zu entfernen.

Ja, schon klar, falls dann doch jemand meint Befehle in der Kommandozeile sind auch von Laien durchführbar (weil z.B. eine Schritt-für-Schritt-Anleitung irgendwo zu finden ist) und deshalb die Förderung wegfällt wäre sehr doof.

mrinas hat geschrieben: ↑Mi Okt 13, 2021 7:06 pm zu 6) nicht machen. Das System ist nicht darauf ausgelegt, verfügt womöglich nicht über die stets tagesaktuellsten Sicherheitsupdates und stellt direkt im Internet erreichbar ein sehr leichtes Angriffsziel dar. Nicht für den Hacker der es speziell auf Dich abgesehen hat, sondern für all diejenigen die auf Verdacht alles was erreichbar ist systematisch nach bekannten Sicherheitslücken abgrasen und automatisiert angreifen. Da hilft dann leider auch ein Reverseproxy kaum - sofern man nicht pre-auth macht. Aber dann hat man das gleiche Problem mit dem Proxy zu lösen.
Einmal auf einem System kann man sich von dort weiter ins eigene Netzwerk verbreiten und die nächsten Komponenten automatisiert angreifen und auch gleich als Quelle für weitere Angriffe, DDoS & co dienen.
Sicherheitslücken werden allerspätestens mit Verfügbarkeit des Patches aktiv ausgenutzt, über den Patch lässt sich häufig ein Angriffsvektor rekonstruieren und ausnutzen.

Für den Zugang von unterwegs nutze ich die openWB Cloud um mal zu schauen was gerade so los ist, ob die Sonne scheint und das Auto läd. Für meinen/unseren Anwendungsfall muss ich in 99% der Fälle nichts an der Box konfigurieren/starten/anpassen sondern die Box regelt das alles für mich so wie ich das will. Scheint die Sonne? Auto wird geladen. Scheint die Sonne nicht? Nachts wird auf den vorgegebenen SoC geladen.

Vermutlich brauche ich das auch eher selten, wenn man gerade mit Fahrrad/öffentlichen Verkehrsmitteln unterwegs ist und dann ungeplant doch noch mit dem Auto weg muss und es ist bewölkt und der Akku ziemlich leer, dann kann man schnell umschalten auf Sofort Laden noch bevor man zuhause ist. So ein Fall der alle 1 bis 2 Jahre mal vorkommt und bei dem man sich dann ärgert wenn man das nicht kann.

Sollte die OpenWB tatsächlich keine regelmäßigen Updates bekommen (kann man über das Interface ein normales Systemupdate anstoßen, da wird doch Raspbian bzw. jetzt Raspberry Pi OS drauf laufen?) wäre ein öffentlicher Webserver natürlich wirklich schlecht, aber die Cloud ist dafür ja völlig ausreichend.

Zumindest in der aktuellen Version 1.9 liegt unter der openWB Software ein älteres Stretch. Einzelne Software wurde je nach Erfordernissen aktualisiert, aber nicht das komplette System. Es gibt keine Möglichkeit und damit auch keinen Support bei selbstständig aktualisierter Umgebung.

VG
Det

stefan_o hat geschrieben: ↑Mi Okt 13, 2021 9:34 pm Sollte die OpenWB tatsächlich keine regelmäßigen Updates bekommen (kann man über das Interface ein normales Systemupdate anstoßen, da wird doch Raspbian bzw. jetzt Raspberry Pi OS drauf laufen?) wäre ein öffentlicher Webserver natürlich wirklich schlecht, aber die Cloud ist dafür ja völlig ausreichend.

Mit der manuellen Aktualisierung werden einzelne Pakete im Betriebssystem mit aktualisiert, das passiert schon. Allerdings genügt das sicher nicht um solch ein System halbwegs sicher im Internet betreiben zu können, hier gibt es m.E. genau eine einzige brauchbare Lösung: 100% automatische Aktualisierung unmittelbar nach Verfügbarkeit eines Sicherheitsupdates.
Ja, keine Frage, das kommt mit erhöhtem Aufwand hinsichtlich Betrieb, Test und Support einher da nie auszuschließen ist dass ein Update zu unerwartetem Verhalten führt.