Skip to content

[General] Add better timeout and error handling#121

Open
tchapi wants to merge 3 commits intogduteil:mainfrom
tchapi:tchapi/error-handling
Open

[General] Add better timeout and error handling#121
tchapi wants to merge 3 commits intogduteil:mainfrom
tchapi:tchapi/error-handling

Conversation

@tchapi
Copy link
Copy Markdown
Contributor

@tchapi tchapi commented Mar 28, 2026

Hello @gduteil 👋🏼

While using the integration in my HA installation (I have a Calypso boiler), I noticed that it was sometimes "losing" the connection, and then the data was not showing anymore (and I couldn't use the actions too). When reloading the integration, it was working again.

I identified a few things that I think could make the integration more robust.

No request timeouts

async with self._session.get(...) has no timeout.

If the Atlantic API hangs (given the quality of their app and ecosystem, ... I'd say it could happen 😅 — but it can also be due to network conditions on the wifi the boiler is), _async_update_data never returns. Since DataUpdateCoordinator runs updates sequentially, the next scheduled poll never starts. The integration freezes silently, data goes stale, HA shows no error.

Network errors don't trigger reconnects

The try/except ContentTypeError is inside the async with response block. Any error that happens before the response body is read — aiohttp.ClientConnectorError, asyncio.TimeoutError, ServerDisconnectedError — is outside the try and propagates up. DataUpdateCoordinator catches it and logs it, but self.online stays True. So the next poll goes down the if self.online: branch again instead of calling connect(). It never re-authenticates.

401 / token expiry has no proactive handling

There's no expires_in tracking and no HTTP status check. Token expiry only self-heals if the API returns a non-list JSON body (triggering self.online = False). If the session degrades silently, it never recovers.

Setting away mode as "pending"

The Atlantic API seems to respond better to setting the away mode as ON rather than PENDING (in CozytouchAwayModeSwitch)

I've tried to fix these four things in the PR here. Hopefully it helps everyone using this integration to have a more robust integration!

I've tested the modified file on my installation for 2 days, no problem so far (and no disconnects + better away mode handling).

Note

I've used Claude to analyze the possible errors and get best practices, but the code is mostly mine.

Comment on lines -263 to -266
headers = {
"Authorization": f"Bearer {self._access_token}",
"Content-Type": "application/json",
}
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please review with hide whitespace: on for clarity (most differences are indentation ones)

self._config_uniq_id = config_uniq_id
self._last_value: str | None = None
self._device_uniq_id = config_uniq_id
self._attr_name = name
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing attr set, while it is used below in the log (making the integration crash)

await self.coordinator.set_away_mode_timestamps(
self._capability["capabilityId"],
self._value_pending,
self._value_on,
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Setting value as pending was actually not setting the away mode to On all the time

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant