EVSE Monitoring and Control

Introduction

This page is about various aspects of Electric Vehicle Supply Equipment (EVSE) management. EVSE units are typically known as “EV charge points” or sometimes “EV chargers” (but the actual battery charger is permanently installed in the vehicle and the role of the EVSE is to safely supply AC power that the charger converts to DC for the battery).

The focus here is on the evolt-branded EV-WBM-SMART unit that was installed as part of the ElectricNation research project, which is actually a re-badged Circontrol Wallbox Smart, model CCL-WBM-SMART. (evolt are / were the UK partner for Circontrol, although they’re now using the Swarco brand name.) From the outside there’s little mention of Circontrol – just one instance of “CIRCONTROL” in a small font on a label – but inside all of the smart control elements carry Circontrol branding.

eVolt WallBox Smart model EV-WBM-SMART

One frustration about the ElectricNation project is that – now the research is complete – the highly capable, intelligent EVSE unit has effectively reverted to completely dumb mode. It was installed together with one of the “CrowdCharge” comms units for the duration of the project and that’s been (presumably) reporting back to CrowdCharge HQ but there’s now no way to access any of the data or influence the charge settings. One big annoyance is that there is no way to track how much electricity is being used for charging, and this is a significant and highly variable chunk of the monthly electricity consumption (other big electrical loads have their own sub-meter installed on the individual circuits, but it didn’t seem worthwhile doing that for the EVSE since it has its own meter built-in). Priority 1 is therefore to access the meter readings and Priority 2 would be to enable full smart charging:

  • Delaying the start of charging to coincide with cheap / low-carbon electricity, which might either be at a fixed time every day or might be more variable
  • Dynamically varying the charge current to track variable electricity generation (notably on-site solar PV) or sharing a restricted supply with other large loads

Given that there can be intelligent charging behaviour in both the car and the EVSE unit, there are options for what control is implemented where. In general, my preference is for the car to be set to charge immediately, at full power, when not at home (since I’m probably using a public charger mid-journey) whereas at home it should wait for the cheapest rate (on the Octopus Go tariff, this is between 00:30 and 04:30 every day). The best way to do that seems to be to leave the car set to charge immediately, at full power, all the time, and to apply the restrictions via the EVSE unit.

If I was purchasing a new EVSE unit now (late 2021) I’d probably choose the zappi from myenergi since that automatically integrates very effectively with other electricity management units, time-of-use tariffs and on-site electricity generation.

evolt / Circontrol Wallbox Smart

The evolt-branded Wallbox Smart (Model: EV-WBM-SMART, Code: 490073EV000000) is just a re-badged Circontrol Wallbox Smart (Model: CCL-WBM-SMART). While investigating the communications aspects it became evident the main “brain” of the unit is a CCL1Mini single board computer made by Circontrol and knowing that made it possible to find some documentation about how it operates and can be configured (there is almost zero information about the evolt-branded unit). CCL stands for CirCarLife.

Based on what I’ve understood so far:

  • Circontrol used a software platform called PowerStudio from partner company Circutor to build the CirCarLife Application
  • The CirCarLife application Engine runs on the CCL1Mini board which hosts several services accessible over the TCP/IP network connection. These include:
  • A web server which presents some basic configuration pages
  • An HTTP API which is based on XML formatting
  • An optional Integration – by default this is the Open Charge Point Protocol (OCPP)
  • There is a user interface to CirCarLife written in Java which is downloadable as a Java Applet from the main web server page

There are some manuals for the PowerStudio platform on Circontrol’s PowerStudio website. While these seem to be aimed mostly at software developers creating Applications such as CirCarLife, there is some good information about the HTTP API in particular (in the appendices).

Some general observations:

  • My device, manufactured in August 2017, is running firmware version 2.3b and is based on PowerStudio version 4.2.3 (or perhaps that the version of the CirCarLife PowerStudio Application?)
  • The main web server listens on TCP port 80 and the home page provides access to some basic configuration settings (mainly network-related)
    • Connecting to http://IPADDRESS/ redirects to http://IPADDRESS/html/setup.html
  • By default, this only responds to clients on the same network subnet
    • A workaround is to configure Source NAT on a network router, which makes it possible to connect from other, specified subnets
  • Some of the options point off to another web server running on TCP port 65432
  • It supports the OCPP 1.5 protocol by which it can be integrated into other EVSE management solutions which support this protocol
    • There is an option to switch to OCPP 1.2 or to disable OCPP completely, under the “Integrations” settings
    • OCPP configuration settings can be amended by a third web server running on TCP port 8080
      • This site is password-protected – By default the credentials are Username: admin, Password: 1234
  • There’s a Java Applet / Application which can be downloaded from the main web page which provides an alternative user interface
    • Under the covers this talks to the HTTP API

Within the physical EVSE unit there are several logical Devices and summary information about the status of these is presented on some of the Web pages; much more detail is available via the Java UI and via the API.

  • It seems that the PowerStudio platform fundamentally works with Devices, each of which have Variables of different types and with different characteristics
  • The logical Devices in my CCL-WBM-SMART are reported as:
    • CCL1Mini
    • Display
    • Plug – Mode 3
    • Reader
    • Plug – Meter
    • EVSE

