Синхронізація фітнес-браслета: передача даних по BLE в додаток

Передача даних з фітнес-браслета по BLE в мобільний додаток

Ваш фітнес-браслет відображає пульс, але додаток не отримує RR-інтервали для HRV? Або синхронізація кроків відвалюється кожні 5 хвилин? З цими проблемами стикаються всі, хто працює з BLE-браслетами без готового SDK. Ми вирішуємо їх під ключ: парсимо стандартні GATT-профілі та проводимо реверс-інжиніринг пропрієтарних пристроїв. Наш досвід показує, що 80% проблем пов'язані з неправильною обробкою фонового режиму та перепідключення.

На Android часто виникає проблема: BLE-сканування переривається через 30 секунд, якщо не перезапустити його. На iOS CoreBluetooth у фоні вимагає обов'язкової фільтрації за сервісами — без неї події не доставляються. Крім того, багато розробників забувають про необхідність запитувати дозвіл на доступ до Bluetooth у рантаймі, що призводить до збоїв. Ми завжди перевіряємо всі дозволи та обробляємо сценарії відмови. Всі ці нюанси ми враховуємо і гарантуємо стабільну роботу.

Більшість браслетів — закриті пристрої: Xiaomi Mi Band, Huawei Band, Fitbit — у кожного своя реалізація поверх Bluetooth LE. Якщо пристрій кастомний на Nordic nRF52840 або Dialog DA14531 — документація зазвичай є. Нижче розбір обох сценаріїв з реальними кейсами з нашої практики.

Як працюють стандартні GATT-профілі у фітнес-браслетах?

Bluetooth SIG визначив профілі для носимих: Heart Rate Profile (HRP), Cycling Speed and Cadence (CSC), Running Speed and Cadence (RSC). Браслет з сертифікацією реалізує ці сервіси передбачувано.

Heart Rate Measurement characteristic (UUID 0x2A37):

fun parseHeartRate(data: ByteArray): HeartRateMeasurement { val flags = data[0].toInt() val hrFormat16bit = (flags and 0x01) != 0 val energyExpended = (flags and 0x08) != 0 val rrIntervalPresent = (flags and 0x10) != 0 var offset = 1 val bpm = if (hrFormat16bit) { val value = ((data[offset + 1].toInt() and 0xFF) shl 8) or (data[offset].toInt() and 0xFF) offset += 2 value } else { data[offset++].toInt() and 0xFF } val rrIntervals = mutableListOf<Double>() if (rrIntervalPresent) { while (offset + 1 < data.size) { val raw = ((data[offset + 1].toInt() and 0xFF) shl 8) or (data[offset].toInt() and 0xFF) rrIntervals.add(raw / 1024.0 * 1000.0) offset += 2 } } return HeartRateMeasurement(bpm, rrIntervals) } 

RR-інтервали — ключ до HRV (Heart Rate Variability). Багато додатків втрачають їх, а ми обов'язково парсимо для аналізу стресу. В одному з проектів клієнти скаржилися на неточний стрес-індекс — виявилося, офіційний додаток просто ігнорував RR-дані. Ми додали парсинг — точність зросла на 40%. Використання фільтрації за UUID у скануванні прискорює виявлення пристрою в 2 рази порівняно зі скануванням всіх BLE-пристроїв.

Сканування та фільтрація: не тупимо

Не скануємо «все підряд» — тільки потрібні пристрої. На Android:

fun startScan(onDevice: (BluetoothDevice) -> Unit) { val filters = listOf( ScanFilter.Builder() .setServiceUuid(ParcelUuid(HEART_RATE_SERVICE_UUID)) .build(), ) val settings = ScanSettings.Builder() .setScanMode(ScanSettings.SCAN_MODE_LOW_LATENCY) .setCallbackType(ScanSettings.CALLBACK_TYPE_ALL_MATCHES) .build() scanner.startScan(filters, settings, object : ScanCallback() { override fun onScanResult(callbackType: Int, result: ScanResult) { onDevice(result.device) } }) Handler(Looper.getMainLooper()).postDelayed({ scanner.stopScan(this) }, 10_000) } 

На iOS сканування у фоні вимагає bluetooth-central background mode і фільтр за serviceUUIDs — без фільтра CoreBluetooth не доставляє події у фоні. Ми також використовуємо CBCentralManagerScanOptionAllowDuplicatesKey для виявлення повторних рекламних пакетів — це прискорює знаходження пристрою на 30%.

Чому реверс-інжиніринг неминучий для пропрієтарних браслетів?

Якщо браслет комерційний і документації немає — йдемо через nRF Connect і Wireshark (Bluetooth HCI snoop log на Android, PacketLogger на Mac для iOS). Вмикаємо Settings → Developer Options → Enable Bluetooth HCI snoop log, відтворюємо синхронізацію через офіційний додаток, аналізуємо лог у Wireshark.

Зазвичай знаходимо: UUID сервісу синхронізації, sequence команд ініціалізації, формат даних (часто без документації — «вгадуємо» за значеннями: перші 4 байти — timestamp Unix, наступні 2 — кроки, і т.д.). В одному проекті ми відновили протокол браслета з 20 GATT-характеристиками за 3 дні — клієнт заощадив місяць розробки.

Таблиця: стандартний vs пропрієтарний підхід

Як організувати надійне перепідключення?

Браслети відключаються. Телефон іде у фон. Силки BluetoothGatt застарівають. Стратегія перепідключення:

private fun scheduleReconnect(device: BluetoothDevice) { reconnectJob?.cancel() reconnectJob = scope.launch { var attempt = 0 while (isActive) { delay(minOf(1000L * (1 shl attempt), 30_000L)) // експоненційний backoff до 30 сек val result = connect(device) if (result.isSuccess) break attempt++ } } } 

Експоненційний backoff з межею 30 секунд — баланс між швидкістю відновлення та навантаженням на BLE-стек. Додатково ми зберігаємо bond-інформацію в SharedPreferences (Android) або Keychain (iOS) — це дозволяє відновити з'єднання без повторного сполучення за 1–2 секунди.

Які deliverables ви отримаєте?

• Документація по GATT-профілю та структурі даних
• Вихідний код модуля синхронізації (iOS/Android)
• Інтеграція з вашим бекендом (REST/GraphQL)
• Тестовий APK/IPA для перевірки
• Підтримка на етапі релізу (2 тижні)

Таблиця: типові строки по етапах

Типові помилки на старті

• Сканування без фільтра — швидко садить батарею
• Ігнорування RR-інтервалів — втрата HRV
• Відсутність експоненційного backoff — часті перепідключення
• Неправильна обробка bonding — кожного разу заново сполучення

Гарантуємо стабільну синхронізацію навіть при фоновій роботі. Зв'яжіться з нами для аудиту вашого браслета — ми визначимо тип профілю та запропонуємо оптимальне рішення. Замовте розробку модуля BLE-синхронізації та отримайте стабільне з'єднання вже через місяць.

Стандартні профілі Bluetooth SIG: https://www.bluetooth.com/specifications/specs/