EVBox charger autostart module
Project – current | Article by Maarten Tromp | Published , updated | 1308 words.
Introduction
In this project, I designed a small autostart module for EVBox G2 and G3 chargers. It replaces the modem, allowing the chargers to operate stand-alone without the need for a backend that no longer exists, bringing them back to life and preventing them from becoming unnecessary e-waste.
Autostart module (render)
In this article:
In a previous project, I turned my managed EV charger into a stand-alone unit using a Raspberry Pi. The original goal was to create a microcontroller-based autostart module, but I had forgotten about that idea once the project reached a point where I could charge my bike.
When I recently received an email asking for simple, step-by-step instructions on how to make an EVBox charger stand-alone, the idea of a simple autostart module came back to me. But this time, I did make it.
This project is becoming increasingly relevant, as the manufacturer, EVBox, has all but gone under. Their EverOn backend—ironically named—is now offline, rendering all chargers that still attempt to connect to it useless. This module could potentially save many perfectly good chargers from becoming e-waste.
EVBox G3 wallbox chargers consist of two main components: the charger itself and a modem. The charger does not make any decisions on its own, it leaves that to the modem. The modem responds to some messages itself, but needs to contact the EVBox EverOn backend for others. This is the reason why everything stopped working when the EverOn backend was shut down.
The autostart module replaces the modem and provides everything the charger needs to function, without requiring an actual modem or backend connection. It effectively turns the charger into a stand-alone autostart unit. No subscription or backend connection is required.
Only a subset of the charger’s functionality is implemented. Features such as metering, remote control, and authentication are not supported. The module is designed specifically for EVBox G2 and G3 chargers, produced between roughly 2015 and 2020. If your charger resembles the photo on the left, it is supported.
The module is a drop-in replacement for the modem. To install it, open the charger, swap the modem for the autostart module, close the charger, and you are ready to go.
Hardware and software are described in separate sections of this article, but in practice their development went hand in hand.
The hardware for the module is quite simple and requires only a small number of components. Charger-specific details are documented here.
As the software is not particularly complex, I selected a suitably small microcontroller. The ATtiny202 features a single USART, an internal clock, 2 kB of flash (program) memory, and 128 B of RAM. It is accompanied by a programming/debugging header.
Communication with the charger uses RS-485, so the design includes an RS-485 transceiver, protection diodes, and termination and bias resistors. The original modem used an Analog Devices ADM3485, which is an excellent transceiver, so I used the same type.
To step down the voltage from the 12 V rail, an AMS1117 voltage regulator is used. The circuit draws very little current (only a few mA), making a linear regulator the simplest solution. A tantalum capacitor provides output stability.
The module connects to the charger via a Phoenix Contact four-pin female pluggable terminal block.
As EV chargers are typically installed outdoors, I selected components rated for extended temperature ranges, from −40 °C to +85 °C.
The schematic diagram is a textbook implementation of an RS-485 interface, a linear regulator, and a microcontroller. In this specific design an input capacitor for the regulator is not required, as it is located very close to an existing capacitor within the charger. Local decoupling for the microcontroller is similarty unnecessary, since it is very close to the voltage regulator output capacitor.
Due to the low component count, and my fondness for optimisation, I aimed to make the module as compact as possible. The result is a 22 × 22 mm PCB, matching the width of the charger connector. There is a ground pour on both sides of the board, with via stitching to improve performance in a noisy environment. The PCB was designed using KiCad.
The starting point for the software was the Python ChargePoint implementation from the earlier stand-alone project. I re-implemented a minimum viable CP in CircuitPython, stripping away modularity, abstraction layers and a cache of all possible commands. This reduced the implementation to just a handful of essential frames, and some logic when to send which frames. I tested this version on the Raspberry Pi Pico with a WaveShare RS-485 board I had recently used for reversing the EVBox ChargeStation Tool. While this made for a convenient prove of concept, for production use I wanted something more robust. So I rewrote the software from scratch in C, compiling it with avr-gcc.
The microcontroller I had chosen has a very small amount of RAM—only 128 bytes—so the software had to be carefully optimised for minimal memory usage. This turned out to be fun to do. As incoming frames are larger than the total amount of RAM, it was not possible to store an entire frame for validation and parsing. Instead, I implemented streaming validation and retained only the few frame bytes that were required for decision making. Since most outgoing frames are static, these are stored in flash memory (PROGMEM) rather than in RAM.
Accompaying the firmware are unit tests, integration test, and regression tests. It's amazing how every harware project turns into a software project.
The PCBs are, once again, produced by PCBWay (affiliate link). There is simply no way that local fabrication houses can match their pricing. I had also requested a quote for assembly, but this turned out to be more expensive than I had hoped. PCBWay generally offers very competitive component pricing, but two of the components were surprisingly costly. Combined with the setup fee, this made assembly prohibitively expensive for such a small run. This led me to consider a plan B: sourcing the components and handling assembly myself. Obviously I was unprepared for what came next.
I spent the following days trawling Conrad, Farnell, Digi-Key, and other relatively local suppliers, before turning to eBay, AliExpress, and Alibaba. Some components proved difficult to source at a reasonable price—or to source at all—such as the Analog Devices RS-485 transceiver, the Microchip AVR (due to its extended temperature rating), and the Phoenix Contact connector. Fortunately, all other components were generic and readily available.
I made a conscious effort to avoid counterfeit parts and "too-good-to-be-true" deals. In the end, I found a promising supplier for one of the difficult components, and decided to order everything from them. In hindsight, I should probably have looked for BOM fulfillment, intead of searching suppliers for individual parts.
This process took several days of work, and I am not entirely confident that I have obtained genuine parts at a good price—or that the parts will arrive at all. At least now I understand the PCBWay assembly setup fee a lot better.
All parts and the PCBs have arrived. The software it nearly finihshed, and I'm currently working on test scenarios. Next I would like to do some testing on the real hardware.
There are so many more things to do in production. I thought the parts sourcing was a rabbit hole, but there's a lot more, like repeatability, tracibility, end-of-line testing, creating test reports, packaging, shipping, writing an installation manual. To me a project is mostly R&D, I sometimes forget that's only the start.
Everything in this project is done using free and open-source software and hardware wherever possible.
Accordingly, the software, hardware, article, and documentation I created for this project are released into the public domain. You can find the relevant files in the downloads directory associated with this article.
The exception to this is anything I did not create myself, as it is not mine to give away. This includes the EVBox protocol, which remain subject to their original licences and copyright.