Improve iaqualink 429 handling

[flz]

Breaking change

Proposed change

Improve handling of 429 ratelimited requests. Don't mark the integration as unavailable, simply log the temporary error.

Please merge in release branch for the next patch release.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Deprecation (breaking change to happen in the future)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes iAqualink is repeatedly going unavailable #152517
• This PR is related to issue:
• Link to documentation pull request:
• Link to developer documentation pull request:
• Link to frontend pull request:

Checklist

• I understand the code I am submitting and can explain how it works.
• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• I have followed the perfect PR recommendations
• The code has been formatted using Ruff (ruff format homeassistant tests)
• Tests have been added to verify that the new code works.
• Any generated code has been carefully reviewed for correctness and compliance with project standards.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies a diff between library versions and ideally a link to the changelog/release notes is added to the PR description.

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[Copilot]

Pull request overview

This PR adjusts the iAquaLink integration’s coordinator update behavior to handle HTTP 429/rate-limiting more gracefully by backing off polling while keeping entities available.

Changes:

• Add throttling (429) handling in the iAquaLink DataUpdateCoordinator by applying an exponential backoff multiplier and resetting the interval once updates succeed again.
• Avoid marking the coordinator/entities unavailable on throttling by treating 429 as a temporary condition.
• Add a regression test to ensure entities retain their last known state and the update interval is increased/reset appropriately.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
homeassistant/components/iaqualink/coordinator.py	Implements throttling-specific backoff behavior and interval reset logic in the coordinator update loop.
tests/components/iaqualink/test_init.py	Adds test coverage for rate-limited updates keeping entities available and validating backoff interval changes.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

[joostlek]

Do you know when to retry later? You can use UpdateFailed and it's methods to postpone the next update

[flz]

Not really. I'm assuming it will simply retry at the next update_interval.

Right now the library handles 429 but I'm actually thinking of yanking the handling and put it on the client-side because it doesn't really make sense to have two layers doing retries (and I need to do it on the HA-side anyway).

[zweckj]

But isn’t the integration technically unavailable when you hit the rate limit? Like, while it’s rate limiting I would assume you also are unable to trigger any actions?

[erwindouna]

Normally when a rate limit occurs this is the case. The retry_after also renders the integration as unavailable during that that time.
It's not a fully fledge backoff strategy with multiple retries, before rendering the integration in a retry state.

[flz]

@zweckj Potentially, that depends how the ratelimiting is done. I suspect the read path and the write path have different ratelimits but it hasn't been confirmed (and I can't test it myself since I don't have the hardware).

I saw habitica was doing something similar (stale data when getting ratelimited) so I figured there was a precedent.

[MartinHjelmare]

Normally, I'd say that raising UpdateFailed from the coordinator update is the thing to do, but since we think that writing is still ok, I think this fix is ok for now. Would be good to investigate this further with affected users though.