There is a similar sensor from Stegen Electronics (Netherlands).
It combines DC (6mA) and AC (30mA) leakage protection.
The only thing is that it requires an external 12V power supply and a logic level (for communicating with the controller) also 12V.
I thought about this question and came up with several options:
1) There is an I2C bus on the OpenEVSE board, which is not used, but its pins are on the terminal. In the firmware, you can configure these pins for input-output and connect a sensor to them (if the one that I suggested is through a voltage divider (for example, an optocoupler). It is impossible without a divider, since the microcontroller is not designed for 12V from the sensor.
Then just read the state of the sensor pin. If a leak occurs, the sensor will change the state of the line, we will see it and will be able to stop charging.
2) If you have OpenEVSE together with ESP (WiFi), you can also connect the sensor to it (via a divider). In it, poll the status of the sensor and, in the event of a leak, send a RAPI command to OpenEVSE to stop charging. But here you need to make sure that the ESP always has a connection with OpenEVSE in order to be ready to stop charging.
Brilliant feedback, THANK you! Working with something that has a binary output makes me a lot more confident ;)
I have also been thinking about where to place the logic (regardless of the choice of hardware), and while I'm theoretically a fan of placing it on the Wifi module, I would be concerned with the amount of opensource "cr*p" that runs on this, and the risks of something halting the CPU. You could probably place the logic for this on the 2nd core of the esp32 (i assume it's not put to use..), but i'd still be concerned about reliability.
So putting it on the OpenEVSE board would be safer and more logical i think..
We will look into putting a header on a future version of the controller. We may be able to put the logic on the output of the current GFCI sensor, this way either the built in sensor or external sensor can trip the circuit.
Putting on WiFi has two issues, the biggest is timing. The trip is required to happen very fast, It would take additional time for the serial communications to be sent, received and acted upon. Secondly the path would not be reliable enough to pas certification.
Just to follow up on this - I hadn't noticed myself:
SmartEVSE uses this exact approach, as you can see in the attached image.
I have managed to integrate the Western Automation RCM14-03 module into the OpenEVSE unit.
This gives AC 30mA and 6mA DC GFCI protection (tested and confirmed). While there are several methods of integrating the module...I wanted to simplify the integration so that DIY builders can easily upgrade their units without having to make modifications to the actual controller board or firmware.
The RCM14-03 gives a 'HIGH' output on its [FAULT] pin via a pull-up resistor when leakage is detected.
This [HIGH] signal can be directly coupled to the sensor input (pin 2) on the GFCI connector. The value of the pull-up resistor is selected (1k2) to level shift from 12V operating level to the 5V input of the GFCI detector.
I added an 'exciter' coil to the RCM14-03 so that the self tests will run without issue. I also made a custom cable with integrated pull-up resistor so that the module can be fitted easily to the controller board.
I received great support from the R&D department of Western Automation who are the manufacturers of the necessary modules.
Please see pictures attached.