[Bug]: Not compatible with Home Assistant Core 2026.8.0 #6

Activity

1. Sergey842248

   added

   bugSomething isn't workingSomething isn't working

   on Jul 31, 2026
2. github-actions commented on Jul 31, 2026

   

   github-actionsbot

   on Jul 31, 2026 – with GitHub Actions

   More actions

   AI Analysis

   Type: issue
   Title: [Bug]: Not compatible with Home Assistant Core 2026.8.0
   Author: @Sergey842248

   This issue requires review. Please check the full description for details.

   ---

   This summary was automatically generated by AI to help with triage and may not be 100% accurate.
3. actuallychris commented on Aug 10, 2026

   

   actuallychris

   on Aug 10, 2026

   Last edited by actuallychris

   Contributor

   More actions

   I can confirm and reproduce this. As far as I can tell, it is related to the aiobottocore changing to bottocore's versioning scheme. Here's an overview generated by Claude (which I validated as correct)

   Root cause: This isn't a Home Assistant compatibility problem — it's a stale version ceiling in manifest.json.

   aiobotocore changed its versioning scheme to track botocore's release cadence more closely, and hasn't published a 2.x release compatible with current botocore since making that switch — it jumped straight to 3.0.0+ instead. The manifest currently pins:

   "requirements": ["aiobotocore>=2.6.0,<3.0.0"]

   That <3.0.0 ceiling excludes every aiobotocore version that's actually resolvable against the botocore version HA 2026.8 pulls in, which is why the resolver reports the requirement as unsatisfiable (the wall of dependency-resolution text in the log is uv's error output — noisy, but it boils down to "no version in the allowed range works").

   Suggested fix: bump the ceiling to aiobotocore>=2.6.0,<4.0.0. I checked the integration's usage of the library (AioSession() / session.create_client(...) in init.py and config_flow.py) — that API is unchanged across the 2.x→3.x boundary, so this should be a safe, drop-in bump rather than a breaking change.

   As a workaround until a release goes out, editing requirements in the installed copy's manifest.json to aiobotocore>=2.6.0,<4.0.0 and restarting HA unblocks setup immediately.

   After testing with this configuration, I was able to confirm that this fixed the issue at hand.

   👍React with 👍4Reacted by Roman Dmytrenko, Florian D., Sylvain and doonga
4. karlspace

   closed this as completedin #7on Aug 23, 2026
5. karlspace commented on Aug 23, 2026

   

   karlspace

   on Aug 23, 2026

   Contributor

   More actions

   Hi @Sergey842248 — thanks a lot for the report. The exact log excerpt plus the precise HA version made this quick to track down.

   And a big thank you to @actuallychris for the diagnosis and the PR — your analysis was spot on, and the workaround you posted helped everyone who hit this in the meantime. 🙏

   This is now fixed on main via #7.

   Root cause

   Your diagnosis was right, and digging into HA Core made it a bit more specific: the trigger sits in Home Assistant Core itself.

   HA Core 2026.8.0 raised its own bundled dependency from aiobotocore==2.21.1 (still the case in 2026.7.x) to aiobotocore==3.7.0, and at the same time introduced a hard pin of botocore==1.42.97 in homeassistant/package_constraints.txt. The comment there states this is deliberate — both are pinned together so that a runtime requirement install cannot pull in a botocore version incompatible with aiobotocore.

   Our manifest asked for aiobotocore>=2.6.0,<3.0.0. The provided 3.7.0 no longer satisfied that ceiling, so HA tried to install a matching 2.x instead — which is unsatisfiable against that botocore pin, since aiobotocore's last 2.x release (2.26.0, Nov 2025) requires an older botocore. The wall of resolver output in your log is uv reporting exactly that.

   That also explains why 2026.7.x and earlier were unaffected.

   Fix

   The ceiling is now aiobotocore>=2.6.0,<4.0.0. The version HA provides satisfies the requirement directly, so no install attempt is triggered at all. The >=2.6.0 lower bound stays, so older HA versions keep working.

   No code changes were needed. We checked both breaking changes in the 3.x line against this integration:

   • 3.0.0 forbids creating loose ClientSession objects after an AioBaseClient leaves its context — we enter the client explicitly via __aenter__(), close it via __aexit__(), and never use it afterwards.
   • 3.8.0 changed AioStreamingBody.__aenter__ to return self instead of the raw aiohttp ClientResponse — we only ever call read() and iter_chunks() on the response body, never use it as a context manager.

   So <4.0.0 is safe across the whole 3.x range, not just against the currently pinned 3.7.0.

   Release

   Version 0.2.3 is prepared in the manifest and CHANGELOG; the tagged release will follow shortly, after which HACS will offer the update. Until then, @actuallychris's workaround (editing requirements in the installed copy's manifest.json and restarting HA) remains valid.

   Closing this as fixed — please don't hesitate to reopen if anything still misbehaves after updating.
6. Sergey842248 commented on Aug 24, 2026

   

   Sergey842248

   on Aug 24, 2026

   Author

   More actions

   Thank you!