Closed taliesin closed 2 months ago
Hi, I think this project could be almost compatible with SmartEVSE v3, which is ESP32 based...
Control of phase switching is possible via Lua script, with digital output you can control relay witch will be driving HV Contactor on L2 & L3. I don't know what should be the input to control the phase switching (MQTT, digital/analog input, Modbus)?
Yes, HW seems compatible. From my point of view the phase switching must be integrated into the charging state machine in evse.c. I didn't checkout the LUA possibilities in that context, but looking at the code, it doesn't seem to offer a chance to change states from the script. The phases are switched autonomously depending on the allowable power provided by the solar panels, the amount of available power may be sent to the EVSE via MQTT, Modbus, whatever.
Maybe I start off with a few pull requests to improve the code here an there (currently I've seen a few typos) and we can figure out how well I behave concerning these fixes before I take on larger changes, if necessary ;-)
Do you have any experience running esp32-evse on smartevse v3 HW? I would like to give it a try...
I haven't used it yet on my SmartEVSE V3, as I only have one and it's currently running the original SW. I'd like to have some features available before I start using esp32-evse along with evcc.io
I looked a bit at the SmartEVSE v3 schematic, so far I noticed a couple of differences. The CPOFF pin, I don't know exactly when it is necessary to set CP floating. The temperature sensor is not 1wire but analog MCP9700A, it could be implemented. LCD display is not necessary, it would be possible to implement Lua api for displaying some values.
The CPOFF pin is only used in conjunction with the ISO15118 modem feature, i.e. if override_pwm is set to 0. In any case I would create an 'extension' branch for SmartEVSE 3, that sits on top of eps32-evse and reduce stuff there if it gets incorporated into esp32-evse. I think it would be wrong to bloat this very device independent project with HW specifics.
What do you think about the modbus master (bridge) feature? From my point of view this would be a valid extension.
I'm glad that you also see it as not bloat this firmware with device dependent stuff :-)
That's why I would like to ask you to think about what Lua API need to be extend, to be able to implement this functionality. Would you need to read the Modbus registers in Lua and set the charging performance according to them?
My inspiration is the Tasmota project, where a lot of functionality can be implemented with a script (originally I also used Berry, but Lua came to me more tuned)
Looking at the modbus bridge feature, there is at least the necessity to allow a serial line to be configured as modbus master, currently it may only act as slave (as far as I could see).
The actual bridge could be implemented in Lua then, reading modbus TCP (or mqtt) requests and creating modbus RTU request from them. However there are existing libraries that totally manage these kinds of application and could be pulled in as git submodule (like emodbus, which is written in C++, but that wouldn't hinder it's use).
For the 1/3phase switching I'm still trying to fully understand the SmartEVSE implementation (the codebase is quite disgusting :-) ). As for my current understanding, the switching from 3ph to 1ph and the other way round, works like:
Thinking about it again, it might just work with Lua using set_enable() to switch to C1 when in C2, then wait for the contactor to turn off and re-enable after switching the 2nd contactor on or off an auxiliary pin.
That's exactly what I meant :)
Hi,
I'm using the SmartEVSE V3 hardware, which allows switching from 1ph to 3ph and back. Especially for solar only charging, this would be helpful, allowing steering the vehicle consumption from 6Ax230V = 1380W to 16Ax230A = 3680W in single phase mode and 3x6Ax230V = 4140W to 3x16Ax230V = 11040W in 3ph-mode.
Typically the current is turned off before switching modes as some vehicle don't like phase switching while charging.
SmartEVSE software seems quite unreliable (and you wouldn't wanna run any quality metric on it).
Do you think, that would be a valuable addition? I'm willing to work on that, but probably need at least a few hints on where to start.