Hi,
I’m just getting started with Home Assistant and ESPHome. The latter as a bluetooth proxy, primarily because the linux bluetooth support seems a bit ropey. (Plus none of my linux boxes are near where I want to use bt, and cheaper to deploy an ESP32 than another pi.) I haven’t yet decided whether to stick with HA itself, or just try to use ESPHome via its api.
I have two bt devices I want to interact with: one is a reflashed xaiomi thermometer which communicates using broadcasts only; the other is another device that requires to be paired. (A Daikin Madoka thermostat.)
I’ve got a bluetooth proxy working. (First attempt stalled since I was trying to use an esp32-s3-devkit-1 but that seems to have platformio issues, so now using a DOIT esp32 dev board.) My temporary HA install can connect to it, and with component debugging turned on, I can see messages coming from the xaiomi, and when I turn on bluetooth on the madoka I see a storm of messages coming from it.
So my question is how to proceed. Can I just use the proxy on the ESPHome, and do all the pairing and stuff at the host end, or do I need to put the bluetooth client onto the ESPHome, and then have that do the pairing itself? If the latter, do I do the pairing by setting up on_this and on_that rules on the ESP32, or can auto_connect take care of it? (There’s a 6-digit key that has to be confirmed when pairing.)
And can a single instance of ESPHome handle both tasks (receiving adverts from one bluetooth device while connected to another bluetooth device) ?
(As a bonus question - would be nice to be able to flash the LED. I think I’ve read that this requires the arduino framework, whereas bluetooth works much better with the esp-idf framework, which is the one I’m using. But I’m sure this will be covered in the docs once I find my way around.)
(If the protoype is successful, I’ll probably switch a board with ethernet, so that bt doesn’t have to compete with wifi.)
Yep, that’s the purpose of BT Proxy, it just forwards everything to HA; you just need the BT device to have an integration in HA. If it’s a core integration, it will usually be auto-discovered whereas if it’s custom, you obviously have to install the integration (but then still frequently auto-discovered).
BT Proxy devices can ‘connect’ to essentially an unlimited number of passive broadcasts, while there’s a hard limit of 3 active BT connections per proxy.
An LED on the ESP? You can definitely do that with either framework, just need to add it to your YAML.
Obviously Ethernet is better, but I have quite a few BT Proxies all using WiFi (and all doing lots of other things simultaneously) and they work great. If you already have Ethernet ran, go for it, but don’t feel like there’s a massive difference you’re missing out on.
Okay, thanks. But if all the proxy is doing is dumbly gateway-ing byte-streams between BT and wifi, and pairing happens at the HA end, then how/why does ESPHome know it’s connected to anything ? Why would there need to be any state stored ?
If I make an analogy with ethernet: a bridge or switch just forwards packets at the ethernet frame level, and has no concept of connected tcp sockets.
Not sure I’m fully following your question. For passive broadcasts, it IS just ‘dumbly’ forwarding everything to HA. For active connections, while it’s the one making the connection, HA is telling it what to do (and where you provide whatever info is required for the integration to pass the necessary info onto the BT device via the proxy).
Additionally, you’re not going to ‘see’ anything on the ESPHome device (other than in the logs). It’s essentially just acting like an additional BT adapter for HA.
I’m not yet sure if I’m going to be using HA - I’m currently considering using ESPHome as a standalone device via the native api. Which is why I’m trying to understand which bits are (can be) done by ESPHome itself, and which bits are delegated to the api client (ie HA).
Yes, passive broadcasts I’m fine with. It’s how active connections are made that I’m still unclear about.
One way it might work is that the proxy sends raw bluetooth over the api, and all the bluetooth protocol implementation happens on the “smart” end. The other way it could work is that the ESPHome takes care of the pairing and whatnot, and then makes higher-level services available over the api. From what I’ve seen of the native api, I’m pretty sure it’s the latter. But anyway, I’ll figure it out…