Hi Thomas,
There is a similar sensor from Stegen Electronics (Netherlands).
https://www.stegen.com/en/ev-products/126-residual-current-sensor.html
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.
Hi Glebiys,
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.
Hi Philip I used a different box to the one supplied as I had one in stock. I also fitted a 40A contactor so needed plenty of room. It was a tight fit as you can see.
Just to confirm that both live and neutral are fed through the RCM module (no earth).
Followed Cyril's instructions above to use the RCM14-03 module for ground fault protection since I'm in the EU. The GFCI self test passes, which I guess at least means the AC detection works. I was pleased to note that the current version of the board has +12V available on the "DC relay" connector. The RCM module is a tight fit below the Packard relay but it works.
Thanks a lot for posting that!
More thanks from me! I've just followed the same instructions to good effect:
I've added an additional refinement: DC leakage can trivially be simulated by passing an additional turn of wire through the RCM module, connecting 12V to one of the DC relay outputs, via a 2k resistor. When the relay output is enabled, 6mA DC will pass through this wire, triggering the RCM's DC fault detection.
(With the stock firmware, this will cause a GFCI fault as soon as the relay is enabled, which isn't very useful but does prove that it works.)
I have some rough and ready code to disable the relay output and add this additional step to the GFCI self-test. I'll try to tidy it up a bit and post it to github in due course.
Out of interest, can anyone tell me what the proper latching connectors for the GFCI sensor and DC relay headers are? The GFCI header looks suspiciously like the analogue audio connector for an internal CD-ROM drive, but my google-fu is failing to find a source of the connectors from this century. I've scrounged up a plug for the DC relay header from an old computer fan, which I think is a Molex KK connector?
The Current Measurement is Molex:
https://www.digikey.com/en/products/detail/molex/0050579502/2405410
The GFCI is molex:
https://www.digikey.com/en/products/detail/molex/0050579404/115057
Thomas Nielsen