lasswellt/govee-homeassistant v2026.10.1 on GitHub

New

H7175 gooseneck kettle gets full support: a water heater, brew modes, status sensors, an on-base sensor, a button-press event, and optional slot labels. The kettle previously only had a power switch. It now gets a water_heater entity with target temperature and power; a Brew mode select with the kettle's own custom/green-tea/oolong-tea/coffee/black-tea-boil/manual modes (choosing a mode switches the kettle on in it; setting a target selects Manual); status sensors for heating state, keep-warm and keep-warm time remaining, and the active DIY slot; a binary sensor for whether the kettle is on its base; a button-press event fired by the kettle's own button; and, in the integration's options, optional display labels for the four custom slots (the API only ever calls them "Custom 1-4"). The integration now also re-reads the kettle shortly after a command and keeps polling it while it's heating, so Home Assistant catches up with it promptly instead of waiting on the next regular poll. Other kettle models (H717A, H7170) are unchanged. Thanks @StevenC4 for this whole series (#228).
New action govee.request_status for pulling fresh device status on demand. Some devices, including the H7175 kettle above, only push an update when asked — watching one closely from an automation meant opening the Govee app to make it talk. This new action asks a device for its status once, or repeatedly on an interval (at least every 3 seconds) for up to 120 seconds. It works for any device with an AWS IoT connection, not just kettles, goes out over MQTT only, and spends none of the daily cloud request budget. Thanks @StevenC4 (#228).
H1252 Ceiling Light Pro gets its own Ring light and Main light entities, including color temperature. Building on the H1232 ptReal support added in v2026.10.0, the H1252 can now switch its main panel and its RGBIC ring independently — on/off, color, color temperature (2700-6500 K) and brightness — written over the device's native command channel, since the regular toggle commands are accepted by Govee but silently do nothing on this model. Both zone lights are optimistic (the device doesn't report their color/brightness back) and are restored after a restart. Verified on real hardware and contributed as a working patch by @holger-dunst (#223).
New optional "Confirm light commands and resend dropped ones" setting. Govee's cloud can answer a light command with success and never deliver it to the device, with no error and no visible sign other than the light just not changing. This off-by-default option checks a light's own status report after a command and, if it still shows the old value, asks for one status update and resends the command once over the cloud. It only applies to lights, never to power-on, groups or appliances. New diagnostics counters (confirmed, resent, unconfirmed, skipped, superseded) and a README section explain what it costs and what it doesn't touch. Based on a proposal and design from @BrawnyBravo (#245).
AWS IoT sessions that go completely silent are now detected and recovered. A session can report itself connected for hours while delivering nothing at all. The integration now notices when 30 minutes have passed with status queries going out and nothing coming back, and reconnects once; if the new session is just as silent, it raises a repair asking you to reconfigure the integration (a fresh login issues new AWS IoT credentials), which clears on the next real message.
Account-data thermometers (e.g. H5179) gain "Last measurement" and "Reported online" diagnostic sensors. These sensors ignore the flapping cloud online flag for their main availability, and "Last changed" in Home Assistant only stamps when a value changes, so a reading that stopped updating months ago could still look current. The new sensors show the device's own timestamp for its last reading and the account's own online flag separately, so a stale sensor is easier to spot (#258).

Fixes

H7175 kettle's water temperature no longer goes stale while it's heating. The kettle's pushed updates weren't being decoded at all, yet still counted as a fresh reading, so Home Assistant skipped the cloud poll that would have supplied a new temperature and the reading froze. Thanks @StevenC4 (#228).
Devices stay available as long as any transport can still reach them. Previously, every entity hard-gated on Govee's cloud "online" flag, which can lag for minutes or get stuck false for a device that answers fine over LAN, BLE or AWS IoT — on a cloud-only install this could take 40+ entities unavailable at once even though the same API response carried valid state. A device now also counts as available when it has a healthy LAN/BLE connection or has pushed an AWS IoT message within the last 10 minutes; a total cloud outage still correctly takes down cloud-only entities. Sending a command to a device that really is offline now shows a clear "device is offline" message instead of a generic failure (#242).
H5111 temperature/humidity sensors behind an H5151 gateway no longer show Unknown. Behind this particular gateway, the regular Developer API poll reports the H5111 offline with an empty reading, while the account's own data has it. The H5111 now reads from that account data, the same way the H5179 and H5112 already do (#236).
H5054 leak sensor with an all-digit device ID is no longer mistaken for a group and dropped. Any device ID made entirely of digits was treated as a group ID, so a real H5054 whose 18-character ID happened to contain no letters lost its leak, battery and connectivity entities. Only short numeric IDs (11 digits or fewer, matching how real group IDs look) are now treated as groups. Diagnosed by @verreaul (#243).
H5108 thermo-hygrometer no longer causes ~35 minutes of MQTT reconnect churn after every restart. Like the H5075/H5074, this model is listed on the account with an AWS IoT topic it never actually answers; querying it directly closed the whole MQTT session. It's now permanently excluded from the periodic status sweep, same as those other models — its readings still arrive fine through the regular cloud poll. On accounts with several of these, this churn was also blocking H5086 plug power readings, which only arrive over MQTT, for the whole outage (#237).
The status sweep now recognizes when AWS IoT is refusing status queries for an entire account, not just one device, and stops itself instead of quarantining every device one at a time. Previously this situation worked through every device on the account, two session drops each, with the reconnect backing off further each time. It's now detected after three different device models are blamed for a drop in a row, and the sweep pauses until the integration reloads, logging one message that explains it and how to disable the automatic status re-query entirely (set its interval to 0) if you'd rather avoid it altogether.
H5086 smart plug energy sensor no longer double-counts after the plug reboots. The plug resets its energy counter on reboot and restores a saved copy about a minute later; the energy sensor used to read the drop-then-restore as a meter reset and counted the restored value a second time. It now tracks resets explicitly and recognizes a reboot-and-restore instead of double-counting it. A once-a-day reading the plug sends in reply to the Govee app's own status query (not ours), which carries a bogus, much smaller counter value, is now ignored as well. A corrupted restored entry with an invalid timestamp is now discarded instead of breaking every subsequent update. Thanks @snoack (#247, part of #200). If you have an existing H5086 energy sensor: after updating, the day's accumulated energy may be counted once more on the first update, since this changes how the sensor tracks resets; you can correct it under Developer Tools → Statistics if needed.
H8057's fourth RGBIC segment can be set again. Writing a color to this segment through the regular API was rejected by Govee with an error, even though it works fine from the Govee app; it's now routed over the device's native AWS IoT command channel instead, and a failure now shows a translated error message rather than raw text. Verified on real hardware by the contributor. Thanks @EasyBizz (#248).
Leak sensor no longer gets stuck reporting "wet" after a reload that happens shortly after it actually dried. A safety fallback forces a leak sensor wet when Govee's cloud shows a recent leak that wasn't seen over MQTT, so real leaks aren't missed if a push is lost. The record of when MQTT last saw a sensor dry didn't survive an integration reload, so a sensor that tripped and dried, followed by a reload within five minutes, could be forced back to "wet" and stay that way until its next frame — which these sensors only send on a state change. That record is now kept across reloads and restarts. This hasn't been verified against real leak-sensor hardware — if you own an H5054 or similar leak sensor, please update and let us know on the issue if you still see a leak sensor latch wet unexpectedly after a reload. Thanks @BrawnyBravo (#257).
Heater target temperature and auto-stop no longer corrupt themselves across restarts. On Fahrenheit-display installs, the restored target was read back in the wrong unit, so 68°F could come back as 68°C (shown as 154°F) and get worse on every restart; it's now restored in the device's native unit and converted correctly. Separately, a target changed on the heater itself or in the Govee app could get silently overwritten by the old Home Assistant value on the next poll, and changing the target or the auto-stop switch could reset the other one back to a default — both are fixed, so each only overwrites the other with a default when nothing else is known. Thanks @BrawnyBravo (#253).
Rate-limit handling and cloud request budget fixes. A 429 ("too many requests") response from Govee no longer clears its own slow-down in the same cycle it was created, and the slow-down can no longer speed polling up past an interval that was already stretched out to pace the daily budget. Control commands (not state reads) are now sent to Govee once instead of being silently retried up to three times by the underlying HTTP client, which could leave a service call hanging for about 90 seconds and spend three times the request quota on one command. The count of requests spent today now survives a reload or restart instead of resetting to zero, so a large install that reloads mid-day can no longer run past Govee's daily cap. A device missing its MQTT topic no longer triggers repeated account-wide lookups on every command. An account with groups, H5054 water sensors or account-data thermometers now correctly shows a full cloud outage instead of masking it (#226). Thanks @BrawnyBravo (#250).
Several options, diagnostics and state-handling fixes. Saving the integration's options no longer drops other devices' saved segment grouping; two Govee accounts no longer share a single diagnostics device (each now gets its own, keeping any area and name you'd already set); a command or MQTT push that arrives while another device is still being polled is no longer discarded, which had been causing lights to briefly snap back to their old state; a diagnostics download no longer includes unhashed device IDs or your own device/leak-sensor names; the Refresh Scenes button (and any scene request) no longer gets stuck replaying stale results after an earlier request was cancelled mid-fetch; and leftover segment entities from a device whose segment count has since been lowered are now cleaned up only when that lower count can be trusted. Thanks @BrawnyBravo (#255).
Compatibility with Home Assistant 2026.10. Home Assistant 2026.10 deprecates the device-registry lookup and the per-device config-entry list the integration relied on; it now uses the newer per-entry lookup instead, so diagnostics device migration and kettle slot-label options keep working going forward. Reported by holger-dunst.