openinverter forum

Currently, configuration of OpenInverter VCUs is often done via the web interface or the PC-based openinverter_can_tool. That tool already supports reading/writing CANopen parameters (SDOs), logging, and firmware updates — but it requires a laptop and a USB CAN adapter.

I’d like to propose building an Android app that brings these capabilities to phones, tablets, or Android head units. The goal is to manage VCUs directly in the vehicle, without extra hardware beyond:
• USB CAN adapters using slcan
• Bluetooth (ELM327-style) devices

Key functions could include:
• Listing and editing parameters
• Logging selected signals to CSV
• Firmware flashing over CAN

The big decision is whether to use native Android (Java/Kotlin) or Flutter:
• Native: Stronger integration with USB and Bluetooth APIs, more direct control for CAN communications.
• Flutter: Easier UI work and potential cross-platform reuse, but would require native plugins for CAN/Bluetooth access. Also runnable on iOS.

I’d be able to take on most of the programming, but I’d like feedback from the community — particularly on whether native or Flutter would be the more practical base for this project.

Personally i prefer the idea of serving a webapp from the esp32, because the presence of an esp32 also allows for run time scripting which solves the enduser customization problem (ie no recompile for each project)

eg look at MPY-jama for a javascript app that can be served by the esp32 and that allows editing, loading and running scripts on esp32


but i like your BTcan idea too, theres probably room for both…

I understand the approach of scripting to make small flexible changes accessible to everyone. Coming from automotive Software Development this feels wrong. Especially for safety and performance reasons. An autosar like approach wouldn’t do something like zombi Vcu with a lot of options on runtime but rather put it in an configuration that triggers macros on compile time. But this differences of Sw architecture is not really what I am proposing with my post.

I looking more into a native implementation of a vehicle menu on my android head unit. Having it not as webinterface will improve performance and allow functionality like logging on the device and uploading to cloud or database.