ESPHome BLE Gateway and other BLE components

Hello!

I’m ussing Passive BLE integration to retrieve data from 8 Xiaomi LYWSD03MMC temperature sensors (stock firmware) in RPi 4 integrated BLE, working with Hass OS. Few days ago I tried to improve reception of some sensors with a ESPHome BLE Gateway. It’s working well now but I’m confussed about PASSIVE OR ACTIVE SCAN. The ESP used code in first intance was:

esphome:
  name: blegateway
  friendly_name: blegateway

esp32:
  board: esp32dev
  framework:
    type: arduino

# Enable logging

logger:

# Enable Home Assistant API
api:
  encryption:
    key: "xxx"

ota:
  password: "xxx"

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

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Blegateway Fallback Hotspot"
    password: "xxx"

captive_portal:

esp32_ble_tracker:

external_components:
  - source: github://myhomeiot/esphome-components

ble_gateway:
  id: blegateway

  devices:
    - mac_address: !secret Estudi_mac
    - mac_address: !secret Golfes(Est)_mac
    - mac_address: !secret Golfes(Oest)_mac
    - mac_address: !secret HabGran_mac
    - mac_address: !secret HabNenes_mac
    - mac_address: !secret Menjador_mac
    - mac_address: !secret TerrassaNord_mac
    - mac_address: !secret TerrassaSud_mac

  on_ble_advertise:
    then:
      homeassistant.service:
        service: ble_monitor.parse_data
        data:
          packet: !lambda return packet;
          gateway_id: $gateway_id

After that the log of the ESP BLE Tracker notify that is using a ACTIVE CONNECTION:

12:08:04][C][esp32_ble_tracker:621]:   Scan Type: ACTIVE

