Android App: Faster connection after opening the App

[Chriner]

After the bot response and some more testing, I changed the content of this issue a bit. Please go directly to the new comment:
#287 (comment)

Is your feature request related to a problem? Please describe.
I started to use evcc end of July 2026. And I'm checking the evcc app several times a day (might decrease in future, but it is still new and interesting). End of July/beginning of August, after starting the app, the evcc showed the results very quick (max 1 second?). It was much faster than the Sungrow iSolarCloud App, therefore I mostly used evcc App.

But with the last updates of evcc or the Android App (don't know which change introduced this problem), starting the connection takes much longer as before, around 4 seconds. It also takes longer time when I check the app after around 1 hour. After opening it again a few minutes later, it directly shows the evcc page. So looks like the connection is lost and in the past it was not lost?

I read something in the changelog, that this should be improved. But for me the opposite happens. I'm using a reverse proxy with Caddy and basic_auth. So was this accidentally made slower for reverse proxy with the last updates? And it improved for other connection types?

So perhaps it is designed like that to have a trade off between slower connections with reverse proxies and perhaps faster connection with Remote Access?

Describe the solution you'd like
Have faster loading of the evcc page after app start.

Describe alternatives you've considered
In case this happened with an update of the Android app, it could be possible to use the older App version?

Additional context
Android App in same WiFi --> Caddy reverse proxy with basic_auth --> evcc running in docker
evcc and docker are in same docker network on the same machine.

[github-actions]

Thanks for the detailed report. This is hard to pin down without more concrete data — a few things would help narrow it down:

• Which evcc version were you on when it was fast, and which version are you on now? (Check Top right menu → About.) A "few seconds slower after an update" report only becomes actionable with a before/after version pair.
• Android app version for both the fast and slow experience — the evcc backend and the Android app are separate projects with separate release cycles, so it matters which one changed.
• A browser network trace of the slow load, taken directly against the Caddy URL (e.g. Chrome DevTools → Network tab, reload, and look at the timing breakdown of the first request/the websocket upgrade — DNS, TLS, TTFB, and any 401 challenge round-trip stand out). That tells us whether the delay is in the basic-auth challenge, TLS/proxy handshake, or the evcc API/websocket itself.
• Does the same slowdown happen when you hit evcc directly (bypassing Caddy, e.g. via its local IP:port) on the same network? That isolates whether Caddy/basic_auth is involved at all.

I looked through server/socket.go (the websocket hub that pushes state to the UI) and didn't find any change that would introduce an idle-timeout/reconnect delay or an auth-dependent slowdown — nor any recent commit in the reverse-proxy/auth code path that matches the "faster for Remote Access, slower for reverse proxy" trade-off you suspect. Without version numbers or a network trace I can't confirm a specific commit, so I'd rather not guess at a root cause.

🤖 Generated with Claude Code

[Chriner]

evcc versions:

• Started with evcc (there it was fast): 0.312.0 or 0.313.0
• Actual used version: 0.315.2

Android app versions:

• Started with evcc (there it was fast): 1.4.0 or 1.4.1
• Actual used version: 1.5.0

Browser network trace:
The problem is only with the evcc Android app. With browser there is no delay at all. A reload refreshes the page < 1 second.
is a network trace possible with the Android app?

evcc directly:
Another server added to the App with direct access without Caddy reverse proxy. I have to check in the next time how this behaves.

If I remeber right in 1 or even 2 of the last updates of evcc or the App there was something in the release notes regarding faster app connection. But somehow I don't find it really.
What I found for app v1.5.0:
New loading animation, faster server switching, instant feedback for unreachable servers in #269
But that sounds positive, but pheraps has side effect?

[github-actions]

Thanks for narrowing this down — the extra data points to this being an Android app issue, not the evcc backend/server.

Key evidence: with the same Caddy + basic-auth setup, a browser reload is consistently < 1s, while only the Android app shows the ~4s delay. That rules out the reverse-proxy/basic-auth path and the evcc server itself (server/socket.go and the websocket/API code haven't had any change between 0.312.0 and 0.315.2 that would explain a reconnect or auth-dependent delay — checked via git log 0.312.0..0.315.2 -- server/).

Looking at the evcc Android app source (evcc-io/app, screens/MainScreen.tsx), the loading/reconnect behavior is fully client-side:

• A setInterval reloads the WebView (bumps webViewKey) every 5s while isConnected is false.
• The loading overlay has a 2s "show delay" before it appears (to avoid flicker on brief outages) and a 500ms "hide delay".

evcc-io/app#269 (merged 2026-08-30, shipped in app 1.5.0) reworked this loading/reconnect logic ("New loading animation, improved server switch"). That lines up with your report of the slowdown starting around the same time as the app update to 1.5.0, and would also explain why it only affects the app and not the browser.

Since the app is a separate codebase, I can't confirm or fix this from the evcc-io/evcc repo. Could you open this in evcc-io/app instead, with the details you already gathered (versions, direct-access-vs-Caddy comparison)? That's where the loading/reconnect logic actually lives.

🤖 Generated with Claude Code

[Chriner]

I wanted to do some testing before opening a new issue for the app. But the issue is already shifted. With the bot responses and some additional testing I have several new information and would like to change the direction of this issue a bit (I also changed the headline).

Describe the solution you'd like
When starting the evcc Android App, I would like to see the results faster. I think technically it could be possible to see the results without any delay (details below).

Technical background:
Results after some tests with an evcc instance behind a Caddy reverse proxy with basic_auth:
Windows PC with browser:

• When clicking on an open tab, it directly refreshes to the new value << 0.5 second
• When opening a new tab, it directly shows the evcc page with new value << 0.5 second

Android smartphone with Chrome browser:

• When clicking on an open tab, it directly refreshes to the new value << 0.5 second
• When opening a new tab, it directly shows the evcc page with new value << 0.5 second
• When opening chrome from a shortcut at the start page, it directly shows the evcc page with new value << 0.5 second

Android smartphone with native evcc App

• When opening the app a few seconds after it was minimized, it directly refreshes to the new value << 0.5 second
• When opening the app a several minutes after it was minimized, loading of the evcc page takes much longer ~ 4 seconds

Can the App be changed, that it directly shows the evcc page. Perhaps remove a detection timeout? Directly load the page? Perhaps with a configuration to switch between different behavior?

Describe alternatives you've considered
For me it looks like the Chrome shortcut from the start page works very good. I will test it the next days. Hopefully the login will not be asked (this happens if Chrome is actively closed).