BLE-уведомления: шлём данные на телефон

Сервер из прошлого урока я довёл до ума и тут же упёрся в неудобство: чтобы увидеть свежую температуру в теплице, надо было каждый раз брать телефон, открывать nRF Connect, жать Connect и тыкать кнопку «читать». Значение обновлялось ровно тогда, когда я об этом просил, — то есть никогда сам. Через неделю таких ручных сеансов я понял, что построил цифровой термометр с ручным заводом, и полез искать, как плата сообщает данные сама. Сам сервер переделывать не пришлось — структура сервис, характеристика, реклама осталась та же, меняется только способ доставки значения.

Ответ — механизм notify, и со второй попытки он заработал, а первая была показательным провалом: я вызвал notify() в setup(), ещё до того, как хоть один клиент подключился, — пакет улетел в пустоту, и никаких предупреждений ни компилятор, ни Serial мне не показали. Вторая грабля ждала на стороне телефона: подписка, которую делает приложение, оказалась отдельным действием — без него плата шлёт и шлёт, а телефон молчит. Разбираем обе темы по косточкам: что происходит на проводе при подписке и как правильно слать поток показаний.

У характеристики, которой разрешён notify, появляется служебный дескриптор CCCD — Client Characteristic Configuration Descriptor, стандартный UUID 0x2902. Это два байта, и когда в приложении вы жмёте кнопку подписки, телефон пишет в них 0x0001: «присылай уведомления по этой характеристике». Хочешь delivery с подтверждением — телефон пишет 0x0002 и получает indicate: та же посылка, но плата ждёт квитанцию от клиента, поэтому медленнее. В nRF Connect это те три стрелочки рядом с характеристикой: одна читает, вторая подписывает на notify, третья — на indicate. Ключевая деталь: подписка живёт на стороне телефона и привязана к соединению — после разрыва CCCD обнуляется, и при новом подключении приложение подписывается заново.

Теперь про размер. По умолчанию MTU BLE-соединения — 23 байта, из которых три уезжают на заголовок протокола: на полезную нагрузку notify-пакета остаётся 20 байт. Телефон может попросить больше — nRF Connect на старте обычно поднимает MTU до 185-517, и ESP32 согласится, — но закладываться надо на худший случай: 20 байт на пакет. Моя строка показаний t=23.5;h=44;n=12 — это 16 символов, влезает с запасом. Если когда-нибудь упрётесь, переходите на компактный формат: температура как целое, умноженное на сто, — два байта вместо шести символов.

И про ритм: notify() не летит в эфир мгновенно — пакет ставится в очередь ближайшего connection event, а интервалы связи задаёт телефон. Стандарт разрешает от 7,5 мс до 4 секунд, телефоны на практике выбирают 30-100 мс. Отсюда вывод, который сэкономил мне вечер экспериментов: слать чаще, чем раз в несколько десятков миллисекунд, бессмысленно — пакеты просто сольются; раз в секунду, как в моём скетче, BLE даже не заметит нагрузки. Сам секундный таймер я собрал на millis() без единого delay по уроку про планировщик — тот же приём, что и в предыдущем уроке.

Отдельный вопрос — чем паковать значение. Текст вроде t=23.5;h=44 читается в любом приложении-сканере глазами, и для отладки это золото. Бинарный вариант компактнее: температура как целое, умноженное на сто, — два байта вместо шести символов; но в сканере такой пакет выглядит как hex-строка 09 30, и без таблицы формата вы не поймёте ни байта. Моё правило: показания — текстом, пока пакет не упрётся в 20 байт; сырые потоки данных, где каждый байт на счету, — уже бинарными полями, и тогда в документации к характеристике живёт таблица расшифровки.

Тут три новинки против прошлого урока, и каждая — по делу. Первая — колбэки: класс ServerCB перехватывает onConnect и onDisconnect, и флаг connected позволяет слать только тогда, когда есть кому. Вторая — addDescriptor(new BLE2902()): именно эта строка прицепляет дескриптор 0x2902, в который телефон пишет свою подписку; без него на ядрах Arduino-ESP32 2.x приложение даже не покажет кнопку подписки. К слову, с ядра 3.0 BLE-библиотека переехала на стек NimBLE, и там дескриптор добавляется автоматически — но и лишняя строка не мешает, код остаётся совместимым с обеими ветками. А бонусом NimBLE экономит сотни килобайт флеша и около 30 КБ RAM — на проектах рядом с WiFi это заметно.

Про строку с setValue — отдельно, потому что тут самая незаметная грабля. Метод принимает указатель на байты и длину, и длина у меня считается через pkt.length() — как в любом настоящем Arduino-коде со String. Лимит в 20 байт при дефолтном MTU никто проверять за вас не будет: длинная строка молча обрежется, и телефон начнёт показывать хвосты. В боевом скетче на этом месте стоит dht.readTemperature() — подключение датчика я разбирал в уроке про DHT11. А привычка печатать собранный пакет в Serial парой имя=значение, поставленная в уроке про отладку логики, ловит кривой формат ещё до телефона.

Третья — правильный разрыв связи. Когда телефон уходит, BLE-сервер молча останавливает рекламу, и плата выпадает из всех сканеров навсегда — я однажды гонял цикл «переподключиться» по двадцать минут, пока не догадался, что после первого же разрыва устройство больше не рекламируется. Строка BLEDevice::startAdvertising() внутри onDisconnect возвращает плату в эфир; на millis() она не тратит ни такта, пока разрыва нет. Формат пакета в setValue — тот же текст t=...;n=..., который мы репетировали в симуляторе прошлого урока: читать такие значения можно в любом приложении без расшифровки байтов, что при отладке в поле экономит больше времени, чем компактный бинарный формат.

В симуляторе ниже — та же механика, но с датчиком: раз в секунду скетч собирает строку показаний DHT и печатает её в Serial. BLE-стек движок страницы не поднимает, поэтому подписку CCCD здесь изображает флаг cccd=1, включённый с самого старта: считайте, что телефон уже ткнул стрелку подписки. Никакой магии в этом флаге нет — это честная заглушка вместо пакета, который телефон писал бы в дескриптор. Смотрите на ритм и формат — они один в один совпадают с тем, что вы увидите в nRF Connect на живой плате, включая счётчик пакетов.

Поток показаний на телефон — уже полноценный IoT на одном радиомодуле, без роутера и облака. Если такой же поток нужен не телефону, а серверу, сравните ощущение: в уроке про HTTP-запросы с ESP32 плата сама стучится в сеть за данными, и та же строка t=...;h=... без изменений уезжает в POST-запросе. Bluetooth и HTTP в моём хозяйстве делят так: телефон рядом — BLE, данные в интернет — WiFi.

А тем, кому нужен не поток данных, а терминал — печатать логи и вводить команды по воздуху, как в мониторе порта, — дальше по маршруту урок про Bluetooth SPP: там классический Bluetooth и SerialBT, знакомый Serial без единого провода. И да, про батарею: пик радио — порядка сотни миллиампер, BLE экономит не током, а скважностью, поэтому для батареечных устройств следующий шаг — глубокий сон между рассылками.