OpenEVSE notes

Ongoing discussion of anything not related to Nissans or diesels.

Moderators: goglio704, Nissan_Ranger, kassim503

Post Reply
User avatar
asavage
Site Admin
Posts: 5431
Joined: 18 years ago
Location: Oak Harbor, Wash.
Contact:

OpenEVSE notes

#1

Post by asavage »

An EVSE (Electric Vehicle Supply Equipment) is a charging station, not a charger. It supplies AC current, typically from 120v to 240v (but can run up to at least 277v in single/split phase, and 400vac in three-phase (Europe, etc.) systems.).

Residential EVSEs are almost always for Level 1 (L1, 120v) and Level 2 (L2, typically 240v) charging.

For L1 & L2, the actual "charger", which converts the 120/240/etc to ~400VDC, is onboard the vehicle.

There are a LOT of mfgrs of EVSEs. I bought an OpenEVSE charging station for my first EV in Aug2017; $600 for the "Advanced" version (with WiFi and color LCD), assembled -- I did not have the time to assemble myself, though I would have loved to.
Where I park the RAV4 EV.  The tree on the corner has since been removed, as it was fouling the garage's foundation.
Where I park the RAV4 EV. The tree on the corner has since been removed, as it was fouling the garage's foundation.
EVSE_01b.jpg (3.48 MiB) Viewed 3436 times
EVSE_02b.jpg
EVSE_02b.jpg (3.43 MiB) Viewed 3436 times
EVSE_03b.jpg
EVSE_03b.jpg (2.74 MiB) Viewed 3436 times
EVSE_04b.jpg
EVSE_04b.jpg (1.95 MiB) Viewed 3436 times
It has the WiFi option board, but until this week, I'd never explored it.

I want to use features of this OpenEVSE to tailor the charge start time every night. My goal is to have the battery charged just before I'm ready to depart. The car's onboard scheduler is too conservative, often completing a charge three hours before I leave, and if I try to fool it by changing the departure time, the pre-climate feature has to be disabled.

The OpenEVSE can circumvent the vehicle's scheduled charge feature. I can put the car in "charge now" mode, and schedule the EVSE when to turn on, to more precisely control charge start time than the car's scheduler allows.

Like most appliances these days, the OpenEVSE has a CPU: Atmel MEGA328P. It has firmware. It shipped with 3.11.1; current is 5.0.1.

The WiFi option board has its own CPU, ESP8266-12F, and its own firmware that also is out-of-date: current is 2.8.2 . It's an AdaFruit unit.

The WiFi CPU's firmware is (usually) upgradeable via a web interface. I ran through the procedure, but finally could not get it to tell me the version of the uploaded firmware, and it wouldn't work correctly after that.

The EVSE's main module's firmware cannot be upgraded via a web interface; wires are needed.

I got to the point where I had to remove both CPUs from the OpenEVSE's enclosure, connect them to a PC, and re-flash them. Argh, the learning curve. Below summarizes the successful path I took; not necessarily an optimized path, but I'm leaving out most of the cruft of wrong turns I took along the way. This is a recipe, probably not the best recipe.

This is an all-Linux recipe (Ubuntu 18.04, in my case). See below for later (Apr2022) Windows notes.

The WiFi module firmware
The WiFi's ESP8266 has to be flashed using the serial interface. On modern PCs, this requires a USB<->serial (not RS232, which is 5-25v) 3.3v signal level converter, and the better ones use an FTDI IC to facilitate the conversion. I ordered two of those, one an AdaFruit via Amazon, and another no-name unit via eBay (FT232RL FTDI USB 3.3V 5.5V to TTL Serial Adapter Module for Arduino Mini Ports). The AdaFruit unit looks great, but I've never been able to make it work. The no-name worked OK.

I had to install esptool, a Python program. My Ubuntu 18.04 has Python 2.7 installed, but not pypi. I think I installed esptool using "python -m pip install esptool

[Apr2022: python 3, default on newer versions of Ubuntu, does not support the above. Instead:

Code: Select all

sudo apt install esptool
. . . and then use "esptool" where previously needed "esptool.py"]

