OpenEVSE EV Charge Controller

OpenEVSE (recently renamed to OpenEV) design and build fully open-source EVSE (Electric Vehicle Supply Equipment) charge controllers for electric vehicles.

An EVSE charging station, is a device an electric car (EV) is plugged into to charge. It communicates to the car to agree on a charging rate that is the fastest and safest rate both the car and the power supply can support.

openevse build9

Note: this post is my account of using the OpenEVSE in the UK (240V single-phase AC), see OpenEVSE website for official build guides

Features

The features that make the OpenEVSE charge controller interesting to us are:

I recently swapped my ageing diesel car for an all-electric Nissan LEAF (it’s fantastic), so it felt like the perfect time to build and test an OpenEVSE charge controller unit!

Nissan LEAF charging from solar PV on a frosty morning:

nissan-leaf-solar-pv

Safety

Even though it is possible to charge an EV via a standard electrical outlet, it is not recommended for a number of reasons:

  1. Charging is very slow since the current is limited by the electrical outlet.
  2. Drawing a significant current (approx 10/12A) for an extended period (up to 10hrs for a 24KWh Nissan LEAF and 30hrs for a 90KWh Tesla Model S!) puts stress on the domestic wiring resulting in heating of the wire or worse if the wiring is in a poor state.

Charging via a properly installed EVSE is the fastest and safest way to charge an EV at home.

OpenEVSE units have been designed to exceed the safety requirements for EV Charging Stations from SAE J1772, NEC and UL. Before supplying power to the car (and continuously while charging) the EVSE unit conducts a number of checks, no power is supplied until all the checks have passed. See OpenEVSE Safety Features

Purchase

Update: we are in communication with OpenEVSE to put together a UK/Europe specific OpeneEVSE package to resell via the OpenEnergyMonitor Online Shop.

OpenEVSE units can be purchased (kit or fully assembled) from the OpenEVSE online store, the units are shipped from California USA. I went for a P50D Level 2 Deluxe OpenEVSE kit with the WiFi connection kit and J1772 Cable.

The OpenEVSE 50A L2 unit will charge any J1772 compliant car at up to 40A continous from a single phase 208-240V AC supply. However, you can dial back the current by setting the ‘max charge current’ to match your supply.

Full disclosure: Chris Howell from OpenEVSE made the unit available free of charge for me to evaluate and improve the Emoncms / OpenEnergyMonitor integration.

Assembly

Warning: Assembly of an EVSE requires wiring Alternating Current (AC) components that will be exposed to voltages from 100 to 250v. If you do not have the experience and knowledge required to safely work with AC voltages please consult with an experienced electrician for assistance and inspection of your work.

Assembly of the unit was straight forward following the openEVSE build guide. No soldering was required, only basic tools e.g. screwdriver, wire strippers etc. Assembly probably took me a couple of hours. I took my time to do a high-quality job of assembling, this is particularly important given the high currents involved.

The hardware components are all top quality, I was impressed by the attention to detail such as rubber seals around the LCD to waterproof the unit.

The hardware inside the unit is split into two main components which are physically separated: a high voltage and high current relay and a low voltage control electronics which is the microcontroller (ATmega328p) ‘brains’ of the unit. My unit contained an OpenEVSE Plus V4 control unit see Datasheet:

openevse build5

Rear PCB showing ATmega328p on the OpenEVSE Plus V4 controller:

openevse build7

Build progress: charge controller, ground busbar, relay, LCD and mode button fixed into enclosure

openevse build2

The finished build: WiFi ESP8266 module is visible on the top left.

openevse build3

Installation

Installation should be undertaken by a qualified electrician. The unit should be wired in using suitably rated cable ideally with a dedicated RCD circuit breaker. The max charge current of the unit should be set to match the supply circuit wiring.

Operation

On first powerup some basic settings are set via the LCD menu using a combination of short/long presses of the front button. The menu system is impressively responsive considering it’s running from an ATmega328! The basic settings include max charge rate (set to match wiring), charging service level and date-time. Settings are saved to EEPROM and date-time is kept up-to-date via a RTC battery backup.

