BLE temperature/humidity with wild values

Configuration
1

I have a few of the Xiaomi Miija temperature sensors and have them connected up through a Bluetooth proxy. I need to get around the 3 device limitation (I have 4 devices) and have been trying to get a BLE tracker to work with them. As an example, I have one connected through the proxy with BTHome and it gives the correct temperature and humidity readings (e.g. 74F, 47%). When it is read by the BLE tracker I get something like 220F, 120%. I’m reading the correct UUIDs and if I use an app (e.g. nRF Connect) I see the correct values with the UUIDs. I’m kind of stumped as to what is going on. YAML snippet:

  - platform: ble_client
    type: characteristic
    ble_client_id: master_bedroom
    name: "Master Bedroom Temperature"
    service_uuid: '181A'
    characteristic_uuid: '2A1F'
    notify: true
    icon: 'mdi:thermometer-bluetooth'
    unit_of_measurement: '°F'

The sensors have the PVVX v4.7 firmware installed and use BTHome v2 advertisement. Any ideas?

2

That limitation is for active connected devices, the Xiaomi’s use passive broadcasting, so no limitation.

3

If I put 4 device MAC addresses in the ble_client: section of YAML, it gives a compilation error. I’m hoping to be able to use the GitHub - myhomeiot/esphome-components: A collection of my ESPHome components which don’t appear to have this restriction, or figure out how to change the limit.

4

if your Xiaomi’s are correctly configured in the pvvx page, you don’t need to put MAC addresses

esphome:
  name: bluetoothproxy
  friendly_name: BluetoothProxy


esp32:
  board: esp32dev
  framework:
    type: esp-idf

# Enable logging
logger:

# Enable Home Assistant API
api:

ota:
  safe_mode: True

wifi:
  networks:
  - ssid: "xxx"
    password: "xxx"
  - ssid: "xxx"
    password: "xxx"

  # Enable fallback hotspot in case wifi connection fails
  ap:
    ssid: "Bluetooth-Proxy Fallback Hotspot"
    password: "xxx"
  

bluetooth_proxy:
  active: true
  
button:
- platform: safe_mode
  name: Safe Mode Boot
  entity_category: diagnostic

- platform: restart
  name: "Proxy Restart"

binary_sensor:
  - platform: status
    name: "Proxy Status"
5

I don’t want to use the proxy. I would rather use the tracker . As I said, the proxy works fine, but the values from the tracker are the issue.

6

Your choice.

7

Thanks. Also, there proxy does have a 3 device limitation, since I only ever see 3 of my devices with values and they cycle. Why ESPhome has to hard code this is beyond me.

8

Only when you use MAC addresses.

9

Like I said, I don’t use the MAC addresses. That is for the BLE tracker.

10

I have 8 using the configuration shown earlier.

11

As @francisp mentioned, that definitely isn’t the case for BT Proxy. Per the docs:

“The Bluetooth proxy of ESPHome provides Home Assistant with a maximum number of 3 simultaneous active connections.”

I have TONS of BT devices all using proxies without any issues, but I only have 2 that require an active connection. I don’t think there’s really a hard limit to passive connections (like your temp/rh sensors).

12

ok. So is there a way to be able to persist the value obtained from one of the devices? In Home Assistant, my devices cycle between showing temp + humidity and Unavailable, which is useless for any automation.

13

I think that’s just due to how you’re currently pulling them in. I have ~20 of them (using the BT Home protocol) and they always show the last received value, although I also have them setup to broadcast fairly frequently (Just used whatever the default in the flasher tool is).

To clarify, this is the specific flasher I’ve used in the past (I believe there are a couple, but this is the most maintained to my knowledge):
https://pvvx.github.io/ATC_MiThermometer/TelinkMiFlasher.html

14

I’m using the same flasher and protocol. I’m going to try a different ESP32 for the proxy.

15

But you’re not using BT Proxy, per the YAML you posted. You don’t need anything specific to your BT device in your YAML: they’ll just be auto-discovered by HA if you have it setup properly.

16

I have a proxy, that is the one that shows 4 devices but only values from 3 of them at a time. I also set up a tracker to see if I could get that working, but that shows the wrong temp and humidity values.

17

Why don’t you post your full BT Proxy YAML? My guess is maybe you have something mis-configured.

I’ll also toss out that I’ve found the range of my BT Proxies to be fairly low (just using standard development boards). Not a huge deal for me, as I have BT Proxies scattered throughout my house doing other things already. Could just simply be a range issue.

18

The YAML is below. It could be a range issue, however the proxy does pick up from each sensor, just only 3 at a time!

substitutions:
  name: "bluetooth-proxy"
  friendly_name: Bluetooth Proxy

esp32:
  board: esp32dev
  framework:
    type: esp-idf

packages:
  esphome.bluetooth-proxy: github://esphome/bluetooth-proxies/esp32-generic.yaml@main

esphome:
  name: ${name}
  name_add_mac_suffix: false
  friendly_name: ${friendly_name}

api:
  encryption:
    key: <key>

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

logger:
  level: INFO
  
ota:

dashboard_import:
  package_import_url: github://esphome/bluetooth-proxies/esp32-generic.yaml@main

esp32_ble_tracker:
  scan_parameters:
    # We currently use the defaults to ensure Bluetooth
    # can co-exist with WiFi In the future we may be able to
    # enable the built-in coexistence logic in ESP-IDF
    active: true

bluetooth_proxy:
  active: true

### Sensors ###

light:
  - platform: status_led
    name: "ESP Status Light"
    pin: GPIO2
    entity_category: "diagnostic"
    disabled_by_default: false

binary_sensor:
  - platform: status
    name: "ESP API Connection"
    disabled_by_default: true

button:
  - platform: restart
    name: "ESP Restart"
    entity_category: "diagnostic"
    disabled_by_default: false
19

I assume it’s not your issue, but I don’t understand the purpose of this when you already have the BT Proxy components/configuration in your YAML.