Now, to locate the correct USB port. Plug in the USB cable to the PC, and see what dev Ubuntu has assigned to it:

Code: Select all

asavage@Ubuntu1:~/Downloads$ [b]sudo dmesg | grep tty[/b]
[ . . . ]
[790893.659693] usb 4-1: FTDI USB Serial Device converter now attached to ttyUSB0
asavage@Ubuntu1:~/Downloads$ 
That meant that my FTDI-chipped USB<->Serial converter resided at /dev/ttyUSB0

There are a couple of different ways to allow a program to access the USB<->serial converter, but for a one-time thing, chmod worked. The problem with using chmod is that you have to re-run the command every time the converter is plugged in to the PC.

Assuming that the flash data file is located in the Downloads folder . . .
In a terminal window, preload these two lines into the terminal buffer:
  • sudo chmod 666 /dev/ttyUSB0 (<-May have to type password, if the last sudo has gone stale)
  • esptool.py --port /dev/ttyUSB0 -b 115200 write_flash 0x00000 firmware.bin (<-this will not complete, because the converter's not been plugged in yet, and that's OK. We're just preloading the command for later use.).
Below, there are TWO DIFFERENT procedures for the early (ESP8266) and later (ESP32) WiFi modules

ESP8266:

In order for the ESP8266 to use its serial interface to input flash data, you have to put the chip in flash mode, by grounding the GPIO0 line on powerup. The Adafruit WiFi module conveniently has a tactile switch to do this.
  • Press the flash button and hold it down
  • Plug in the USB<->Serial converter to the PC. This powers up the WiFi module
  • Continue pressing the flash button until . . .
  • In the terminal window, scroll back and run both the above commands, in that order
  • . . . you see "erasing" or similar, then release the flash button
  • Results: see below

Code: Select all

asavage@Ubuntu1:~/Downloads$ [b]sudo chmod 666 /dev/ttyUSB0[/b]
[sudo] password for asavage: 
asavage@Ubuntu1:~/Downloads$ [b]esptool.py --port /dev/ttyUSB0 -b 115200 write_flash 0x00000 firmware.bin[/b]
esptool.py v2.7
Serial port /dev/ttyUSB0
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: 5c:cf:7f:19:92:42
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 705152 bytes to 399582...
Wrote 705152 bytes (399582 compressed) at 0x00000000 in 35.3 seconds (effective 159.9 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
asavage@Ubuntu1:~/Downloads$
115200 baud seemed to be required; I was unable to use 9600.

ESP32:

I upgraded my original ESP8266 WiFi hardware to the current ESP32-WROOM-32 version. I bought the module from Adafruit for $13.50 + shipping, around $22 on my doorstep, and it comes with some pin header strips. OpenEVSE does sell their version (same Espressif chip, different PCB and headers) for $40 + shipping, and it comes pre-loaded with a recent firmware, but since I already have the USB<>UART programming tool, I decided to buy the bare/no-firmware-installed board. I cut off a chunk of pin header, six pins long, and soldered it to the board: hardware part done.

Instructions for the esptool command line are here. Since this is a new install, flashing the bootloader and the partitions file is required, as well as the actual firmware, so for Ubuntu 21.10 and python 3 and the esptool Ubuntu package installed, I used:

Code: Select all

esptool --port /dev/ttyUSB0 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 40m --flash_size detect 0x1000 bootloader.bin 0x8000 partitions.bin 0x10000 openevse_huzzah32.bin
That requires three files (from here):
  • partitions.bin
  • bootloader.bin
  • openevse_huzzah32.bin

Subsequent firmware updates should be able to be OTA via the unit's web UI, but if I ever needed re-flash this module, I would not need to re-flash the bootloader or partitions info.
  • Connect the ESP32 to the USB<>UART converter (four wires, and Rx/Tx on one board connects to Tx/Rx on the other).
  • Plug in the USB<->Serial converter to the PC.
    • The converter then powers up the WiFi module.
    • The OS assigns a dev to the USB port. See above instructions for using dmesg to confirm that port. In my case, it's always ended up being ttyUSB0
  • Code: Select all

    asavage@Ubuntu1:~/Downloads$ sudo chmod 666 /dev/ttyUSB0
    [sudo] password for asavage: 
    asavage@Ubuntu1:~/Downloads$ esptool --port /dev/ttyUSB0 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 40m --flash_size detect 0x1000 bootloader.bin 0x8000 partitions.bin 0x10000 openevse_huzzah32.bin
  • esptool should be "connecting" . . .

    Code: Select all

    asavage@Ubuntu1:~/Downloads$ esptool --port /dev/ttyUSB0 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 40m --flash_size detect 0x1000 bootloader.bin 0x8000 partitions.bin 0x10000 openevse_huzzah32.bin
    esptool.py v2.8
    Serial port /dev/ttyUSB0
    Connecting........_____....._____.....___
  • You'll have around 20 seconds to get the ESP32 to begin accepting data. In order for the ESP32 to use its serial interface to input flash data, you have to put the chip in flash mode, by using the two switches on the Adafruit ESP32 Huzzah.
    • Press and hold the GPIO0 button
    • Press and hold the Reset button for ~1/2 second
    • Release both buttons
    • If the button pressing/releasing timing was right, esptool will stop "connecting" and move on to "Detecting chip type..."
ESP32-WROOM-32 Huzzah initial firmware/bootloader/partitions load
ESP32-WROOM-32 Huzzah initial firmware/bootloader/partitions load
ESP32_Initial_Programming_01b.png (377.96 KiB) Viewed 1686 times




The OpenEVSE main module firmware

The OpenEVSE's main module uses the Atmel MEGA328P, which is an AVR microcontroller, and uses In System Programming (ISP) (or In-circuit Serial Programming: ICSP) to update its code, using the board's Serial Peripheral Interface (SPI). I purchased an AVR programming tool from the OpenEVSE online store, but though they accepted my order on Wednesday, I received no tracking info until I emailed them Friday asking for it, and then they returned a USPS tracking number that shows they haven't actually shipped it yet (Sunday night). Sigh. After calling around a bit to try to find an alternate AVR programming tool locally, I fell back to Amazon: ordered Fri. night, dropped at my work's Amazon locker Sunday morning. I purchased a Waveshare AVRISP XPII programmer (clone of discontinued Atmel AVRISP mkII) for $42. It worked perfectly, and after checking the pinouts of it and the OpenEVSE's main module's SPI header pinout, they matched, so I didn't even have to get out the jumpers.

The Waveshare's docs warn that it won't power the unit to be programmed, so I used power from one of FTDIs to run the main module.

I had to install avrdude.

Code: Select all

sudo apt install avrdude 
I also installed libusb-dev, but in the end I'm not sure that I needed it.

Code: Select all

sudo apt install libusb-dev
OpenEVSE has a guide to performing the firmware upgrade to the main module, but it's Windows-centric. The firmware releases are here. The pre-compiled firmware has a .bat file which contains clues on how to proceed, though.

These lines are the meat of it. I only had to substitute "avrisp2" where the orginals contained "USBasp". The Waveshare AVR ISP programmer is a clone of an Atmel AVR ISP mkII, which uses the parameters in avrdude.conf associated with avrisp2.
  1. avrdude -c avrisp2 -p m328p -U lfuse:w:0xFF:m -U hfuse:w:0xDF:m -U efuse:w:0x04:m [see comment in "Windows notes" below about "0x04"]
  2. avrdude -c avrisp2 -B0.5 -p m328p -V -U flash:w:open_evse.hex
  3. avrdude -c avrisp2 -p m328p -V -U eeprom:w:eeprom_24.bin -V
A note about the first line: There is a complaint about efuse:

Code: Select all

avrdude: reading input file "0x04"
avrdude: writing efuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0x04:
avrdude: load data efuse data from input file 0x04:
avrdude: input file 0x04 contains 1 bytes
avrdude: reading on-chip efuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0xfc != 0x04
avrdude: verification error; content mismatch
Based on this discussion I ignored this error:
oPossum wrote:Bits 3 to 7 of efuse will always read 0 - they are not used.

So 0xFC (1111 1100) is the same as 0x04 (0000 0100)
Bits 0-2 are to enable/disable Brown Out Detection (BOD), and if enabled, to set the voltage below which the AT328P will not run. The OpenEVSE code sets it to only run when the supply voltage is above 4.3v .

Atmel ATMEGA328P Brownout Detection voltage chart.
Atmel ATMEGA328P Brownout Detection voltage chart.
Atmel_at328p_BOD_chart.png (23.37 KiB) Viewed 3432 times
The default for this chip is/was 0xFF (B1111 1111) (opinions vary), or different programming tools/versions read-back an unset bit (which on this device: unset = 1) as either 0 or 1, so depending on the tool and version and age of the chip, one might get 0x04 or 0xFC.

See this post for more.

It's even possible that the WinAVR version of avrdude, and the Linux version read-back unset bits differently. I'm not chasing it down further, I'm happy with it working.

=================================================

After the above, the EVSE's web UI shows the updated firmwares:
OpenEVSE Advanced v4 with updated firmware for the controller and WiFi modules.
OpenEVSE Advanced v4 with updated firmware for the controller and WiFi modules.
EVSE_05b.png (52.37 KiB) Viewed 1750 times
A couple of reference pics from Oct2019:
OpenEVSE Advanced v4 hardware
OpenEVSE Advanced v4 hardware
OpenEVSE_Advanced_Oct2019_01b.jpg (1.62 MiB) Viewed 3116 times
OpenEVSE Advanced v4 hardware
OpenEVSE Advanced v4 hardware
OpenEVSE_Advanced_Oct2019_02b.jpg (2.04 MiB) Viewed 3116 times
=================================================

Windows notes (Apr2022)

The Waveshare USB AVRISP XPII is a clone of a long-ago discontinued Atmel AVR ISP mkII. Above, in 2019, I successfully used it to update the OpenEVSE controller's firmware, under Ubuntu Linux. At that time, I had the controller on my workbench. Today, I wanted to update the firmware again (from 5.0.1 to 8.2.0) with the EVSE still mounted outside, using my all-purpose auto diagnostic laptop which runs Win8.1, but it took a bit of reading to get that working.
Waveshare USB AVRISP XPII (Atmel AVRISP mkII clone), and Win8.1 laptop.
Waveshare USB AVRISP XPII (Atmel AVRISP mkII clone), and Win8.1 laptop.
EVSE_06b.jpg (1.23 MiB) Viewed 1720 times
Waveshare USB AVRISP XPII with ribbon cable's IDC connector's key shaved off
Waveshare USB AVRISP XPII with ribbon cable's IDC connector's key shaved off
EVSE_08b.jpg (1.16 MiB) Viewed 1720 times


The Guide to updating the OpenEVSE controller firmware is here. It's riddled with errors, though. It probably was mostly correct when it was written, but things have changed.

WinAVR (from 2010!) has to be installed.

By default, the tool avrdude, running under Windows, expects the OS to supply a COMx port for the Waveshare USB device, but I was unable to find a suitable driver that worked with that device. Without a COMx port, the command lines I used with Ubuntu returned errors stating that no COM1 was found.

The successful steps I used were:
  • I used the Zadig tool v2.7 to switch the Windows USB driver for the Waveshare USB AVRISP XPII to the libusb-win32 driver.
  • Added a commandline parameter to instruct avrdude to use USB rather than COM1.
    1. avrdude -c avrisp2 -P usb -p m328p -U lfuse:w:0xFF:m -U hfuse:w:0xDF:m -U efuse:w:0x05:m [*this has changed from :x04 in previous versions, or I typo'd it above in 2019]
    2. avrdude -c avrisp2 -B0.5 -P usb -p m328p -V -U flash:w:openevse.hex
    3. avrdude -c avrisp2 -P usb -p m328p -V -U eeprom:w:eeprom_24.bin -V
The "-P usb" may have to have "usb" in lowercase.

Other issues

The OpenEVSE project at GitHub isn't terribly well maintained for use by non-programmers. In particular, it's non-obvious to a casual user just where the firmware files you want are to be downloaded. First, you've got to select the correct release (pre-selected in the link in the previous sentence), then scroll to the bottom of the page to find "Assets". Yes, "openevse.hex" is there (note: it's been renamed from "open_evse.hex" that's specified in the Guide. At the time of writing this, there is no "flash.bat", nor "eeprom_24.bin".

In order to find those missing files, I had to poke around in older release directories.

The "flash.bat" is for the usbasp programming tool, and has to be adapted for different programming tools; this is not a fault of the Guide.

The Guide specifies wire harness wire colors not present in the harness supplied by OpenEVSE's store; the ISP programmer they sent me -- and which I didn't use -- is a Pololu USB AVR Programmer v2.1 . It, like the Waveshare unit, is supplied with a grey ribbon cable and IDC plug with key. There are many different PCB versions of the OpenEVSE controller, and on my version, the key on the plastic IDC connector of the ISP must be shaved off in order to allow insertion onto the controller's pins, as there's no room for the key on my version of the controller: the key fouls the DC-DC converter. Later PCB versions moved the ISP pins left to provide more room, and yet other PCB versions have rotated the ISP pins on the PCB, so there are a lot of variables.
Waveshare USB AVRISP XPII with ribbon cable's IDC connector's key shaved off
Waveshare USB AVRISP XPII with ribbon cable's IDC connector's key shaved off
EVSE_09b.jpg (1.44 MiB) Viewed 1720 times
Waveshare USB AVRISP XPII with ribbon cable's IDC connector's key shaved off
Waveshare USB AVRISP XPII with ribbon cable's IDC connector's key shaved off
EVSE_10b.jpg (1.77 MiB) Viewed 1720 times
Later OpenEVSE controller, showing the DC-DC converter has been moved to allow room for ISP IDC connector key.
Later OpenEVSE controller, showing the DC-DC converter has been moved to allow room for ISP IDC connector key.
EVSE_11b.jpg (312.55 KiB) Viewed 1719 times
No room for the IDC connector's key.
No room for the IDC connector's key.
EVSE_12-1b.jpg (364.36 KiB) Viewed 1684 times
Regards,
Al S.

1982 Maxima diesel wagon, 2nd & 4th owner, 165k miles, rusty & burgundy/grey. Purchased 1996, SOLD 16Feb10
1983 Maxima diesel wagon, 199k miles, rusty, light yellow/light brown. SOLD 14Jul07
1981 720 SD22 (scrapped 04Sep07)
1983 Sentra CD17, 255k, bought 06Jul08, gave it away 22Jun10.
User avatar
asavage
Site Admin
Posts: 5431
Joined: 18 years ago
Location: Oak Harbor, Wash.
Contact:

J-1772 nozzle ("J-Plug" by QC Charge) failure

#2

Post by asavage »

The EVSE in the preceding post is Order #4254 06Aug2017 "Model P50A Advanced - 40A", and was shipped as a v4 hardware design; as of this writing, they are shipping v5.5, which has a different hardware layout but the same or similar components.

I use this EVSE primarily with a 2014 Toyota RAV4 EV, which can actually draw 40 amperes; most non-Teslas cannot get close to that, and the 2014 RAV4 EV has a Tesla onboard charger. I have this EVSE configured for 40A max (240v) on a 50A supply circuit, with a ~20' supply run from the breakers panel to the EVSE's inlet socket.

I normally plug in when I arrive home. The vehicle has its own charge timer, which I have configured such that it calculates when to begin charging so that the vehicle is fully charged when I am about to depart the next day. So, I'm normally handling a "cold" nozzle: cold when I plug it in, cold when I unplug it, because it finished charging at least an hour before I am ready to depart.

Recently, I had occasion to need to charge during the day -- an unusual situation for me -- so I set the vehicle to ignore its charge schedule and "charge immediately", and I plugged in. I was starting from around a 50% SOC. I unplugged at around 85% SOC because I needed to move the vehicle. Immediately, I noticed that distinctive "hot electrical/hot plastic" smell we come to recognize. I found my cheap Raytec IR thermometer and was able to obtain a momentary reading of 200°F ! To me, that is a hair-raising temperature for an electrical connector. By the time I got my phone camera ready to document, the highest reading I could obtain on the nozzle was 189°F.
J-Plug overheated!
J-Plug overheated!
IMG_2298.jpg (1.38 MiB) Viewed 1755 times
OpenEVSE J-Plug, 40A
OpenEVSE J-Plug, 40A
IMG_2295.jpg (950.5 KiB) Viewed 1755 times
J-Plug's sockets look fine, no melted bits or discoloration.
J-Plug's sockets look fine, no melted bits or discoloration.
IMG_2299.jpg (766.96 KiB) Viewed 1755 times
RAV4 EV's J-1772 inlet socket.  Pins look good, no melted plastic.
RAV4 EV's J-1772 inlet socket. Pins look good, no melted plastic.
IMG_2300.jpg (1.1 MiB) Viewed 1755 times


I see no discoloration/corrosion or melted bits on either the nozzle or the vehicle's inlet nozzle.

I asked the mfgrs of the OpenEVSE Advanced v4 unit about a safe connector temperature, and received this reply:
OpenEVSE Support wrote:
The contacts should not get very hot, The wire insulation for EV charging is rated to 105C or 221F.
[ . . . ]
A good contact on this issue is Tony Williams at QC Charge. He is an expert in the RAV4 and coincidently his company manufactured the plug/cable on your station. https://qccharge.com/
Aha. This is one of Tony's nozzle/cables.

I ordered a replacement nozzle/cable from OpenEVSE Store, this time the 48A version, and replaced mine. While the finished lengths of the cable (the end with the ring terminals, etc) are for the v5.x hardware and are not optimum for my older v4 hardware, I was able to get it installed without major compromise or having to re-terminate the leads. I have yet to have an opportunity to charge from a low-enough SOC to get to 40A draw yet, so I can't say if this cured the high temperature problem at the old nozzle.

[two days later]

I disassembled the old nozzle, and found a failed crimp connection from one of the high-current sockets to its twin 12ga wires:
J-Plug failed crimp connection
J-Plug failed crimp connection
J-Plug_40A_failure_10b.jpg (1.14 MiB) Viewed 1725 times
J-Plug failed crimp connection
J-Plug failed crimp connection
J-Plug_40A_failure_05b.jpg (1.14 MiB) Viewed 1725 times
J-Plug failed crimp connection
J-Plug failed crimp connection
J-Plug_40A_failure_06b.jpg (1.22 MiB) Viewed 1725 times
J-Plug failed crimp connection
J-Plug failed crimp connection
J-Plug_40A_failure_07b.jpg (1.01 MiB) Viewed 1725 times
J-Plug failed crimp connection
J-Plug failed crimp connection
J-Plug_40A_failure_08b.jpg (1.06 MiB) Viewed 1725 times
J-Plug failed crimp connection
J-Plug failed crimp connection
J-Plug_40A_failure_09b.jpg (1.27 MiB) Viewed 1725 times

There's also evidence of moderate corrosion of two of three fasteners. I'm surprised corrosion-resistant hardware wasn't utilized, as I live near Seattle, and it's not reasonable to expect charging in only dry conditions, when everything outdoors is wet most of the year here.
Regards,
Al S.

1982 Maxima diesel wagon, 2nd & 4th owner, 165k miles, rusty & burgundy/grey. Purchased 1996, SOLD 16Feb10
1983 Maxima diesel wagon, 199k miles, rusty, light yellow/light brown. SOLD 14Jul07
1981 720 SD22 (scrapped 04Sep07)
1983 Sentra CD17, 255k, bought 06Jul08, gave it away 22Jun10.
Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot] and 12 guests