Open Source Firmware for EV chargers using the ESP32 Chip (Autoaid / EN-Plus / EVSEDO)
an invention by bschmidt
Hack Week 23
Project Description
The project has evolved since last Hack Week (I left what I wrote about it in HW 21 down below).
It still is about having an Open Source Firmware for proprietary EV Chargers / Wallboxes based on the ESP32 chip.
In HW 22 I stated that there are 4 devs + the ones that will join here besides me (instead of 2) now working on this project. Realistically I have to say, albeit the 4 people are still in, we all are only driving the project as a side project and the slow progress makes this obvious.
Anyway, the project is quite mature now and has it's own github organisation named warp-more-hardware.
Any ESP32 with 4MB or more should be good to get you going with this project. If you are into the more fancy stuff you might want to get something with 8MB flash and use it for another project later on.
This will do to participate.
Goals for this Hackweek
1. Evaluate the first prototype of a open source firmware for the charge controller (GD chip)
2. Test a way to reset the GD chip running the original firmware
3. Depending on the outcomes of 1. and 2. -- make a new release of the software for the EN+ 11kW Smart Home Series Wallbox (AC011K).
4. Tackle as many issues as possible from the project issue tracker.
Resources
github repository (fork of the TinkerForge repo)
wiki (one page with some photos and description in german - has to be refreshed within this hack week)
Everyone is welcome to work with us here, especially if you know something about ESP32 / C / C++ / preact.
># Goals for Hackweek 22 where
>1. Make a proper release of the software for the EN+ 11kW Smart Home Series Wallbox (AC011K). 2. Tackle as many issues as possible from the project issue tracker.
># This was Hack Week 21 >## Project Description This Project is about having an Open Source Firmware for proprietary EV Chargers / Wallboxes based on the ESP32 chip.
>There is a very good Open Source firmware for the TinkerForge WARP Charger by TinkerForge. The WARP Charger uses the Espressif ESP32.
>This Project is to port this Firmware to other Hardware also using an ESP32.
>The Project is already in a pretty good state.
>There is a working version, but it is based on an older (1.x) version of the original software.
>To be able to follow the progress of the upstream project more closely, the port needs to get updated and merged with the original. So, the goal is just that.
>There could be stretch goals if I find collaborators ;-).
>## Goals for this Hackweek
>1. Have the firmware version 2 line working on the EN+ 11kW Smart Home Series Wallbox (AC011K-AE-25). 2. Have the same version on the Sonoff Dual R3 to master load management
>## Resources
>github project fork (work is done in a special branch: warp on other hardware)
>wiki (one page with some photos and description in german)
>Everyone is welcome to work with me here, especially if you know something about C / C++ / Typescript.
Looking for hackers with the skills:
This project is part of:
Hack Week 21 Hack Week 22 Hack Week 23
Activity
Comments
-
almost 2 years ago by okurz | Reply
I looked a bit into forum posts and related articles around your project and I found https://www.mikrocontroller.net/topic/516384 and https://www.goingelectric.de/forum/viewtopic.php?f=105&t=66898 and https://www.akkudoktor.net/forum/e-autos-e-bike/open-source-firmware-fuer-autoaid-en-plus-esp32-tinkerforge-wallboxen/ :) are there even more relevant resources? And now for purely selfish reasons as still needing a Wallbox myself: What device would you recommend me to get at the current time? :)
-
almost 2 years ago by bschmidt | Reply
Oh, I just saw your post, I can recommend both, the TinkerForge and the EN+ hardware.
TF: https://amzn.to/3jzM8iV
EVDSO: 4-Meter, 7-Meter cableObviously the EN+ hardware is more capable for a lower price, but the TF hardware has ethernet and is open source out of the box if either of that is important for you. One more thing, the meter in the TinkerForge hardware is "Eichrechtskonform" as opposed to the internal one in the EN+ hardware.
Regarding resources, our warp-more-hardware github and the Wiki are the best resources for EN+ hardware and the TinkerForge Forum as well as the TinkerForge API docs are very good for the software.
-
almost 2 years ago by okurz | Reply
cool, thx. IIUC All of those options don't have automatic phase switching between 1-3 phases which I would prefer for my home situation with photovoltaics, right?
-
almost 2 years ago by bschmidt | Reply
With some extra effort that is possible on the TinkerForge hardware, but even more expensive then.
Lately we found, that the integrated EN+ hardware is capable of doing that, but the firmware of the GD chip is not. So, it might come later, but that is not sure.Either way, depending on the circumstances (size of you rooftop solar installation), it might be the easiest to just use only one phase at all.
-
-
-
-
almost 2 years ago by mpagot | Reply
From my side I'm having fun with Wifi MESH for https://github.com/warp-more-hardware/esp32-firmware/issues/11
I made some experiments with https://gitlab.com/painlessMesh/painlessMesh in a small getting started project: https://github.com/michelepagot/mesh-mash and contributing to the painlessMesh documentation.
Similar Projects
New KDE Plasma notification app/applet by apappas
Description
My memory is terrible so I depend a lot on notifications to carry me through the workday. As a plasma user I am ok with the current applet, but I don't love it. It is too small for the centrality it has in my day. Also I dislike how you can not go back to notifications you have dismissed
Goals
Develop a plasma app that * must gather notifications without disrupting the existing notification app * must offer the ablity to refer to dismissed/archived/seen notification up to some defined point in the past * must allow deletion of notifications
Port some classic game to Linux by MDoucha
Let's pick some old classic game, reverse engineer the data formats and game rules and write an open source engine for it from scratch. Some games from 1990s are simple enough that we could have a playable prototype by the end of the week.
Write which games you'd like to hack on in the comments. Don't forget to check e.g. on Open Source Game Clones, Github and SourceForge whether the game is ported already.
Hack Week 24 - Master of Orion II: Battle at Antares & Chaos Overlords
Work on Master of Orion II continues but we can hack more than one game. Chaos Overlords is a dystopian, lighthearted, cyberpunk turn-based strategy game originally released in 1996 for Windows 95 and Mac OS. The player takes on the role of a Chaos Overlord, attempting to control a city. Gameplay involves hiring mercenary gangs and deploying them on an 8-by-8 grid of city sectors to generate income, occupy sectors and take over the city.
How to ~~install & play~~ observe the decompilation progress:
- Clone the Git repository
- A playable reimplementation does not exist yet, but when it does, it will be linked in the repository mentioned above.
Further work needed:
- Analyze the remaining unknown data structures, most of which are related to the AI.
- Decompile the AI completely. The strong AI is part of the appeal of the game. It cannot be left out.
- Reimplement the game.
Hack Week 20, 21, 22 & 23 - Master of Orion II: Battle at Antares
Master of Orion II is one of the greatest turn-based 4X games of the 1990s. Explore the galaxy, colonize planets, research new technologies, fight space monsters and alien empires and in the end, become the ruler of the galaxy one way or another.
How to install & play:
- Clone the Git repository
- Run
./bootstrap; ./configure; make && make install - Copy all *.LBX files from the original Master of Orion II to the installation data directory (
/usr/local/share/openorion2by default) - Run
openorion2
Further work needed:
- Analyze the rest of the original savegame format and a few remaining data files.
- Implement most of the game. The open source engine currently supports only loading saved games from the original version and viewing the galaxy map, fleet management and list of known planets.
Hack Week 19 - Signus: The Artifact Wars
Signus is a Czech turn-based strategy game similar to Panzer General or Battle Isle series. Originally published in 1998 and open-sourced by the original developers in 2003.
How to install & play:
- Clone the Git repository
- Run
./bootstrap; ./configure; make && make installin bothsignusandsignus-datadirectories. - Run
signus
Further work needed:
- Create openSUSE package
- Implement full support for original game data (the open source version uses slightly different data file contents but original game data can be converted using a script).
RISC-V emulator in GLSL capable of running Linux by favogt
Description
There are already numerous ways to run Linux and some programs through emulation in a web browser (e.g. x86 and riscv64 on https://bellard.org/jslinux/), but none use WebGL/WebGPU to run the emulation on the GPU.
I already made a PoC of an AArch64 (64-bit Arm) emulator in OpenCL which is unfortunately hindered by a multitude of OpenCL compiler bugs on all platforms (Intel with beignet or the new compute runtime and AMD with Mesa Clover and rusticl). With more widespread and thus less broken GLSL vs. OpenCL and the less complex implementation requirements for RV32 (especially 32bit integers instead of 64bit), that should not be a major problem anymore.
Goals
Write an RISC-V system emulator in GLSL that is capable of booting Linux and run some userspace programs interactively. Ideally it is small enough to work on online test platforms like Shaderoo with a custom texture that contains bootstrap code, kernel and initrd.
Minimum:
riscv32 without FPU (RV32 IMA) and MMU (µClinux), running Linux in M-mode and userspace in U-mode.
Stretch goals:
FPU support, S-Mode support with MMU, SMP. Custom web frontend with more possibilities for I/O (disk image, network?).
Resources
RISC-V ISA Specifications
Shaderoo
OpenGL 4.5 Quick Reference Card
Result as of Hackweek 2024
WebGL turned out to be insufficient, it only supports OpenGL ES 3.0 but imageLoad/imageStore needs ES 3.1. So we switched directions and had to write a native C++ host for the shaders.
As of Hackweek Friday, the kernel attempts to boot and outputs messages, but panics due to missing memory regions.
Since then, some bugs were fixed and enough hardware emulation implemented, so that now Linux boots with framebuffer support and it's possible to log in and run programs!
The repo with a demo video is available at https://github.com/Vogtinator/risky-v
YQPkg - Bringing the Single Package Selection Back to Life by shundhammer
tl;dr
Rip out the high-level YQPackageSelector widget from YaST and make it a standalone Qt program without any YaST dependencies.
See section "Result" at the bottom for the current status after the hack week.
Current Status
See the development status issue at the GitHub repo.
tl;dr: It's usable now with all the key features.
It does real package installation / removal / update with reasonable user feedback.
The Past and the Present
We used to have and still have a powerful software selection with the YaST sw_single module (and the YaST patterns counterpart): You can select software down to the package level, you can easily select one of many available package versions, you can select entire patterns - or just view them and pick individual packages from patterns.
You can search packages based on name, description, "requires" or "provides" level, and many more things.
The Future
YaST is on its way out, to be replaced by the new Agama installer and Cockpit for system administration. Those tools can do many things, but fine-grained package selection is not among them. And there are also no other Open Source tools available for that purpose that even come close to the YaST package selection.
Many aspects of YaST have become obsolete over the years; many subsystems now come with a good default configuration, or they can configure themselves automatically. Just think about sound or X11 configuration; when did you last need to touch them?
For others, the desktops bring their own tools (e.g. printers), or there are FOSS configuration tools (NetworkManager, BlueMan). Most YaST modules are no longer needed, and for many others there is a replacement in tools like Cockpit.
But no longer having a powerful fine-grained package selection like in YaST sw_single will hurt. Big time. At least until there is an adequate replacement, many users will want to keep it.
The Idea
YaST sw_single always revolved around a powerful high-level widget on the abstract UI level. Libyui has low-level widgets like YPushButton, YCheckBox, YInputField, more advanced ones like YTable, YTree; and some few very high-level ones like YPackageSelector and YPatternSelector that do the whole package selection thing alone, working just on the libzypp level and changing the status of packages or patterns there.
For the YaST Qt UI, the YQPackageSelector / YQPatternSelector widgets work purely on the Qt and libzypp level; no other YaST infrastructure involved, in particular no Ruby (or formerly YCP) interpreter, no libyui-level widgets, no bindings between Qt / C++ and Ruby / YaST-core, nothing. So it's not too hard to rip all that part out of YaST and create a standalone program from it.
For the NCurses UI, the NCPackageSelector / NCPatternSelector create a lot of libyui widgets (inheriting YWidget / NCWidget) and use a lot of libyui calls to glue them together; and all that of course still needs a lot of YaST / libyui / libyui-ncurses infrastructure. So NCurses is out of scope here.
Preparatory Work: Initializing the Package Subsystem
To see if this is feasible at all, the existing UI examples needed some fixing to check what is needed on that level. That was the make-or-break decision: Would it be realistically possible to set the needed environment in libzypp up (without being stranded in the middle of that task alone at the end of the hack week)?
Yes, it is: That part is already working:
https://github.com/yast/yast-ycp-ui-bindings/pull/71
Agama Expert Partitioner by joseivanlopez
Description
Agama is a new Linux installer that will be very likely used for SLES 16.
It offers an UI for configuring the target system (language, patterns, network, etc). One of the more complex sections is the storage configuration, which is going to be revamped. This project consists on exploring the possibility of having something similar to the YaST Expert Partitioner for Agama.
Goals
- Explore different approaches for the storage UI in Agama.
Cobbler Angular Web Interface by SchoolGuy
Project Description
The old Cobbler webinterface was built into the server, leading to a huge dependency stack only required for a few people.
Goal for this Hackweek
The project should aim to finalize the first prototype of the new Angular based web interface.
A secondary goal of this hackweek is to learn a lot of Angular.
Update for Hackweek 24
The GH project received some traction since I have some vacation. As such it is my aim to get a first alpha released to close the milestone 0.0.1 (or whatever version I can release with semantic release).
Resources
Grapesss: a physical Shamir's Secret Sharing application [ESP32-C3 + Mobile] by ecandino
Description
A couple of years ago I created StegoSecretS, a small cli used to encrypt and split a secret into multiple keys, using the Shamir's Secret Sharing algorithm.
The idea is to re-implement the project using physical devices. One device alone will be useless, but when close together they can be used to decrypt the secret.
On a practical side the user encrypts the secret with a mobile application. The same application is used to split the secret, and load the partial keys into different micro-controllers. Another user will be able to decrypt the secret only having at least N devices close together (using the application).
I'm planning to use a couple of ESP32-C3 I bought, and build a very simple Android mobile application.
Goals
- Learn about Rust and micro-controllers (ESP32-C3)
- Learn about mobile applications (Android and Kotlin)
Resources
Play with esp32 and arduino to create domotics stuff by aginies
Description
got some esp32 board and multiple small periphericals since a while at home, its time to play with them and learn a bit more about this stuff. Connect them to Home assistant.
Goals
learn more about esp32 and creating domotics objets.
Resources
esp32 home
Capyboard, ESP32 Development Board for Education by emiler
Description
Capyboard is an ESP32 development board built to accept individual custom-made modules. The board is created primarily for use in education, where you want to focus on embedded programming instead of spending time with connecting cables and parts on a breadboard, as you would with Arduino and other such devices. The board is not limited only to education and it can be used to build, for instance, a very powerful internal meteo-station and so on.
I already have one initial prototype ready and tested. The next iteration addresses several issues the first prototype had. I am planning on finishing up the mainboard and one of the modules this week.
This project is also a part of my master's thesis.
Goals
- Finish testing of a new prototype
- Publish source files
- Documentation completion
- Finish writing thesis
Resources
- github.com/realcharmer/capyboard
- github.com/realcharmer/capyboard-starter
- github.com/realcharmer/capyboard-docs
- docs.capyboard.dev