I saw the tricks of multiplying by 3 the L1 power phasis, but when you have then a charge in mono calculation is wrong.
There is this guy that posted a really interesting solution involving wiring differently the L1 L2 L3 through the core, and no code change on EVSE.
https://www.stuartgraves.info/measuring-3-phase-current-in-openevse/
I haven’t saw any discussion about it yet, but if there’s no cons shouldn’t we do this on all default 3phazed openevse from now?
I think there’s one con that’s described in the guy’s blog post: you can’t have overcurrent limiting working properly in all cases with this method. For that you will always need to measure all three phases separately I think.
I am not sure what the goal should be for the EVSE in connection with current measuring.
If it is only for the calculation of power used/actual current, I am not sure if this should be implemented at all due to the amount of work to be done if you want to catch all different configurations and get to a reasonable accurate measurement for all those configurations, a simpler solution would be to install a kwh meter. Maybe an indication only would be enough based on the current pilot from the EVSE itself.
From a safety aspect, I do not know which faults should be picked up by the coil.
In the EU you will need to have a circuit breaker(CB) installed which will take care of your overcurrent protection, i guess this is similar in the rest of the world. As far as I know it is even mandatory in most of the EU to get a CB + Ground fault current detection(GFCI) installed specific feeding only the charger. So if I am not mistaken there is no requirement for the current coil in respect for safety.
My 2 cents would be to make decision on how to go forward with the current sensing and if you want to continue to offer a kwh meter included in the OpenEVSE.
If you would like to offer a feature like that, I would actually opt for a dedicated optional board that has 1/3 current sensors on it with a dedicated IC and/or microcontroller which interfaces via i2c to OpenEVSE or Wifi board.
This is important for features like current shaper and divert + correct display on UI
For now the shaper is wrong with triphase
By the way, I think we can solve the over current protection on fw side for triphase fw builds .
It just mention it doesn’t work as it with original fw.
-D THREEPHASE build should then forget factoring by 3 the measured amp, and then calculate over current protection correctly.
But this won’t solve the portable charger switching from mono to tri
I like the idea of an I2C ADC extension with current sensing X3 , I’d add then the voltage divider needed too to get voltage data without Mqtt
Hi, first many thanks for implementing the 1 vs 3 phase toggle.
Ok something on the overcurrent protection in the openEVSE itself first.
Is this subject to any standard for car-chargers? Or is it in any standard written that an electronic device will need to limit current draw in a fault situation?
Basically the overcurrent protection which is included is the mismatch between pilot and actual current drawn by the car. Electrical overcurrent is the current what the system is not laid out for.
So the cabling, contactor and car are laid out for a certain current, 16A, 32A, 64A. This should then be protected by a Circuit breaker corresponding to that current.
So in an overcurrent situation where the fault is in the car or in the cable from the charger to the car, this will be picked up by openEVSE.
Again for 1 phase systems in the US and other non-EU places, it might be that you have multiple consumers behind a circuit breaker and the overcurrent protection might be mandatory or of more value that it is implemented in the OpenEVSE (however the cable from the circuit breaker to the charger is not protected here by the OpenEVSE).
In a three phase system, europe based, it is mandatory to have your dedicated circuitbreaker including GFCI installed. So OpenEVSE will not add anything extra with the implemented overcurrent protection as the system parts should be able to handle the overcurrent until the circuitbreaker trips.
The next topic, Solar divert
For this to work you will need to know if you are connected with 1 or 3 phase, hence the toggle, but in best case this would be done automatically so at least 2 phases should be detectable. Basically with some additional wiring throught the coil and some firmware changes this could be managed, however it will complicate the firmware but most important you are interfering with the overcurrent protection which might be a safety feature in the 1 phase countries.
Best would be to have an additional coil implemented on phase 2 to an IO to the ESP, as the solar divert is already in the ESP32 this will then not impact the firmware of the OpenEVSE and will be the most cheap and straight forward solution in my opinion.
Oh my I am really going here now. sorry for the long read.
The kwh meter:
I would not have it at all in the OpenEVSE, as it is a carcharger not a kwh meter, it will need a lot of work and attention, and yes a standalone board would be great but is it worth the time and money to design a kwh-meter. I have done a bit of work to see if I could make one, but the dedicated IC’s alone are already pretty expensive (for example ADE7758).
In my opinion it would be best to focus on interfacing with existing kwh meters, and this would then need to be implemented in the ESP32, which will receive the kwh’s from the kwh meter somehow (modbus, MQTT, etc) and passes it through to the OpenEVSE. Just to have the philosophy that the OpenEVSE is for the charger and safety stuff, not for all the extra’s.
Well this has been a very long piece, and please do not hesitate to just ignore all things here 
I don’t fully agree with this, because this mandate only concerns the fixed system parts. If one were to design a socketed EVSE that can handle 32A, but someone plugs in a 16A cable, then the car and EVSE themselves are responsible for limiting the maximum current based on the PP resistor value.
I do fully agree with this one!