Battery-Emulator: making a used EV pack look like a home battery

A translation layer, not a battery management system

The problem statement in the README is economic rather than technical, and it is worth stating in full because it explains the design. Home battery systems let homeowners store power from the grid or from renewables, and almost all of them charge a high cost per kilowatt hour. At the same time, EV manufacturers have been putting high capacity packs into cars with no firm plan for what happens to those batteries after a crash or at the end of the vehicle's life.

The project's answer sits between those two facts. Battery-Emulator enables EV battery packs to be repurposed for stationary storage by acting as a translation layer between the EV battery and the home inverter. The claim is that this makes large EV batteries cheap and easy to use in a plug and play fashion, and the mechanism is specific: the battery keeps speaking its native CAN protocol, and the firmware speaks the inverter's protocol to the outside world.

That framing explains the whole codebase. It is not trying to manage cells, balance them or decide state of charge. It is trying to make two devices that were never designed to meet believe they are talking to the partner each expects.

Physical installation in six steps

The installation section is short because the hard part is the compatibility research, not the wiring. The list runs: connect the emulator hardware to the EV battery, connect it to the inverter, wire the high voltage cable between inverter and battery, add a low voltage power supply to the emulator board, then configure whatever additional requirements your pack needs before the emulator can switch it on, which the README calls closing contactors.

Step five is where battery knowledge becomes necessary. An EV pack will not deliver current until something asserts the contactor, and each platform has its own condition for that assertion. The README points at each battery type's own wiki page for wiring examples, with the Nissan LEAF page named specifically, which tells you how much variation there is.

The README carries a caution callout that deserves quoting rather than paraphrasing: working with high voltage is dangerous, always follow local laws and regulations regarding high voltage work, and consult a licensed electrician if you are unsure about the rules in your country. That is not boilerplate here. The system runs at traction battery voltages, and the low voltage supply in step four exists to power the board itself, not the pack. The repository also includes an AI_POLICY.md alongside the usual contributing and conduct files, which is unusual for a hardware project and worth a look before contributing.

Firmware installed over the air from a browser page

Software installation avoids the usual C++ toolchain entirely. The documented path is a web installer page at the BE-Web-Installer site, and the steps are: open that page, follow its instructions, connect to the wireless network the board creates with the password given in the README, then open the setup page and configure component selection. Connecting the board to your home Wi-Fi afterwards is marked optional, and you finish by wiring the battery and inverter to the board.

That last point is unusual and worth noting. Once the board is on your home network it is reachable from your own machines, which is how the settings pages work, but the commissioning path does not require it. Someone can install and configure firmware standing next to the pack in a garage before the system ever talks to anything in the house.

The over the air update story is developed further in the release notes. Version 12.5.0 added automatic rollback, where the system returns to the previously used firmware if a newly applied update is crashing during the first 40 seconds of uptime, which the release notes describe as making it much harder to brick an install. Versions 12.4.0 and 12.6.0 both carry a warning that to update to them you must already be on a v10 release, and that first crossing requires a one time USB setup through the installer page. That is the single most important practical detail in the release history: over the air updating is only available once you have crossed the v10 boundary by cable.

Supported platforms grow with every reverse engineering effort

The release cadence is fast and the feature list is dominated by new platforms. Version 12.5.0 added Akasol batteries, Growatt LV GBLI series batteries, FoxESS EP series inverters and Ferroamp ESO15 inverters. Version 12.4.0 added diagnostic trouble code reading and clearing for the Renault Zoe Gen1 and the Stellantis CMP Smart car platform, on top of the Kia and Hyundai EGMP platform covered in 12.5.0. Version 12.6.0 extended DTC support to the Kia and Hyundai 40 and 64 kWh platform.

That pattern is the honest way to read the project. Each new entry is a protocol somebody worked out, and the dependency list shows the sources: separate repositories for BYD battery CAN data, TeslaBMSV2, a Solax CAN bus project, FoxESS protocol notes, Renault Zoe CAN matrix information, and links to a Pylon protocol discussion on eevblog. The firmware is an accumulation of other people's reverse engineering, and it credits the sources by name.

The practical consequence is that compatibility is a list you check rather than a standard you rely on. If your pack and inverter appear in the wiki, the project will save you a great deal of money. If they do not, the work ahead of you is writing the CAN message handling yourself, and the value of the codebase to you is the framework rather than the support.

An ESP32 project built with PlatformIO and a web frontend

The tree describes an embedded C++ project rather than a hosted service. `platformio.ini` is the build definition, `boards/` holds board definitions, `Software/` the firmware sources, and `web_data/` the files served over the built in web server. There are three flash layout CSVs at the root, `default_16MB.csv`, `default_8MB.csv` and `min_spiffs.csv`, which are ESP32 partition tables describing how the limited on-chip flash is divided between application and data.

The three libraries that matter for CAN are worth calling out because they explain why the firmware can talk to vehicle buses at all: `acan-esp32` and `acan2517FD` from pierremolinaro, both MIT licensed, provide the CAN and CAN FD controller drivers for the ESP32 family. `AsyncTCP` and `AsyncWebServer` from ESP32Async handle the network side, and `ArduinoJson` handles serialisation. `ElegantOTA` provides over the air updates under an AGPL licence, and `Adafruit_NeoPixel` under LGPL drives any status LEDs on the board.

There is also a `test/` directory and a `.pre-commit-config.yaml`, so formatting and tests are wired into the contribution flow rather than left to reviewers. For a project that touches traction voltage hardware, that hygiene is part of why the release notes can claim improvements in robustness without overstating what they mean.

Diagnostics, balancing and cell history as a battery health story

The recent releases show the project maturing from protocol translation into something closer to a battery monitoring tool. Version 12.6.0 adds histograms for the Nissan LEAF so you can inspect how hard a life the pack had before it went into stationary use, and it renames the More Battery Info page to More Battery/Cell Info to keep the extra detail out of the main view.

Cell balancing support for BYD batteries arrived in 12.5.0, with a dedicated page for inspecting balancing hours per individual cell. That is a meaningful addition because balancing data is the closest thing available to a history of how the pack has been treated. An EV pack that spent years in a hot climate with a full charge every evening looks different from one that was barely driven, and before this feature you had no way to ask.

So the practical progression for someone building this is worth naming. First you get the pack talking to an inverter at all, which is the translation problem. Then you get diagnostics and per cell history, which tells you whether the pack was a good bet. The README and repository cover the firmware side well; the judgement about whether a particular used pack is worth installing still comes down to reading the wiki page for that battery.

Editorial conclusion

Battery-Emulator solves a specific and real economic problem: a Nissan LEAF pack that would otherwise be scrap can be turned into household storage for a fraction of what a new home battery costs, and this firmware is the piece that makes an off the shelf inverter willing to talk to it. The practical entry point is the wiki, not the repository, because the battery compatibility list, the inverter list and the hardware bill of materials all live there and change as new platforms are reverse engineered. Releases are frequent and specific, with 12.6.0 in September 2026 adding Nissan histograms and Kia and Hyundai DTC support, and 12.5.0 adding automatic firmware rollback if an update crashes. Before buying anything, check that your exact pack and inverter both appear in those two lists, because a platform missing from them is a hardware project rather than a firmware one.

Frequently asked questions

Official sources

1. dalathegreat/Battery-Emulator on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases