Trouble upgrading from original 8266 to ESP32 configuration-cant detect EV

Integrations OpenEVSE
1

Rather long series of attempts to upgrade to the newer environment resulted in my EMONEVSE not being able to detect the car is present ie:EV Not Connected.
I was originally on EVSE v2.9.1 and wifi V5.0.1EU.
I swapped out the 8266 with a nodemcu ESP32 and installed V4.0.1 on the ESP, worked fine.
Upgraded the EVSE to V7.3.1, worked fine.
Upgraded the EVSE to V8.2.3 and noted EV lockout unless Wifi was upgraded so upgraded the ESP to V4.2.2, Cant detect the EV.
I tried successive downgrades, but to no avail.
So I tried building the EV simulater, which I think is doing what its supposed to, but still refuses to acknowledge that an EV (simulated) is present.
If I simulate a “Vent Required” error using position 3, with the “EV Present” jumper on, then the error remains until I remove the “EV Present” jumper. ie jumper position 1, short jumper 3 breifly, then error remains until I remove jumper 1. To me that implies that the hardware (and software) can read the CP signals fine.
I have tried multiple times to reset the eeprom by using a command similar to that shopwn in the flash.bat file, but avrdude responds with " No valid record found in Intel Hex file “C:\Allan\eeprom_24.bin”".
I’ve also trierd resetting to factory in the GUI, but although that removes my configuration settings, the EV detect problem remains.

I’m at a loss as to what I should try next.

I’m using AVRDUDE from the Arduino IDE on a windows 10 PC and the programmer is a Nano with the “ArduinoISP” software installed.

Output from AVRDUDE:
C:\WINDOWS\system32>C:\Users\test\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/bin/avrdude -CC:\Users\test\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/etc/avrdude.conf -V -pm328p -cstk500v1 -PCOM3 -b19200 -Ueeprom:w:C:\Allan\eeprom_24.bin:i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.05s

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: reading input file “C:\Allan\eeprom_24.bin”
avrdude: ERROR: No valid record found in Intel Hex file “C:\Allan\eeprom_24.bin”
avrdude: read from file ‘C:\Allan\eeprom_24.bin’ failed

avrdude: safemode: Fuses OK (E:FD, H:DF, L:FF)

avrdude done. Thank you.

2

I meant to mention that I checked the voltages on the pilot wire and they seem correct with both the simulator and the EV. ie:
sim/EV unplugged - 12V
sim/EV plugged in - 9V
sim charging - 6V
Vent reqd sim - 3V

Car reports ready to charge, but EVSE not ready.

3

Re-Upgraded to current firmwares, EVSE v8.2.3, ESP v4.2.2.
It now seems to recognise the EV state Ok, and also outputs a negative 12V on the pilot when EVSE is instructed to sleep.
A scope on the pilot signal on the simulator shows the various voltage levels, but no 1000Hz signal is ever produced.

4

Did you flash the pre-compiled release controller FW: https://github.com/OpenEVSE/open_evse/releases/download/8.2.3/openevse_eu.hex

It sounds like you may have flashed emonevse.hex rather than openevse_eu.hex?

No need to flash the eeprom, you just need to flash the FW:

avrdude -p atmega328p -B6 -c usbasp -P usb -e -U flash:w:firmware.hex

This is the latest ESP32 WiFi firmware for the nodeMCU : https://github.com/OpenEVSE/ESP32_WiFi_V4.x/releases/download/latest/openevse_nodemcu-32s.bin. If you can load the web interface you can load this via the GUI or if not you can use a USB serial programmer and esptool, you’ll need to put the module into bootloader mode first by pressing GPIO button while resetting.

sptool.py --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 40m --flash_size detect 0x10000 openevse_nodemcu-32s.bin

5

Thanks Glynn.
What a reflief to have this working again.
Using the openevse_eu.hex file has solved the problem. I had come to the conclusion that the problem was software, I just didnt know how to fix it.
I would really like to know why the version has an effect on such a fundamental function, ie enabling recognition of the vehicle and allowing charging. I assumed that the US vs UK/EU versions would be more about options/features than basic functionatlity.
Also, why do I need to load openevse*.hex rather than emonevse*.hex when I thought the unit I bought in 2019 was an EmonEVSE.
I’m confused !!!

6

I am sure someone will be able to give you the answer why one does not work and the other FW does but

openEVSE is the “kit” with the captive cable

emonEVSE is the pre built version with the socket on it for you to use a bit like a public charger

It may be that the emonEVSE FW is looking for the resistor in the cable to let it know what size of cable has been connected and the openEVSE with its tethered cable does not have this.

John