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!
This is a very interesting topic.
Reading this and the linked post multiple times, it seems to me that Kips recent threephase mod to the firmware and the trick of passing the cables through the CT in reverse directions should work.
PV divert calculations would work and over current would also work.
Am I missing something ?
I haven’t tested , I have no three phase here, but it should work yes.
I’d like to know how it goes 
edit: I guess in this case, there won’t need to use the is_threephase switch on the wifi fw then , as there will be no need of factoring by 3 anymore.
I think the evse fw stilll need to be tweaked to let the over current protection works well. As with rewiring the coil it will mesure the total current on all 3 phase.
But still doesn’t solve the switching between mono / tri then.
I’m agree with @Jippe , best way is making an i2c/spi extension for the wifi module ( + why not a new wifi module rev integrating directly all this )
I’d like to have on such board:
I’d vote for SPI over I2C, better with microSD reader.
Also if new wifi rev + evse rev , I’d like a gpio on the serial pad , + the reset pad on openEvse uart side
I agree on the comments for a more expandable wifi board.
The esp32-dev board is a good start - its has sd card reader, ethernet, wifi and many gpios exposed.
The line between the openevse controller and the wifi module would become more blurred and the question could then be, why not improve the control board to deal with 3 phase (add 2 more CT inputs at a minimum). With this auto-detection of single vs three phase is easy and current measuring simplified (all done by the controller).
[edit] The current control board has ADC (ADC3, ADC6, ADC7) inputs spare, so this could be easily added : OpenEVSE_PLUS/OpenEVSE_PLUS_v5.5.pdf at master · OpenEVSE/OpenEVSE_PLUS · GitHub
In the meantime, I’m still thinking the best way to deal with 3 phase in existing hardware, my main goal is to switch to single phase when on pv-divert, which should be very simple.
I would also suggest a design improvement for openevse would be 2X 2pole contractors as opposed to 1x4 pole for 3 phase. This way the L2/L3 contactor could be individually controllable and construction of the 3 phase variant would require another identical contactor added, not a 4 pole replacement - simplifying the construction / parts list.
[edit2]
Crazy idea. On the openevse controller, the i2c pins are connected to ADC inputs on the ATMEGA. They could be repurposed for 2xCT and the display control moved to the wifi unit… which also has i2c… That would solve the 3 phase problem fully.
Still missing a gpio pin to control the other contactor?
I’m discovering the dev board after few month of dev :)) thanks
Yes. I’m beginning to think the best place to control this is in the main openevse AVR controller, not the ESP. It would require more difficult code changes, but it would end up in the ‘right’ place.
Well, guess what ?
It looks like the openevse v5.5 can already control 2 relays… both in the code and the the actual relay connector.
Looking at the schematic: OpenEVSE_PLUS/OpenEVSE_PLUS_v5.5.pdf at master · OpenEVSE/OpenEVSE_PLUS · GitHub
You can see there are 2 independently controlled relay pins, and only one appears to be used.
In the code, both the relay pins are controlled at the same time, so I’m sure we can change that semi-easily, and trigger it somehow from the wifi board via RAPI.
J1772EvseController.cpp - the chargeOn() function shows both relay activation clearly and they are both brought on at the same time…
Food for thought.
I know nothing about EVSE, but I remind you of the old engineering adage: “If it looks right, it sounds right and it feels right, it probably is right.” If it feels wrong, it most likely is and you’re only creating problems for yourself further down the line.
OK, not as hard as I had thought.
I’ve created a PR Added timeout POC for LCD backlight (untested) by alandpearson · Pull Request #16 · OpenEVSE/open_evse · GitHub (yes I know it covers 2 features, I need to get better at git branching) that enables the 2nd relay to be enabled or disabled by RAPI command ‘SR’.
SR 1 will enable the 2nd relay during charge events, SR 0 will disable it. By default it is enabled to match the openEVSE behaviour today.
This will mean that in the future, Kip or I can easily add the option to use PV Divert on single or three phase, from the Wifi board. I envisage that the 2nd relay is connected to the L2/L3 contactor. This contactor is controlled by openEVSE in the chargingOn and chargingOff events only, so there is no danger of activating the contactor accidentally via either the RAPI command, or if we had attempted to control it via GPIO on wifi board. For example executing the RAPI SR command during an existing charging session will do nothing.
I believe this is the right, safest and best method to achieve single phase PV divert option on three phase systems.
Let’s see if @jeremypoulter thinks the same - I’m sure the code implementation could be improved… I’m an amateur C programmer at best, and C++ is not something I’m overly familiar with.
Do you think we can use the AC Test 1 and 2 with booth relays at the same time ? ( for the security check ) .
edit: I mean adding a second hcpl2731 on the same 2 digital pin used.
I don’t see enough digital pin available on the chip to separate them.
This is surely the way. if you need some more space you can compile it without scheduler & limits as they are useless now. There’s still other old stuff you can remove i think.
you should make separated PR from separated branch for this
Not sure what you mean. AC Test1 and 2 seem to across be L1 and N.
In the current design it seems it doesn’t test for AC at all on L2 or L3. Not sure if it needs to or not. If you did add two more hcpl2731, you’d likely want them across L2/N and L3/N. Then you’d either have to use different digital pins on the AVR or take them through a TTL OR gate chip… otherwise they’d probably fight each other. Not sure.
[edit] I see what you mean. As we now use 2 relays, we miss stuck relay check for relay2 / contactor2. Good point. I don’t know why AC_Test1 and AC_Test2 are connected to L1 and N. Maybe this is to accommodate ‘Split Phase’ common in North America. I’d need someone smarter than me to confirm, but if this 3phase design did go forward, I see no reason AC_Test2 would not instead connect to L2. This way both contactors are monitored for stuck relay.
[edit2] I don’t think AC_Test needs to across Lx and N. The HCPL2731 negative input for both inputs is connected to ground. For the 3 phase units, you would not need to check ‘N’ for voltage, in my opinion, but would need to check at least L2 or L3 on the other contactor for stuck relay. When I get to the stage of putting in my 2 contractors I will move the AC_Test2 to L2 on contactor 2.
[edit3] HCPL2731 is a simple dual optocoupler https://docs.broadcom.com/doc/AV01-0546EN
I can see no reason why routing one input to L2 would not be sufficient.
I don’t think it’ll need more space. It was a very small addition on the AVR code and imagine a very small addition on the LCD code.
I’m not good with web development, so I’m happy to do the logic in the esp32 code for it, but would need you to add config options etc to the gui. We’d need an option for 3phase or 1phase PV Divert.
All of this is untested as I only have an esp32_dev board to play with, I don’t have a test openevse board.
I have on order 2x 2pole contactors and will replace my 4 pole contactor with these. Do you (or anyone else) have a test system ?
Another way to avoid stuck relay check altogether on relay2 would be to power it from relay1 output. That way, contactor2 would only energise if relay1 was on. In the event relay2 was stuck, it would not matter as it would not have 240V to its input unless relay1 was on. This is what I planned when originally thinking to control relay2 from ESP.
However, I think the right approach is to use AC_Test2 as described above.
So you keep a three contactor relay 1 with all the 3 phases on it, then put L2 L3 on relay 2 ?
That would do the trick sure
The web dev part is easy to mimic on UI2, but I can bring some modification in another branch for your tests.
You can still use directly the api with rest api tools like Boomerang in chrome store when you’re testing your fw changes