deCONZ authentication breaks after restart – API key matches zll.db but integration still fails

Configuration Zigbee
1

Hi everyone,
I’m facing a strange authentication issue with the deCONZ add‑on that only started a few days ago. Until then, everything had been running perfectly for a long time.

Since this week, after every Home Assistant or deCONZ restart, the integration loses access to the deCONZ API and throws an authentication error. What I’ve checked so far:

  • The integration was removed and re‑added multiple times
  • A new API key was created successfully
  • The API key stored in Home Assistant matches the key inside zll.db
  • Phoscon works normally and all devices are visible
  • No configuration changes were made before the issue started

Despite all this, Home Assistant refuses to authenticate after a reboot and asks me to reconfigure the integration again. It looks like deCONZ is no longer accepting the stored key on startup, or something internally resets the authentication state.

Has anyone experienced this recently?
Could this be related to a recent update, database issue, or startup timing problem?

Any ideas or hints would be greatly appreciated.

2

image
image624×131 6.7 KB

Checked API keys in zll.db against the Hassio Add-on; the key was not found in the database.

3

Seen a near-identical shape on a deCONZ + HA container setup. Three things I’d check before touching zll.db again:

  1. Container start order. If HA starts before deCONZ finishes binding to the Conbee/RaspBee, the integration caches a failed handshake and won’t auto-retry. Try depends_on / healthcheck on the deCONZ service and restart HA after deCONZ is healthy.
  2. API key vs. client hash mismatch. deCONZ stores the auth record keyed by the HA client’s hostname/IP. If HA’s container hostname or assigned IP changed on restart (Docker network regeneration), the key in zll.db is correct but deCONZ won’t match it to the new caller. Inspect /api/config/whitelist and compare devicename to what HA presents now.
  3. Expired session, not expired key. Some deCONZ builds expire the session token bound to the key after a hard restart; re-authorizing from the HA integration UI (not re-adding) often resolves it without a key rotation.

If the container-hostname theory checks out, the broader pattern is that credential-bound integrations on HA break whenever the caller identity drifts. We’re working on a small open-source credential proxy that sits between HA and upstream APIs and keeps the handshake identity stable across restarts — happy to DM the writeup if you want to poke at it after you’ve unblocked deCONZ itself.