Repository navigation
startSession always fails on load due to tokenCreated defaulting to datetime.min #123
Description
Summary
The Hive integration fails to initialise on every HA startup and first setup due to two related bugs. The integration shows "Initialising" indefinitely before failing with HiveRefreshTokenExpired.
Bug 1 — tokenCreated defaults to datetime.min when loading stored tokens
When startSession loads tokens from the HA config entry it calls:
await self.updateTokens(config["tokens"], False)With update_expiry_time=False, tokenCreated is never set and stays at datetime.min (0001-01-01). The expiry check then always evaluates as expired:
Current : 2026-05-04 19:30:37
Expiry : 0001-01-01 00:54:00 ← always in the past
This happens even when tokens were issued seconds earlier during the config flow.
Bug 2 — force_refresh=True after _retryLogin hangs indefinitely
After the fallback login succeeds and fresh tokens are obtained, _retryLogin immediately calls:
await self.hiveRefreshTokens(force_refresh=True)Attempting a Cognito token refresh on a brand new refresh token either:
- Hangs until boto3 timeout (~5 minutes in v1.0.8)
- Fails with
HiveRefreshTokenExpiredcausing setup cancellation
There is no reason to force refresh tokens that were just issued.
Observed log sequence
tokenCreated: 0001-01-01 00:00:00 | tokenExpiry: 1:00:00
Session token expiry time (Current: 2026-05-04 19:30:37 | Expiry: 0001-01-01 00:54:00)
WARNING: Refresh token is invalid or expired.
WARNING: Session Token refresh failed (HiveRefreshTokenExpired), falling back to login.
... login succeeds, fresh tokens obtained ...
tokenCreated: 2026-05-04 19:30:37
[hangs here on force_refresh=True]
ERROR: Setup of config entry cancelled
Impact
Affects all users on first setup or after any HA restart.
| Version | Behaviour |
|---|---|
| 1.0.8 | Falls back to _retryDeviceLogin → hangs ~5 min → fails |
| 1.0.9 | Falls back to _retryLogin → login succeeds → hangs on force refresh |
Fix
Option 1 (recommended): Remove the redundant force refresh after a successful login
# _retryLogin — remove this line, tokens from fresh login are already valid
await self.hiveRefreshTokens(force_refresh=True)Option 2: Store tokenCreated in the config entry so tokens survive HA restarts without appearing immediately expired
Environment
pyhive-integration1.0.8 and 1.0.9- Home Assistant (all recent versions)
- Python 3.14
Activity
markybry commentedon Jun 12, 2026
@KJonline and @Rendili Any progress on this it seems to be a pretty serious bug.
maxwell-01 commentedon Jun 24, 2026
bump please
matt-thepie commentedon Oct 20, 2026
Reproduced this today against a real account on both branches, simulating an HA restart that reloads a JSON-serialised config entry (stored
tokensplusdevice_data).On
master(1.0.9, what HA installs): both bugs are still present.startSessionloads tokens withupdateTokens(config["tokens"], False)sotokenCreatedstays atdatetime.min(src/session.py:77,:836), and_retryLoginstill callshiveRefreshTokens(force_refresh=True)after a successful login (src/session.py:483).On
dev(2.0.0 betas): both are addressed._retry_loginno longer forces a refresh after logging in.token_createdstill defaults to the epoch when loading stored tokens, so the first expiry check fires, but the refresh succeeds and no fallback login happens.devalso implements option 2 from the report:get_device_data()returns a fourth value,token_created, andstart_sessionparses it (including the ISO string it becomes after an HA restart) and uses it as the real issue time.Live result on
dev, 8 climate zones, no SMS prompt:device_data(2.0 config flow)device_data(legacy 1.0.9 entry)One gap remained:
device_login()never recordedtoken_created, so after a device login (every reauth) the fourth value wasNoneand the epoch default was used anyway. #175 fixes that; with it applied the 4-value shape starts with the correct expiry and does no startup refresh at all.So this is fixed on
devand only needs a release. Until 2.0.0 ships, HA users stay on 1.0.9 and will keep hitting this. Note that 1.0.9 is also broken by today's Hive login page change (#169 / #170), so a 1.0.10 frommastercarrying #170 plus a backport of the_retryLoginforce-refresh removal would fix both for HA with a one-line manifest bump.