Can ESPHome be used as a BLE to MQTT proxy/hub/gateway?

ESPHome
,
1

Hello everyone,
not sure how to best describe this but can ESPHome be used as a proxy/hub/gateway for filtering data?

My current setup uses an ESP32 running tasmota where all bluetooth sensor data is being received by the ESP32 and then “sent” to an MQTT broker. NodeRed then filters all data on that broker and forwards the filtered data to a second MQTT broker which is read by Home Assistant.

I was wondering if ESPHome could perform the same task?
The BLE sensors would be using BTHome advertising format.

Thank you
Alex

2

Maybe this helps

3

Using the Bluetooth Proxy and MQTT components you should be fine.

Bluetooth Proxy - ESPHome - Smart Home Made Simple

MQTT Client Component - ESPHome - Smart Home Made Simple

1 Like
4

If you use esphome write some code, that’s definitely feasible.

5

Did you try it ? I have some Bluetooth proxies with mqtt, but never have seen Bluetooth messages going over mqtt, only the temp/humidity info from the sensors on the same esp32. (They use both api: and mqtt, this could be the problem too)

6

Well, before we had a proper API for ESPhome, all data was sent to HA via MQTT. Since the API came out I’ve never looked at MQTT again.

7

It seems that esphome is still very unstable when it comes to ble. I have 15 devices and that works with Tasmota but when using esphome it seems unstable.

8

Will need to try and configure ESPHome freshly and see if it runs stable now.

