esphome / esphome/feature-requests

Instant sensor updates when waking up from deep sleep, using BLE Server

Open
#1,634 1 comment 0 reactions 0 assignees View on GitHub
component: esp32_ble_server
Dominant language
No language data
Stars
450
Forks
29
PR merge metrics
No merged PRs in 30d

Description

**Describe the problem you have/What new integration you would like**

Wake up from deep sleep + connect to wifi + HA API takes too long to be reliable. We could use BLE to quickly send new states to a second ESPHome that is always on, so they can be relied to Home Assistant.

**Please describe your use case for this integration and alternatives you've tried:**

My use case is a battery-operated fingerprint scanner with an ESP32 and the Grow Fingerprint integration. I can wake up from deep sleep with the sensing pin whenever a finger is placed on the sensor, and watching the logs the finger is recognized in ~1s. However, the ESP still needs to connect to WiFi (1-2s, could be shorter with static IP etc), and wait for Home Assistant API to connect to it, which means waiting for HA to initiate the connection (sometimes >5s). This means that you have to read the fingerprint and wait for almost 10 seconds for a reaction.

I believe we could use a BLE server implementation so that it wakes up and updates its state using BLE notifications. This is not compatible with the Home Assistant API as it's done over IP, but can be picked up by any other ESPHome device, then relied to HA. It could bring total runtime to 1s, then back to sleep, with almost instant updates to HA.

**Additional context**

I am not dead set on using BLE for this, but am looking for ways to have a more snappy, reliable battery operated ESPHome devices. Any other method that achieves a similar result would be great too!

Contributor guide

No contributing guide indexed for this repository

Research direction

No files, tests, or entry points are named. Start by reviewing the deep-sleep, WiFi, Home Assistant API, and BLE-server constraints in the request, then define an agreed communication approach and acceptance criteria for reliable near-instant state delivery.

Written by the indexing model from the issue text.

Assessment

Domain
embedded-iot
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
18/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.