openinverter forum

I *accidentally* created a fork of the esp32 web interface for Open Inverter. It started off with just the goal to improve the UI a bit, but I ended up expanding to a lot more than that as I thought out my user experience a bit more. Suddenly, I had a new project

This project was also an experiment for me to vibe code an app that had an existing embedded and web codebase. Apologies in advance if there are some nonsensical decisions in the code. I used Claude Code to build this out and only gave it some light guidance / guard rails.

Here's some of the notable changes:

• You can now scan and discover nodes on the network + name them. Previously saved nodes are remembered for easier connection
• Improved lifecycle management and communication detection to both the ESP32 as well as remote nodes
• Responsive UI for different screen sizes including mobile
• Internationalization - it uses Intlayer to support new languages for translations of the UI
• Improved robustness of CAN traffic - it uses FreeRTOS threads and async message sending / reception
• Basic UI for sending CAN messages + `canio` control messages - this UI still needs iterations
• Expanded support for `libopeninv` commands (work in progress)
• Individual charting of spot values
• Named parameter keys - adding this in the firmware of the Openinverter Device will show more display friendly names for a parameter
• Multiple client / web browser support (needs more testing)

You can view the code here: https://github.com/outlandnish/openinve ... -interface

This fork is designed more for system overview / basic logging and only supports communication over CAN. If you're doing logging for tuning motor control, you're still better off with the OpenInverter CAN tool or the original ESP32 web interface for now.

(Work in progress) - I've still got some UI work to re-visit now

Screenshots:

wow.
will give it a test

Thanks!

Fixed some big issues with loading / updating parameters after a refactor. Updates are live

wow,

i was actually actively working on this for my systems. your new interface takes the cake. it covers everything i thought off. including the one shot can message.


thank you for working this out. i will flash it and test it on my systems and some of my new designs.

thanks tons again.

will report back my thoughts after testing a bit

karim

7yatna wrote: ↑Mon Jan 05, 2026 7:46 am wow,

i was actually actively working on this for my systems. your new interface takes the cake. it covers everything i thought off. including the one shot can message.


thank you for working this out. i will flash it and test it on my systems and some of my new designs.

thanks tons again.

will report back my thoughts after testing a bit

karim

Thanks! I'm still finding some bugs / instability since I refactored the CAN layer recently. I'll keep you posted as I sort it out

Absolute impressive what you did. I will give it a try as soon as possible. Just read 1,5h through your repository and the others. Amazing style of coding and also how you use ai. For me so many things to learn. I fear most of openinverter Forum members will have a hard time to understand what you are doing. Do you think you can generate a software architecture diagram ? This will help to understand the structure behind so many clustered files.

I also have a quite big backlog of ideas for the interface. Might I share it with you? As soon as I got a full understanding I am happy to contribute.

Also your other repositories are quite impressive. Do you mind to make a post about your ECU ? From my point of few this has high potential of becoming next gen open inverter framework. This would solve so many topics the big monolithic ZombieVCU code has. I would love to discuss with you on this.

Hi @outlandnish,

This is beautiful work, so much so I had to use your ideas in my own re-imagining of the use of the ESP32!


***************************************************************************
Damien WARNING
***************************************************************************

Do NOT read the following it is very BORING!!!!!!
Go watch a cat video instead
Or just read the code at https://github.com/jetpax/scripto-studio-registry

****************************************************************************


But I ended up with a very different architecture, based on a few observations:

1. There are many other projects related to OpenInverter that expose a configuration interface for an ESP32 CAN based system (GVRET, OVMS, Dana's Battery Emulator etc)
2. The end user will ALWAYS want to change slightly the way the system works for their own implementation, and so run-time behaviour modification through scripting is essential (eg Dynamlabs (proprietary) with Lua )
3. The ESP32 is a very capable device that should not get a free ride in the overall design, ie sitting doing nothing once the initial config is done
4. We should be able to easily port this to other mid-end processors such as ESP32-P4 or RP2350
5. The connected client (PC, tablet etc) has enormous horsepower and storage compared to our devices, so run _and serve_ the UI on the client
6. The client MUST be OS agnostic
7. The system MUST work without internet connectivity, ie isolated LAN
8. All client<>device communications MUST be secured by TLS
9. Its 2026, Agents MUST be able to help write the scripts
10. The Agents will make mistakes (not us of course) so the script engine SHOULD have a visual debugger

Based on that, I redesigned the system with the ESP32 becoming an 'Application Processor', running MicroPython, with some hardware accelerators to ensure that things like secure networking and CAN work at decent speed. This binary rarely gets changed, and running with a different application processor is just a question of using a different MicroPython port. ( I currently have ESP32-S3 and P4 running seamlessly).

That allows the user add any "Extensions" at run time, such as OI, GVRET (@uhi22), OVMS (@bigpie), Dana's Battery Emulator with the same binary and hardware platform, without compilation or flashing new firmware. Multiple simultaneous users of the CAN busses are managed by a CAN manager so that for example, OVMS can peacefully co-exist with OI ).

OpenInverter Web Interface becomes just another app loaded at run-time by a PWA that communicates with the 'App Processor' over wss:// ( I also created a new IANA websocket subprotocol to make this work efficiently ). The 'App' includes the device side Python code that communicates with OpenInverter devices over CAN (only) eg Zombieverter, Foccci etc., which is automatically installed on the device when the user installs the app.

eg etc

Also, once an app is loaded , users can add prewritten device scripts to make the app fit their particular application, using ScriptObjects for which I've created a registry. (The key idea here was borrowed from jczic's ESP32-MPY-Jama, although it is a completely different code base).
And finally, users can change that functionality using scripts, as the system has a built in editor/debugger and file manager.
And if you don't like the colors And one last thing, there's an integrated AI Assistant that can write the Scripts for you
And of course its smart enough to know the CAN ID for a Tesla Model 3 brake, so you don't have to look all that up

Funnily enough, I based my hardware on OpenInverter ported to STM32F405 Micromod, so together with your STM32F413 VCU port, looks like we've been on somewhat parallel paths!

Would love to discuss further with you and /or @modellfan, or maybe we need a new category for this sort of discussion on the forum?

modellfan wrote: ↑Mon Jan 12, 2026 10:48 pm Absolute impressive what you did. I will give it a try as soon as possible. Just read 1,5h through your repository and the others. Amazing style of coding and also how you use ai. For me so many things to learn. I fear most of openinverter Forum members will have a hard time to understand what you are doing. Do you think you can generate a software architecture diagram ? This will help to understand the structure behind so many clustered files.

I also have a quite big backlog of ideas for the interface. Might I share it with you? As soon as I got a full understanding I am happy to contribute.

Also your other repositories are quite impressive. Do you mind to make a post about your ECU ? From my point of few this has high potential of becoming next gen open inverter framework. This would solve so many topics the big monolithic ZombieVCU code has. I would love to discuss with you on this.

Yeah, I'll plan on making a video soon that goes over architecture + contributing to the project for both this + the ECU experiments I've been doing. Feel free to DM me about some of the ideas you have - happy to discuss 'em!

jetpax wrote: ↑Wed Jan 14, 2026 6:54 pm Hi @outlandnish,

This is beautiful work, so much so I had to use your ideas in my own re-imagining of the use of the ESP32!

But I ended up with a very different architecture, based on a few observations:

