Bug Fix: Deterministic client_id for Govee Account Login
Fixes login failures reported in #28 by users whose accounts require strict client_id validation.
What was broken
Previously, the integration generated a random UUID for client_id in 4 places:
- Login request
- IoT key fetch (ignored the login's client_id)
- Device topics fetch (ignored the login's client_id)
- Startup re-login (new random UUID each HA restart)
This meant a single login session sent 3-4 different client_ids, and every HA restart sent yet another. Govee caches (email, client_id) pairs after first login -- seeing a different one on subsequent calls triggered 2FA hardening or outright rejection on newer accounts.
What's fixed
The client_id is now derived deterministically from your email using uuid5(NAMESPACE_DNS, \"hacs-govee:{email}\"). The same email always produces the same client_id, and that same ID is used across:
- Login
- 2FA verification code request
- IoT key fetch
- Device topics fetch
- AWS IoT MQTT connection
This matches the pattern used by all other working Govee integrations (homebridge-govee, wez/govee2mqtt, TheOneOgre/govee-cloud).
For API-key-only users
The warning message for users who don't need real-time MQTT updates has been improved. If you see the 2FA warning and don't want MQTT, use Reconfigure to remove email and password -- the API key alone is sufficient for polling.
Testing
13 new tests covering deterministic derivation and propagation. Total: 548 tests passing.
If you're still experiencing issues after upgrading
Some users may be temporarily rate-limited by Govee (~30 logins/day). Wait 24 hours after upgrading before declaring failure. If it still doesn't work, open a new issue with debug logs.
References
Research document: docs/_research/2026-04-06_client-id-fix-validation.md