ragsna hat geschrieben: ↑Di Mai 25, 2021 7:06 am
Ist ggf. etwas off-topic hier, aber ich möchte euch meine Box nicht vorenthalten.
Vielleicht ist es ja auch eine Inspiration für den einen oder anderen
OWBControlBox1.jpg
Anfangs wollte ich die Ausgänge der add-on Platine nutzen, aber ich habe es nun mittels eines ESP8266 via MQTT direkt realisiert, so dass keine Kabelverbindung zur openWB mehr notwendig ist.
Ich habe alle drei Modi plus standby und stopp via Taster laufen. Der rechte Taster dient nur dazu, dass Display wieder einzuschalten, da es sich nach 5 min ausschaltet. Das ganze ist wie gesagt via MQTT realisiert und klappt auf meinem Test-System einwandfrei. Die Hardware openWB Lieferung ist für heute angekündigt und ich werde es dann damit mal testen...
OWBControlBox2.jpg
Da die I/O des ESP8266 nicht ausreichend sind, habe ich noch eine Port-Erweiterung via MCP23017 eingebaut.
P = PV Leistung, A = Hausbatterie, G = Netz, V = EV. In der dritten Zeile werden dann noch Daten beim Laden des EV angezeigt, wie chargedsinceplugged, evremaining, evphases oder evsoc (derzeit 0% )
Tolle Lösung!
Kannst Du diese mal genauer vorstellen? -Vielleicht in einem extra Faden.
Danke - ich schau mal ob ich bei Gelegenheit dazu komme.
Ansonsten bei Bedarf für Details einfach PM.
Funktioniert nach kleineren SW Optimierungen tadellos hier.
ich bin seit gestern auch Betreiber eines Raspberry PI mit openWB. Die Standalone wird vom Hersteller derzeit wohl nicht einzeln angeboten, weshalb ich die Option Raspberry Pi nutzen musste.
Ich finde die Lösungen mit Taster, Display und LED echt genial.
Gibt es dazu auch fertige Lösungen, die irgendwo oder von einem Nutzer angeboten werden, und die man mit dem Raspberry PI betreiben kann? Also ein separater Kasten etc.
Eher nicht.
Das Aufwendige dürfte das individuelle Intergrieren in die oWB oder eine extra Leitung (Kabeldurchführung in der oWB) zu Deinem erwähnten "Kasten" sein. Da hat jede(r) andere Vorstellungen.
Der Beitrag ist zwar alt, beim Lesen kam mir aber eine Idee, die ich der Community nicht vorenthalten möchte.
JSAnyone hat geschrieben: ↑So Apr 18, 2021 8:41 am
ragsna hat geschrieben: ↑So Apr 18, 2021 8:38 am
Ggf. würde ja auch ohne WLAN reichen, einfach den ESP zwischen die LED Ausgänge sowie den Tastern gesetzt wird und die "Logik" umsetzt.
Ja das müsste auch gehen. Dann aber kein ESP8266, weil der verträgt nur 3.3V an den Eingängen, sondern ein Arduino (Nano). Den ESP8266 habe ich nur wegen Wlan gewählt. Mit einem Arduino müsste das aber theoretisch gehen...
Edit: Zwischen die Taster setzen macht keinen Sinn, weil dann eine Lademodusänderung übers Webinterface usw nicht erkannt werden würde. Möglich wäre, dass die LED-Ausgänge der openWB in den Arduino gehen und der Arduino dann entsprechend die 5 LEDs schaltet. Aus den 3 Ausgängen der openWB wird man aber vermutlich nicht auf alle 5 Lademodi schließen können schätze ich.
Doch, kann man!
Mit den 3 Ausgängen lassen sich 2³=8 Zustände kodieren. Wenn man zum dekodieren einen 74LS138 hernimmt, geht das sogar ganz ohne µProzessor und Programmierung.
Mit Blinken/Dauerleuchten ließen sich so alle 10 konfigurierbaren Modi darstellen.
In sw2 kann - auf vielfachen Wunsch - jeder Ladepunkt (LP) bzw. jedes Fahrzeug mit unterschiedlichem Lademodus genutzt werden, sofern auch Fahrzeuge mit unterschiedlichen Lade-Profilen konfiguriert sind.
Das ist dann ein Problem für ev. nachgerüstete Taster und LED's, denn die müssen fest für einen zuvor definierten LP/Fahrzeug gelten. Dafür noch einen extra Taster samt LED einzubauen ist m.E. nicht zielführend. Abgesehen von fehlenden freien GPIO wird das auch bei der Nutzung von >1 LP/Fahrzeug verwirrend.
Nur wenn man die LP/Fahrzeuge einheitlich konfiguriert (selber Lademodus an allen LP/Fahrzeug) oder nur 1 LP/Fahrzeug vorhanden ist , würden die Taster/LED Sinn machen. Damit kassiert man aber die neue, o.g. Hauptfunktion der unterschiedlichen Lademodi, die gut punktet.
Dahingehend könnten Taster&LED max. in Abhängigkeit der (sehr einschränkenden) Vorgaben des vorangegangenen Absatzes freigeschalten werden. Das Frust-Potential halte ich jedoch für hoch, weil schon ein einziges weiters Lade-Profil ausreichen würde, die komplette Taster&LED-Funktion zu deaktivieren.
Selbst das sicher in sw2 abzufangen, birgt zusätzliches Bug-Potential.
In SW2.x bestimmt das Auto, wie es geladen werden will, egal an welchem Ladepunkt man es ansteckt. Dieser Philosophie folgend müssten die Taster am Auto und nicht an der Wallbox angeschlossen werden.
Eher in die Philosophie würden die Taster zur Autoauswahl passen. Das geht aber auch schon per RFID.
openWB-series2, openWB-Buchse, E3/DC S10pro+19.5kWh, 30kWp Ost-Süd, Model 3 und Ion
auch wenn der Ursprungsbeitrag schon älter ist, meine OpenWB´s sind halt jetzt erst eingezogen.
Ich betreibe eine openWB series2 standard+ mit einer Open WB Pro, die Pro habe ich in eine alte Zapfsäule eingebaut, nun habe ich hier diese Lösung gefunden und frage mich ob diese Lösung auch mit meiner Pro praktikabel wäre da diese ja als Slave hinter der Standard+ hängt und entsrechend die Einstellungn dan auf dem Display der Standard+ angezeigt werden. Wobei ja vieles wohl über die Ladeprofile der Fahrzeuge in Version 2 eredigt werden kann, jedoch möchte ich in erster Linie immer PV laden aber bei Bedarf auf sofort umschlten können und halt den Ladevorgang mittels Led signalisieren.
Ich hoffe hier liest noch jemand und kann mir das beantworten.
)