The basic operation is very straightforward: just plug the car in and charging begins! Charging can be stopped/resumed by pressing the button on the front of the unit. Charging state is indicated by the backlight colour of the LCD and basic info such as current charging current and total kWh is displayed on the LCD.

Here is a photo of the unit charging my Nissan LEAF @ 26A. At this charge rate my 6.6Kw charge (24Kwh battery) Nissan LEAF will charge from flat in about 4hrs:

openevse build4

Here’s a nice demo of the basic features of the unit. Credit: YouTube user civicturbo2009:

Remote Datalogging

The Wifi kit (ESP8266) enables data logging from the OpenEVSE unit to a custom Emoncms server data.openevse.com via a local Wifi connection. The Wifi kit also allows remote control (see RAPI commands below).

openevse build4

Remote Control (via RAPI commands)

The OpenEVSE unit can be controlled and monitored remotely via serial RAPI (Remote API) commands. These commands can be issued directly via serial or the OpenEVSE WiFi kit (ESP8266) can be added to allow RAPI commands to be issued remotely via an HTTP web interface.

Variable Charge Rate

OpenEVSE charge controller can vary the charge rate, or more specifically the OpenEVSE can ‘request’ a particular charge rate from the car. It is actually the cars charging control electronics that varies the charge rate. OpenEVSE requests a particular charge rate by varying the pilot signal square wave duty cycle see OpenEVSE technical theory of opperation. Charge rate can be varied from 6A (SAE/IEC standard min charge current) up to max charge rate (28A for my Nissan LEAF) in 1A increments. The car responds almost instantly to a charge rate adjustment request from the OpenEVSE controller. Charging can also be paused and resumed remotely if required.

Example:

$SC13 will set the current charge current to 13A. The screen shot on the right below illustrates issuing the $SC 13 RAPI command into the OpenEVSE local web page interface (served from ESP8266). The screenshot on the left shows the effect of reduction in charge rate as monitored by emonPi displayed using Emoncms:

openevse build6

Rapi commands can also be issued directly via a single HTTP request. Eg. the same rapi command to set charging rate to 13A:

http://192.168.0.108/r?rapi=%24SC+13

To sleep (pause a charge) issue RAPI command $FS

http://192.168.0.108/r?rapi=%24FS

To enable (start a charge) issue RAPI command $FE

http://192.168.0.108/r?rapi=%24FE

Assuming 192.168.0.108 is the local IP address of the OpenEVSE ESP.

There is also an OpenEVSE RAPI command python library.

RAPI commands can be used to control and check the status of all OpenEVSE functions. A full list of RAPI commands can be found in the OpenEVSE plus source code.

Future developments

I would like to add MQTT support to the OpenEVSE WiFi ESP8266 firmware, this will allow RAPI commands to be issued via MQTT over an authenticated local MQTT server e.g. emonPi / RaspberryPi or remote MQTT server e.g. Hive MQTT / Cloud MQTT. Using MQTT will make it easier and more secure to control the OpenEVSE. MQTT allow easy integration with all home automation and control platforms e.g nodeRED / OpenHAB / Emoncms.

See this forum thread for related discussion.

Open Source

The source code and CAD hardware designs for the OpenEVSE unit can be found on github:

OpenEnergyMonitor community forum thread documenting OpenEVSE build


Introducing emonTH V2

The emonTH V2 is an open-source, wireless, battery-powered temperature and humidity monitoring node.

The emonTH V2 features a Silicon Labs Si7021 temperature and humidity sensor instead of the DHT22 sensor. The Si7021 is more accurate and significantly (2000 times!) lower power then the DHT22. This will result in an increase in the emonTH battery life; from 10 months to several years. The Si7021 is also much smaller than the DHT22.

emonTH V2

The Si7021 sensor can be seen in the top right-hand corner of the PCB. The white film on top of the sensor is a dust film and should not be removed. The dust film is factory fitted and will protect the sensor from dust and air contaminants.

emonTH image

The emonTH V2 is now shipping via our online shop

As with all our hardware units the emonTH V2 is fully open-source and manufactured locally in North Wales, UK using non-conflict materials lead-free processes.

Read on →

Summer Placement