The reason why I need MQTT is so HomeAssistant does not receive the original sensor data. I want to filter out all the resundant data (I don’t need to know when the temperature or humidity change by 0.01. That just floods the database because the readings are every few seconds. Lots of useless data.

Using to MQTT brokers I can read the data on one, filter it and then send the filtered data to the MQTT broker exposed to HA. Cut my database growth rate significantly.

P.S.: I don’t purge data, so filtering is important.

9

Can someone help me with the config?

esphome:
  name: "esp32-wroom-32d-devkitc-v4-3"
  friendly_name: ESP32-WROOM-32D_DevKitC_v4_3
  min_version: 2025.9.0
  name_add_mac_suffix: false

esp32:
  variant: esp32
  framework:
    type: esp-idf

esp32_ble_tracker:
  scan_parameters:
    # Contrary to other implementations, xiaomi_ble listens passively to advertisement packets and does not pair with the device. 
    # Hence ESPHome has no impact on battery life. Thus, if you only use such sensors, you can safely set 
    # scan_parameters.active: false in esp32_ble_tracker configuration, to save from spamming your RF environment with useless scan requests.
    active: false

xiaomi_ble:

bluetooth_proxy:
  active: true

mqtt:
  broker: 192.168.0.2
  port: 1883
  username: !secret mqtt_user
  password: !secret mqtt_password

# Enable logging
logger:

# Enable Home Assistant API
# The ESPHome native API is used to communicate with clients directly, with a highly-optimized network protocol. 
# Currently, only the ESPHome tool, Home Assistant and ioBroker use this native API.
api:

# Allow Over-The-Air updates
ota:
- platform: esphome

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  manual_ip:
    static_ip: !secret wifi_static_ip
    gateway: !secret wifi_gateway
    subnet: !secret wifi_subnet

Can I disable the api if I am not using it for Home Assistant? Or will this also disable the ESPHome WebUI/dashboard support?

CoPilot suggests that bluetooth proxy should be disabled if I want to forward the decoded sensor data to mqtt broker:

  • The bluetooth_proxy component only forwards raw Bluetooth advertisements over the ESPHome API, it does not publish decoded sensor entities to MQTT.
  • If your goal is “ESP32 → MQTT only”, enabling bluetooth_proxy adds nothing useful because mqtt publishing comes from the sensor integrations (xiaomi_ble, device-specific BLE platforms) rather than from the proxy.
  • The bluetooth_proxy requires the api component to send the proxied advertisements; keeping bluetooth_proxy while removing api is misconfigured and may produce errors or no useful output.
  • Leaving both bluetooth_proxy and per-device xiaomi_ble integrations enabled can cause duplicated or confusing behavior; remove bluetooth_proxy to keep the ESP32 scanning and letting xiaomi_ble decode and publish sensor entities directly to MQTT.

Any ideas?

I want to read my Xiaomi Mijia sensors (flashed with pvvx firmware. Ideally I would like to have them detected automatically and not have to define them one by one. But the docs read like I have to define each sensor manually (which seems a bit redundant given each sensor follows a defined syntax).

10

So… Thats why Esphome also uses Filters so that you can specifically control what conditions cause a sensor update and then even modify the frequency of those updates or add on additional conditions that must be met before it will pass on those sensor states that dont meet your “criteria/filters”

This is all really simple and beginners level type of things you can do and certainly dont need to incorporate NR or evej MQTT for what you want and really its all just unnecessary bloat/fat that could be cut out.

1 Like
11

Dude… You need to take some time and invest into yourself by reading through the Esphome documentation where it explains all of these thing’s so that you have the answers and you can be able to write your config without having to ask and then wait around in forums for someone else to answer your questions or solve your simple problems.

Here again is answers for your questions in the documentation.

Esphome api

12

I read that doc, and as you can see, I copied it into my config so I know why I changed that setting (or would change it). But that suggests to me that ESPHome tool needs it, i.e. if I disable it I won’t be able to communicate with my ESPHome device using the ESPHome tool. Or is ESPHome tool unrelated to ESPHome Web? Maybe my mistake was in thinking the ESPHome Web is part of the ESPHome tool (or is identical to it).

Re filtering:
Last time I tried ESPHome is admittedly a few months back, but back then the filtering was quite basic compared to what you could do with Node-Red.

My filtering is also used for energy sensors and other kinds of sensors where I defined thresholds based on absolute values, updates based on individual sensor values, pre-defined forced update intervals and so on. The filtering of insignificant steps is just one, small example.

But of course this might all be possible now with ESPHome and that would be great. But that would be a next step IF all my BLE and Wifi devices are supported. If any device is not supported, I will need my filtering Node-Red instance anyway and might as well continue to use it.

So do I really have to define every sensor manually? They are not automatically identified the way they are in tasmota?

13

Giving up for today. So far I have not seen any mijia sensors showing up in my log when using BTHome v2.

The docs also have no mention of BTHome v2 support:

Not sure if maybe that is a typo anyway in the docs as I assume that platform: pvvx_mithermometer would use pvvx and not custom.

14

Im not 100% sure about what it is you’re referring to when asking about this “Esphome tool” so, hard to answer.

The Filters haven’t changed significantly or much at all in the last several months and they’re not “simple” at all. Between Filters and custom lambdas you have the capability to do whatever it is someone could need. The same is true with HA sensor filters too and the vast capabilities available to everyone is a large reason for NodeRed falling out of favor from what it used to be roughly 2 years ago. Yes, people certainly still use NodeRed, just nowhere near the levels historically.

IMO if you like NodeRed and are technically competent using it then id say just keep using it then and maybe its best to not rock the boat if it isnt necessary…

That will depend on what you use with HA doing the tracking of the beacons. If you use Espresense which is what i use because it allows me to pull in battery data then yes, youll need to create sensors in your HA config.yaml under the mqtt_room: platform.
[Mqtt room](MQTT room presence - Home Assistant MQTT room presence - Home Assistant)

Espresence firmware

1 Like
15

My filtering is probably around 2 years old and since not all devices I am filtering seem to be supported out of the box (e.g. eQ-3) and I am not sure if it is simpler to setup filtering of tasmota’s incoming MQTT braodcasts using ESPHome, I set up NodeRed once and have been using it since.

I am sure there are muuuuch more elegant solutions (e.g. also Berry on tasmota) but I managed to get NodeRed to do what I want (with a lot of community support, of course).

I stopped looking at the HA sensors a while back, but unless something significant has changed, the HA sensors do not allow filtering of original input data. What I mean is, that the data comes in through the tasmota integration of HA. I cannot place a filter between HA backend/MQTT broker and the tasmota integration. I could only block tasmota from writing sensor data to the database and then create fake sensors that filter and then write. That is too inelegant even for me :smiley:

But now I have hit a bottleneck with the lack of BTHome v2 support in tasmota’s bluetooth driver. So I need a new solution to bridge that one gap (currently still need tasmota for my power sockets and eQ-3 TRV anyway).

I currently do not have any presence sensors, btw. Not really interested in who is where yet. Maybe when I have kids :smiley:

Essentially I love the simplicity and ease of use of Home Assistant but it does lack a proper data filtering BEFORE it is processed by the different integrations.
So my approach is to have two brokers. One with the original data and a second with the processed data. HA only sees the second, so I do not need to tamper with the data in HA anymore.

Edit:
I know that AI is forbidden as answer, but I checked anyway to see if maybe I overlooked something in the documentation. MAybe someone can say if Claude/CoPilot are correct or not.

Claude.ai and CoPilot both say that
You're correct - that is a limitation. With the bthome platform in ESPHome, you do need to manually specify each entity (temperature, humidity, battery, etc.) for each device.

If that is the case, then ESPHome does not really support BTHome format for Xiaomi mijia devices. Because for pvvx format you only specify the device (based on MAC) and the platform automatically identifies the different entities, just like tasmota does.

If ESPHome only allows manual creation of each individual entity, then okay, I could do that, but then it would be far inferior to having tasmota support BTHome format (because there you do not even have to define the devices, it just automatically identifies them based on their names and reads all entities from the data).

16

Oh, hell thats 90% of the reason i made mine! You can only be running late out of the house so many mornings and at the last minute hear, “I cant find my backpack” or “I cant find my phone” before you have an epiphany and say, "im gonna put a BT beacon on all this crap and stop playing hide and seek throughout the house looking for stuff! Other than being good for finding your kids things they keep losing, they’re actually very handy for pets and key rings! If my dog gets out of the yard and i dont notice right away then she will cover some serious ground in as little as 10min! With the beacon i can be notified right away and then i maybe only have 1 or 2 streets over to search instead of 1 or 2 miles! With the car keys, if you’ve ever dropped them in your yard and then spent 8 hours searching couch cushions and tearing your house apart looking for them then i dont need to tell you how nice it is to just go look on HA and see which room their in and how far away they are from the node in that room and not need to go around flipping cushions over!

I honestly dont even use the ability to track specific devices and do specific automations based on whos devices enters/exits a room like for example I could have my Amazon Echos announce “Please rise, the king has entered the room” but, my smart mouth daughter would probably tease me to death over being a dork untill i made it stop… I really only use them as a way to find things if they’re lost and additionally to track BT beacon batteries as well.

1 Like