Three fixes, all driven by reporter investigations that went well past "it's broken."
RGBIC segment counts corrected for the H7075 and H7076
Both wall lights advertise 15 segments over the cloud API. The H7075 has 3 physical sections; the H7076 responds on 4 indices. Everything above that was accepted with HTTP 200 "success" and did nothing, leaving phantom segment entities stuck on whatever colour the optimistic state last set.
GoveeDevice.segment_count now clamps the API count against fields[].size.max — an automatic safety net for any SKU that over-reports the same way — and applies an explicit SKU_SEGMENT_OVERRIDES entry as the authoritative value for known SKUs. govee.set_segment_color also rejects out-of-range indices instead of dispatching a command the cloud would refuse.
The H7076 needed the explicit entry because it reports size.max: 15 as well, so the two fields agree and the clamp has nothing to catch.
Migration: phantom entities already in your registry stay as orphans — the fix only prevents new ones. One-time cleanup: Settings → Devices & Services → Entities, filter by _segment_, delete the out-of-range rows.
Thanks to @andreuSignes, who diagnosed the elementRange / size.max split and verified the fix end-to-end on four live H7075 units (#161), and to @Eschwinm, whose index-by-index testing on the H7076 established which four indices actually do anything (#160).
Note on the H7076: capping at 4 removes the phantom entities but does not unlock the finer control the Govee app has. The app reaches 17 segments per side over BLE; the cloud segmentedColorRgb capability collapses that to 4 indices, and no integration change recovers it while the cloud is the only channel.
Gateway-bridged thermometers now read their temperature from the hub's own push
An H5310 behind an H5044 could sit at unknown indefinitely. Govee leaves deviceExt.lastDeviceData empty for the sub-device on some accounts, and the Developer API lists nothing for it either — so there was no reading source at all.
The hub was pushing the value the whole time, as ee34 multiSync frames the decoder discarded: 0xEE 0x34 was handled only as a leak/dry report. Byte 3 turns out to be the sub-device class (0x02 leak, 0x08 thermometer), and it is the only byte separating them. Thermometer frames are now decoded and applied; everything else still takes the leak path, so no leak SKU can be silenced by the change.
This also removes a latent bug: thermo frames were falling through the leak branch and emitting a spurious dry-event for whatever leak sensor shared their slot on the hub.
Thanks to @Araknus13 (#151), who decoded the temperature encoding by pairing 30 on-the-hour frames against their own logged cloud history — 24.4–29.5 °C over 31 hours — establishing T[°C] = (byte13 + 112) / 10 to 0.1 K across every point, and confirming bytes 9–12 as a big-endian Unix timestamp within 3 seconds of receive time. Two candidate formulas from an earlier single-point capture were both wrong by 19–38 K; they had looked identical because they intersect exactly where that one reading sat.
Manual LAN device overrides for segmented networks
LAN control could not reach devices on a separate VLAN, for two different reasons. Scan correlation needs the device's reply, which is multicast and never crosses the boundary. And some firmware accepts LAN writes but never answers a devStatus read at all, even from its own subnet — so the write-health gate could never pass.
lan_targets now also accepts:
device_id=ip— bind a device straight to an IP, skipping discovery. Normal read/write/health treatment after that.device_id=ip!— additionally mark it write-only: skip the read-health gate and the write-confirm readback, and exclude it from the read poll so it is never demoted back out.
Use the ! form only when a device genuinely never answers reads. It disables every LAN health check for that device, which means a wrong IP will look like it is working while the device never responds. A mistyped IP or device ID is now rejected in the options form rather than saving silently and doing nothing.
Thanks to @chrisns (#164, #165), who separated the two failure modes with an A/B test across subnets — proving the same command works from the device's own VLAN and is silently ignored from another — and verified the fix on real hardware.
Worth trying if cloud colour commands are ignored on your device (#149, #158): if Govee's cloud accepts a colour write with "success" and your light does nothing, and the device is on a different subnet from Home Assistant, a device_id=ip override may get LAN control working where discovery could not. The device ID is in the device's diagnostics download.
Full Changelog: v2026.8.2...v2026.8.3