SmartEVSE / SmartEVSE-3

Smart Electric Vehicle Charging Station (EVSE)
MIT License
112 stars 84 forks source link

OCPP support? #24

Open fluppie opened 2 years ago

fluppie commented 2 years ago

Seems like libraries are being developed to add OCPP support to for example OpenEVSE https://github.com/matth-x/ArduinoOcpp https://github.com/OpenEVSE/ESP32_WiFi_V4.x/blob/master/src/ocpp.cpp

Could SmartEVSE v3 also be OCPP compatible in the future?

dries007 commented 2 years ago

I would also appreciate this capability. I now own a SmartEVSE v2 and would upgrade to a v3 if this becomes an option. Would merge requests be welcome for this?

mstegen commented 2 years ago

Yes merge requests are welcome, once it's clear it's possible to include this into the SmartEVSE v3 software.

dries007 commented 2 years ago

Is it possible to develop on a generic ESP32 WROOM board? I'd prefer that over having to buy a second SmartEVSE before I know it'll be something I can use :)

mstegen commented 2 years ago

Yes that will work (just tried), although i had to change the upload speed to 921600 bps. v3 does not have a CLI option like v2 had, so it's not possible to configure it without display + buttons.

But of course you can force the Wifi-portal by setting WIFImode to 2. That should start the portal. The portal password should be listed on the serial debug output.

You can also send me an e-mail and i'll lend you a light used SmartEVSE v3 to dev on. ;-)

dries007 commented 2 years ago

I think the only thing I can't DIY from the schematic is the LCD, but a borrowed unit would help a lot. I'll email the address on the website.

fluppie commented 2 years ago

Nice :-), OCPP could open the way to have automatic invoicing of home charging by parties like Last Mile Solutions.

wbitholedotbe commented 2 years ago

I don't think it's possible without an internal clock

dries007 commented 2 years ago

I've used the network time sync as a clock source so far.

A small status update from me:

I'm having some problems with the way OCPP 1.x makes assumptions about the relationship between components (controller, server). It basically assumes the evse is dumb and all settings and configuration must be done via OCPP, meaning I'd have to strip out significant parts of the current firmware or make them work together somehow. OCPP 2.x seems much better in this regard, since it acknowledges the existence of local load balancing for example. The problem is that I can't find a working (embedded suiteable) library for 2.x, and even most server projects are still on 1.x.

For now I'm focused on getting to know the standards and the existing firmware a bit more before I push stuff to git.

wbitholedotbe commented 2 years ago

You should focus on ocpp1.6 as v2 is far to complicated and not widely used yet. Not to mention not every backend supports v2

mstegen commented 2 years ago

Not sure if it's of any use, but EVerest has implemented the OCPP-J 1.6 protocol in a module.

It's available here: https://github.com/EVerest/everest-core/tree/main/modules/OCPP