Start a new topic

Bricked WiFi Modules after 4.2.2 firmware update?

I have an OpenEVSE on version 7.1.3 with the ESP32 wifi module. I downloaded openevse_esp32-gateway-f_gui-v2.bin and updated it through the GUI. After the update, the WiFi module never came back online. The display showed a message saying that the firmware update was complete, and just sat there for over 20 minutes. I finally power cycled the OpenEVSE, and the lights on the wifi module never returned, and the EVSE acts as if no wifi module is installed. The wifi module does not connect to my network, nor does it create its own hotspot. Thinking it must be something with that one wifi module, and as I happen to have a spare on hand, I downloaded openevse_esp32-gateway-f_gui-v1.bin and updated that through the gui of the second wifi module. This time it hung at 98% on the LCD display, and the wifi module dropped from my network. After 20 minutes sitting at 98% I power cycled OpenEVSE and it acts exactly as in my first case, no lights, no wifi, no indication on the display that a wifi module is even installed.


In case anyone else gets stuck with this, I'll own up that it was my mistake. I naively thought that the normal Wi-Fi module with an ESP32 chip used the firmware labelled as "esp32". In fact it's supposed to be the firmware labelled "wifi v1".

I was able to recover by manually flashing with esptool and a usb ftdi cable.

The release notes tell you to make sure you have the right file, but you have to go back to about 4.1.5 to find release notes that show you in detail how to tell which one is "right".

Thank you for the feedback. I have put the module image up on the latest release.

1 person likes this

I have made the same mistake (I am a novice in this...) can you help me how to get this corrected now?

As I am not such an expert, I would need a bit more extensive description....

As it is still working to charge my car, the need is not the highest, but I would like to charge a bit more on the solar.

Thanks for the help


The recovery process requires some technical expertise. Instructions are available here:

There's a note that talks about the Huzzah board requiring holding the GPIO0 button while pressing reset. This is also true for the OpenEVSE wifi v1 module. On mine though that did not work and what worked for me was holding the GPIO0 button down while plugging in the USB. (Not sure if the reset button on mine wasn't working right? Or if there's some additional quirk to these modules?)

Thanks a lot. 

I will buy a serial interface and try to get it working.

I just did the same thing, even with the module images being added. I work in IT and am familiar with flashing firmware for stuff like like this (DD-WRT, Raspberry Pies, motherboard BIOS, stuff like that). I don't do it very often, maybe like once a year, maybe less, but this is not new to me. I just want to explain the logic I went through which led me to the incorrect result, and maybe some wording can be updated to make it clearer.

I saw the 3 images. I went out and took the cover off my OpenEVSE to see which model I had. I have the one that is labeled OpenEVSE Wifi V1 on the page (the green one).

I look at the listing of .bin files and read the notes on the page. It appears that all the modules have two different UIs, this is noted by v1 and v2 in the file names. From what i could gather, it does not matter if I use v1 or v2, it seems to be a personal preference between the two.

OK, now I know I just need to pick the correct one from 3 options:




With that in mind, I know my module is an ESP32. I also know that two of the modules pictured are ESP32s. There are also two modules listed as being Huzzahs. So I try to go with process of elimination. Match each module up to a file. As long as each match up makes sense, I should be fine.

starting with the module listed as Huzzah ESP8266, i look through the list and see no exact matches. 

It is not an ESP32, so it likely is not the esp32-gateway files

it IS a Huzzah, but the Huzzah file says huzzah32, not 82 or 8266. (I realize now that its possible the 32 in the file name is just referring to 32bit and has nothing to do with the model of the module)

the last file (wifi_v1) is fairly nondescript. it does match up with the green module picture, but in my opinion the file name is fairly vague. So maybe the ESP8266 matches with the Wifi_V1 files if the other two modules match up better with the other 2 sets of files.

now looking at the Huzzah ESP32

it could match up with the esp32-gateway files

it matches up better in my opinion with the Huzzah32 files since it is a Huzzah AND an esp32 - I think the Huzzah ESP32 module goes with the Huzzah32 files

again the Wifi_v1 seems vague

looking at the OpenEVSE Wifi V1

it matches up well with the ESP32-Gateway files. it is an ESP32 after all and it does not match the Huzzah files. 

As just stated, it is not a Huzzah, so it should not match with the Huzzah32 files

Wifi_V1 does match here, but since i need to have a match for the Huzzah ESP8266, it seems more logical to me that the Wifi_V1 belongs to the Huzzah ESP8266. I believe that the ESP8266 is one of the oldest revisions of the OpenEVSE platform, so maybe thats why the file is called Wifi_V1, it was just the first iteration of the Wifi module. 

Now knowing that I was wrong, I know that the module and files match up like this:

Huzzah ESP8266 goes with the Huzzah32 files

Huzzah ESP32 goes with the ESP32-Gateway files

OpenEVSE WiFi V1 goes with the Wifi_v1 files

The reason I got this wrong was because in my opinion it is unclear that the Huzzah ESP8266 should be paired with the Huzzah32 files. Would it be possible to put under each of the module pictures the unique part of the file name they should be paired with? Kind of like this:

Huzzah                    Huzzah                   OpenEVSE
ESP8266                 ESP32                    Wifi V1

huzzah32_gui          esp32-gateway       wifi_v1_gui

Or the whole file name with a # for the ui number. like:



Or if changing the files names are an option (I understand that sometimes this cannot be done for various reasons), I would think that changing the files names to something like this would keep things clear. Replacing # with the UI version number obviously



the last file set would not need changing in this case

1 person likes this

We submitted a Github issue to improve file names.

Please track and comment there.

Login or Signup to post a comment