Java User Interface

Modern web browsers won’t launch Java Applets directly so it’s not possible to bring up the Java User Interface within the web browser window, but a quick review of the HTML source for the web pages shows that the Applet code is downloadable at http://IPADDRESS/html/AppletScada.jar

From a Linux system, this can be downloaded and then run with the following commands:

$ wget http://IPADDRESS/html/AppletScada.jar
$ java -jar AppletScada.jar IPADDRESS

It takes a minute or so to grab the details (via the HTTP API) and then shows an overview like this (for the Device called “EVSE”):

CirCarLife Scada – EVSE View (Status: Available)

API Access to Meter Readings

It’s actually not too difficult to access the meter readings. The latest reading is included in the chargeInfo.xml status summary, accessible at http://IPADDRESS/services/chargePointsInterface/chargeInfo.xml

The XML response looks like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<chargesinfo>
  <chargeinfo>
    <id>47D21F22-D016-44CB-A373-9578B8CE7349.4F81287C-B0F0-425E-A957-82E31508AB52</id>
    <name>EVSE.PLUG</name>
    <number>1</number>
    <chargeId>4BE8E65E-4E8C-11EB-4E8C-11EBAC7
 E8993</chargeId>
    <state>0</state>
    <user>00FFFFFFFF</user>
    <activeEnergy>4535970.000000</activeEnergy>
    <partialActiveEnergy>35240.000000</partialActiveEnergy>
    <requestDate>1609764998.667000</requestDate>
    <beginDate>1609765003.363000</beginDate>
    <endDate>1610044168.035000</endDate>
    <chargeTime>279164</chargeTime>
    <stopped>4</stopped>
  </chargeInfo>
</chargesInfo>

The total, cumulative meter reading is in element activeEnergy. The other element, partialActiveEnergy, relates to the consumption in the current / most recent charge session.

As with other meters in the house, I run a script at regular intervals to grab the reading and publish it as an MQTT message which is then logged to an InfluxDB time-series database.

OCPP

The Open Charge Point Protocol (OCPP) is a standard specification for connecting EVSE units into a wider control / management / payment system framework. The EVSE unit needs to be configured with the details of an OCCP server which it then connects to – and from then on it’s possible to perform a selection of management transactions from the OCCP server.

The main appeal of OCPP is that it’s a standard protocol which is independent of the particular make / model / version of EVSE. As a consequence of this it holds the prospect of being a good way of integrating different types of EVSE into things like Home Automation systems.

A little research turned up SteVe (GitHub page is here) as a capable OCPP server for Linux which supports OCPP v1.5, the latest version of the protocol supported by v2.3b of the Circontrol firmware. I installed this via a pre-prepared Raspberry Pi disk image downloaded from here and found that it worked well – but the constraints of the OCPP v1.5 protocol mean that relatively few transactions are supported. Crucially, there is no way to control the current delivered by the EVSE – and yet I know that must be possible since that’s what was done during the ElectricNation research trial.

It’s possible that a later version of the CirControl firmware will support a more advanced version of OCPP and permit a wider range of transactions to be performed, but for now mu conclusion is that OCPP doesn’t help with the more advanced control ambitions. It also doesn’t appear easy to have SteVe respond to automation commands from a higher-level control system such as a Home Automation ‘hub’.

HTTP API

It’s taken me a while to properly understand the PowerStudio HTTP API but now I’ve done that I can see it’s actually rather elegant:

  • It’s quite ‘generic’, able to accommodate a wide range of different electrical power monitoring and control devices
  • It’s effectively self-documenting:
    • The main entry point is an API which returns a list of Devices known to the PowerStudio Engine instance hosting the API
    • Then there’s an API which will return information about a specific Device, including a list of Variables known to that Device
    • A further API will return information about a specific Variable – including its Description, its Units and whether or not it can be Set via the API

There are some more detailed notes and examples of the responses from different API calls in the related GitHub repository (MarshFlattsFarm/CCL-WBM-SMART_API) which I will not repeat here, but there are a few observations to make about the Smart Charging Control aspects:

  • In order to have the car not immediately start charging when plugged in, it seems to be necessary to ‘Disable’ the EVSE
    • This can then be Enabled at the appropriate time (e.g. when the low-rate electricity tariff period starts)
    • Simply setting the EVSE to ‘Enabled’ again is not enough to start start the charging process – I think because the car doesn’t spot anything changing. It’s also necessary to run the ‘Remote Start’ transaction
  • There are few Variables which relate to the power level delivered by the unit and which might be candidates for using to control / reduce the output:
    • The one that looks most promising is Plug - Mode 3.PREDUCTION
      • This refers to a ‘Percentage REDUCTION’ of the charging current – e.g. setting this to 50% reduces the current from 32A to 16A
      • Changing this value while the car is charging takes immediate effect – so it is a mechanism which can be used when other loads are competing for a share of a limited electricity supply

CC BY-SA 4.0 EVSE Monitoring and Control by Marsh Flatts Farm Self Build Diary is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.