ESP ZeroCode AI · Community
Heart Rate Monitor
A simple BLE heart rate monitor example, that creates a GATT server demonstrating standard Heart Rate measurement service. This example creates GATT server demonstrating standard Heart Rate measurement service to client when the notifications are enabled. It should use ESP32's Bluetooth controller and NimBLE stack based BLE host. It should first advertise with legacy advertising data which includes the name as "NimBLE HR". It should register a gatt service, where Heart Rate service ( with UUID 0x180D ) is the primary service. It should have 2 characteristics. First characteristic should be Heart-rate measurement (with UUID 0x2A37) . This should have a notify flag enabled where remote can be sent notifications if registered. Second characteristic should be Body Sensor location (with UUID 0x2A38) with read permission. Remote client can subsribe for notification. The heart rate example can simulate a heart beat (say every 2 seconds) and send it to connected client via notifications. After every 100 seconds, the counter resets. After every 120 seconds, it gives a count of notification sent as a feedback
What it does
- BLE GATT server with Heart Rate Service (0x180D)
- Heart Rate Measurement characteristic (0x2A37) with notify
- Body Sensor Location characteristic (0x2A38) with read permission
- Simulate heart rate readings (every 2 seconds)
- Counter reset every 100 seconds
- Report notification count every 120 seconds
- Legacy BLE advertising with device name 'NimBLE HR'
- LED1 (advertising) — GPIO 2
- LED2 (connected) — GPIO 4
- LED3 (notification activity) — GPIO 5
- Always-on BLE advertising (connectable anytime)
- USB powered with persistent bonding (remember clients)
- Simulated heart rate data (no external sensor)
Manual
Device Type
BLE Heart Rate Monitor (Simulated)
Device Description
A wireless heart rate monitor that broadcasts simulated heart rate data via BLE. Clients connect via GATT to subscribe for real-time heart rate notifications. Three LED indicators show advertising, connection, and notification activity status. Powered by USB; intended for testing and demonstration of NimBLE GATT server capabilities.
Hardware
chip: ESP32 — board: DOIT ESP32 DevKit V1 — gpios: pin: GPIO2 — peripheral: LED1 (Advertising) — role: output — driver: digital GPIO · pin: GPIO4 — peripheral: LED2 (Connected) — role: output — driver: digital GPIO · pin: GPIO5 — peripheral: LED3 (Activity) — role: output — driver: digital GPIO — peripherals: name: LED1 (Advertising) — type: Status LED — gpio: GPIO2 — function: Indicates BLE advertising state · name: LED2 (Connected) — type: Status LED — gpio: GPIO4 — function: Indicates BLE connection state · name: LED3 (Activity) — type: Status LED — gpio: GPIO5 — function: Flashes on notification sent
Outputs
kind: LED Status Indicator — label: LED1 (Advertising) — hardware: GPIO2 — behavior: Blink pattern during advertising; solid off when no advertising · kind: LED Status Indicator — label: LED2 (Connected) — hardware: GPIO4 — behavior: Solid on when BLE client connected; off when disconnected · kind: LED Status Indicator — label: LED3 (Activity) — hardware: GPIO5 — behavior: Brief flash/pulse each time a heart rate notification is sent
Connectivity
stack: NimBLE — transport: Bluetooth Low Energy (BLE) — purpose: Primary communication; broadcasts Heart Rate Service GATT, accepts client subscriptions
Commissioning
method: Automatic continuous advertising — instructions: Device starts advertising immediately on power-up with the name 'NimBLE HR'. Open a BLE scanner app (iOS/Android Health apps or generic BLE apps) and look for 'NimBLE HR'. Select it to connect. The device will accept the connection and allow client subscription to Heart Rate Measurement notifications.
Business Logic
powerOnBehavior: On power-up or reset, device initializes NimBLE stack, registers GATT services, and begins BLE advertising with the name 'NimBLE HR'. LED1 begins blinking to indicate advertising state. — dayToDayOperation: 1. Simulated Heart Rate Generation: Every 2 seconds, firmware generates a simulated heart rate value (e.g., 60–100 BPM range) and updates the Heart Rate Measurement characteristic. 2. Client Notification: If any BLE client has subscribed to notifications on the Heart Rate Measurement characteristic, that value is immediately sent as a GATT notification. LED3 flashes to indicate activity. 3. LED Status: LED1 (Advertising) blinks during advertising and stops when a client connects. LED2 (Connected) is off when idle/advertising; solid on when a BLE client is connected. LED3 (Activity) flashes briefly each time a notification is sent. 4. Counter & Reporting: Every 100 seconds, an internal counter resets (used for demonstration/timing). Every 120 seconds, the firmware logs a count of notifications sent (useful for debugging and validating notification delivery). 5. Persistent Bonding: Paired clients are remembered across power cycles; the device will prioritize reconnection from previously bonded clients.
Factory Reset
trigger: Press and hold the boot button (GPIO0) for 5+ seconds, or power-cycle the device (unplug and replug USB). — effect: On long button press: NVS (non-volatile storage) is cleared, all bonded clients are forgotten, and the device restarts fresh. All LEDs briefly flash, then resume normal operation with clean state. On power-cycle: Device restarts with stored bonding info intact (unless NVS was manually erased).
Failure Modes
scenario: BLE client disconnects unexpectedly — behavior: LED2 turns off; device continues advertising (LED1 resumes blinking). Heart rate simulation continues internally even if no client is listening. · scenario: USB power unplugged — behavior: All operation stops immediately. On USB reconnect, device boots fresh and resumes advertising. · scenario: BLE stack crash or reset — behavior: Device may watchdog reset. On recovery, it reinitializes NimBLE stack and advertising (LED1 resumes blinking).
Power Management
batteryPowered: false — powerSource: USB 5V (always powered)
Custom Behavior
Simulated Heart Rate Algorithm: Firmware simulates a realistic heart rate waveform (e.g., 60–100 BPM range with small variations per sample to mimic real physiology). Body Sensor Location: Hard-coded to a fixed value (e.g., chest or wrist) accessible via the Body Sensor Location characteristic; read-only, no changes in firmware. Timing Feedback: Logging of notification counts every 120 seconds is intended for demonstration and debugging; it may be printed to UART console or logged internally.
Published 2026-09-01
Built with ESP ZeroCode AI — describe a device, get production firmware.