Repository navigation
enable API usage with local webUI - basic version attached #339
Description
Since owning my go-eCharger I regret, that I can only control it trough additional software or via the Internet.
A nice employee from the go-e phone support mentioned to me in 2023, before buying my go-eCharger, that you consider including a webUI. It was a major argument to buy a go-eCharger for me.
EVCC and HA are nice options, but I use my go-eCharger mostly on the road, so there's no well suited place to run such a server software. So I started developing a HTML+JS webUI, which uses the API documented by go-e to control the go-eCharger. You may find it here:
https://codeberg.org/kolAflash/go-eCharger-webui/src/branch/pages/go-eCharger-webUI.html
It's a single HTML file which I offer as OpenSource (MIT licensed). I propose to ship this file with the go-eCharger firmware. So when a user opens http://CHARGER_IP/ in the web browser he doesn't get a disappointing Nothing matches the given URI message.
=> Please consider including this HTML file in the go-e firmware.
Or with which improvements (design?) would you consider including it in the Firmware?
No server side logic is needed. The HTML file simply needs to be put on the ESP32 Firmware web server.
Additionally I suggest, that you (go-e) may extend this webUI with your internal APIs for enabling the open APIv2 solely trough the webUI. So the Android / iOS app isn't needed from the start on.
Reasons
I like hardware to be fully functional in itself. The Android / iOS app puts strong dependencies on a lot of things like smartphone operating systems and Google / Apple appstore availability. And I prefer using my Debian-Linux notebook over using my phone. (if I use Android, then usually without GoogleServices / GooglePlay installed)
I don't do this out of a mood. These are decisions helping to enable long term use of hardware - notebooks, ev chargers, ... - helping to improve sustainability and by that also save hardware costs. When buying hardware I hope to be able to use it for 10 or 20 years. But I don't know if my phone in 20 years will still be capable to run the then probably quite old go-eCharger Android app.
I also don't like to connect things to the Internet when there's no strict need. It only complicates IT security and data protection. Connecting devices to the local network is fully sufficient for most scenarios.
Also other smart home vendors like Warp-Charger, Shelly or DeLock (Tasmota) ship local webUI interfaces with their firmware. Similar to the webUI on your home wireless router (e.g. "FritzBox"). All you should need to control these devices is a web browser (Firefox, Chrome or any of the others) and by that it's fully independent from third party vendors like Smarphone vendors, app store operators (Google, Apple) and even from the cloud servers of the manufacturer.
Activity
chk2902 commentedon Jul 13, 2026
I agree with you. Some sort of simple setup would be nice. Personally, I have go-e chargers since 2018, though I never missed a web page setup. And it's not as simple as "htpp://" as the access point IP you encounter at first is in a .24 range that you need to select first in the smartphone, so you need a smartphone anyway (a Notebook would work too, but I guess that's a rare case) to let it into your (W)LAN.
And it's also not as simple as "just add the web page into the firmware" as you need to add a local web server with some advanced scripting to the firmware, and keep it up to date (also the security issues). I don't know about the chargers, but I guess firmware space is limited - maybe less in the new versions, at least I hope so - so you need to drop some other code. IIRC, Fronius left out HTTP API, maybe for space reasons to add some control software for their purposes.
And there's even more to support, they already have HTTPv1, HTTPv2, Modbus, Websocket interfaces. Developers are not cheap and not that many.
Additionally, nowadays the chargers do have that many options, a web page space is very inconvenient as you are really limited on clients other than tablets or PC/notebooks. At least for advanced use. More and more companies convert their apps to a WebViewer hosting the web page for the same purpose, but I can't disagree more, as for me as a user this often comes with UI limitations and space waste. But I'm in IT, so this view might be limited.
kolAflash commentedon Jul 13, 2026
Give this a second thought.
The go-eCharger firmware has the local HTTP API - the API which this repo is documenting. So there is already a web server in the go-e firmware.
And the beauty of this webUI is, that from the perspective of the web server it's just a static HTML file. The web server only needs to send it to the web browser. No server side scripting is needed (no php/nodejs/rails/...).
All the logic is happening in the browser client. And it's using only the already existing HTTP API. So from the IT security perspective this webUI is extremely secure.
chk2902 commentedon Jul 14, 2026
OK, yes, I was thinking of running scripts on the server. Just sending HTTP pages without anything running on the server is something else, and I stand corrected.
chk2902 commentedon Jul 14, 2026
And some "initial setup" to get the wallbox into the Wi-fi of the local network via bluetooth (just like Shelly is doing it) would make it much easier... maybe they do, but I went the old-school way manually switching to the charger's access point when installing my CORE (a much better construction and better looking hardware than the older go-eChargers) ;)