Same Xiaomi BLE thermometers: smooth graphs via ESPHome local decoding, stepped graphs via Shelly BT proxy + Xiaomi BLE integration — why?

Hi all,

I have six Xiaomi BLE thermometers around the house, all on stock firmware: 5× LYWSDCGQ (the round one, unencrypted MiBeacon) and 1× LYWSD03MMC (encrypted, using its bindkey).

Setup 1 (years old, works great): two ESP32 nodes running ESPHome with esp32_ble_tracker: and per-device local decoding — xiaomi_lywsdcgq / xiaomi_lywsd03mmc sensor platforms, no filters configured. The decoded values reach HA as native ESPHome entities. Note these nodes are not Bluetooth proxies — there is no bluetooth_proxy: component in their config. Example:

esp32_ble_tracker:

sensor:
  - platform: xiaomi_lywsdcgq
    mac_address: XX:XX:XX:XX:XX:XX
    temperature:
      name: "MJ Salon Temp"
    humidity:
      name: "MJ Salon Humidity"
    battery_level:
      name: "MJ Salon Battery"

Setup 2 (new): I recently added some Shelly devices. HA automatically started using them as Bluetooth proxies, and the same thermometers were auto-discovered by the Xiaomi BLE integration with zero configuration. Nice!

The issue: for the same physical device, the ESPHome entity draws a smooth, fluid temperature curve, while the Xiaomi BLE entity (fed through the Shelly proxies) draws a clearly stepped/staircase graph.

Since both paths are decoding the same MiBeacon advertisements (so the payload resolution — 0.1 °C — is identical), my working theory is that the difference is update cadence, not resolution:

  • ESPHome’s esp32_ble_tracker scans continuously and pushes every decoded advertisement to HA, so I get lots of closely-spaced data points.
  • The Shelly BLE gateway reportedly forwards a given device’s advertisement at most every ~3 s, bundles advertisements, and some users report gaps of over a minute — so far fewer points reach the Xiaomi BLE integration, and the 0.1 °C jumps become visible steps.

My questions:

  1. Is this analysis correct, or is there something else in the Xiaomi BLE / Bluetooth integration (throttling, deduplication of unchanged values, scanner selection) that reduces update frequency further?
  2. Is there anything tunable on the Shelly side (BLE observer script parameters?) or in HA to get denser updates through the Shelly proxies?
  3. If I add bluetooth_proxy: to my existing ESPHome ESP32 nodes, should the Xiaomi BLE integration entities then update as frequently as my locally-decoded ESPHome entities do?

Thanks!