Introduction

Last fall I came across an interesting article in Hackaday, where Arne van Itersen made an interesting solar power display with an analog gauge and an e-paper screen.

It immediately grabbed my attention because it solves the biggest problem with e-paper displays—they need a few seconds to refresh, making them unsuitable for displaying continuously changing data like solar power. A simple analog needle takes care of that problem but is limited to displaying one thing only. But if you put the needle in front of an e-paper screen, you get continuous power information from the needle. You can then use the e-paper display for displaying things that only change every few minutes, like storage battery level, daily production, and system operation mode.

But using an analog dial from a multimeter seemed a bit fiddly to me, and I thought about how to improve on that. Using a small servo instead would be better, because I could use needles of any size. Controlling the servos is quite simple too, I needed the ESP32 to control the e-paper display anyway. It took a weekend to put together a simple prototype for a one gauge display, which I used for my DIY EV-charger.

The thing worked like a charm and got me thinking about how to improve it. I was thinking about updating my solar system display for a while now, and this seemed like a good solution.

Thinking About The Design

One needle wasn’t going to cut it this time—I wanted one for solar power, one for power coming from the grid, and one for the power going into the house. After thinking about it for a while, I decided to put the grid and house power servos on the left and right side of the display. The solar servo would be on the bottom. This provides some spatial logic too—power flows from the grid (left) or solar (bottom) to the house (right). I guess putting the solar need on top could also work, but that didn’t look right to me for some reason.

I wanted to put the display outside, where it would be exposed to the elements, so it needed a weatherproof housing. So I had to think a bit on how to make a housing that would be both weatherproof and easy to assemble. It’s easy to build a two part shell, but how to design it in a way you can assemble and then disassemble it easily while keeping it watertight? I decided to approach it differently. I designed a mounting plate for the servos and the e-paper display first and gave it a flange on the sides and on the bottom. Then I designed a one-piece housing with a window and a simple top cover. This housing had simple guides to hold the flanges of the mounting plate. The window can be closed using some acrylic glued with silicone to make it weatherproof. The top cover is designed to have rainproof downslopes and only needs a drop of superglue on each side to keep it in place. This makes the assembly and testing really simple, you can do everything with the mounting plate alone.

The Software

I’m used to Arduino, so this is what I used. E-paper in Arduino is IMO best used with the GxEPD2 library, which includes the Adafruit GFX functions, the servos are controlled using the Servo library, data exchange is done using Adafruit MQTT, and network connectivity uses WiFi.

The program is subscribed to several MQTT topics, containing the values for grid power, house power, solar power, solar production, battery level, and system mode. Each of these topics is linked to a callback function that triggers on topic updates. The callback functions for grid, house and solar power all move the respective servo needles. The callbacks for battery level and solar production only update the relevant global variables. Screen refresh is only directly triggered by a system mode topic change or every 10 minutes, but this updates the display with the latest data stored in the globals.

Startup makes a full sweep of all the needles, serving as a kind of servo calibration check, then starts the main loop. The main loop is really short and only keeps the MQTT connection alive and resets the whole thing if Wi-Fi drops.

Getting the Data To the Topics

The one remaining job on the software side was to get the data from my solar system to the MQTT topics. The solar system is connected to my Home Assistant installation, so it was really easy to set up some automations that publish the relevant data to MQTT topics when the relevant sensor states change. I used state changes for triggers and the MQTT Publish service to send the data to the MQTT topic. I already had a MQTT broker set up for my other projects, so I just used that one.

Build

Once I was satisfied with the results, it was plain sailing:

• 3D-print the enclosure using ABS
• Cut the acrylic to size and glue it to the enclosure using some silicone glue
• Drill a hole for the power cable on the appropriate spot, then use some mounting glue to fix the enclosure to the wall
• Connect the power and insert the mounting plate in the housing.

You can find all the relevant code and files on Github

If you found this article useful, you can buy me a beer here.

What Do I Mean by Low Power?

I was involved in an art project where we wanted to use a smallish (10 x 15cm) solar panel to power an e-paper display inside a gallery, controlled by an ESP32 micro controller.

This would be a pretty trivial job outdoors: the panel has 5W peak power and I could just put a small DC-DC converter on it to get stable 3.3V power from it during normal daylight.

Indoors, the game changes completely, due to two main issues: low illuminance and low solar panel efficiency at low illuminance.

Outdoors, the illuminance will be anywhere from 1000 to 100000lux during the day. On the other hand, normal indoor lighting would normally range from 100 to 500lux. This alone reduces the available power from the solar cell by a factor of 200 or more. 5W turns into 25mW.