1. There are many other projects related to OpenInverter that expose a configuration interface for an ESP32 CAN based system (GVRET, OVMS, Dana's Battery Emulator etc)
2. The end user will ALWAYS want to change slightly the way the system works for their own implementation, and so run-time behaviour modification through scripting is essential (eg Dynamlabs (proprietary) with Lua )
3. The ESP32 is a very capable device that should not get a free ride in the overall design, ie sitting doing nothing once the initial config is done
4. We should be able to easily port this to other mid-end processors such as ESP32-P4 or RP2350
5. The connected client (PC, tablet etc) has enormous horsepower and storage compared to our devices, so run _and serve_ the UI on the client
6. The client MUST be OS agnostic
7. The system MUST work without internet connectivity, ie isolated LAN
8. All client<>device communications MUST be secured by TLS
9. Its 2026, Agents MUST be able to help write the scripts
10. The Agents will make mistakes (not us of course) so the script engine SHOULD have a visual debugger

Funnily enough, I based my hardware on OpenInverter ported to STM32F405 Micromod, so together with your STM32F413 VCU port, looks like we've been on somewhat parallel paths!

Would love to discuss further with you and /or @modellfan, or maybe we need a new category for this sort of discussion on the forum?

Hey, thanks and glad to have inspired some of your UI re-design! A couple of notes:

• This work allows the client to be OS agnostic too. You can run the web app on any platform including mobile and it just works
• This app is served over local WiFi - either with a pre-configured WiFi network or as an access point

I think what you're building is a much better all around solution for modifying your car and am excited to try it myself. When I built this work out, I wanted to limit my scope as much as I could to just improving the user experience.

Happy to chat about where this can go! And yes, I think a different place in the forum would be appropriate.

outlandnish wrote: ↑Thu Jan 15, 2026 2:12 pm Yeah, I'll plan on making a video soon that goes over architecture + contributing to the project for both this + the ECU experiments I've been doing. Feel free to DM me about some of the ideas you have - happy to discuss 'em!

Perfect, thank you. I am waiting for it. Instead of DM, I post it here for a public discussion. Some are the points are already ticked by you:

Improvement Ideas & Proposals

Overview
This post captures proposed improvements for the ESP32 web interface firmware and UI.
Ideas are grouped by architecture, performance, and extra functionality, with a short proposal for each.

1) Architecture & Structure

1.1 Interchangeable CAN / UART Interface Abstraction

Idea:
Create a clear, interchangeable interface for CAN bus communication so that CAN, UART, or other transports can be swapped without changing business logic.

Proposal:

• Define a small, stable transport interface with send, receive, and subscribe functions
• Implement separate CAN and UART transport implementations
• Ensure higher-level logic depends only on the interface, not the concrete transport

Benefits:

• Portability to other chips and transports
• Clear separation between transport and logic
• Easier testing and simulation

1.2 SDO as a Communication Layer Class (Multi-Instance)

Idea:
The SDO should act as a communication layer that receives data from a transport and provides parameter access. It should support multiple node IDs.

Proposal:

• Refactor SDO into an instantiable class
• Pass the transport interface and node ID during creation
• Allow multiple instances to run concurrently
• Expose get, set, and subscribe APIs per instance

Benefits:

• Supports multiple nodes without global state
• Simplifies testing and future expansion

2) Performance

2.1 Selective Polling of Values

Idea:
Allow users to choose which values are polled to avoid hitting the maximum parameter limit.

Proposal:

• Add UI and configuration options to select pollable parameters
• Only poll the selected subset at runtime

Benefits:

• Reduced bus load and CPU usage
• Better scalability with many parameters

2.2 Skip Polling for CAN-Mapped Values

Idea:
Avoid polling values that are already mapped to CAN and available directly from the bus.

Proposal:

• Rely on CAN bus updates instead of polling for mapped values

Benefits:

• Avoids redundant traffic
• More responsive real-time values

2.3 One-Time Parameter Polling on Startup

Idea:
Some parameters are static and only need to be read once.

Proposal:

• Fetch these parameters during startup and cache them

Benefits:

• Lower ongoing bus usage
• Faster main runtime loop

3) Extra Functionality

3.1 Node 0 System Values Visualization

Idea:
Expose device and system values as parameters under node 0.

Proposal:

• Create a virtual node with ID 0
• Expose system metrics such as signal strength, free memory, and uptime