Reading the specifications of esp32_ble_tracker shows that the scan type is ACTIVE y default (https://esphome.io/components/esp32_ble_tracker.html). Why the BLE Gateway code example is with this parameter as active? And does it represents that the BLE Gateway is eating more battery of sensors ?

I tried to recompile ESP with the option PASSIVE SCAN:

esp32_ble_tracker:
  scan_parameters:
    active: False

The ESP log:

[12:42:38][C][esp32_ble_tracker:617]: BLE Tracker:
[12:42:38][C][esp32_ble_tracker:618]:   Scan Duration: 300 s
[12:42:38][C][esp32_ble_tracker:619]:   Scan Interval: 320.0 ms
[12:42:38][C][esp32_ble_tracker:620]:   Scan Window: 30.0 ms
[12:42:38][C][esp32_ble_tracker:621]:   Scan Type: PASSIVE
[12:42:38][C][esp32_ble_tracker:622]:   Continuous Scanning: True

I don’t see any change, I continue receiving a lot of data from my sensors. I can see this in ESP log and in history data in HA, that is recording values every 5 minuts now. Before the modifications introduced by BLE Gateway, the history data only record every time that the integrated BLE received a passive transmission. I have Passive option in Passive BLE Component in HA also selected.

How I can corfim that the integrated Rpi4 BLE and the ESP is working in PASSIVE MODE ? And why the history in HA is recording data every 5 minuts now ? The LYWSD03MMC sensors default update interval time is much more than 5 minuts (10 minutes I think)…

Thank you!

Hello,

BLE Gateway can work with any configuration of esp32_ble_tracker (some users adjust interval, window, and duration parameters). Usually active scan requires more device powers, and can bring more data from device, but LYWSD03MMC doesn’t requires active scan, so to disable it was a good idea. Active scan can’t change how many BLE advertisement send by device it’s can get more data from sent advertisement.

AFAIK LYWSD03MMC with stock firmware send data when it’s changes or every 10 minutes. You can check how many BLE advertisements send from one LYWSD03MMC device by checking the ESPHome log. To make this simpler, leave only one LYWSD03MMC device in BLE gateway configuration.

Active scan is asking close by devices to advertise new data rather than waiting then self advertise. So it asks but doesn’t wait for the reply, just processes incoming ble data.

Debouncing spammy devices

Thank you for this amazing tool!
In the past I was using it to forward BLE advertisements from my 2 Hörmann garage door openers to Passive BLE monitor which worked like a charm.

Now i wanted to add a LYWSD03MMC and noticed that the bluetooth of my ESP32 can’t keep up with the high frequency of advertisements and dropping some/many of them. This is mostly due to the Hörmann devices being very spammy and basically broadcasting every other ms. In the past this was no issue because there were enough advertisements from the door openers going through for HA to update the sensors. However now I am at a point where I can not reliably include the Xiaomi because the single advertisements from it get dropped so easily due to the spam.

I played around with scan interval and -window however the amount of advertisements coming from the Hörmanns is insane.
Is there any way to debounce those or any idea how I can have both device types on a single ESP32-gateway?

I have also Horrman garage door, you are right about spamming but not sure if I am dropping any messages.

Are you using service call or event generation?

I am using the service call provided by the Passive BLE Monitor-Integration.

Do you have other BLE devices on the same gateway/ESP32 as the Hörmann?

Of course I could increase the advertising rate of the Xiaomis and hope that more of them make it through consistently and thus living with the decreased battery life. However I was hoping for a more elegant solution.

On the other hand the pvvx repo even says that dropped advertisements are to be expected when using an ESP32 with ESPHome for many (or therefore also few very spammy) devices.

Please can you share the exact service name you are calling?

I have couple other sensors nearby garage door but I am not processing them.

Yes of course.

Here is the relevant YAML from my ESPHome device (ESP32 D1 Mini):

# Enable ble tracker
esp32_ble_tracker:
  scan_parameters:
    interval: 200ms
    window: 100ms
    active: False

# Config BLE Gateway
ble_gateway:
  id: blegateway
  devices:
    # Hörmann-Antriebe
    - mac_address: !secret garage_links
    - mac_address: !secret garage_rechts
    # Xiaomi Hygrometer
    - mac_address: !secret hygrometer_wohnzimmer_mac
  on_ble_advertise:
    then:
      homeassistant.service:
        service: ble_monitor.parse_data
        data:
          packet: !lambda return packet;

I personally followed the advice here and didn’t play with interval and window values.

I did not check the BT proxy documentation before. Thank you for pointing that out.

1 Like

I’m trying to get this working on a Switchbot Plug Mini (ESP32-C3) and when I add the ble_gateway config and install, I get errors saying: “undefined reference to `vtable for esphome::ble_gateway::BLEGateway’”

Is there something obvious that I’m doing wrong?

HARDWARE: ESP32C3 160MHz, 320KB RAM, 4MB Flash
 - framework-espidf @ 3.40407.240606 (4.4.7) 
 - tool-cmake @ 3.16.4 
 - tool-ninja @ 1.7.1 
 - toolchain-esp32ulp @ 2.35.0-20220830 
 - toolchain-riscv32-esp @ 8.4.0+2021r2-patch5
Reading CMake configuration...
No dependencies
Linking .pioenvs/sbotplug-ab1fdc/firmware.elf
/data/cache/platformio/packages/toolchain-riscv32-esp/bin/../lib/gcc/riscv32-esp-elf/8.4.0/../../../../riscv32-esp-elf/bin/ld: .pioenvs/sbotplug-ab1fdc/src/main.o: in function `setup()':
/data/build/sbotplug-ab1fdc/src/main.cpp:287: undefined reference to `vtable for esphome::ble_gateway::BLEGateway'
/data/cache/platformio/packages/toolchain-riscv32-esp/bin/../lib/gcc/riscv32-esp-elf/8.4.0/../../../../riscv32-esp-elf/bin/ld: /data/build/sbotplug-ab1fdc/src/main.cpp:287: undefined reference to `vtable for esphome::ble_gateway::BLEGateway'
/data/cache/platformio/packages/toolchain-riscv32-esp/bin/../lib/gcc/riscv32-esp-elf/8.4.0/../../../../riscv32-esp-elf/bin/ld: /data/build/sbotplug-ab1fdc/src/main.cpp:288: undefined reference to `vtable for esphome::ble_gateway::BLEGateway'
/data/cache/platformio/packages/toolchain-riscv32-esp/bin/../lib/gcc/riscv32-esp-elf/8.4.0/../../../../riscv32-esp-elf/bin/ld: /data/build/sbotplug-ab1fdc/src/main.cpp:288: undefined reference to `vtable for esphome::ble_gateway::BLEGateway'
collect2: error: ld returned 1 exit status
*** [.pioenvs/sbotplug-ab1fdc/firmware.elf] Error 1
========================= [FAILED] Took 14.78 seconds =========================

Hello,

Should works, similar problem can happened with ESP-IDF if you add new component and not cleanup build files. In ESPHome dashboard select … for this device choose Clean Build Files and try to install again.

But be very careful with ESP32-C3 and Bluetooth, device can fail to boot. Do you use Bluetooth in this device before? Please read my post here

Hi everyone, first of all, let me thank the developer who created this great component.

Currently I have created one BLE gateway and using it well.
But I want to add a new Passive BLE device LYWSD03MMC that is far away from the gateway (i.e. on the opposite side of the house).

My question here is, is it okay to add another ESP32 with BLE gateway installed, so that there are a total of 2 ESP32 with BLE gateways installed in the house?

Of course I know I can just do it, but I’m writing this to reduce trial and error.

Yes yo can!
If you want more info watch this:

and read this:

Just saw this, this is exactly what I need for a couple projects. Thanks OP!

Thank you so much. I’ll give it a try soon.

Sure, this is exactly how this designed, to extend BLE range you can install as many gateway/proxy as you need.

Instead of adding a ble gateway in a remote location, would it be enough to just put an esp32 board there with the bluetooth_proxy: option set?

Yes, but keep in mind that BLE Gateway and BLE Proxy (bluetooth_proxy) it’s a different things. BLE Gateway can only receive BLE data and send it to Passive BLE Monitor integration for decode. BLE Proxy it’s a part of Home Assistant and use build-in BLE devices plugins for decode data and can also send data back to BLE devices (if you specify active: true in its configuration).

So if you already familiar with BLE Gateway and has it configured, you can just add extra ESP32 with same BLE Gateway configuration as one which you already have.

Ah, that makes sense now, thanks for the detailed explanation.