But there is another problem: The solar panel efficiency drops at low light. At full illuminance, the total power conversion efficiency of a modern solar panel can exceed 20%, but the same panel will have a much lower efficiency at low light due to interior current leakage. The expected 25mW turns into 5 or 10mW at most with normal indoor lighting.

To put this in perspective: ESP32 will consume somewhere around 900 mW transferring data via WiFi and some 20 to 70 mW with radio off. See this helpful article.

So is there no way to power the ESP32 using our solar panel?

The Solution

Our project involves refreshing an e-paper display at certain intervals and e-paper consumes power only during the refresh (drawing). So the solution is to somehow store the miniscule amount of available energy until there is enough to draw the next picture, turn everything on, draw the picture, save the data for the next one, and power off.

The Hardware

On the hardware side, I achieved this using a solar harvester chip AEM10941 evaluation board that very efficiently charges a single super-capacitor. This super-capacitor in turn powers a low-power, low-voltage boost converter and this powers the ESP32.

The Software

But the hardware alone is not the solution yet: I needed a way to turn off everything so the harvester has the chance to charge the capacitor up, do the drawing only when the capacitor is full and then turn off everything again until there is enough power available.

ESP32 Deep Sleep

The solution is to implement the deep sleep on the ESP32. While in deep sleep, the ESP32 chip only consumes 10μA, but it powers off almost everything, leaving only a small portion of slow RTC RAM and a counter that periodically wakes it up.

So how does it all work?

1. The system spends most of the time in deep sleep, where the combined power usage of the power harvesting system, converter and ESP32 never exceeds about 150μW.

2. Every 5 or 10 seconds it wakes up for a fraction of a second to measure the capacitor voltage:

   2a. If the voltage is not high enough, it goes to deep sleep again.

   2b. If the voltage is high enough, it draws the picture, stores the sequence number into the RTC RAM and goes to deep sleep again.

3. Rinse and repeat.

Pick the Right ESP32 Board!

There is a possible pitfall here: Some ESP32 development boards, like the basic ESP32 Dev Module, power additional circuitry (level converters, USB-to-RS232 chips etc.) from the 3.3V rail. This means they will always use at least 10mW of power, regardless of the deep-sleep mode, which is useless for our use case. I had really good experience with the Olimex ESP32-DevKit-LiPo boards in this respect, but there are other well built development boards out there.

There Are Always Unintended Consequences

Remember how the chip powers off almost everything when in deep sleep? All the regular RAM contents are lost too, only the sequence number in RTC RAM remains. So when I try to draw the next picture, the system doesn’t know a picture was already drawn previously and simply draws over it. The results are really ugly:

I spent way too much time thinking how to fix this…

One option would be to use a full refresh, but that would entail the annoying blinking of the whole display. Then I thought about adapting the library and storing some of it’s variables in the RTC RAM. This seemed like a sure way to lose all my remaining hair, though.

After a lot of thinking, I finally thought of a nice hack. The system doesn’t know what was displayed previously? I should draw the exact same picture as the last time to “refresh it’s memory” and right afterwards draw the new one.

This worked beautifully:

Conclusion

Super-capacitors are a wonderful way to power small devices that work at intervals when there is not much power available. They are preferable to batteries due to their much better cycling ability. I like things that you can put on a wall and expect them to work for years and years instead of becoming electronic waste soon.

And if you use deep sleep with ESP32, always keep in mind the lost RAM contents when the chip wakes up again.

The Code

#include <GxEPD2_BW.h>

#include "GxEPD2_display_selection_new_style.h"

#include "bitmaps/images.h"
#include <pgmspace.h>

#include <driver/adc.h>
#include <esp_sleep.h>

RTC_DATA_ATTR int pic_index = 0;
const int adcPin = 34; // GPIO34 (ADC1_CH6)
const int sleepTimeSeconds = 3; // Sleep time in seconds
const int array_size = sizeof(images)/sizeof(images[0]);
const int refresh_size = 30;

void setup()
{
  // Configure ADC
  adc1_config_width(ADC_WIDTH_BIT_12);
  adc1_config_channel_atten(ADC1_CHANNEL_6, ADC_ATTEN_DB_11);
  
  // Read the voltage on pin 34
  int adcValue = adc1_get_raw(ADC1_CHANNEL_6);
  float voltage = adcValue * (3.3 / 4095.0); // Convert ADC reading to voltage

  if (voltage>2.45) { // Only if voltage is high enough
    if (pic_index%refresh_size == 0 || pic_index%array_size == 0) {
      display.init(0, true, 2, true); // first update should be full refresh
    } else {
      display.init(0, false, 2, true); // following updates should be normal refresh + draw previous picture to avoid artifacts
      display.drawImage(images[(pic_index-1)%array_size], 0, 0, 400, 300, false, false, true);
    }

    display.drawImage(images[pic_index%array_size], 0, 0, 400, 300, false, false, true);
  
    display.hibernate(); //Turn off voltage converters inside the display to save power

    pic_index++;
  }

  // Configure the ESP32 to wake up after a fixed delay
  esp_sleep_enable_timer_wakeup(sleepTimeSeconds * 1000000);
  esp_deep_sleep_start();
}