Benefits:

• Unified view for internal and external values
• Easy expansion for GPS or time sources later

3.2 Dynamic Values with User-Defined CAN Mappings

Idea:
Allow users to define their own CAN-mapped values and labels to visualize OEM messages not implemented in firmware.

Proposal:

• Provide a configurable list of dynamic value slots
• Each slot defines CAN ID, signal or bitfield, scale, and display label
• Show these values like normal parameters in the UI

Benefits:

• Extensible for unknown or custom OEM messages
• Enables fast prototyping without firmware changes

3.3 MQTT Configuration Page

Idea:
Add a configuration page to control MQTT publishing and subscribing, enabling integration with external applications such as MyOpenInverter.

Proposal:

• UI to define which values are published
• Configurable publish rates per value
• Define which values can be written via MQTT
• Configure buffering and offline queue limits
• Persist configuration in firmware storage

Benefits:

• Clear and user-controlled MQTT data flow

Did you even build and test the Canlite environment?

Debug Env was not able to compile because of an sdk .h file missing . Changing the flash method fixed it. Then no Wi-Fi in AP mode visible. Changed to release mode. Was not compilable . Had to change the configs in platform.ini . Now I get watchdog resets direct after start.

modellfan wrote: ↑Mon Mar 09, 2026 7:11 am Did you even build and test the Canlite environment?

Debug Env was not able to compile because of an sdk .h file missing . Changing the flash method fixed it. Then no Wi-Fi in AP mode visible. Changed to release mode. Was not compilable . Had to change the configs in platform.ini . Now I get watchdog resets direct after start.

No, I haven't built / tested that environment yet. I just added it to PlatformIO for further development since that's the official OpenInverter device. I've been using a Canipulator which is ESP32-C6 based instead of the XTENSA based ESP32-Sx boards like the can-lite. There's probably a host of issues like the ones you found. I haven't been able to work on it lately, but I'll revisit and address that. Or happy to take contributions from you if you'd already debugging it

I put already some time into it and have some more changes to be uploaded: https://github.com/Modellfan/esp32-web- ... ll-changes

To be honest I like the way of multitasking and separation with queues. But the code is really hard to read for a human. The abstraction levels between CAN , SDO and the device representation are not really well defined from my perspective and code that belongs together is separated across multiple files. Maybe a result of Claude ?

From my point of view it’s the perfect idea , to bring the webinterface to the next level. But I am now reconsidering going back to the original version. Spending more time on it would need imho some cleanup first and I am not sure you are open for this ?
What do you think?

Yeah, I'm going to take a new pass at it. It might be re-writing it, I'm not sure. It's functional but yeah, poor on legibility for contribution because of Claude. I'll see, I haven't had too much time lately, but I'm hoping to dig back into it soon to figure that out.

I think once you opt for code generation you have to stick to the path. We used to work with Simulink code generation and the output was unreadable and not meant to be edited.

So either Claude all the way or traditional coding with the usual techniques for readability perhaps with Claude output as a starting point

What I've found works well in my day job of seeing up the code principles ahead of time manually and having a good set of rules in Claude.md to provide in repeatable rules in its context for how to interact with your codebase. I want to do another pass having learned from this one to see if I can do that a bit better.

johu wrote: ↑Mon Mar 23, 2026 5:21 am I think once you opt for code generation you have to stick to the path. We used to work with Simulink code generation and the output was unreadable and not meant to be edited.

So either Claude all the way or traditional coding with the usual techniques for readability perhaps with Claude output as a starting point

I need to disagree with you on this point. That is exactly the difference for me between vibe coding and classical Simulink style code generation. For my projects I supervise quit close the architecture and function to file distribution and then use vibe coding for the implementation. That used to give me much better results. And you can control also the naming to make it more reasonable. Eg in your code the in and out queue for can task have completely different names.

I can also do an proposal of how I would structure the code if you like.