A large release: encrypted BLE for newer SKUs, independent control of the Ceiling Light Pro's two zones, a fourth segment mode, Spanish and Catalan, a new diagnostic sensor, and a temperature fix.
Most of this came from contributors with the hardware in front of them.
Encrypted BLE transport for newer SKUs
Newer Govee models silently discard the plaintext BLE frames this integration sends — no error, no reply, nothing. They accept the same frames wrapped in AES-GCM after a session handshake, so this adds only that transport wrapper; every command encoding is unchanged.
Devices are probed for their protocol version rather than allowlisted, decided from the service cache with no extra I/O, so plaintext devices are unaffected.
It deliberately fails closed. BLE writes here are response=False, meaning a plaintext frame sent to an encrypted device raises nothing at all — left to fail open, the integration would record a transport success, skip the LAN/MQTT/cloud fallback, and show you a command that never reached the device. A failed probe or handshake now drops the connection instead.
Also fixed alongside it: BLE enrolment only ran from advertisement callbacks, which are refused while the connectable scanner count is zero. Bluetooth proxies register their scanners after this integration sets up, so every restart left BLE devices cloud-only until someone reloaded the config entry by hand.
By @chrisns (#172), field-tested on an H1270 through an ESPHome proxy. Two details from that work worth recording: the GCM tag is 16 bytes where public write-ups say 12 (with 12 the device accepts the write and ignores it, indistinguishable from a wrong key), and the H1270 needs the segmented colour encoding — it discards the single-zone frame.
Ceiling Light Pro: the main panel is independently switchable
On the H1270 the obvious capabilities cannot separate the downlight from the RGBIC ring. mainLightToggle and backgroundLightToggle report success and do nothing, and powerSwitch is whole-fixture — it kills the ring too, and leaves the firmware waking the panel on any later command. That last part is the "segments turn the main light on" coupling reported in #131; it is a powerSwitch artefact rather than device behaviour.
The two zones sit on different channels: the ring on segmentedColorRgb, the panel on the whole-device colour channel. So the panel is now switched with RGB(0,0,0) — dark panel, powerSwitch still on, ring free to light from its own channel. Since a main-channel write clobbers the ring, the ring's colours are replayed immediately afterwards.
Gated to the H1270, the only SKU verified on hardware. Owners of an H1250 or H60A6: see #131, where confirming three behaviours would let it extend to yours.
By @chrisns (#166). Two honest caveats from the author: switching the panel on briefly flashes the ring before the replay darkens it, and the guard against a concurrent power-off is best-effort rather than a closed race.
A "both" segment mode
Segment mode was exclusive — a device got either the grouped "all segments" light or the individual per-segment lights. both runs them together.
The non-obvious part: Govee never reports real per-segment state, so both entity types are purely optimistic and nothing reconciles them. Without extra wiring a light.turn_off on the group would leave every individual entity still showing "on". By @chrisns (#167).
Spanish and Catalan
Full es and ca translations — 153 strings each, in neutral registers, with protocol terms and SKU names left in English as Home Assistant's own locale files do. By @andreuSignes (#162).
Connection mode diagnostic sensor
A per-device sensor reporting which transport is actually delivering state right now: ble, lan, mqtt, cloud_api or unavailable — one glanceable value instead of digging through per-transport attributes.
It requires a transport to have actually delivered state, not merely to report itself available. MQTT marks itself available on broker connect even for devices that never push anything, so the weaker test would have named a transport the device isn't using. By @andreuSignes (#163).
Kettle temperature no longer converted twice
An H7170 in a 77 °F room reported 170.6 °F — exactly (77 x 9/5) + 32, a Fahrenheit value converted as though it were Celsius.
The device declares its unit in the same API response, but we only read that hint from the instance name heaters use. The kettle carries the identical shape under sliderTemperature, so the hint was dropped and the reading fell through to a SKU allowlist that doesn't list the H7170.
The unit is now taken from any temperature setting that declares one, whatever the instance is called — no allowlist entry needed. A device stating its own unit now also overrides an allowlist guess in the other direction, which is the case that matters more for correctness.
Reported with a complete diagnosis by @jcv (#171), who identified both the cause and the fix.
Also
- Fixed: a data-only config-entry write (such as storing a refreshed account token) triggered a full integration reload — tearing down every entity and dropping the MQTT connection. The update listener now reloads only when options actually change.
- Repository: the default branch is now
main. Existing clones keep working through GitHub's redirect;git remote set-head origin -aupdates yours.
Upgrading
No action needed. If you have an H1270 and previously had "Main light" or "Background light" switches, those two are removed — they never did anything — and replaced by a working Main light entity plus the segment entities for the ring. Any automation referencing the old switches needs updating, and the old registry rows can be deleted from Settings → Devices & Services → Entities.
Full Changelog: v2026.8.4...v2026.8.5