Support
How can we help you today?
No Earth Ground stopping charging
OpenEVSE Support
No Earth Ground is different than Ground Fault. Ground fault is a mismatch as you describe.
On V5.5 which has earth ground monitoring while charging, No Earth Ground means when the relay should be closed a small current that should be running from each hot to ground is not detected. A correct positive indication would be a bad ground connection somewhere between the Controller board and the earth rod in your home. A possible false positive scenario would be the relay is not closes or opens up unexpectedly when it should be closed.
Firmware Version 7.1.3 has a known issue where the relay hold power is not high enough for all possible conditions and the relay can open. The solution is to issue a command to increase relay hold power or upgrade firmware, we suggest 8.2.2.
Here is the article on the issue https://openev.freshdesk.com/a/solutions/articles/6000248647
As a first step we would suggest issuing the command $Z0 255 255 (explained in the article) to disable the lower relay hold power.
scott browning
I have had my Open EVSE for almost 3 years - and put a few MWh through it, but over the last 12 months or so I am getting a 'No Earth Ground' status in the log which stops charging - either for the night or for a few hours.
It is now happening so regularly we are struggling to keep up the the charging of 2 EV's in winter (where we mostly charge using our midnight to 6am cheap rate.
Is my understanding correct that this error comes from the CT across active and neutral detecting a miss-match in current? (as in some is not returning via neutral but being leaked to earth? or can it be caused by the MID400 voltage monitoring circuit also?
It only happen once it is up and running, sometimes it will run all night (6 hours), sometimes it will fault after seconds, but generally it is after 1-2 hours.
What is my first step in resolving this? it is using the V5.5 board, with wifi and the 2 line screen, still on the original software (4.1.2 and 7.1.3)