Hi! My name is Eben I’ve been working with OpenEnergyMonitor for the past 10 weeks as part of a summer placement organised by Arloesi Gwynedd Wledig; a local project aimed at highlighting the local tech sector employment opportunities on Parc Menai the business park where we are located in North Wales, and the difficulties that they face, as well as the great perks of living in such a beautiful area.

image

The scheme organised placements for four students in four seperate tech companies in Parc Menai. Here is a video with highlights the whole 10 week scheme:

Working in a small company in a rural area, that has such a large online community has really opened my eyes to the possibilities that the internet and the digital age can offer, in that people are no longer bound to cities. Increasing infrastructure development in terms of roads and internet speeds has increased this mobility further, and I look forward to the growth that this will no doubt provide in Gwynedd. OpenEnergyMonitor is for me the perfect example of a growing business that has been made possible by opensource development, global connections and communities, and new technology.

Read on →

EcoHome Lab: From Monitoring to Control

Last night I attended EcoHomeLab meetup in Manchester organised by the CarbonCoop.

EcoHomeLab monthly meetups at MadLab brings householders and green-technologists together to take control of home energy use and generation.

It was great fun to catch up with regular faces as well as meet many new interesting people.

I gave a short presentation overview of our efforts as OpenEnergyMonitor to make it as easy as possible for people to get started with energy monitoring and control (home automation) with a sustainability / energy saving focus.

I presented the recent work we have been doing to integrate platforms such as MQTT, Node-RED and openHAB ready-installed and pre-configured on the emonPi, our RaspberryPi based energy monitoring platform. These additional platforms run alongside Emoncms on the emonPi.

See the Integrations section of our user guide for more info

Here are copy of my slides from the event:


HTU21D / Si72021 Temperature and Humidity Sensor

I have been been evaluating the HTU21D temperature and humidity sensor made by Measurement Specialties as a possible DHT22 replacement for the emonTH. This is quite a new sensor, released in 2013. The Si72021 is also a posiblity with an identical pin-out and specs.

image

The metrics speak for themselves:

Metric HTU21D Si72021 DHT22 DHT22 vs HTU21D Difference
Cost in 1k off £1.42 (July16) £2.15 £4.57 (July16) 3.2 times cheaper (£3.15 less!)
Vcc 2.1v - 3.6V 1.9V - 3.6V 3.3-6V  
Humidity accuracy ±2% RH ±2% RH ±2%RH n/a
Humidity Range 0-100% RH 0-100% RH 0-100% RH n/a
Temperature accuracy ±0.3°C ±0.4°C ±0.5°C 40% more accurate
Temperature Range -40°C +125°C -40°C +125°C -40°C +80°C 56% more accurate
Sleep Current 0.02uA 0.06uA 15uA 750 times less power
Measurement Current 0.045mA 0.09 mA 0.5mA 11 times less power
Measurement time 0.01s - 0.0026s 0.01s - 0.0026s 2s 200 times faster
Energy consumed per sample 1.5uJ 2.97uJ 3300uJ 2000 times less power
Time sampling per day* 14.4s   2800s  
Time sleeping per day* 86386s   83600s  
Energy consumed per day* 2.36mW [1]   2836mW [2] 1201 times less energy per day!
Read on →

Part 3/3: Continuous Deployment (Over-The-Air Update to ESP8266)

This post is part of a series


Following on from my last couple of posts in this series we now have a working continuous cloud-based build & test (firmware compiling) flow using PlatformIO and TravisCI, to quickly recap:

  1. Code change is committed to the EmonESP repo on GitHub
  2. TravisCI triggers a build (compile) using PlatformIO running in a TravisCI container in the cloud.
  3. If build/compilation process fails we get an email alert, if pull-request we get a warning before merging if proposed changes break the build.
  4. If a Git commit is tagged as a release the build process uploads the generated compiled binary (.bin) to the repo GitHub release page.

The next step is to get the compiled binary from GitHub-releases (EmonESP in this example) deployed to a WiFi connected production ESP8266. Here’s the user facing EmonESP web-interface for this firmware update process:

image

Read on →

Emoncms Docker

We have made the first steps towards running Emoncms to run in a Docker container.

