I’ve built a bunch of binary sensors with ESP32 that should transmit their data using Bluetooth low energy and not wifi, since they are supposed to be battery-powered. However, while researching how to run a BLE client on home assistant I couldn’t find any components available. What I could find (and have running currently) is the BLE-device-tracker and some device specific implementations (like the miflora sensors).
If I understand BLE correctly, if I set my ESP32 sensors as a BLE server, I should be able to capture the info on my server if I setup a BLE client there. Looking around I could also find several possible python packages that interface with the bluetooth dongle, so this appears to be relatively straightforward.
What I couldn’t find to my surprise is a generic BLE component, somewhat like we have zwave and zigbee components. I would expect that this would be the basis for using BLE as a way to transmit data for home assistant.
Since i couldn’t find it, is there something I misunderstand about BLE? If I create a specific component for binary_sensors using BLE using pygatt for instance, will it not work? What issue am i overlooking that stops home assistant from using this inexpensive way of communication currently?
I’ve used ESPHome up to now, but it can only handle WiFi, so it won’t give me what I need. When running the sensor using ESPHome it only lasts about 1,5 day on a (relatively huge) 18650 battery, which I’ll never get down to acceptable levels. Asking and looking around it becomes clear that using BLE to commincate isn’t likely to happen within esphome.
The BLE component is just the tracker, you cannot receive information with it as far as I can see, only detect devices.
OpenMQTT is also not an option, since that’ll again use wifi.
Do you expect more elaborate client-server protocol with your BLE device or just simple BLE broadcast of sensor data similar to miflora sensor or miscale ?
Every Bluetooth device has its own protocol/ message structure. Even different Xiaomi devices vary between themselves regarding the message structure. I think this is the reason why there’s no any generic component in HA for BLE tracker. But I think you could take one if HA BLE tracker sensors, rework it and build the integration this way.
I also suggest you post a feature request to the ESPhome Team since this is a very interesting case to make a sensor from ESP32 communicating via BLE.
ESPhome currently only supports TCP communication with HA. Building a BLE communication would be a lot of work but also may be useful when one wants to build a sensor with esp32.
What I’m not sure however is if esp32 is designed to work as a battery sensor. I mean sensors based for example on Z-Wave most of the time spent on being in sleep mode thus not really draining battery. I’m not sure if esp32 supports being in sleep mode. The battery drain you experienced using Wi-Fi may not only be caused by the Wi-Fi itself but also because esp32 constantly doing some work some work in the background or just being active all the time. I think that battery powered devices only wake up their chip If there is anything to be sent to the outside world. Perhaps you need to design your own PCB with esp32 and wake it when you have something to be sent via ble
Not quite true, it can get info from some xiaomi bluetooth devices, but this is not what you want anyway,
Have you thought about sleeping the esp and only waking when it has new data? This is quite a popular strategy with esp (not just in esphome, but esphome does support this).
I’m not sure yet. In principle just broadcasting from the sensors is enough, but I don’t know how reliable it is and how much extra battery is required to indicate back that the message was received. What I’ve understood so far from online sources is that both is possible at least.
The ESP32 supports several sleep modes including a ‘deep sleep’ and I’ve read articles that say it is very effective (about 10 micorA )usage. I have no practical experience with it, but it looks like an average usage of 1mA should be obtainable, which I think is sufficient.
Regarding the protocol, isn’t it correct to say that there is some standerdisation in the characteristics? On this website I see a whole range of IDs: https://www.bluetooth.com/specifications/gatt/characteristics/. What I’ve understood is that in this way different components can still be used interchangebly (like multiple heart monitors for instance).
My Idea basically is that it would be nice to at least implement a ‘template’ characteristic where you provide the ID of the service and characteristics, that way you have a ‘basic’ sensor. Than you could expand this to other types and specific platforms, just as (at least to my understanding) is the case with zwave/zigbee.
now this idea makes so much sense to me, that I’m wondering why it isn’t there yet, which is basically why I started the thread. I’m unsure why the xiaomi flora sensor is a seperate component for instance, and from the forums it looks like implementing a seperate component for each device leads to many issues (not the least of which multiple APIs than can’t be used at the same time).
I want the sensor to react asap (detection of passage through doors, including direction), so I don’t think this’ll work for me with wifi. I haven’t tried it though, but in general the wifi connection time will be too much for me to be practical I think.
Hello!
Sorry for revival of the old thread, but I wonder if there are already some customizations in HASS for reading data from generic BLE sensors?
Thx.
Very surprising indeed. Since ESPHome is such a success I think having a BLE alternative should basically replace the Wifi stack with custom BLE GATT services. Bookmarking this thread anyway…
What @sophof refers to is the amount of time to setup a Wifi connection. With many laptops / smartphones it takes several seconds to get the entire IP connection up and running using Wifi. BLE on the other hand, while lower in bandwith also is also more lightweight in connectivity. Basically you should be able to get it up and running in roughly 1 second if tweaked well enough. Since you spend such a low amount of time building up the connection, it also allows the central to collect the data relatively fast and disconnect again. In the end peripherals spend a minimal amount of time to wakeup, share their data, and go back to sleep. It can be done in just a handful of seconds. Also the RF chips are also more targetting low power use cases, hence BLE. For a low-distance battery powered sensor BLE makes a lot of sense, technically it was designed for this purpose. This is why many heart rate sensor, cadence sensors, smartwatches, etc. build upon BLE, and not Wifi. It can last for days/weeks on a single battery charge.
But that is the theory, honestly I’m a ESPHome virgin so I can’t tell how you much you can optimize it to be low-power while still assuring you don’t get any connectivity issues.
Can you elaborate that please, I’m just getting to know these edge corners of Home Assistant.
BUT these are examples of esphome getting data from other BLE sensors, not making a BLE sensor from a esp. Even if you could, you are still reliant on wifi or perhaps zigbee to get your data into HA. BLE just doesn’t have the range to be suitable all around your house without at some point channeling it through wifi or zigbee.
BLE just doesn’t have the range to be suitable all around your house without at some point channeling it through wifi or zigbee.
More generally spoken there is a big tradeoff between range and power consumption, where Wifi is better in range it also consumes more. If you’re making BLE sensors, off course your gateway also requires BLE hardware and some sore of BLE central software/add-on.
Which one is the best choice depends on the use-case that needs to be covered. But now that I’ve had a look at ESPHome:
uses wifi, thus has better range than BLE
integrates well in HA using MQTT
supports all sorts of sensors out-of-the-box
has filters
uses wifi, thus be careful with battery powered solution, but ESPHome also has support for battery optimization
For that I think the wisest solution is to first check ESPHome and see where you strand combining software tricks such as deepsleep when building a battery powered solution. I couldn’t find much info about power usage, I’ll be looking into that next.
Just a heads-up. Although you are correct that is what I’ve meant, I’ve since found out (after building this myself manually) that the BLE chip on the esp32 can not be used independently from the wifi. This means that there isn’t really a ‘low-power’ mode that I could find, nor a way to wake it up quickly without also powering the wifi.
Long story short, even if this was supported, it probably wouldn’t have the battery life and response time one would expect/want. My conclusion was that a new chip is needed that supports just BLE.
just like the author, I was surprised at the lack of availability of BLE sensors apart from the Mijia Xiaomi stuff.
I don’t think this would be too difficult as long as there’s no need for encryption of the broadcasted data (although this probably can be added later on and decrypted using some code in a Home Assistant module)
ESP32 may not be suitable for low powered purposes.
I’m sure somewhere out there there’s some BLE board that incorporates battery and a BLE/MCU combination with UART/I2C that allows you to program and add on analog or digital sensors.
Off the top of my head, Nordic, ST,NXP, Silabs (EFR32?) may all have suitable boards?
All that’s needed is a a way to ensure you get the reading, broadcast the result, and then write some config in Home Assistant to parse that data properly?
Would love to hear if anyone has experience in this
Bonus is that some of the chips also have Zigbee on them
esp32 does that well. Of course you are welcome to use another chip with zigbee and bluetooth. for example a CC2530 + any of the well documented BLE chips available - I pointed to one above. Of course you will have to navigate the two 2.4Ghz protocols (zigbee and ble) and interference etc, but as the designers of the esp32 have been able to do it, I guess you can too.