CurtRod hat geschrieben:Nachdem ja fast zur gleichen Zeit das Projekt openWB hier im Forum veröffentlicht wurde, würde ich gerne kurz erklären, was momentan meine Ziele von SimpleEVSE-WiFi sind, und was nicht.
Ziele:
Die Ziele des Projekts bewegen sich mehr innerhalb der Wallbox.
- Anbindung der Wallbox ans WLAN
- Freischaltung über App/Webinterface und RFID-Tags
- Konfiguration des Ladestroms, ggf. Ladezeit, vorgegebene Energiemenge in kWh
- Auslesen des Zählers der Wallbox
- Log (ggf. Auswertung) der Ladevorgänge
- Steuerung der SimpleEVSE WB über offene Schnittstellen (MQTT/API)
Nicht-Ziele:
- "intelligentes" Lademanagement
- Energiemanager Software
- Auslesen von PV-Ladung und Anpassung des Ladestroms durch den ESP
Der ESP8266 bietet für sehr wenig Geld einiges an Rechenleistung. Für die Ansteuerung der SimpleEVSE WB via Modbus, WebAPI und die oben genannten Dinge reicht der mehr als aus. Ich habe mich bewusst gegen einen Raspi entschieden, da ich für diese Aufgaben kein vollwertiges Linux-System brauche und der für die oben genannten Zwecke krasser overkill wäre.
100% Zustimmung. Bei openWB stehen Deine "Nicht-Ziele" im Vordergrund, weshalb dort der RPi prädestiniert ist.
nochmal zum Stromverbrauch und Mitnutzung der Stromversorgung der "EVSE WB":
Der AC/DC der "EVSE WB" liefert laut Aufdruck 12V 85mA. Damit wird das Schützansteuerrelais direkt mit 12V gespeist. Die EVSE selbst läuft mit 5V. Wenn ich die Platine begutachte, sieht mir das nach einem Linearregler für die 5V-EVSE-Versorgung aus, weil die kleine PIC-MCU vermutlich nur ganz wenig Strom braucht.
Für den ESP wäre es daher besser, einen 12V to 3,3V stepdown zu verwenden und gar nicht über 5V zu gehen. Kann man den Wemos Mini D1 direkt mit 3,3V speisen oder braucht der zwingend die 5V? M.E. sind die nur, um ihn an einem 5V-USB-Netzteil betreiben zu können.
CurtRod hat geschrieben:
Das Problem beim ESP sind die Stromspitzen beim Einschalten und wenn im WLAN gesendet wird. Ohne ausreichend dimensioniertem Elko schafft es das Netzteil der EVSE nicht, den ESP überhaupt zu starten.
Der kommt extra rein - Safety first.
CurtRod hat geschrieben:
Am meisten kann man beim ESP über Software rausholen. Wenn man das im Coding vernachlässigt, ist es ziemlich egal und beide brauchen relativ viel Strom für einen µC.
Kannst Du da mal forschen, was wir da nutzen könnten?
CurtRod hat geschrieben:
Modbus ist ja bereits implementiert, um die EVSE WB damit auszulesen. Im anderen Thread schreibt ihr, dass es die Modbus Firmware nur für die EVSE DIN gibt!? Das kann ich nicht bestätigen. Auch für die EVSE WB gibt es eine Firmware, die Modbus kann!
Da hast Du mich missverstanden. Natürlich kann die EVSE das Modbus-Protokoll sprechen, aber bei der "EVSE WB" nur direkt über den UART. Die neue "EVSE DIN" hat jedoch die zugehörige Hardware onboard, um Modbus auch über lange 2-Drahtleitungen zu ermöglichen.
Bsp.:
Bei openWB haben wir sowohl die SDM-Zähler als auch die Beta-"EVSE DIN"
ZUSAMMEN an
EINEM Modbuskabel (A u. B) hängen. Der RPi kann diesen entweder über einen USB/RS485-Adapter oder auch über einen externen LAN/RS485-Konverter steuern.
CurtRod hat geschrieben:
Aber zurück zum Thema: Auch Zähler über Modbus auszulesen ist bereits geplant. Wie gesagt, die hälfte dafür ist eh schon implementiert und der ESP langweilt sich mit den aktuellen Aufgaben die er hat, eh die meiste Zeit!
D.h. der ESP liest irgendwann mal Modbus-Zähler aus und bringt die Daten auf's webinterface (so wie jetzt S0-Zähler). Die Ansteuerung der "EVSE WB" läuft weiter über den UART und nutzt dort auch die Modbusregister der "EVSE WB".
VG U x I
ps
@all: Bitte untescheidet die EVSE-Versionen korrekt. Aktuell gibt es:
1. "simple EVSE" - abgespeckte Variante (würde ich nicht empfehlen, da manche EV das -12V-Signal brauchen)
2. "simple EVSE WB" => nenne ich immer "EVSE WB" wegen besserer Unterscheidung
3. demnächst "EVSE DIN" im 2-TE-Hutschienengehäuse mit oder ohne Modbushardwarebestückung (muss bei Bestellung angegeben werden)