Dockerfiles and setup notes are in the emoncms-docker repository:

https://github.com/emoncms/emoncms-docker

image

Docker is an exciting tool to help make development, testing and deployment of web-applications easier.

What is docker? (the short version):

Docker containers wrap a piece of software in a complete filesystem that contains everything needed to run: code, runtime, system tools, system libraries – anything that can be installed on a server. This guarantees that the software will always run the same, regardless of its environment.

What is docker? (the long version):

Docker is an open-source platform for developers and sysadmins to build, ship, and run distributed applications. Consisting of Docker Engine, a portable, lightweight runtime and packaging tool, and Docker Hub, a cloud service for sharing applications and automating workflows, Docker enables apps to be quickly assembled from components and eliminates the friction between development, QA, and production environments. As a result, IT can ship faster and run the same app, unchanged, on laptops, data center VMs, and any cloud.

Quick Start

$ docker pull openenergymonitor/emoncms
$ git clone https://github.com/emoncms/emoncms-docker
$ cd emoncms-docker
$ docker-compose up

That’s it! Emoncms should now be runnning, browse to http://localhost:8080

Read on →

ESP8266 WIFI developments

Glyn and I have been doing a bit of development recently on using the ESP8266 WiFi board with OpenEnergyMonitor hardware, we are quite excited about the potential of this little module to both reduce the cost of the system and simplify setup and installation especially for applications that primarily post to a remote emoncms server such as emoncms.org.

Note: we have no plans to discontinue developments and support for Raspberry Pi based systems e.g. emonPi / emonBase. Quite the opposite: the local storage and processing of a Raspberry Pi based system has many advantages particularly for systems requiring more flexibility and customisation e.g Local Emoncms storage. MQTT, openHAB & nodeRED integration. The ESP developments will be ran in parallel, in fact ESP could be configured to post to an emonPi / emonBase via MQTT for local on-site storage and integration.

We are at the moment working on three initial uses of the ESP8266:

1. EmonTx V3 + ESP8266 module

We are initially using the Adafruit HUZZAH ESP8266 module as a development platform. For anyone keen to get going with the ESP8266 Huzzah module it is available from a number of places such as adafruit (USA) and Pimoroni (UK). Any ESP8266 with ESP-12 module should work the same. See lower in the post for EmonESP firmware dev.

image

There will be another post very soon detailing how to use this module with the EmonTx v3.

Read on →

Part 2/3: Firmware Continuous Test & Build

This post is part of a series


Following on from the last blog post on using PlatformIO to compile and upload firmware locally, we’re now going to take things a step further and do the same but in The Cloud!

Groan…I know I just used the clichéd ‘C’ word, however there are many advantages to compiling and testing the code in the cloud. At least I didn’t mention ‘IoT’…whoops, just doing my bit for SEO!

In this instance when we say ‘compile in the cloud’ I mean use GitHub, Travis IO and PlatfromIO to compile the firmware and if the branch is tagged with a ‘Git Release’ auto-generate a compiled binary and upload it back to GitHub release page.

The motivation behind this automated-build and testing is working towards creating a robust infrastructure to push OTA updates to ESP8266 connected nodes (EmonESP dev) inspired by this blog post by Daniel Eichhorn (@squix78).

Read on →

Part 1/3: PlatformIO open-source embedded development ecosystem

This post is part of a series:


Getting an Arduino based project (or other embedded platform) to compile and upload can be a pain. Making sure all the libraries are installed in the correct locations and are the correct versions can be tricky and time-consuming.

I’m sure many developers will agree that the tools we use for embedded development are generally not as good as those used for web application development.

The Arduino team have done a good job with their IDE to try and make the embedded development tool-chain setup as easy as possible. However, I still find library management a cause of frustration. Especially since I move between computers and OS’s frequently.

Recently I have been using PlatformIO and am rather impressed with the ease of setup, speed of compilation, uploading (auto port detection), and most importantly an excellent library manager.

PlatformIO is an open-source ecosystem for IoT development.

Cross-platform build system, IDE integration and continuous testing. Arduino, Espressif, ARM and mbed compatible.

PlatformIO IDE

Read on →