Residential EVSEs are almost always for Level 1 (L1, 120v) and Level 2 (L2, typically 240v) charging.
For L1 & L2, the actual charger is onboard the vehicle.
There are a LOT of mfgrs of EVSEs. I bought an OpenEVSE charging station for my first EV in Aug2017, for $600 for the Advanced version, 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.
- EVSE_01b.jpg (3.48 MiB) Viewed 762 times
- EVSE_02b.jpg (3.43 MiB) Viewed 762 times
- EVSE_03b.jpg (2.74 MiB) Viewed 762 times
- EVSE_04b.jpg (1.95 MiB) Viewed 762 times
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 it's 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: typical. 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).
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 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 (instructions from github). My Ubuntu 18.04 has Python 2.7 installed, but not pypi. I think I installed esptool using:
Code: Select all
python -m pip install esptoolCode: Select all
asavage@Ubuntu1:~/Downloads$ dmesg | grep tty
[ . . . ]
[790893.659693] usb 4-1: FTDI USB Serial Device converter now attached to ttyUSB0
asavage@Ubuntu1:~/Downloads$ There are a couple of different ways to allow access to the USB<->serial converter, but for a one-time thing, chmod worked.
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.
Assuming you have the flash data file in Downloads . . .
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, but that's OK).
- Press the flash button and hold it down
- Plug in the USB<->Serial converter
- Continue pressing the flash button
- In the terminal window, scroll back and run both the above commands, in that order
- Results: see below
Code: Select all
asavage@Ubuntu1:~/Downloads$ sudo chmod 666 /dev/ttyUSB0
[sudo] password for asavage:
asavage@Ubuntu1:~/Downloads$ esptool.py --port /dev/ttyUSB0 -b 115200 write_flash 0x00000 firmware.bin
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$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 locker Sunday morning. I purchased a Waveshare Atmel AVR ISP programmer 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 Code: Select all
sudo apt install libusb-devThese 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.
- avrdude -c avrisp2 -p m328p -U lfuse:w:0xFF:m -U hfuse:w:0xDF:m -U efuse:w:0x04:m
- avrdude -c avrisp2 -B0.5 -p m328p -V -U flash:w:open_evse.hex
- avrdude -c avrisp2 -p m328p -V -U eeprom:w:eeprom_24.bin -V
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 mismatchBits 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 .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)
- Atmel ATMEGA328P Brownout Detection voltage chart.
- Atmel_at328p_BOD_chart.png (23.37 KiB) Viewed 758 times
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.
=================================================
A couple of reference pics from Oct2019:
- OpenEVSE Advanced v4 hardware
- OpenEVSE_Advanced_Oct2019_01b.jpg (1.62 MiB) Viewed 442 times
- OpenEVSE Advanced v4 hardware
- OpenEVSE_Advanced_Oct2019_02b.jpg (2.04 MiB) Viewed 442 times