Classic API session expiry — how widespread, and how to detect it?

[johanzander]

Background

This issue is specific to the Classic API (GrowattApi). The V1 API (OpenApiV1) uses token-based authentication and does not have this problem.

GrowattApi uses server-side session cookies. At some point after login, the server may invalidate those cookies. The observable symptoms are unclear to me — callers may get an HTML login page instead of JSON (causing json.JSONDecodeError), an HTTP redirect (the existing allow_redirects=False on plant_list suggests this was known to happen), or some other signal depending on the endpoint.

The HA integration calls login() unconditionally before every coordinator refresh (every 5 minutes). It is not clear whether this was intentional API design (treating each session as single-use) or added defensively at some point. A contributor found that this still wasn't sufficient in some cases and submitted a targeted fix in johanzander/growatt_server_upstream#13 — catching JSONDecodeError and re-authenticating on the fly — which was confirmed working on a real Growatt MIC 3000TL-X.

This design also creates a practical problem for HA integration development: since login() is called unconditionally before every data fetch, adding a new coordinator (e.g. for a new device type or data endpoint) increases the login call rate proportionally. That makes it hard to extend the integration without risk of hitting server-side rate limits or account blocking, even if the coordinator only polls slowly.

---

Questions for @indykoning and the community

1. Is session expiry common, and under what conditions?
The workaround in PR #13 was confirmed on one real device, but I don't know how common the underlying problem is. Is this something you've seen reported before, or is it a rare edge case triggered by specific conditions (extended inactivity, certain server regions, account types)?

2. What does session expiry actually look like on the wire?
From what I can tell, the server returns HTTP 200 with Content-Type: text/html (the login page) when the session has expired. Are there other signals — e.g. HTTP 302 redirect to a login URL, a specific JSON error body, or a particular HTTP status code? The fact that plant_list uses allow_redirects=False suggests redirects may also occur on some endpoints.

3. Is JSONDecodeError the right detection signal?
Catching JSONDecodeError as a session-expiry indicator works, but it also catches genuine malformed responses. Is there a more precise signal available, or is JSONDecodeError + retry the accepted pattern?

---

Potential library-level fix

If the problem is real and reproducible, the cleanest solution would be to handle re-auth transparently inside the library rather than requiring every caller to implement a JSONDecodeError → re-login → retry loop themselves.

Concretely: login() stores credentials on the instance, and internal request helpers detect the HTML-response signal and re-authenticate + retry once automatically. This would mean callers only ever need to call login() once at startup.

Sketch of the approach:

class GrowattApi:
    def login(self, username, password):
        self._username = username  # store for re-auth
        self._password = password
        response = self.session.post(...)
        ...

    def _get(self, url, **kwargs):
        response = self.session.get(url, **kwargs)
        if self._is_session_expired(response):
            self.login(self._username, self._password)
            # Check again: if still expired after re-login (bad credentials,
            # server blocking), raise explicitly rather than returning a
            # bad response that will cause a cryptic JSONDecodeError upstream.
            if self._is_session_expired(response):
                raise GrowattApiError("Re-authentication failed")
        return response

    def _is_session_expired(self, response):
        # Exact condition TBD — this is the key question
        content_type = response.headers.get("Content-Type", "")
        return "text/html" in content_type

Happy to draft a PR if @indykoning or anyone else confirms the detection approach is correct and the fix is wanted.