Govee BLE H5074 sensors — sporadic updates after 2026.6 (ESPHome proxies forced to passive, no UI override available)

Hardware
1

HA version: 2026.6.1 Integration: govee_ble Hardware: 8× Govee H5074 temperature/humidity sensors, 3× ESPHome Everything Presence Lite acting as Bluetooth proxies, HA running on Mac Mini (not HAOS)

Symptom

Since upgrading to 2026.6, all 8 H5074 sensors have dropped from updating approximately every 60 seconds to sporadic updates every 5–15 minutes, with long gaps of no data at all.

The pattern is clearly tied to the upgrade — sensor history shows dense continuous data up until the moment of upgrade, then sparse isolated data points afterwards. Upgrading to 2026.6.1 reduced the gaps slightly but did not resolve the issue.

Root cause (as I understand it)

2026.6 changed Bluetooth proxy scanning to Auto (passive) by default, only switching to active scanning when an integration specifically requests it.

The Govee H5074 requires active scanning to report reliably. In passive mode the proxy just listens and only occasionally triggers the active poll the H5074 needs, producing the sporadic update pattern I'm seeing.

I can see in the 2026.6 changelog that #172051 added logic to trigger an active scan when Govee devices are picked in the config flow, and #173116 was intended to fix advertisement processing for active scans. However the issue persists on 2026.6.1.

What I've tried

  1. Checked the Bluetooth adapter settings UI — the EPL proxies show no gear/cogwheel icon in Settings → Devices & Services → Bluetooth. There is no option to change scanner mode for ESPHome proxies through the UI in 2026.6.
  2. Added active: true to EPL YAML:

yaml

esp32_ble_tracker:
  scan_parameters:
    active: true

HA 2026.6 remotely overrides this and forces passive mode on ESPHome proxies regardless of local YAML config.

  1. Deleted and re-added the Govee Bluetooth integration — this triggers the active scan in the config flow per #172051, which partially helps short-term, but the effect doesn't persist reliably.

Related thread

There's an older thread here covering a similar issue on 2025.5.1 with H5075 sensors: Latest update broke Govee H5075 sensors. The fix described there was unchecking a passive mode checkbox on the Bluetooth adapter — that option doesn't exist for ESPHome proxies in 2026.6, which is what makes this harder to work around. Both H5074 and H5075 appear to have the same active scanning requirement.

What I'd expect

Either:

  • ESPHome proxies should respect local YAML active: true and not have it overridden remotely by HA, or
  • The Govee integration should maintain a persistent active scan request for devices known to require it (H5074, H5075), not just trigger it once at setup time

Tagging @bdraco as the author of #172051 and #173116 — you likely have the most context here. Is this a known remaining issue post-2026.6.1, or is there a workaround I've missed?

Happy to provide logs, diagnostics, or test any proposed fix.

2

For esp bluetooth scanning I had same issue. This setting is under ESPhome instead of bluetooth

image_2026-06-09_231547253
image_2026-06-09_2315472531798×1285 103 KB

Fixed it for me to force it to active. At first I did not find the setting as documentation only mentioned Bluetooth component.

3

Hey @Dennis87 that's it!!!

Yea the documentation is incorrect, like you found it is in the ESP32 intigration, was driving me crazy as the cog was just not there in the Bluetooth settings.

Thank you mate :oncoming_fist:t2:

4

Ahhh, thanks for posting about this! I had the same roll-off in temp ingest from 5074 sensors as well when updating HA to 2026.6.3 today. Even with a 30 sec active scan window as HA sends a wave of active scans across the ESPHome proxies, I had a few 90+ min windows of no data.

5

I stand corrected, I'm mostly seeing 10 sec active scans on my boards that roll across the network of ESPHomes and come back to a given board every 5 min, but I think the H5074s advertise every 20 sec or so. The active scan timing also doesn't have much drift forwards or backwards in time, so I think my blackout windows are when the Govee sensor's advertisement lands in a passive-only window from multiple boards (and that window tends to be stable)

edit: some quick analysis numbers with help from a script:

  • Normal pattern: active for ~10 seconds every ~5 minutes
  • Median start-to-start gap: ~300s
  • Average active window: 9.85s
  • Total captured span: 12:48:29 to 20:30:44, about 7.7 hours
  • Complete active windows: 93
  • Total active time: ~15.3 minutes
  • Effective active-scan duty cycle: ~3.3%

scan time relative to board startup: mostly phase-locked to a 5-minute cadence, with occasional step changes.

Using active-start time modulo 5 minutes:

  • Early phase: around xx:x8:29 / xx:x3:29, then it settles toward +3:10
  • Midday stable phase: mostly +3:09 to +3:10
  • After the ~20 min gap at 16:53 -> 17:13, it shifts earlier to about +3:02
  • Evening stable phase: mostly +3:02

So if you have a device with a decent clock and your advertisement interval is modulo 10 seconds, you might always advertise when no ESPs are listening.

7

How did you manage to get this working? I’ve been trying to get my Govee present sensor to show up and it won’t discover it every time. I set it to active it just says that there’s no devices found on the network.

8

I have same problem with H5127, so far I have gotten a whole new sensor, a new ESP Home board configured as BLE Proxy, but nothing works. Govee app detects presence and absence just fine, HA sees nothing

9

if anyone facing similar issues, I fixed it by modifying a system file

1. Enter the Home Assistant container shell

docker exec -it homeassistant bash

2. Change directly to the govee_ble library directory

cd /usr/local/lib/python3.14/site-packages/govee_ble/

3. Force line 164 from True (sleepy mode) to False (active scan mode)

sed -i '164s/True/False/' parser.py

4. Remove the broken name validation restriction from line 344

sed -i '344s/ and "H5127" in local_name//' parser.py

5. Verify your two changes are in place

grep -n "H5127" parser.py

6. Exit the container shell back to your host machine

exit

7. Restart the Home Assistant container to reload the patched driver

docker restart homeassistant

10

@priyo1 can you share some more info about how you discovered that, and what behavior changes you see?

11

@cbowns this took me quite a while and a lot of help from Gemini.
June 11 my govee presence sensor stopped working. I initially thought it was the BLE chip on my old LT that dies, since the Govee app was tracking everything fine. so i got a ESPHome and flashed it as BLE proxy

I also got a new govee sensor ( needed it anyway)

none of those new gizmos worked, so finally found that HA forces the BLE to be passive even if you set it to active in the GUI.

So I went down the rabbit hole to figure out if the actual integration (Govee bluetooth) is reading it as passive vs active. thats where I saw, even after the GUi change in HA, the actual parser.py has Sleep mode = true

the above resulted in app working just fine, but HA never gets the change in the binary sensor. changing it to False solves this problem. All my automations are back working and i also verified the state changes in the entity under dev tools

I am aware another HA update would break it, I am thinking about scripting this down the road or just manually changing it when that happens. depends on how often I have to do this.

Edit to add: I had to remove the goveen sensor and add it back again before everything worked

12

@priyo1 I was able to get my 5074s to ingest reliably with one nearby board manually set to Active scan under /config/integrations/integration/esphome. (I also just got some 5100s to test and have been much happier so far, they transmit temp as part of their passive advertisement and the batteries are cheaper to maintain, so I think they're a double win overall.)