fix: add 2FA login support for Govee accounts#656
Conversation
Govee now mandates 2FA on undocumented API logins, returning status 454. Changes: - Upgrade login endpoint from /v1/login to /v2/login - Bump APP_VERSION to 7.4.10 and User-Agent to match current iOS app - Add GOVEE_2FA_CODE env var / --govee-2fa-code CLI arg for passing the verification code - On 454: automatically request verification code via /v1/verification, then bail with actionable error message - On 455: bail with clear message about incorrect/expired code - Reduce login negative_ttl from 15 minutes to 10 seconds so 2FA errors don't cache-poison the entire code validity window Tested against live Govee account with 2FA enabled. Verified all existing devices (lights, thermometers, air quality monitors) reconnect after providing the code. Fixes wez#647 Relates to wez#649, wez#628, wez#627, wez#626
|
Hi, I'd like to help test this. How can I install it? |
I found this other guys fork that you can just punch in as the repo https://github.com/jastan1971/govee2mqtt |
|
Well, install Wez's branch or this fork, try it, and you will see in your logs that you get an http error 454; which is the challenge from Govee on the API. Once you are sure that your API token, username and password are correct and still getting the errror, apply my fix and test it. It should let you authenticate and all is good, no error. |
|
I tried this fix but it's spamming govee 2fa code in my mails. It does work tho. once I run the docker I need to stop right after to avoid mail spam and remove the docker than edit .env and start the docker back. but yeah this 2fa fix works, it just need a little fix for the mails spamming! |
…uirks API resilience - undoc_api: env/CLI-overridable Govee Home app version (--govee-app-version / GOVEE_APP_VERSION) with helpful error when Govee raises the minimum. Recovers without a new release when login returns "app version is too low". Covers issues wez#622, wez#626, wez#627, wez#628, wez#637, wez#647, wez#649. - undoc_api: Govee 2FA login support (status 454/455). Auto-requests an email code on first failure; user supplies it via --govee-2fa-code / GOVEE_2FA_CODE and restarts. Closes wez#656/wez#652. - iot: refresh transaction IDs on every publish (Govee dedupes on transaction; reusing one silently drops the publish). Likely fixes wez#635 Tap-to-Run drops. - hass: client id uses '-' instead of '/' so Mosquitto 7 doesn't reject it as a "dangerous client id". Closes wez#659/wez#661. New entities - fan.rs: HA MQTT Fan entity backed by the existing workMode/percent machinery. Power, speed-percentage (FanSpeed mode), and preset modes all wired up. - sensor.rs: DeviceSettingDiagnostic exposes battery % and Wi-Fi level from the undoc DeviceSettings struct. Wi-Fi has no device_class (Govee reports 0-100% but HA's signal_strength expects dBm). Covers wez#646/wez#668. - sensor.rs: carbonDioxideConcentration, pm25, pm10 mappings with correct units, device classes, state classes, and friendly names. Promoted air- quality measurements to primary entities (not diagnostic). - enumerator.rs: route fan-type devices through Fan entity; auto-add battery and Wi-Fi diagnostics where reported. Effect filtering - light.rs / device_config: per-device `allowed_effects` overrides the global GOVEE_ALLOWED_EFFECTS env var. Useful to keep Google Home SYNC payloads under the size limit without losing scene control inside HA. Closes wez#613. - light.rs: skip empty `supported_color_modes` in MQTT light discovery so brightness-only bulbs (H6093) don't fail HA validation. Closes wez#589. Quirks (device coverage) - AirQualityMonitor device type + helpers; H5140 (CO2 monitor) and H5106 (BLE-only AQM) classified correctly instead of falling to "Other". Closes wez#634, wez#561. - LAN-capable: H616D outdoor strip, H6039 wall sconce, H61E5 strip pro. - Color-temp clamps: H6076 (2700-6500K) and H61E5 (2700-6500K) — API reports 2000-9000K which is wrong. Closes wez#591, partial wez#567. - IoT routing: H6006 bulbs now use IoT instead of rate-limited Platform API (10-15s delays before this). Closes wez#621. - BLE-only classified (controllable when BLE path lands): H6125_321A, H6125_5321, H5129 motion sensor, H5181-H5185/H5198 meat thermometers. Closes wez#569, wez#580, wez#630. Addon - addon/config.yaml + run.sh: surface govee_app_version and govee_2fa_code options; redact 2FA code from env dump. - addon/translations/en.yaml: matching strings.
|
This PR has been out there for a month but is there a path to getting it officially merged? I'm not sure the normal cycle for this repo. |
Summary
Govee now mandates 2FA on undocumented API logins, returning status 454 and breaking all govee2mqtt installations. This PR adds complete 2FA support so users can authenticate again.
Fixes #647. Relates to #649, #628, #627, #626.
Changes (single file:
src/undoc_api.rs)/v1/login→/v2/loginAPP_VERSIONto7.4.10, update User-AgentGOVEE_2FA_CODEenv var +--govee-2fa-codeCLI arg/v1/verification, bail with actionable messagenegative_ttlfrom 15 min → 10 secHow it works
GOVEE_2FA_CODE): login hits 454 → automatically calls/v1/verificationto email the code → logs actionable error and exitsGOVEE_2FA_CODE=<code>and restartsDifference from PR #652
PR #652 detects the 454 but does not include the
GOVEE_2FA_CODEmechanism to actually pass the code — it explicitly defers that to a follow-up PR. This PR is the complete flow: detection, automatic code request, code passing, and error handling, in a single focused change (1 file, 89 insertions).Test plan