PLC communication support

[landswellsong]

I tried raising this question on the fora, but the issues seem to be the place of more active communication, please correct me if this isn't the right place to do it.

We're working on an open-source ISO 15118 / DIN 70121 component stack and we'd love to reuse as much OpenEVSE as possible and contribute to the project. We're currently tinkering on our own, but if we were to ever push something back, I'd love to hear some guidance on the architectural decisions.

As it stands now, we're developing a board that has a QCA7000/7005 modem on it and can run all the necessary CCS stack. As per the docs, the station is supposed to set PWM to 5% when the car is connected and try to establish a PLC connection, falling back to J1772 if unsuccessful, so that's one modification of OpenEVSE here, a command to make it set PWM to a fixed 5% and a command to revert to J1772 logic PWM. From there for the AC case, the car is still supposed to do the resistor dance, so OpenEVSE will work as intended except for the extra communication channels between the car and the station.

And here's our question, is it wiser to connect our board to the WiFi or to OpenEVSE itself?

OpenEVSE:
+ Allows for more streamlined RAPI logic, i.e. WiFi can say "limit current to 10A" via RAPI regardless of whether PLC or J1772 is used and OpenEVSE itself will either change PWM or instruct our companion board to do the digital thing.
+ Allows us to build a DC board that will use existing RAPI (with maybe some additions) so that we can readily plug it into WiFI and it will just work with us only designing board for both PLC and DC control in the DC case.
- Will need to add new RAPI commands for extended things like battery SOC.
- Will need to use RAPI if PLC needs something done over the network (i.e. when we get to plug and charge).
- There's probably not a lot of room for code on the OpenEVSE board left?
- Not sure if OpenEVSE has a spare UART to communicate with our board. If not, will have to share traffic on I²C or something like that.

WiFi:
+ Minimal changes to OpenEVSE hardware itself.
+ No awkward "ask X on the Internet via RAPI" communcation.
= It may be technically possible to wire the PLC modem to the WiFi board directly with SPI and just add code to the WiFi board.
- Pushes a lot of extra logic over to WiFi, e.g. WiFi handles the switch between PLC and J1772 communication, which doesn't sound well architecture wise.
- We won't be able to combine the PLC board and the DC unit control into one board.
- WiFi will essentially have 2 RAPIs because a lot of extra communication will need to happen.

I'd be glad to hear feedback on those.

[jeremypoulter]

IMHO I would connect to the WiFi module, much more space for code changes and easier to update. A lot of the resent changes have also been made with a view of supporting multiple OpenEVSE and/or other EVSE modules, although by no means this is complete. You also have a much wider range of connection options on the ESP32.

[landswellsong]

@jeremypoulter thanks. I just realized that with Tesla API in the WiFi module, we can reuse some bits, at least in the "also display SoC / range on the LCD" and "I want this to be charged only to X%" department. The only thing that bugs me, if the EVSE internal logic commands a change of permitted amps (say it's getting hot or some other condition), will the WiFi module be able to query this value, is there RAPI for that?

[jeremypoulter]

We are intending to move some of that logic to the WiFi module so the scaling back the current will be done using the EVSE manager. This is mostly because the OpenEVSE has the temperature sensor on. But that aside the WiFi module does poll the EVSE for state changes, like current/pilot.

[jeremypoulter]

And yeah the Tesla work in #198 does go some way to abstract the vehicle SoC. It does not (yet) include limiting based on SoC but that is on the roadmap.

[landswellsong]

@jeremypoulter question, why does one need that at all, even though the car's BMS is already supposed to limit the current based on SoC? Is it to be overly cautious or to implement things like "charge to 80% only" in a CC-CV manner?

[jeremypoulter]

Yeah I think this is for those that like to be a bit cautious about the battery because the vehicle is not used that often and/or may want to do things like in eco (PV divert) mode charge at full power to add 50miles to the range then continue on normal eco mode

[landswellsong]

@jeremypoulter how bad is the idea to implement support within the WiFi codebase then? What we need is basically a SPI connection to the modem and a bunch of libs (some kind of TLS which WiFi already has, lwip, openvg and my tiny lib for the modem support).

[jeremypoulter]

Sure that is certainly possible, we do already support both WiFi and Ethernet so adding an additional comms method shouldn't be that bad as long as it brings up a lwip interface, everything else should just work.

If you don't actually need WiFi then maybe you could consider a different MCU and run the stack on that, I don't think that will be a huge effort, not much tying the stack to ESP32, and Mongoose, the networking stack, has been ported to many MCUs, but maybe as a second stage?

[landswellsong]

I want to piggyback on the WiFi because you already to EnonCMS / MQTT / OCPP in future and also for the Plug and Charge stuff we'll need an internet connection anyway so if we base off the OpenEVSE we'd still need to encapsulate Internet traffic between that new MCU and the WiFi module anyway.

My only concern is whether or not this will eat too much of program memory and there's a few concerns over flash etc but I'll research this in due time.

[jeremypoulter]

I was more referring to running the WiFi firmware on a different MCU, but as I said that could be a later step. I believe there is plenty of headroom on the ESP32 (WiFi), not so much on the ATMEGA328 (OpenEVSE module)