void loop()
{
}

If you found this article useful, you can buy me a beer here.

If you’ve been reading my DIY EV Charging Point Basics post, you probably wonder how all the options mentioned might be distilled into a practical DIY project. This post describes a charging point I actually built. I will explain why and how I made the individual choices, list an actual BOM, describe how everything is connected and even give you the configuration files I used in the first version.

Design Objectives

Some Background

I built this charging point for a neighbor friend who recently, after some deliberation, decided to start driving an EV in the best possible way for “beginners”: He bought a used short-range EV he uses as the “second car” to drive to work and do errands (he has a big family, so there are many errands to take care of). This saves him a ton of gas money and the objectively better driving experience is simply the icing on the cake.

Until now, he was using the charging cable he got with the car, but this was slow (only half the available charging power) and he had no handy sockets to plug it in, forcing him to use an extension cord. So we talked and I offered to help him build a proper Type 2 charging point, enabling him to use the full charging power and avoid dealing with the “cable salad”, while having everything properly prepared for the next EV that is sure to come in time. We sat down, talked and decided what to build.

Parameters

• He does not have a smart home solution, so the solution had to be standalone.
• We decided it would be best if we installed it on the outside wall of his house, next to his driveway.
• To keep the charging point visually clean, we would use a socket, not a cable.
• Although his present car only has a one-phase internal charger, we decided to build a full three-phase charging point, since the difference in costs is minimal and we wanted to keep everything future-proof.
• With 3x 20A distribution fuses, dynamic current control was a must.
• He needs minimal access control, a switch in the house was enough.
• There should be some easy way to charge only at night, when energy is cheaper. But there should also be an option to charge at any time to top up the car when needed.

Design Choices

After the parameters were set, it was relatively easy to decide on the final solution:

• I decided to use the SimpleEVSE controller to take care of the SAE J1772 standard signalling and control since I had good experience using it in the past.
• I would use a ESPHome controller, connected to the WiFi to control the EVSE controller (current and time control, monitoring).
• The charging point would have it’s own weatherproof switchboard on the outside wall, containing the fuse, relay, EVSE controller and the ESPHome controller. The socket would be built right next to it.
• He had some space left in an auxiliary switchboard inside the house, so we would put the RCD switch there, so it can also serve as an access control switch to turn off the whole charging point when needed.
• We would install a cheap smart electricity meter in the main switchboard to measure the currents on distribution fuses. Since this switchboard is on the other side of the house and wiring an extra data transfer cable to the charging point would be a problem, I decided to read it using a separate ESPHome controller connected to the home WiFi network.

The Actual Build

In our case, the system is housed in two small boxes, but if your installation allows, you could connect the energy counter directly to the charge control ESPHome controller, saving yourself one extra ESPHome controller and getting better reliability.

BOM:

Current Supervisor:

• Wiring box as your situation requires
• An energy meter with Modbus interface, e.g. this one or this one
• RS485 to 3.3V converter, e.g. this
• ESP8266 or ESP32 module, e.g. this
• A 5V power supply

Charge Control Unit:

• Wiring box
• RS485 to 3.3V converter, e.g. this
• ESP8266 or ESP32 module, e.g. this
• 12V to 5V DC-DC converter, e.g. this
• EVSE DIN controller, buy it here, the have many other parts for this project too
• 4-pole contactor, like this one
• A RCD, type B, like this one
• A MCB (fuse), 16A B-type in our case
• A 4P T2 surge protecting device (SPD), like this one
• A type 2 socket, like this one

Build Instructions

Use the schematic as your guide. Be careful about proper grounding, correct wire and component sizing, weatherproofing, wiring screw torques etc. DIN-rails are your friend.

You should have enough experience with electric projects to be able to build and customize this from the data I provided. If you don’t, it’s likely you are not able to build it safely on your own, so talk to people who understand it better.

Example Code for the Two ESPHome Controllers

Current Supervisor:

esphome:
  name: stevec

esp8266:
  board: d1_mini
  
