No ground fault after upgrading OpenEVSE v5 controller to D8.2.0


I recently replaced the ESP8266 wifi module with an ESP32 wifi module and flashed the latest controller firmware (D8.2.0) with the modifications shown below (limit max current to 15A due to issue with Gen 1 Nissan Leaf charger). The controller is now showing a “No Ground Fault” at boot up. The same issue has been reported before. This used to work fine with 5.0.1 controller firmware and 2.9.1 wifi firmware. I’ve double checked the wiring; ground is certainly there.

diff --git a/firmware/open_evse/open_evse.h b/firmware/open_evse/open_evse.h
index dc8d501..a7cadcc 100644
--- a/firmware/open_evse/open_evse.h
+++ b/firmware/open_evse/open_evse.h
@@ -439,7 +439,7 @@ extern AutoCurrentCapacityController g_ACCController;
 // minimum allowable current in amps
@@ -449,10 +449,10 @@ extern AutoCurrentCapacityController g_ACCController;
 // maximum allowable current in amps
-#define MAX_CURRENT_CAPACITY_L1 16 // J1772 Max for L1 on a 20A circuit = 16, 15A circuit = 12
+#define MAX_CURRENT_CAPACITY_L1 15 // J1772 Max for L1 on a 20A circuit = 16, 15A circuit = 12
-#define MAX_CURRENT_CAPACITY_L2 80 // J1772 Max for L2 = 80
+#define MAX_CURRENT_CAPACITY_L2 15 // J1772 Max for L2 = 80

I had a quick look at the code and compared it with the 5.0.1 code. There are some minor changes for the ground fault detection… my gut feeling (also observing the fact that @dakaix had to flash the firmware twice) is that it might be an initialisation issue. I also flashed the firmware twice but unfortunately the firmware still thinks that there’s a ground fault while there is not.

Interesting, let us know if you find the cause of this issue

I did a quick test and flashed the old 5.0.1 firmware on the controller and as expected no ground fault this time. In other words, changes to the controller firmware since 5.0.1 (for this “v5” hardware) must have introduced this issue.

The code is a bit hard to read for me with all the conditionals (as I don’t know whether these apply or not).
At line 798 the relays are being tested. I’m not sure how Relay1 == none and Relay2 == none is related to “open ground” or what “L2 both hot” means but clearly svcState can only become OG if both Relays are “none”. Both relays are “off” which means that both N and L on the car charger side are floating / not connected. If I recall correctly I did set the service level to 2 on 5.0.1 but do admit I never looked into what service level actually means. I’m in NZ, single phase 240VAC and need 15A max charge current :slight_smile:

Any suggestions for further debugging are much appreciated.

And for good measure, reflashed D8.2.0 and the No Ground Fault is back. Definitely software, not hardware.

The plot tickens:

  1. Update the code to initialise RelayOff:
-  uint8_t RelayOff;
+  uint8_t RelayOff = none;

Starting the controller shows the “No ground fault”.
So I guess it wasn’t that (but might still good to make this change: there are conditions in which RelayOff is not initialised purely from a code observation point of view (ie. regardless if real world scenarios would never leave RelayOff uninitialised).

  1. Changed the service level from Auto to 2 and power cycled the unit.
    Display shows “GFCI Fault” (that however does not show up in the web interface). Controller proceeds as usual.

  2. Rebooted the ESP32 from the web interface.
    Display shows “GFCI Fault”. Controller proceeds as usual.

  3. Rebooted the controller from the web interface.
    Display shows “Safety Error”, “Self Test Failure” (controller stuck in this state).

  4. Powercycled the unit.
    Display shows GFCI Fault and then proceeds as normal.

  5. Changed service level to 1 and power cycled the unit.
    No more faults are shown. Car is away so can’t test whether it would start charging.

  6. Changed service level to 2 and power cycled the unit.
    Display shows GFCI Fault.

  7. Changed service level to Auto and power cycled the unit.
    Display shows “No Ground fault”.

  8. Changed service level to 2 and power cycled the unit.
    Display shows GFCI Fault but very briefly.

  9. Changed max current to 15A and power cycled the unit.
    Display shows GFCI Fault but very briefly.

  10. Changed service level to 1 and max current to 15A and power cycled the unit.
    Display shows GFCI Fault for a few seconds.

Is this observed behaviour to be expected or indicative of - I’m guessing here - something not right with initialisation?

Are you using an EmonEVSE or OpenEVSE kit?

I’m using the OpenEVSE kit - bought in the US.

Ah right, can you see what EVSE controller hardware version you have?

I think it’s “v5” … at least that’s according to the documentation I stored when I bought them in 2019.
Is there a way to find out? Does the photo (above) help? The description on the invoice is saying “Advanced Series - 48A/40A/32A Kit”.

I also note that the error counts in the webinterface are all 0…?

Ah I’ve been made aware of an issue with V8.2 on V5.0 hardware. I would recommend using V7.1.3 :

V8.2 works fine on the current V5.5 hardware.

Hi @glyn.hudson,

Thanks for that, I’ll give 7.1.3 a go later today.
Any pointers to the issue? Do you think 8.2 will support v5.0 hardware at some stage?


And just out of curiosity … what is “#define OEV6”? Does that refer to version 6 of the controller hardware? Should that be defined for v5.0?

I have the same problem.
But I see now that 8.2.0 has disappeared from github …?

I see that the software should detect if the board is v5.5 or v5
“Added GPIO pin pulled HIGH to auto detect board version in software to automatically set new/old pin values without requiring different firmware”

@glyn.hudson Many thanks for addressing these issues (auto detect board version) and increasing overcurrent issue. I was about to fix the overcurrent issue as our Gen 1 Leaf is one of those too-slow cars. Will give D8.2.0 a go soon.

1 Like

Please try 8.2.1 Release 8.2.1 · OpenEVSE/open_evse · GitHub