In this sample, b-parasite sensors are periodically read and broadcast using Bluetooth Low Energy (BLE) dvertising packets.
Available configurations and their default values are in Kconfig. They are set in prj.conf. Here are some notable examples.
To save energy, the board spends most of the time in a "deep sleep" state, in which most peripherals and radio are completely turned off. The period of sleep is controlled by the PRST_SLEEP_DURATION_SEC config.
When it wakes up, the sample reads all sensors and keep broadcasting advertising packets for PRST_BLE_ADV_DURATION_SEC before going back to sleep.
There are different ways to encode the sensor data in a BLE advertising packet.
BTHome is a new (as of Dec/2022) open standard for encoding sensor data in BLE applications. Home Assistant supports it out of the box. This makes the deployment extra convenient, since no additional configuration is needed - Home Assistant will automatically detect b-parasites in range.
What's even more interesting is that by employing ESPHome bridges with the bluetooth_proxy component, the range of BLE coverage can be transparently increased. Multiple ESPHome bridges will forward received BLE broadcasts to Home Assistant.
This is what a typical deployment with BTHome looks like:
There are two versions of BTHome encodings supported by this sample:
PRST_BLE_ENCODING_BTHOME_V2=y(default) uses the BTHome V2, supported by Home Assistant since version2022.12PRST_BLE_ENCODING_BTHOME_V1=yuses the legacy BTHome V1, which was briefly in use
PRST_BLE_ENCODING_BPARASITE_V2=y selects the legacy encoding, used historically in this project. This is the encoding that the b_parasite ESPHome component understands.
With this encoding and a ESPHome + b_parasite component, this is an usual deployment topology:
The disadvantages of this encoding are:
- Each b-parasite has to be configured in the ESPHome component
- Range is limited, unless multiple ESPHome bridges are deployed with the same static configuration
tl;dr: Theoretically well over two years with default settings.
While in deep sleep, the board consumes around 3.0 uA:
In the active broadcasting state, the average power consumption is highly dependant on the advertising interval.
With the default settings (in the [30, 40] ms range), we see an average of around 810 uA:
If for example we lower the connection interval to the SDK defaults ([100, 150] ms, roughly trading off range for power), the average current consumption is around 345 uA:
With a 200 mAh CR2032 battery, we can use this spreadsheet to estimate the battery life to over two years. Note that this is a simplified model and results in practice may vary.