# Disable logging to be able to use Modbus
logger:
  baud_rate: 0

ota:

wifi:
  networks:
 —ssid: "ssid"
    password: "pass"

web_server:
  port: 80

uart:
  id: mod_bus
  tx_pin: GPIO1
  rx_pin: GPIO3
  baud_rate: 9600
  stop_bits: 1
  parity: even

modbus:
  id: modbus_stevec
  send_wait_time: 200ms
  flow_control_pin: GPIO5

modbus_controller:
 —id: stevec
    address: 24
    modbus_id: modbus_stevec
    update_interval: 5s
    setup_priority: -10

sensor:
  #Template sensor
 —platform: template #Max phase current, will be written by lambda
    name: "TokMax"
    id: tokmax

  #Readouts of individual phase currents from the smart meter
 —platform: modbus_controller
    modbus_controller_id: stevec
    id: tokr
    name: "TokR"
    address: 0x0008
    unit_of_measurement: "A"
    register_type: "read"
    value_type: FP32
    accuracy_decimals: 1
    filters:
     —sliding_window_moving_average:
          window_size: 6

 —platform: modbus_controller
    modbus_controller_id: stevec
    id: toks
    name: "TokS"
    address: 0x000A
    unit_of_measurement: "A"
    register_type: "read"
    value_type: FP32
    accuracy_decimals: 1
    filters:
     —sliding_window_moving_average:
          window_size: 6

 —platform: modbus_controller
    modbus_controller_id: stevec
    id: tokt
    name: "TokT"
    address: 0x000C
    unit_of_measurement: "A"
    register_type: "read"
    value_type: FP32
    accuracy_decimals: 1
    filters:
     —sliding_window_moving_average:
          window_size: 6


time:
 —platform: sntp
    id: sntp_time
    on_time:
      # Every 10 seconds do readout of max phase current
     —seconds: /10
        then:
         —lambda: |-
              id(tokmax).publish_state((id(tokr).state > id(toks).state) ? ((id(tokr).state > id(tokt).state) ? id(tokr).state : id(tokt).state) : ((id(toks).state > id(tokt).state) ? id(toks).state : id(tokt).state));              

This is simple: We talk to the Modbus electricity meter every 10 seconds to get the three currents. We do a moving average to keep track of fast current changes. The result (largest average current) is available over HTTP API.

Charge Controller:

esphome:
  name: evse

esp8266:
  board: d1_mini

# Disable logging to be able to use Modbus
logger:
  baud_rate: 0

ota:

http_request:
  useragent: esphome/ESP8266
  timeout: 10s
  esp8266_disable_ssl_support: yes #to prevent OTA filing
  id: http_request_data

wifi:
  networks:
 —ssid: "ssid"
    password: "pass"

web_server:
  port: 80

uart:
  id: mod_bus
  tx_pin: GPIO1
  rx_pin: GPIO3
  baud_rate: 9600

modbus:
  id: modbus_evse

modbus_controller:
 —id: evse
    address: 0x01
    modbus_id: modbus_evse
    update_interval: 30s
    setup_priority: -10

sensor:
 —platform: template #Max phase current, will be written by lambda
    name: "TokMax"
    id: tokmax

  #EVSE sensors
 —platform: modbus_controller
    modbus_controller_id: evse
    id: set_charge_current
    register_type: holding
    address: 1000
    value_type: U_WORD
    name: Set Charge Current
    unit_of_measurement: A
    device_class: current
    state_class: measurement
    accuracy_decimals: 0

 —platform: modbus_controller
    modbus_controller_id: evse
    id: vehicle_state
    register_type: holding
    address: 1002
    value_type: U_WORD
    name: Vehicle State
    accuracy_decimals: 0

 —platform: modbus_controller
    modbus_controller_id: evse
    id: ctrl_bits
    register_type: holding
    address: 1004
    value_type: U_WORD
    name: Control Bits
    entity_category: diagnostic
    disabled_by_default: true

 —platform: modbus_controller
    modbus_controller_id: evse
    id: evse_state
    register_type: holding
    address: 1006
    value_type: U_WORD
    name: EVSE State
    accuracy_decimals: 0

#Manual current setting slider
number:
 —platform: modbus_controller
    modbus_controller_id: evse
    id: set_charge_current_input
    address: 1000
    value_type: U_WORD
    name: Set Charge Current (Input)
    unit_of_measurement: A
    min_value: 0
    max_value: 16
    step: 1
    use_write_multiple: True
    write_lambda: |-
      if (x > 0 && x < 6) {
        return 6;
      }
      return x;      

