Add async support using httpx

[johanzander]

Summary

• Replaces requests with httpx for both sync and async HTTP support
• Adds async counterparts: AsyncGrowattApi, AsyncOpenApiV1, AsyncMin, AsyncSph
• Uses a coroutine-passthrough pattern where base class methods share ~60 methods with zero duplication — only 6 methods need explicit async overrides
• Async classes accept an optional session (httpx.AsyncClient) for session sharing (e.g. Home Assistant integrations)

Trade-offs to discuss

This is a draft PR for discussion — see #149 for the broader conversation.

Breaking change: Replaces requests with httpx, so consumers catching requests.exceptions.RequestException need to switch to httpx.HTTPError.

Complexity: The coroutine-passthrough pattern avoids code duplication but adds architectural complexity (shared base classes, MRO-dependent dispatch). An alternative approach is to duplicate sync files into async copies (how large SDKs like openai do it), potentially with auto-generation — but that brings its own maintenance trade-offs.

Key questions:

1. Is the requests → httpx breaking change acceptable, or should we keep requests for sync and only use httpx for async?
2. Is the coroutine-passthrough pattern too clever, or is the duplication reduction worth it?
3. Would a code-generation approach (sync → async transformation) be preferable?

Test plan

• Verify sync usage works identically to before (minus requests exception types)
• Verify async usage with asyncio.run() and async with context manager
• Verify session sharing with externally-provided httpx.AsyncClient
• Run existing examples against test API token

🤖 Generated with Claude Code

[indykoning]

If the switch to httpx.HTTPError is the only breaking part of this transition (excluding the requirement) i'm fine with that.
So long as we make sure we tag it as a major update, which we should anyways due to the dependency change. And document a migration path from requests.exceptions.RequestException to httpx.HTTPError in the release notes we'd be fine.

The changes look good so far, less overhaul needed than i expected.

---

Only thing i'm concerned about is, how do we ensure feature parity between sync and async in future PRs?
So we don't end up in a situation where a feature only exists in the async version because somebody added it there.

Perhaps (for a future PR) we need to look into testing the package in both sync and async mode with Github actions so any change will get tested for sync and async functionality.
We won't be able to use the Growatt API itself so we'll probably need to set up fake data.

[johanzander]

Good points! The feature parity concern is actually one of the main reasons I lean toward the shared-base approach in this PR over the duplicated-files approach in #151.

With the coroutine-passthrough pattern here, ~60 methods live in the shared base class and work for both sync and async automatically. A future contributor adding a new API method just adds it to the base — both modes get it for free. Only the handful of HTTP-touching methods (6 currently) need explicit async overrides. With duplicated files, every new method would need to be added in two places, which is exactly the drift scenario you're worried about.

I also considered auto-generating async from sync (like unasync does), but for this codebase it would add build tooling complexity without much benefit since the shared-base pattern already solves the parity problem.

Regarding the breaking change — the main concern is that Home Assistant (and potentially other consumers) currently catch requests.RequestException directly. Rather than forcing everyone to switch to httpx.HTTPError overnight, I think we should introduce library-owned exceptions (e.g. GrowattApiError) and have the library catch transport errors internally and re-raise them as our own types. That way consumers depend on the library's API, not its transport layer.

For the transition we could do a deprecation period: have the library exceptions inherit from both the new GrowattApiError and the old requests.RequestException, and log a deprecation warning when they're caught via the old type. That gives consumers time to migrate from requests.RequestException → GrowattApiError before we drop the requests dependency entirely in a later major release.

For testing, I agree we should set up mocked HTTP responses and run the same test suite against both sync and async classes. Happy to put that together in a follow-up PR.