#Switch for turning EVSE on or off. Note the negated function: switch on = EVSE off!
switch:
 —platform: modbus_controller
    modbus_controller_id: evse
    id: disable_charging
    name: Disable Charging
    use_write_multiple: True
    register_type: holding
    address: 2005
    bitmask: 16384

#Template binary sensor for enabling/disabling the whole EVSE system, used for time scheduling to reduce electricity costs
 —platform: template
    name: Enable
    id: enable
    restore_state: true
    optimistic: true
    turn_on_action:
     —switch.turn_off: disable_charging
    turn_off_action:
     —switch.turn_on: disable_charging

#Readouts and automation
time:
 —platform: sntp
    id: sntp_time
    on_time:
      # Every 30 seconds do readout of max phase current
     —seconds: /30
        then:
         —http_request.get:
              url: http://stevec.local/sensor/tokmax
              headers:
                Content-Type: application/json
              verify_ssl: false
              on_response:
                then:
                 —lambda: |-
                      json::parse_json(id(http_request_data).get_string(), [](JsonObject root) {
                        id(tokmax).publish_state(root["value"]);
                      });                      
      # Every 5 minutes do current control
     —seconds: 0
        minutes: /2
        then:
         —lambda: |-
              //Current limits of system
              const float max_phase_current=20, max_charge_current=16, min_charge_current=6;
              //Only do current control if EVSE is ON
              if (!id(disable_charging).state) {
                //Only do current control if max phase current is too high or charge current setting is reduced (plus offset to prevent corrections under 1A, which have no effect)
                if ((id(tokmax).state > (max_phase_current + 0.5))||(id(set_charge_current).state < max_charge_current)) {
                  //If max phase current is too high (plus offset)
                  if (id(tokmax).state > (max_phase_current + 0.5)) {
                    //If current is low enough to limit properly
                    if (id(tokmax).state < (max_phase_current + id(set_charge_current).state—min_charge_current)) {
                      //Reduce current setting by exactly the excess current
                      auto call = id(set_charge_current_input).make_call();
                      call.set_value(id(set_charge_current).state—(id(tokmax).state-max_phase_current));
                      call.perform();
                    } else {
                      //Turn off EVSE to cool everything off
                      id(disable_charging).turn_on();
                    }
                  } else if (id(set_charge_current).state < max_charge_current) {
                    //Increase current setting by exactly the unused current capacity
                    if ((id(set_charge_current).state—(id(tokmax).state-max_phase_current)) < max_charge_current) {
                      auto call = id(set_charge_current_input).make_call();
                      call.set_value(int (id(set_charge_current).state—(id(tokmax).state-max_phase_current)));
                      call.perform();
                    } else {
                      //Or set maximum charge current
                      auto call = id(set_charge_current_input).make_call();
                      call.set_value(max_charge_current);
                      call.perform();
                    }
                  }
                }
              }              

      # Every 15 minutes turn EVSE back on
     —seconds: 0
        minutes: /15
        then:
         —if:
              condition:
                lambda: |-
                  return id(enable).state;                  
              then:
               —switch.turn_off: disable_charging

This is the main functionality. We set up the Modbus communication with the EVSE controller and prepare the necessary variables to control it. My neighbor did not want to have the whole Home Assistant setup, so the control works via a slider in the inbuilt web server.

The control principle is simple – if the average max current exceeds the permitted maximum, the charging current is set to a lover value. E.g. with 20A limit, if the actual phase current is 22A and the set charging current is 16A, the charging current is reduced by 22-20 = 2A, e.g. to 14A. If there is headroom (a big load has disconnected), the charging current is set higher in the same way. This repeats every 5 minutes.

In extreme cases, where the charging current would have to be reduced under 6A (minimum for the EVSE standard), the charging point is turned off until the next 15 minute interval. This should cool off the fuses enough. Keep in mind that normal fuses should hold a significant overload for tens of minutes (standard requirement is: blow in less than one hour for 45% overload, over one hour for 13% overload).

All that is left is a simple option to turn the whole thing on or off via a switch in the web server or an API call.

Final Notes

This was intended as an illustration of how to build a safe EV charging point with dynamic current control. There are literally thousands of ways how you could go about achieving this, but the general outline will always be the same:

Measure current coming into your home, compare to limit, set charging current, repeat. Turn off EVSE for 15 minutes, if load is too damn high 😉

This could be thought of as trivial, but there is an important point here: if you buy a ready-made charging point, it needs to dynamically control the charging current! If you buy a “dumb” charging point, you are going to be paying for blown fuses at least some of the time and extra power capacity all the time.

If you found this article useful, you can buy me a beer here.