(eu version lumi.gateway.mieu01)

В этом посте я расскажу как можно собирать данные BLE и передавать через MQTT в системы умного дома, например в HomeAssistant.

Как все начиналось?

Эта история началась в прошлом году: у меня появился несколько таких шлюзов. В то время было несколько статей по получению root доступа, интеграции miio в HA и по прошивке чистого openwrt на шлюз. Толчком к развитию стал сезон распродаж в разных магазинах, где стоимость шлюза стремилась к нулю, и многие энтузиасты получили интересную железку.

Первым большим делом для меня было заставить работать zigbee2mqtt с чипом и прошивкой находящимся в шлюзе. И пока я допиливал интеграцию в zigbee-herdsman, ребята в чатике @xiaomi_gw_hack занимались добавлением поддержки в openwrt периферии, которая была в шлюзе (светодиоды RGB, динамик, датчик света, wi-fi модуль).

Отдельное спасибо @lenz1986, @Alx2000y, @belokobylskiy!

Было обнаружено, что в wifi модуле rtl8723bs европейской версии шлюза есть встроенный bluetooth с поддержкой BLE.

Но в стоковой системе на шлюзе нет никаких следов bluetooth. И лишних uart, по которому можно было бы с ним работать тоже. @lenz1986 провел раскопки

Он вызвонил контакты, и обнаружил что на плате разведены все 4 UART от процессора. Один из которых вел на uart от bluetooth части модуля wifi rtl8723bs. Потом он добавил поддержку этого uart в DTB, где описываются вся периферия устройства для openwrt и нашел подходящие драйвера. За что @lenz1986 огромное спасибо!

модуля

Внимание! Все действия я описываю и делаю на базе openwrt прошивки для шлюза. Установить ее можно по воздуху просто подключившись по uart к шлюзу. (спасибо @divanikus)

Подробнее описано на https://openlumi.github.io/

Bluetooth инициализируется через rtk_hciattach при запуске шлюза. После загрузки мы получаем такую картину hciconfig

Я знаю 2 пути, как можно включить bluetooth адаптер.

• Руками hciconfig hci0 up

• изменив параметр AutoEnableконфиге /etc/bluetooth/main.confна true

Я выбираю второй. Интерфейс запущен. Для проверки можно запустить скан hcitool lescan

Работа с BLE

Мои знания по BLE были на нуле, и чтобы было проще разобраться я искал что-то готовое по типу zigbee2mqtt. Перепробовал несколько решений на Node.Js, в том числе пакеты для node-red. Остановился на проекте EspruinoHub. (хоть и код там не супер современен и технологичен, но зато работает)

После запуска с отсылкой данных в локальный mqtt сервер, в CLI и web интерфейсе уже показались распарсенные данные с части датчиков LYWSDCGQ (круглые гигротермографы) .

Это меня порадовало, но у меня было еще несколько устройств, данные от которых я увидел почти в raw виде. И я решил использовать эту программу и немного улучшить ее.

Многие устройства Xiaomi с bluetooth шлет BLE Advertising Packet, в большинстве случаев в нем содержится полезная нагрузка в виде измерений, которые производит устройство. Часто данные отправляются открыто, но используется шифрование с ключом.

Например для браслета MiBand данные выглядят вот так. Если есть данные о пульсе то они добавляются в конец

В устройствах xiaomi, часто используется BLE сервис fe95. В интернете есть небольшая документация по нему .На github есть множество проектов которые умеют парсить эти данные. На основе этих данных и существующей реализации espruino я немного улучшил парсинг открытых данных, но потом я нашел более красивое решение из hannseman/homebridge-mi-hygrothermograph. Мне особенно понравилась стандартизация разных событий и расшифровка исходя из данных заголовка.

Этот парсер закрыл вопрос с большинством устройств Xiaomi, отправляющих данные в fe95. Можно еще попробовать добавить некоторые типы событий (движение, дым, нажатие на кнопку), но у меня нет таких устройств под рукой.

Я добавил в EspruinoHub данный парсер, и реализовал возможность указать настройки для разных устройств. Это необходимо для устройств, которые шифруют с помощью bindKey свои пакеты. Получить bindKey можно из miHome.

MQTT Discovery - Home Assistant

Данных стало больше, но хотелось чтобы они автоматически появлялись в HomeAssistant. EspruinoHub отправляет данные которые и слышит в эфире, и не имеет на данный момент привязки к конкретным устройствам. Поэтому в момент появления данных, если они из списка поддерживаемых отправляется config устройства в топик homeassistant в mqtt и устройства появляются в системе умного дома

Добавленные и протестированные устройства.

В результате изучения разных решений и raw сообщений от устройств удалось добавить или улучшить интеграцию следующих устройств в пассивном режиме (только слушаем эфир не подключаемся к устройствам и не тратим батарейку).

LYWSDCGQ - работал "из коробки". Добавил только mqtt discovery в HA

LYWSD02 - температура, влажность и батарейка

Самый бюджетный датчик температуры и влажности с экраном LYWSD03MMC - температура, влажность и батарейка (нужен bindKey). Существует 2 альтернативные прошивки, они очень крутые и продвинутые. Особенно от Виктора pvvx. Рекомендую использовать именно ее. Помимо лучшего потребления она шлет данные в одном пакете, а не в трёх и имеет множество настроек.

MI SCALE - 181d v1 По крупицам из разных источников допилена реализация в которой показываются данные о - стабилизации веса (весы моргают) - убрали вес (встали с весов) - дата и время измерения. 181b v2 Работает, но не тестировал лично. Возможно нужно что-то допилить

Mi band 3 fee0 Шаги и Пульс в режиме тренировки. Чтобы браслет отправлял данные необходимо включить обнаружение в MiFit.

Как оказалось шлюз очень хорошо и далеко слышит, а эта функция включена у многих людей. Работает это и для других моделей и даже на некоторых часах например Amazfit GTS

HHCCJCY01 MiFlora, Huahuacaocao - temperature, moisture, illuminance, conductivity, battery_level

Другие устройства тоже можно попробовать подключить. Если они шлют в кодированном виде, то в mqtt об этом будет ошибка с просьбой указать bindKey в конфиг.

YEERC - я обнаружил что прошивка для esp32 tasmota сообщает, что поддерживает данный пульт. Он идет в комплекте с многими люстрами YEELIGHT, но к сожалению у меня не получилось нигде найти как получить 32 символьный bindKey для него. Сообщения нажатий я вижу, но не могу расшифровать. (Значение event закодировано и зависит от counter который увеличивается с каждым нажатием) Возможно кто-то из читателей подскажет как добыть данный ключик. Пульт можно привязать к нескольким люстрам в разное время и они будут вместе расшифровывать и отрабатывать нажатия. Скорей всего ключ там не изменяется со временем или привязкой.

Как установить EspruinoHub на шлюз Xiaomi с OpenWrt ?

Можно установить и на другие устройства с помощью git / npm, инструкция на странице проекта EspruinoHub

Установка

Мои последние наработки собраны в пакет и ставятся с помощью opkg

Необходимо подключить фид по инструкции https://openlumi.github.io/openwrt-packages/

Дальше установить собранный пакет.

opkg updateopkg install node-espruinohub

Конфигурирование

По-умолчанию он будет пытаться подключиться к локальному mqtt без авторизации. Если вы хотите подключить к внешнему брокеру mqtt, то нужно изменить конфиг в /etc/espurinohub/config.json

Внимание! у некоторых настроек в начале стоят слеши чтобы они не применялись. (конфиг в этом проекте частично сделан как пример и я не стал ничего менять)

Пример конфига можно посмотреть тут. Если вы знаете мак адреса своих устройств то рекомендую их прописать и установить"only_known_devices": true, чтобы не отправлялись данные с чужих устройств из эфира.

Для работы с HomeAssistant достаточно отправлять данные в json формате, а остальное можно выключить. По умолчанию будет отправлять в топики с группировкой по типу данных.

"mqtt_format_json": true,"homeassistant": true,"mqtt_cache_state": true

Планы

Отслеживание носимых устройств по rssi между комнатами. Для этого в конфиг я добавил возможность указать минимальный rssi в разрезе устройства и таймаут присутствия.

Активные подключения: хочу попробовать управлять некоторыми устройствами по BLE, но для одновременного подключения и сканирования Bluetooth модуль и ПО могут работать нестабильно. Поэтому я пока только изучаю этот вопрос.

Альтернативные opensource проекты работающие с BLE на шлюзе

• devbis/ble2mqtt - своя реализация на python через bleak, умеет подключаться к чайникам, но сильно грузит процессор.

• Beetle-II/lumi - тот же парсер из hannseman/homebridge-mi-hygrothermograph, но без возможности задать индивидуальный ключ bindKey для устройства. Нет raw данных и управление через mqtt. + Умеет работать не только с BLE.

Заключение

Спасибо, что дочитали до конца!

Если у Вас есть вопросы, то можете задавать их в комментариях.

Создание кастомного сервиса и тем более клиента Bluetooth Low Energy прогулка по граблям с завязанными глазами. По крайне мере так было для меня 4 года назад, когда я только начинал работать с BLE-устройствами. Сейчас почти каждый мой проект предусматривает использование этого протокола, поэтому в свое время пришлось в нем долго и мучительно разбираться.

Разложить все по полкам помогла книга Мохаммада Афане "Intro to Bluetooth Low Energy" и серия постов на Novel Bits. Лично для меня эта книга стала настоящим открытием. Изначально я делал ее перевод на русский для своих коллег, не имеющим опыт работы с BLE. С согласия автора (огромное ему спасибо) решил опубликовать свою работу здесь. Надеюсь, перевод окажется полезным.

Это первая часть перевода (всего их будет 5), которая рассказывает, что такое BLE, ее возможности и отличия от Bluetooth Classic и описывает архитектуру протокола.

Об авторе

Мохаммад Афане занимается разработкой встроенного программного обеспечения и прошивок с 2006 года. Он работал и консультировал множество крупных компаний, включая такие как Allegion (Schlage locks), Motorola, Technicolor, Audiovox, и Denon & Marantz Group. На протяжении всей своей карьеры он работал над множеством проектов Интернета Вещей, включая: беспроводные электронные дверные замки, спутниковые приемники, беспроводные дверные замки и т.д.

В июле 2015 года он принял решение прекратить работу на полную ставку для того, чтобы основать собственную компанию Novel Bits, LLC, где он делится своими знаниями и опытом на своем web-сайте, локальных тренингах и в электронных книгах, посвященных разработке приложений с поддержкой Bluetooth Low Energy.

Вы можете связаться с Мохаммадом по его электронной почте: mohammad@novelbits.io или через профиль на LinkedIn.

Базовые понятия Bluetooth Low Energy

1. Что такое Bluetooth Low Energy?

Bluetooth был задуман как технология связи ближнего диапазона, призванная заменить провода в таких устройствах, как компьютерные мыши, клавиатуры или персональные компьютеры. Если у вас есть современный автомобиль или смартфон, то скорее всего вы использовали Bluetooth хотя бы раз в своей жизни. Он повсюду: в громкоговорителях и колонках, беспроводных наушниках, автомобилях, носимых устройствах и даже в шлёпанцах!

Первая официальная версия стандарта была выпущена компанией Ericsson в 1994 году. Разработчики назвали свое изобретение в честь короля Дании Харальда Гормссона по прозвищу Синезубый, объединившего в 10 веке враждовавшие датские племена в единое королевство.

В настоящее время существует два типа устройств с поддержкой Bluetooth:

• Bluetooth Classic (BR/EDR), используется в беспроводных громкоговорителях, автомобильных информационно-развлекательных системах и наушниках;

• Bluetooth Low Energy (BLE), т.е. Bluetooth с низким энергопотреблением, который появился в версии стандарта Bluetooth 4.0. Он чаще всего применяется в приложениях, чувствительных к энергопотреблению (например в устройствах с батарейным питанием) или в устройствах, передающих небольшие объемы данных с большими перерывами между передачами (например, разнообразные сенсоры параметров окружающей среды или управляющие устройства, такие как беспроводные выключатели).

Эти два типа устройств несовместимы друг с другом, даже если они выпущены под одним брендом или спецификацией. Устройства с поддержкой Bluetooth Classic не могут напрямую связываться с устройствами, использующими BLE. Это причина, по которой некоторые устройства, такие как смартфоны, выполняются с поддержкой обоих типов соединения (так называемые Dual mode Bluetooth devices), что позволяет им обмениваться информацией с обоими типами устройств.

Несколько важных замечаний о BLE:

• Официальная спецификация Bluetooth сочетает оба типа Bluetooth (Classic и BLE), что иногда затрудняет поиск документации, специфичной для BLE;

• BLE был введен в версии 4.0 спецификации стандарта Bluetooth, выпущенной в 2010 году;

• BLE иногда называют Bluetooth Smart, BTLE или Bluetooth 4.0, что является ошибкой, так как эта версия в действительности включает оба типа Bluetooth;

• Bluetooth Classic и BLE работают в одном и том же частотном диапазоне 2.4 ГГц, ISM-диапазон.

Поскольку во многих устройствах Интернета Вещей (IoT) используются небольшие устройства и датчики, BLE стал наиболее часто используемым протоколом связи (в сравнении с Bluetooth Classic) в приложениях Интернета Вещей. В декабре 2016 года группа компаний Bluetooth Special Interest Group (SIG), регулирующая развитие стандарта, выпустила Bluetooth версии 5.0 (для простоты маркетинга была убрана точка из названия, так что официально он называется Bluetooth 5). Большинство улучшений и новых функций, представленных в этой версии, были ориентированы на BLE, а не на Bluetooth Classic.

Вы также могли слышать о другом термине, связанном с Bluetooth Bluetooth Mesh. Bluetooth Mesh был выпущен в июле 2017 года и основан на BLE. Для работы ему требуется полный стек BLE (ПО, которое действует как интерфейс для другого программного или аппаратного обеспечения), но он не является частью основной спецификации Bluetooth. Мы рассмотрим более подробно эту технологию в отдельной главе.

Подводя итог, посмотрим на диаграмму, показывающую прогресс BLE за прошедшие годы с начала его появления:

Технические факты о BLE

Некоторые из наиболее важных технических фактов о BLE включают в себя:

• Используемый частотный диапазон 2.400 - 2.4835 ГГц.

• Весь частотный диапазон поделен на 40 каналов по 2 МГц каждый.

• Максимальная скорость передачи данных по радиоканалу (начиная с Bluetooth версии 5) 2Мбит/с.

• Дальность передачи сильно зависит от физического окружения, а также используемого режима передачи. Например, в режиме большой дальности передачи дальность связи будет выше, а скорость передачи ниже, чем в высокоскоростном режиме. Типичная дальность передачи: 10-30 метров.

• Потребление электроэнергии также может изменяться в широких пределах. Оно зависит от реализации устройства, различных параметров протокола и используемого чипсета. Типичное потребление BLE-трансивера во время передачи данных как правило не превышает 15 мА.

• Обеспечение безопасности не обязательно при обмене данными через BLE и зависит от устройства и реализации приложения разработчиком. Другими словами, существует несколько возможных для реализации уровней обеспечения безопасности.

• Для всех операций, связанных с шифрованием, BLE использует алгоритм AES-CCM с длиной ключа 128 бит.

• BLE предназначен для передачи данных по каналу с низкой пропускной способностью. Использование BLE для приложений с большим объемом часто передаваемых данных существенно увеличивает потребление электроэнергии и сводит на нет основное преимущество BLE. То есть минимизация использования радиосвязи, насколько это возможно, позволяет достичь минимального уровня потребления энергии.

• Версии Bluetooth (в части BLE) являются обратно совместимыми. Тем не менее возможности связи будут ограничены функциями более старой версии. Например, устройство с поддержкой Bluetooth 5 LE может установить связь с устройством с поддержкой Bluetooth 4.1 LE, но возможности, появившиеся в версии 4.2 и более новых, будут недоступны. В то же время они смогут использовать возможности подключения, рассылки и приема широковещательных пакетов, обнаруживать сервисы и характеристики, а также читать и записывать их независимо от поддерживаемой ими версии стандарта, так как эти возможности доступны во всех версиях Bluetooth.

Сравнение Bluetooth Classic и BLE

Важно помнить, что существует большая разница между классическим Bluetooth и Bluetooth с низким энергопотреблением с точки зрения технических спецификаций, реализации и типов приложений, для которых они предназначены. Это в дополнение к тому факту, что они несовместимы друг с другом.

Некоторые из упомянутых различий представлены в этой таблице:

Таблица 1. Сравнение Bluetooth Classic и BLE

С момента официального выпуска в 2010 году BLE прошел череду ревизий и изменений. Наиболее важное изменение произошло в декабре 2016 года с внедрением Bluetooth 5, который привнес множество важных улучшений в спецификацию стандарта, большинство из которых касалось BLE. Эти улучшения позволили удвоить скорость передачи, в 4 раза увеличить дальность передачи и в 8 раз увеличить размер широковещательного пакета.

Возможности и ограничения BLE

Каждая технология имеет свои ограничения, и BLE не является исключением. Как мы упомянули ранее, BLE наилучшим образом подходит для приложений с небольшим радиусом передачи и редко передаваемыми небольшими объемами данных.

4.1. Ограничения BLE

Пропускная способность

Пропускная способность BLE ограничена физической пропускной способностью радиоканала, т.е. скоростью, с которой данные передаются по радиоканалу. Пропускная способность зависит от используемой версии Bluetooth. Для Bluetooth 4.2 и более ранних, доступна только пропускная способность в 1 Мбит/с. В Bluetooth 5 и более поздних версиях пропускная способность зависит от выбранного режима PHY (Physical Layer, рассматривается в разделе физического уровня). Она может составлять 1 Мбит/с как в более ранних версиях или 2 Мбит/с при использовании высокоскоростной передачи. При использовании функции дальней связи пропускная способность ограничена значениями 500 или 125 Мбит/с. Мы обсудим это более подробно в главе, посвященной Bluetooth 5.

Скорость передачи с точки зрения конечного пользователя всегда будет ниже скорости передачи по радиоканалу в силу следующих факторов:

• Промежутки между пакетами данных: спецификация Bluetooth определяет зазор в 150 микросекунд между передаваемыми пакетами как требование для соблюдения спецификации. В этот промежуток времени невозможна передача данных между устройствами.

• Служебная информация внутри пакета: каждый пакет содержит помимо полезной нагрузки заголовок и служебные данные, обрабатываемые на уровнях ниже уровня приложения. Они учитываются при передаче данных, но не используются вашим приложением.

• Требование на передачу служебной информации периферийным устройством: спецификация требует обязательного ответа ведомого устройства на каждый пакет, переданный ведущим. В случае, когда необходимая для передачи информация отсутствует, передается пустой пакет.

• Переотправка пакетов данных: в случае потери пакета или перекрестных помех от находящихся поблизости устройств, потерянные или поврежденные данные отправляются заново.

Дальность передачи

BLE был разработан для применения на коротких расстояниях, и, следовательно, его диапазон действия ограничен. Вот некоторые факторы, ограничивающие дальность передачи при помощи BLE:

• На передачу в ISM-диапазоне 2.4 ГГц сильно влияют окружающие нас препятствия, такие как металлические предметы, бетонные стены, вода и человеческие тела.

• Диаграмма направленности и коэффициент усиления антенны.

• Корпус устройства, в котором находится антенна, также ухудшает характеристики антенны.

• Ориентация устройства в пространстве, от которого зависит ориентация антенны, например в смартфонах.

Потребность в шлюзе для интернет-соединения

Для передачи данных с устройства, поддерживающего только BLE-соединение, необходимо другое устройство с поддержкой как BLE, так и IP-соединения. Именно оно будет получать данные и отправлять их в интернет.

4.2 Преимущества BLE

Даже с учетом представленных выше ограничений BLE имеет некоторые существенные преимущества перед другими аналогичными технологиями передачи данных для IoT.

Вот некоторые из них:

• Меньшее энергопотребление;

По сравнению с другими низкопотребляющими технологиями передачи данных, BLE потребляет гораздо меньше электроэнергии. Это достигается благодаря глубокой оптимизации протокола, выключению передатчика при первой возможности и пересылке малых объемов данных на низкой скорости.

• Бесплатный доступ к официальным спецификациям;

Чтобы получить доступ к спецификациям большинства других протоколов вы должны стать членом официальной группы или консорциума по этому стандарту. Стать членом можно за внушительную сумму (от 7500 до 35000 долларов в год). В случае с BLE, спецификации для основных версий (4.0, 4.1, 4.2, 5) доступны для загрузки с сайта Bluetooth абсолютно бесплатно.

• Низкая цена модулей и чипсетов по сравнению с другими технологиями;

• Наконец, не менее важный фактор наличие в большинстве смартфонов на рынке. Возможно, это наибольшее преимущество BLE перед такими технологиями как ZigBee, Z-Wave и Thread.

4.3 Наиболее подходящие области применения BLE

Исходя из ограничений и преимуществ, указанных выше, существуют варианты использования, где BLE раскрывается наиболее полно:

• Малый объем передаваемых данных;

BLE подходит для случаев, когда устройство передает небольшие объемы данных, например, данные датчиков или команды исполнительных устройств.

• Настройка устройств;

В случаях, когда BLE не удовлетворяет основным требованиям системы, он может использоваться для настройки устройства до того, как оно окажется подключенным к основной сети передачи данных.

Например, некоторые устройства с поддержкой WiFi добавляют BLE как вспомогательный протокол вместо использования таких технологий как WiFi Direct. Это технология, которая позволяет двум устройствам с поддержкой WiFi соединяться напрямую, минуя роутер. Вы можете узнать подробнее о ней на Википедии или здесь.

• Использование смартфона в качестве интерфейса;

Компактные малопотребляющие устройства обычно не имеют больших экранов и зачастую отображают ограниченное количество данных конечному пользователю,например, путем светодиодной индикации. В настоящее время, благодаря широкому распространению смартфонов, BLE может предложить альтернативный, гораздо более информативный и удобный интерфейс для этих устройств. Еще одним преимуществом смартфона является возможность загрузки данных в облако.

• Персональные и носимые устройства;

Для случаев, когда устройство является носимым и находится вне зоны покрытия беспроводных сетей (таких как WiFi или сотовая связь), BLE может оказаться единственным доступным способом подключения.

• Устройства без возможности установления соединения.

Вероятно вы слышали или видели ранее такие устройства как маячки. У этих устройств одна простая задача выдавать через определенные промежутки времени в эфир данные так, чтобы другие устройства могли их обнаружить и принять передаваемые данные. Существуют и другие технологии, которые могут быть использованы для этих целей. Тем не менее BLE становится все более популярным, так как большинство людей имеют смартфоны, которые поддерживают BLE из коробки.

Все вышеперечисленные сценарии только выигрывают от использования BLE. С другой стороны, есть условия, при которых, как правило, использование BLE невозможно или не дает ощутимых преимуществ, такие как:

• Потоковая передача видео;

• Трансляция высококачественного звука (прим.: стала возможна в BLE 5.2);

• Передача больших объемов данных в течении длительного времени в тех случаях, когда важно сокращение энергопотребления.

Архитектура BLE

Рисунок ниже иллюстрирует различные уровни, присущие архитектуре BLE. Три главных блока в этой архитектуре приложение, хост и контроллер.

В этой книге мы сфокусируемся на верхних уровнях архитектуры, кратко ознакомившись с нижними уровнями в этой главе. Подробное описание верхних уровней GAP (Generic Access Profile), GATT (Generic Attribute Profile) и Security Manager вынесем в отдельные главы.

Прикладной уровень

Прикладной уровень зависит от варианта использования девайса/приложения и относится к реализации на основе общего профиля доступа (GAP) и общего профиля атрибутов (GATT) он отвечает за то, как ваше приложение обрабатывает данные, полученные от других устройств и отправленные на них, а также управляющую логику.

Эта часть является кодом, который вы написали для своего приложения и, как правило, не является частью BLE-стека для платформы, под которую вы разрабатываете. Эта часть не рассматривается в книге, поскольку она зависит от специфики вашего приложения и способа использования.

Хост-уровень

Хост включает следующие уровни:

• Общий профиль доступа (GAP, Generic Access Profile);

• Общий профиль атрибутов (GATT, Generic Attribute Profile);

• Протокол атрибутов (ATT, Attribute Protocol);

• Менеджер безопасности (SM, Security Manager);

• Протокол управления и адаптации логических связей (L2CAP, Logical Link Control and Adaptation Protocol);

• Интерфейс хост-контроллера (HCI, Host Controller Interface), зона ответственности хоста.

Контроллер

Контроллер включает следующие уровни:

• Физический уровень (PHY, Physical Layer);

• Слой связи (Link Layer);

• Режим прямого тестирования (DTM, Direct Test Mode);

• Интерфейс хост-контроллера (HCI, Host Controller Interface), зона ответственности контроллера.

Уровни архитектуры BLE

Физический уровень (PHY)

PHY относится к части оборудования, ответственного за прием, передачу, модуляцию и демодуляцию сигнала. BLE работает в ISM-диапазоне (2.4 ГГЦ), который разделен на 40 каналов по 2 Мгц, как показано на рисунке ниже:

Три выделенных канала носят название Первичных Широковещательных Каналов, в то время, как оставшиеся 37 используются в роли Вторичных Широковещательных и для передачи данных во время соединения. Мы подробно рассмотрим принципы их использования в разделе Адвертайзинг и сканирование, но для начала кратко ознакомимся с ними в этой главе.

Адвертайзинг заключается в рассылке широковещательных пакетов по трем Первичным Каналам Адвертайзинга (или части из них). Это дает возможность обнаружить широковещающее устройство и прочитать его данные сканирующим устройствам. После этого сканирующее устройство может инициировать соединение, если широковещающее разрешает подключение. Также сканирующее устройство может послать запрос на сканирование, и, если широковещающее устройство поддерживает эту функцию, то оно пошлет ответ на сканирование. Запросы на сканирование и ответы на него позволяют передавать дополнительные данные без подключения к устройству.

Вот некоторые другие важные технические детали, касающиеся физического уровня передачи BLE:

• Он использует скачкообразную перестройку несущей частоты (FHSS, Frequency Hopping Spread Spectrum), что позволяет двум взаимодействующим устройствам переключаться на случайные предварительно согласованные частоты для обмена данными. Это значительно повышает надежность и позволяет устройствам избегать перегруженных каналов.

• Мощность передачи может быть:

Не более: 100 мВт (+20 дБм) для версии 5 и более новых, 10 мВт (+10 дБм) для версии 4.2 и более старых;

Не менее: 0.01 мВт (-20 дБм).

• В старых версиях Bluetooth (4.0, 4.1 и 4.2) была доступна только одна скорость передачи 1 Мбит/с. Физический уровень радио (PHY) в этом случае называется 1M PHY и является обязательным во всех версиях, включая Bluetooth 5. В Bluetooth 5 были также введены два новых дополнительных PHY:

  • 2 Мбит/с PHY, используемый для удвоения скорости передачи по сравнению с более ранними версиями Bluetooth.

  • Зашифрованный PHY, используемый для связи на дальних расстояниях.

Мы рассмотрим эти два новых PHY и концепцию кодирования в главе, посвященной Bluetooth 5.

Канальный уровень

Канальный уровень отвечает за взаимодействие с физическим уровнем радио и предоставление другим уровням абстракции для взаимодействия с радио (через промежуточный уровень интерфейса хост-контроллера, который мы вскоре обсудим). Он отвечает за управление состоянием радио и соблюдение требований к временным задержкам, необходимых для удовлетворения спецификации BLE. Также он отвечает за управление аппаратно-ускоренными операциями, такими как вычисление контрольных сумм, генерацию случайных чисел и шифрование.

Существует три основных состояния, в которых может находиться устройство с BLE:

• Широковещательное состояние (Advertising);

• Состояние сканирования (Scanning);

• Подключенное состояние.

Когда устройство посылает широковещательные пакеты, оно позволяет сканирующим устройствам обнаружить себя и подключиться. Если широковещающее устройство допускает подключения, сканирующее устройство нашло его и послало запрос на подключение, оба они переходят в подключенное состояние.

Канальный уровень управляет различными состояниями радио, показанными на рисунке:

• Standby: состояние по умолчанию, когда радио не передает и не принимает никаких данных.

• Advertising: состояние, в котором устройство посылает широковещательные пакеты для обнаружения и чтения другими устройствами.

• Scanning: состояние, в котором устройство ищет устройства, посылающие широковещательные пакеты.

• Initiating: состояние, в котором начинается процесс установки соединения с устройством, находящимся в состоянии advertising.

• Connected: Состояние, в котором одно устройство установило соединение с другим и регулярно обменивается с ним информацией. В подключенном состоянии устройство, которое находилось в состоянии scanning и инициировало соединение, называется ведущим. Устройство, которое рассылало широковещательные пакеты, называется ведомым.

Мы рассмотрим эти состояния более подробно в последующих главах.

Bluetooth адрес:

Bluetooth-устройства идентифицируются посредством 48-битного адреса, похожего на MAC-адрес. Существуют два основных типа адресов: публичный и случайный.

Публичный адрес:

Это фиксированный адрес, запрограммированный на фабрике. Он не может быть изменен и должен быть зарегистрирован в IEEE (также, как и MAC-адреса устройств с поддержкой WiFi или Ethernet).

Случайный адрес:

Так как у производителей есть возможность выбирать, какой тип адреса использовать (публичный или случайный), случайные адреса встречаются более часто, так как они не требуют регистрации в Институте инженеров электротехники и электроники. Случайный адрес программируется на устройстве или генерируется в ходе выполнения программы. Он может относиться к одному из следующих подтипов:

• Статический адрес

  • Используется в качестве замены публичного адреса;

  • Может быть заново сгенерирован при загрузке кода или оставаться постоянным в течение всего срока службы;

  • Не может изменяться при включении или выключении.

• Частный адрес включает в себя следующие подтипы:

  Неразрешимый частный адрес:

  • Случайный, генерируется на определенный промежуток времени;

  • Широко не используется.

  Разрешимый частный адрес:

  • Используется для обеспечения безопасности;

  • Генерируется с использованием ключа (IRK, Identity Resolving Key) и случайного числа;

  • Периодически меняется (даже во время соединения);

  • Используется для защиты от отслеживания злоумышленниками;

  • Доверенные устройства (связанные, описанные в главе, посвященной безопасности) могут расшифровать адрес, используя предварительно сохраненный ключ.

Режим прямого тестирования

Режим прямого тестирования (DTM, Direct Test Mode) используется исключительно для проведения испытаний радиочасти во время производства или сертификационных испытаний. Он не относится напрямую к теме нашей книги, поэтому мы оставим его без подробного рассмотрения.

Уровень интерфейса хост-контроллера (HCI)

Интерфейс хост-контроллера это стандартный протокол, определенный спецификацией Bluetooth, который позволяет уровню хоста коммуницировать с уровнем контроллера. Эти уровни могут быть реализованы на двух раздельных микросхемах или существовать на одной. В этом смысле он также обеспечивает взаимодействие между микросхемами, поэтому разработчик устройства может выбрать два сертифицированных Bluetooth-устройства, контроллер и хост, и быть на 100% уверенным в том, что они совместимы друг с другом в плане связи между уровнями хоста и контроллера.

В случае, когда хост и контроллер находятся на разных микросхемах, связь между ними может быть реализована посредством трех официально поддерживаемых физических интерфейсов: UART, USB или SDIO (Secure Digital Input Output). В случае, когда хост и контроллер находятся на одной и той же микросхеме, интерфейс хост-контроллера будет логическим интерфейсом.

Задача интерфейса хост-контроллера состоит в передаче команд от хоста контроллеру и передаче информации и событий от контроллера к хосту. На рисунке ниже приведен пример обмена командами и событиями между уровнями хоста и контроллера.

Примеры сообщений включают в себя: пакеты команд, настройку контроллера, запрос действий, управление параметрами соединения, пакеты событий, завершение команд и события состояния.

Уровень протокола управления и адаптации логического канала (L2CAP)

Протокол L2CAP предоставляет услуги по работе с данными, как ориентированные на соединения, так и без ориентации на них, протоколам более высокого уровня с возможностями мультиплексирования и обеспечения операций по сегментации и обратной сборке. Он заимствован из стандарта Bluetooth Classic и в случае BLE выполняет следующие задачи:

• Принимает несколько протоколов с верхних уровней и помещает их в стандартные пакеты BLE, которые передаются на нижние уровни под ним.

• Управляет фрагментацией и рекомбинацией пакетов. Он берет большие пакеты с верхних уровней и разбивает их на порции, которые соответствуют максимальному размеру полезной нагрузки BLE, поддерживаемому для передачи. На стороне получателя он принимает несколько пакетов и объединяет их в один пакет, который может быть обработан верхними уровнями.

В случае BLE уровень L2CAP управляет двумя основными протоколами: протоколом атрибутов (ATT, рассмотрен в главе, посвященной GATT) и протоколу управления безопасностью (SMP, рассмотрен в главе, посвященной безопасности).

Слои верхнего уровня

Протокол атрибутов (АТТ), общий профиль атрибутов (GATT), менеджер безопасности (SM) и общий профиль доступа (GAP) будут подробно рассмотрены в следующих главах.

На этом заканчивается первая глава книги. Большое спасибо дочитавшим. Следующая часть будет посвящена классам устройств и адвертайзингу методу, с помощью которого устройства сообщают о своем присутствии окружающему миру.

Это вторая часть перевода книги Мохаммада Афане Intro to Bluetooth Low Energy. В представленных главах мы поговорим о типах устройств и об адвертайзинге, методе, с помощью которого периферийные устройства сообщают о своем присутствии.Первая часть здесь.

Хочу сразу отметить, что адвертайзинг может использоваться не только для обнаружения устройств, но и для отправки кастомных данных. Например, в портативном мониторе качества воздуха Atmotube, пакеты адвертайзинга и ответа на сканирование используются для передачи сведений о текущих показаниях сенсоров. Это удобно для контроля показаний сенсоров на этапе производства и при сборе данных несколькими устройствами.

2. Периферийные и центральные устройства BLE

Существуют несколько важных определений, с которыми вы будете постоянно сталкиваться при изучении BLE. Два наиболее важных касаются ролей устройства: BLE central и BLE peripheral.

Рассмотрим их более детально.

2.1 Периферийные устройства

Периферийное устройство устройство, которое объявляет о своем присутствии путем адвертайзинга, т.е.рассылки широковещательных пакетов, и принимает запросы на соединение от центральных устройств.

Другой связанный термин BLE-передатчик, устройство, которое также рассылает широковещательные пакеты, но имеет одно отличие от периферийного устройства:оно не разрешает другим устройствам устанавливать с ним соединение. С другой стороны, устройство-наблюдатель только обнаруживает устройства, производящие процедуру адвертайзинга, но не имеет возможности инициировать соединение с ними.

Типичный пример устройства, реализующего роль передатчика маячок (beacon). Маячки это устройства, которые передают информацию без возможности установить с ними соединение. Они очень популярны в двух сферах: розничная торговля и определение местоположения внутри помещений.

Например, некоторая сеть магазинов использует мобильное приложение, которое может обнаруживать маячки на территории магазина. Если покупатель, имеющий на своем смартфоне это же приложение, приблизится к маячку, то в приложении отобразится специальная скидка на группу товаров, связанную с маячком.

Отличить маячок от периферийного устройства можно по типу широковещательных пакетов, которые он передает. Существуют различные типы пакетов: некоторые указывают на возможность установить соединение, а другие просто указывают на наличие маячка в этом месте. Когда центральное BLE-устройство обнаруживает широковещательные пакеты другого устройства с BLE (будь оно маячком или периферийным), оно знает, может ли оно начинать процедуру установки соединения или нет в зависимости от типа принятых широковещательных пакетов.

Как только периферийное устройство подключается к центральному, оно принимает на себя роль ведомого. Центральное устройство в таком случае называется ведущим. Это роли, определенные на канальном уровне, тогда как роли периферийного и центрального устройства определены на уровне GAP.

2.2 Центральные устройства

Центральное устройство устройство, которое обнаруживает периферийные устройства и считывает передаваемую ими информацию. Оно также может устанавливать соединение с одним или несколькими устройствами одновременно.

Наблюдатель устройство, схожее по функционалу с центральным, но не имеющее возможности устанавливать соединение с другим устройством.

2.3 Сравнение типов устройств

Рассмотрим возможности и ограничения четырех типов устройств: передатчик, наблюдатель, периферийное и центральное устройство.

Табл. 1: Сравнение типов устройств

2.4 Энергопотребление и требования к вычислительной мощности

Протокол BLE асимметричен. Большая часть тяжелой работы, связанной с управлением соединениями, управлением временем и обработкой информации, лежит на центральном устройстве. Это помогает снизить энергопотребление и требования к вычислительной мощности периферийного устройства, что позволяет интегрировать BLE в компактные устройства с ограниченными ресурсами, например, устройства с батарейным или аккумуляторным питанием.

Центральное устройство BLE также может иметь батарейное питание, но обычно имеет перезаряжаемый аккумулятор большой емкости. Как правило, роль центрального устройства на себя берет смартфон, компьютер или планшет.

Центральное устройство может быть подключено к нескольким периферийным одновременно. Характерный пример смартфон, подключенный к умным часам, термостату умного дома и фитнес-трекеру одновременно.

2.5 Многоролевые устройства BLE

В некоторых случаях поддержка BLE-устройством центральной и периферийной роли одновременно приносит заметную пользу. Например, устройство может контролировать несколько датчиков (периферийных устройств) и в то же время иметь возможность передавать данные с этих датчиков на смартфон, обеспечивая доступ к ним из интерфейса мобильного приложения.

2.6 Роль смартфонов в BLE

Одним из наиболее значимых преимуществ BLE перед другими похожими малопотребляющими технологиями, такими как ZigBee, Z-Wave, Thread и др.,) является его наличие в большинстве смартфонов, представленных на рынке. Практически все смартфоны уже имели на борту Bluetooth Classic с самых ранних дней, и большинство производителей чипсетов Bluetooth теперь внедряют в свои чипы поддержку и BLE, и Bluetooth Classic. В результате в настоящее время подавляющее большинство смартфонов поддерживает BLE.

Для смартфона возможность взаимодействовать с устройствами BLE дает пару существенных преимуществ:

• Смартфоны предоставляют пользователям привычный интерфейс. Использование мобильного приложения для взаимодействия с BLE-устройством зачастую оказывается удобнее непосредственного взаимодействия с этим устройством.

• Смартфоны, как правило, постоянно подключены к Интернету. Это означает, что данные, полученные с BLE-устройства, могут быть переданы в облако и сохранены для последующего анализа и обработки.

Сложности, связанные с BLE на смартфонах

В настоящий момент существуют две основные мобильные операционные системы: Android и iOS. Android представил встроенную поддержку BLE API в версии Android 4.3 (выпущена в июле 2012 года), в то время как iOS сделал то же самое немного раньше в октябре 2011 года.

Важно отметить, что многое зависит от возможностей аппаратного обеспечения операционной системы. В случае с iOS, поддержку BLE имеют все устройства, начиная с iPhone 4s. Ситуация с Android гораздо сложнее. Эта операционная система работает на устройствах разных производителей с разной аппаратной конфигурацией, поэтому нет простого способа определить, какие устройства первыми начали поддерживать BLE. Эта проблема фрагментации Android представляет большую проблему при разработке приложений, использующих BLE, которые должны работать одинаково на всех существующих Android-устройствах.

3. Рассылка и сканирование пакетов адвертайзинга

3.1 Общий профиль доступа (GAP)

Общий профиль доступа предоставляет фреймворк, который определяет способы взаимодействия BLE-устройств друг с другом. Он включает в себя следующие аспекты:

• Режимы и роли устройств;

• Обнаружение устройств: рассылка пакетов адвертайзинга, сканирование, параметры рассылки и сканирования, содержимое пакетов;

• Установка соединения: инициация, подтверждение, параметры соединения;

• Обеспечение безопасности

Реализация этого фреймворка является обязательной согласно официальной спецификации, и это то, что позволяет устройствам BLE обмениваться данными и взаимодействовать друг с другом.

Мы кратко осветили состояния сканирования и рассылки пакетов адвертайзинга BLE-устройств и упомянули, что периферийное устройство всегда запускается в состоянии рассылки пакетов адвертайзинга, даже если оно предназначено для работы в подключенном состоянии большую часть времени. Чтобы два устройства могли обнаружить друг друга, одно из них должно рассылать пакеты адвертайзинга, а другое сканировать первичные широковещательные каналы (радиоканалы 37, 38, 39) в поисках пакетов адвертайзинга, отправленных периферийным устройством.

Если периферийное устройство поддерживает возможность подключения и центральное устройство обнаружило его, они могут установить соединение. В этой главе мы сфокусируемся на начальных состояниях периферийного и центрального устройства: адвертайзинг и сканирование.

3.2 Рассылка пакетов адвертайзинга

В состоянии адвертайзинга устройство рассылает пакеты, содержащие полезную информацию для других устройств, чтобы они приняли и обработали её. Пакеты посылаются через определенные интервалы времени, которые называются интервалы адвертайзинга.

В BLE существуют 40 радиоканалов, разнесенных на 2 МГц (от центра до центра), как показано на рисунке ниже. Три канала называются каналами первичного адвертайзинга, в то время как оставшиеся 37 каналов используются для вторичного адвертайзинга, а также для передачи пакетов данных во время соединения.

Замечание: Так как устройство посылает пакеты адвертайзинга на одном из этих каналов и, как правило, постоянно переключается между ними, они (каналы) разнесены далеко по спектру друг от друга для того, чтобы избежать перекрестных помех между устройствами, вещающими на разных каналах. Также, расположение этих каналов на спектре выбрано таким, чтобы избежать помех от наиболее часто используемых Wi-Fi каналов.

Процесс адвертайзинга всегда начинается с посылки широковещательного пакета по трем первичным каналам адвертайзинга или части из них. Это позволяет центральным устройствам найти периферийные и прочитать и пакеты адвертайзинга. Затем центральное устройство может запустить процесс подключения, если периферийное устройство поддерживает такую возможность.

Также центральное устройство может послать запрос на сканирование и, если периферийное поддерживает такую возможность, оно пошлет пакет, содержащий ответ на сканирование. Запросы на сканирование и ответы позволяют периферийному устройству отправить дополнительные данные, которые не поместились в основной пакет адвертайзинга без установки соединения.

Примечание: длина первичного пакета адвертайзинга ограничена 31 байтами. Длина вторичного пакета адвертайзинга может составлять до 254 байт.

Как мы упоминали ранее, некоторые устройства (маячки) всегда остаются в состоянии адвертайзинга и не принимают запросы на подключение, в то время как другие (периферийные устройства) позволяют переход в подключенное состояние, если центральное устройство инициирует соединение.

Главное преимущество нахождения в состоянии адвертайзинга состоит в том, что множество центральных устройств могут получать данные с одного периферийного без необходимости в подключении. В то же время есть существенные недостатки, такие как отсутствие защиты данных и невозможность для периферийного устройства получать данные от центрального устройства (передача данных является однонаправленной).

3.3 Состояние сканирования

Центральные устройства, находясь в поиске пакетов адвертайзинга от периферийных устройств, перестраиваются между тремя первичными каналами адвертайзинга, прослушивая каждый из них в определенный момент времени. Для того, чтобы центральное устройство обнаружило периферийное, оно должно быть настроено на тот же канал, на котором в данный момент вещает периферийное. Для того, чтобы увеличить вероятность этого события и ускорить его наступление, можно изменять некоторые параметры адвертайзинга и сканирования.

Устройство, которое прослушивает каналы адвертайзинга в поисках пакетов адвертайзинга а затем посылает запросы сканирования, находится в режиме активного сканирования, а устройство, которое только принимает пакеты адвертайзинга, и не посылает запросов на сканирование, соответственно находится в режиме пассивного сканирования.

3.4 События адвертайзинга

Событие адвертайзинга состоит из нескольких пакетов, отправленных по всем или нескольким из трех каналов первичного адвертайзинга (37, 38 и 39). Существует семь типов событий адвертайзинга (их можно рассматривать как различные типы пакетов):

• Подключаемое и сканируемое ненаправленное событие.

Этот тип позволяет другим устройствам принимать пакеты, посылать запросы сканирования отправителю и устанавливать с ним соединение.

• Подключаемое ненаправленное событие.

Позволяет другим устройствам принимать пакеты и устанавливать соединение с их отправителем.

• Подключаемое направленное событие.

Позволяет определенному устройству принимать пакеты и устанавливать соединение с отправителем

• Неподключаемое и несканируемое ненаправленное событие.

Позволяет всем устройствам принимать пакеты. В то же время отклоняет все запросы сканирования и попытки установить соединение.

• Неподключаемое и несканируемое направленное событие.

Позволяет определенному устройству принимать пакеты без возможности установить соединение или послать запрос сканирования.

• Сканируемое ненаправленное событие.

Дает возможность другим устройствам посылать запросы сканирования отправителю для получения дополнительного пакета данных.

• Сканируемое направленное событие.

Позволяет определенному устройству посылать запросы сканирования отправителю пакета адвертайзинга для получения дополнительного пакета данных.

3.5 Параметры адвертайзинга

Под параметрами адвертайзинга понимают:

• Интервал адвертайзинга.

Наиболее важный параметр из относящихся к адвертайзингу это интервал адвертайзинга. Значение этого параметра может дискретно изменяться в пределах от 20 миллисекунд до 10.24 секунд, с шагом в 625 микросекунд. Интервал адвертайзинга оказывает большое влияние на продолжительность работы от батареи, поэтому выбору его значения следует уделить самое пристальное внимание. Рекомендуется выбирать наибольший интервал адвертайзинга, позволяющий соблюсти баланс между скоростью обнаружения и энергопотреблением.

• Данные адвертайзинга и ответа на сканирование.

Давайте посмотрим на формат пакета адвертайзинга и составляющие его поля. Стоит отметить, что пакет ответа на сканирование использует такой же формат.

Данные адвертайзинга используют формат, аналогичный формату TLV (Type-Length-Value, Тип-Длина-Значение), используемому для передачи данных. Отличие состоит в том, что в пакетах адвертайзинга длина данных следует перед их типом. Данные адвертайзинга входят в состав протокольных данных (PDU, Protocol Data Unit) BLE-пакета и включает в себя:

• Длину: длину данных, которые следуют за самим значением длины, включая тип данных и непосредственно данные.

• Тип данных адвертайзинга: тип данных адвертайзинга, содержащихся в этой структуре TLV.

• Данные адвертайзинга: непосредственно данные.

Типы данных адвертайзинга определены в дополнении спецификации Bluetooth (не в основном документе).

Ниже приведены одни из наиболее часто встречающихся типов данных:

• Local Name: имя устройства, считываемое при его обнаружении другими устройствами, производящими процедуру сканирования.

• Tx Power Level: Мощность передачи, измеряемая в дБм.

• Flags: множество однобитных логических флагов (переменные, которые могут принимать одно из двух значений, истина [1] или ложь [0], включающее в себя:

  • Limited Discoverable Mode (ограниченный режим обнаружения);

  • General Discoverable Mode (общий режим обнаружения);

  • BR/EDR Not Supported (возможность поддержки классического протокола Bluetooth);

  • Возможность одновременной поддержки классического и Low Energy Bluetooth на одном устройстве со стороны контроллера;

  • Возможность одновременной поддержки классического и Low Energy Bluetooth на одном устройстве со стороны хоста.

Примечание: понятия BR (Basic Rate, базовая пропускная способность) и EDR (Enhanced Data Rate, расширенная пропускная способность) относятся к Bluetooth Classic.

• Service Solicitation: список из одного или нескольких UUID, показывающий, какие сервисы поддерживаются и представлены GATT-сервером устройства. Это помогает центральному устройству узнать о поддерживаемых периферийным устройством сервисах до установления соединения.

• Appearance: вид, определяет тип устройства в соответствии со спецификацией стандарта. Включает в себя такие виды как телефон, измеритель сердечного ритма, брелок для ключей и множество других.

Если вы не можете найти вид, к которому можно было бы отнести ваше устройство, вы всегда можете оставить ему значение по умолчанию Неопределенный.

3.6. Параметры сканирования

Существует три основных параметра сканирования:

• Scan Type (тип сканирования): пассивное или активное.

• Scan Window (окно сканирования): определяет, длительность сканирования.

• Scan Interval (интервал сканирования): определяет частоту повторения сканирования.

Центральное устройство прослушивает один из первичных каналов адвертайзинга в течении всего окна сканирования с периодом, равным интервалу сканирования, причем каждое последующее сканирование проходит на новом канале.

__________________________________

А что дальше?

В следующей статье мы рассмотрим вопросы, связанные с соединениями, а также разберемся с сервисами, характеристиками и способами работы с ними.

Это третья часть перевода книги Мохаммада Афане Intro to Bluetooth Low Energy. Сегодня мы подробнее рассмотрим процесс подключения устройств и поговорим о сервисах.

Предыдущие части:
Про архитектуру BLE
Про типы устройств, адвертайзинг и сканирование

Благодаря сервисам происходит обмен как стандартными данными (уровень заряда батареи через Battery Service, текущее время устройства через Current Time Service и т.д.), так и кастомными, при помощи сервисов, созданных разработчиком устройства для удовлетворения специфических нужд. Например, для Atmotube Pro мы сделали два сервиса, в которые сгруппировали несколько характеристик для синхронизации истории, передачи данных о концентрации пыли и летучих органических соединений.

Эта часть получилась очень большой, извините. Я старался сократить ее, или разбить на несколько, однако это нарушило бы целостность восприятия, пожалуй, самой важной темы книги. В следующей части мы поговорим о нововведениях Bluetooth 5 и рассмотрим методы обеспечения безопасности соединения и пользовательских данных в BLE.

4. Соединения

Для того, чтобы два BLE устройства установили соединение, необходимо выполнить следующие шаги:

• Периферийное устройство должно начать процесс адвертайзинга и не останавливать его до момента установки соединения.

• Центральное устройство должно сканировать радиоэфир в поисках пакетов адвертайзинга.

• Если центральное устройство прослушивает канал адвертайзинга в момент, когда периферийное устройство посылает по нему данные, то оно обнаруживает периферийное устройство.

• Затем центральное устройство посылает пакет CONNECT_IND (также известный как запрос на соединение).

• Периферийное устройство всегда прослушивает текущий канал адвертайзинга после отправки пакета. Это позволяет ему получить запрос на соединение от центрального устройства, что запускает процесс установки соединения между двумя устройствами.

После того как будут выполнены эти шаги, соединение будет считаться созданным, но еще не установленным. Соединение будет считаться установленным, после того как устройство получит пакет данных от своего партнера по соединению. После установления соединения центральное устройство возьмет на себя роль ведущего, а периферийное, в свою очередь, ведомого. Ведущее устройство будет отвечать за управление соединением, контроль параметров соединения и контроль временных интервалов между различными событиями.

4.1 События подключения

Во время событий подключения ведущий и ведомый отправляют друг другу данные до тех пор, пока не останется данных, требующих передачи. Есть несколько фактов о соединениях, которые очень важно знать:

• События подключения происходят периодически до тех пор, пока соединение не будет закрыто или потеряно.

• Событие подключения состоит как минимум из одного пакета посланного ведущим устройством.

• Ведомое устройство всегда посылает отвечает отправкой пакета, если оно получает пакет от ведущего.

• Если ведущий не получает ответный пакет от ведомого, он закрывает подключение - он возобновит посылку пакетов во время следующего события подключения.

• Подключение может быть закрыто как ведущим, так и ведомым.

• События подключения разнесены во времени на период интервала соединения.

4.2 Параметры соединения

Параметры, определяющие соединение:

• Интервал соединения

  Интервал соединения может принимать любое из значений между 7.5 мс и 4.0 секундами с шагом в 1.25 мс. Он задается центральным устройством в пакете запроса соединения. Центральное устройство может принять во внимание Предпочитаемые Параметры Соединения Периферийного Устройства (PPCP). Центральное устройство вправе принять их, модифицировать или отклонить.

• Задержка ведомого (Slave Latency)

  Параметр задержки ведомого позволяет периферийному устройству оставлять без ответа определенное количество событий соединения и не слушать центральное устройство во время этих событий без инвалидации соединения. Это позволяет периферийному устройству переходить в режим энергосбережения на более длительный срок. Задержка ведомого отображает количество событий соединения, которое периферийное устройство может пропустить.

  Например, если установлена задержка три, то периферийное устройство может пропустить три последовательных события соединения, но затем оно должно будет выйти из режима энергосбережения, прослушать центральное устройство и ответить на следующее событие соединения.

• Таймаут наблюдения (Supervision Timeout)

  Таймаут наблюдения используется для определения потери соединения. Он определяется как максимальное время между двумя полученными пакетами данных, прежде чем соединение считается потерянным. Его значение может задаваться в диапазоне между 100 мс и 32 секундами с шагом 10 мс. Другое условие выглядит следующим образом:

  Таймаут наблюдения > (1 + задержка ведомого) * интервал соединения * 2

  Существует исключение, для которого таймаут наблюдения не применяется - в момент, когда соединение создано, но еще не установлено. В этом случае ведущее устройство примет решение о потере соединения, если не получит пакета от ведомого в течении 6 интервалов соединения.

• Расширение длины данных (DLE)

  Это опция, которая позволяет пакетам данных содержать большее количество полезной нагрузки (до 251 байта, в случае, когда эта настройка выключена, полезная нагрузка составляет 27 байт). Эта возможность введена в версии 4.2 спецификации Bluetooth.

• Максимальная единица передачи (MTU)

  Понятие максимальной единицы передачи используется в компьютерных сетях и определяет максимальный размер данных, которые можно передать по определенному протоколу. Максимальная единица передачи атрибута (в спецификации определена как ATT_MTU) это наибольший размер полезной нагрузки атрибута, который можно передать между клиентом и сервером.

  Эффективный размер ATT_MTU определяется наименьшим значением максимальных ATT_MTU поддерживаемых ведущим и ведомым. Например, если ведущее устройство поддерживает ATT_MTU 100 байт и ведомое устройство сообщает, что оно поддерживает ATT_MTU 150 байт, то ведущий решает, что для этого соединения будет использоваться ATT_MTU 100 байт.

  Примечание: Для достижения максимальной пропускной способности убедитесь, что включено расширение длины передаваемых данных (в случае, если вы используете Bluetooth 4.2 или новее). Это поможет снизить количество избыточно передаваемых служебных данных, таких как заголовки пакетов, за счет уменьшения числа пакетов.

4.3 Переключение между каналами

Как мы упоминали ранее в начале этой главы, существуют 37 радиоканалов, используемых для передачи пакетов данных в течении соединения. В то же время, не все 37 каналов необходимы для соединения. Используемые каналы определяются картой каналов, которая включена в пакет запроса соединения, отправляемый центральным устройством периферийному для установки соединения. Для каждого события соединения пакеты данных будут переданы по другому каналу в карте каналов.

Последовательность каналов, используемая для каждого события соединения определяется картой каналов и шагом прыжка (hop increment). Шаг прыжка, также как и карта каналов, включен в пакет запроса соединения. Комбинация карты каналов и шага прыжка определяет, какой канал будет использован для каждого интервала соединения.

Существует два алгоритма выбора каналов в BLE. Рассмотрение подробностей их работы лежит вне поля зрения этой книги. Для того, чтобы узнать больше об этих алгоритмах и принципах их работы, обратитесь к спецификации Bluetooth (version 5.0 | Vol 6, Part B, Section 4.5.8.2).

4.4 Белый список и фильтрация устройств

BLE поддерживает фильтрацию устройств для процедур, связанных с состояниями адвертайзинга, сканирования и стадией инициации (при установлении соединения).

Белый список это список адресов и типов адресов определенных устройств. Он используется для определения того, в каких устройствах заинтересовано конкретное устройство. Запись для анонимного типа адреса устройства позволяет сопоставить все широковещательные пакеты, отправленные без адреса.

Фильтрация устройств происходит на канальном уровне контроллера (нижний уровень протокола Bluetooth), что позволяет сохранить время и не производить лишнюю работу на уровне хоста (на верхних уровнях протокола). Однако именно хост отвечает на конфигурацию белого списка.

Ниже приведен список различных правил фильтрации для каждого из состояний:

• Правило фильтрации для состоянии адвертайзинга (периферийное устройство)

  Эта политика фильтрации определяет, как периферийное устройство будет обрабатывать запросы сканирования и запросы на подключение. Она может быть сконфигурирована следующим образом:

  • Обрабатываются запросы сканирования и запросы на подключение только от устройств из белого списка.

  • Обрабатываются запросы от всех устройств (фильтрация не используется).

  • Обрабатываются запросы сканирования только от устройств из белого списка, обрабатываются запросы на подключение от всех устройств.

  • Обрабатываются запросы на подключение только от устройств из белого списка, обрабатываются запросы сканирования от всех устройств.

• Правило фильтрации для состояния сканирования (центральное устройство)

  Это правило фильтрации определяет, как сканирующее устройство будет обрабатывать пакеты адвертайзинга. Может быть сконфигурировано следующим образом:

  • Обрабатываются пакеты адвертайзинга от всех устройств (белый список не используется).

  • Обрабатываются пакеты адвертайзинга только от устройств, включенных в белый список.

• Правило фильтрации для состояния инициации (центральное устройство)

  Это правило определяет, как устройство, инициирующее соединение, будет обрабатывать пакеты адвертайзинга. Может быть сконфигурировано следующим образом:

  • Обрабатывать пакеты адвертайзинга и инициировать соединение только с устройствами, включенными в белый список.

  • Обрабатывать пакеты адвертайзинга и инициировать соединение только с устройствами, определенными хостом.

  Обратите внимание, что это не опция для обработки пакетов и подключения к подключаемому периферийному устройству, которого нет в белом списке.

5. Сервисы и характеристики

Прежде чем начать рассказ о сервисах и характеристиках, мы должны рассмотреть два очень важных понятия: Общий профиль атрибутов (GATT) и Протокол атрибутов (ATT).

Для того, чтобы понять, что из себя представляет общий профиль атрибутов, необходимо сперва разобраться, что из себя представляет его нижний слой - протокол атрибутов. GATT вступает в игру только после того, как будет установлено соединение между двумя устройствами.

5.1 Протокол атрибутов (ATT)

АТТ определяет, в каком виде сервер представит свои данные клиенту и как эти данные будут структурированы. Существует две роли, связанные с АТТ:

• Сервер:

  Это устройство, которое предоставляет данные, которые оно содержит, или которыми управляет и, в некоторых случаях, другие аспекты поведения сервера, которые могут контролировать другие устройства. Это устройство, которое получает входящие команды от связанного устройства и отправляет ответы, уведомления и индикации.

  Например, беспроводной термометр будет вести себя как сервер, когда он будет предоставлять температуру окружающей среды, единицу измерений, свой уровень заряда и, возможно, временные интервалы, с которыми термометр производит измерения и сохраняет их результаты. Он также может уведомлять клиент (объясним позже) об изменениях температуры для того, чтобы клиент не опрашивал его непрерывно в ожидании готовых к отправке данных.

• Клиент:

  Это устройство, которое взаимодействует с сервером с целью считать предоставляемые сервером данные и/или для того, чтобы контролировать его поведение. Это устройство, которое посылает команды и запросы и получает входящие уведомления и индикации. В предыдущем примере, мобильный телефон, который подключался к беспроводному термометру и считывал его показания температуры, действовал в роли клиента.

  Данные, предоставляемые сервером, сгруппированы в атрибуты. Атрибут это общий термин для любых типов данных, предоставляемых сервером, он определяет структуру этих данных. Например, сервисы и характеристики (будут описаны позднее) являются атрибутами. Ниже состав атрибута:

• Тип атрибута (универсальный уникальный идентификатор, UUID)

  Это 16-битное (в случае стандартных атрибутов Bluetooth SIG) или 128-битное число (в случае атрибутов, определенных разработчиком устройства, vendor-specific UUID).

  Например, UUID для одобренного консорциумом атрибута значения температуры 0x2A1C. Одобренные консорциумом типы атрибутов имеют один общий (за исключением 16 бит) специальный 128-битный UUID:

  0000XXXX-0000-1000-8000-00805F9B34FB

  16-битный UUID будет подставлен вместо символов ХХХХ в базовом UUID.

  Собственный UUID может быть любым 128-битным числом, не совпадающим ни с одним из одобренных Bluetooth-SIG базовых UUID. Например, разработчик может создать свой собственный UUID для показаний температуры, такой как:

  F5A1287E-227D-4C9E-AD2C-11D0FD6ED640

  Одно из преимуществ использования стандартных UUID состоит в уменьшении размера пакета, так как UUID может быть передан в виде 16-битного числа, вместо передачи полного 128-битного числа.

• Дескриптор атрибута

  Это 16-битное число, которое сервер присваивает каждому из своих атрибутов. Это число используется клиентом как ссылка на конкретный атрибут, и сервер гарантирует, что эта ссылка будет уникальной для атрибута, которому она присвоена, в течении всего времени существования соединения между устройствами. Дескриптор может иметь любое значение в диапазоне 0x0001-0xFFFF, значение 0х0000 зарезервировано.

• Права атрибута

  Права определяют, может ли атрибут быть прочитан или записан, может ли он посылать уведомления или индикации, и какие уровни доступа требуются для каждой из этих операций. Эти права не определяются протоколом атрибутов (АТТ) и не могут быть прочитаны через него, они определяются на верхнем уровне (GATT или уровне приложения).

5.2 Общий профиль атрибутов (GATT)

Теперь, когда мы рассмотрели концепцию атрибутов, познакомимся с другими тремя важными понятиями в BLE, с которыми вам придется постоянно сталкиваться.

• Сервисы

• Характеристики

• Профили

Эти понятия введены для того, чтобы обеспечить возможность иерархического представления данных, предоставляемых сервером. Сервисы и характеристики это атрибуты, служащие для определенной цели. Характеристики это низкоуровневые атрибуты в базе данных атрибутов. Сервисы служат для группировки характеристик по функциональному признаку. Профили немного отличаются и не обнаруживаются на сервере - мы расскажем о них позже в этой главе.

GATT определяет формат сервисов и их характеристик, а также процедуры, используемые для взаимодействия с этими атрибутами, такие как обнаружение сервисов, чтение и запись характеристик, уведомления и индикации.

GATT выполняет ту же роль, что и протокол атрибутов (АТТ). Роли устанавливаются не для устройств, они определяются во время транзакций (такие как запрос ответ, индикация подтверждение, уведомление). Таким образом, устройство может действовать как сервер, предоставляющий данные клиентам, и в то же время быть в роли клиента, получая данные, подготовленные другими серверами одновременно.

5.3 Сервисы и характеристики

5.3.1 Сервисы

Сервисы это группа из одного или большего числа атрибутов, некоторые из которых являются характеристиками. Он предназначен для группировки связанных атрибутов, удовлетворяющих специфической функциональности сервера. Например, одобренный SIG сервис батареи содержит одну характеристику под названием уровень заряда.

Сервисы также содержат другие атрибуты, которые помогают структурировать данные сервиса, такие как объявления сервера, объявления характеристик и другие.

Вот что из себя представляют сервисы:

На рисунке мы видим различные атрибуты, составляющие сервис:

• Один или несколько включенных сервисов

• Одна или несколько характеристик

  • Свойства характеристики

  • Ее значение

  • Дескрипторы характеристики

Включение сервисов позволяет сервису ссылаться на другие сервисы как на включенные в него. Существует два типа сервисов:

• Первичный сервис: предоставляет основную функцию устройства или одну из них.

• Вторичный сервис: предоставляет дополнительную функциональность устройства и включен в как минимум один первичный сервис на устройстве (вторичные сервисы очень редко применяются, и еще реже возникает необходимость в них они не будут более подробно рассматриваться в этой книге).

5.3.2 Характеристики

Характеристика всегда является частью сервиса и предоставляет часть тех данных, которые сервер хочет предоставить клиенту. Например, характеристика уровня заряда батареи показывает оставшийся уровень заряда батареи в устройстве, который может быть прочитан клиентом. Характеристика содержит набор атрибутов, которые облегчают работу с содержащимися в характеристике данными:

• Свойства: представлены набором бит, определяющих то, каким образом значение характеристики может использоваться. Пример свойств: чтение, запись, запись без ответа, уведомление, индикация.

• Дескрипторы: используются для хранения информации, связанной со значением характеристики. Примеры использования: расширенные свойства, пользовательское описание, поля, используемые для подписки на уведомления и индикации, поля, описывающие представление характеристики, такие как формат или единица измерения.

Понимание этих концепций важно, однако вы, как разработчик приложения, будете в основном взаимодействовать с API, предоставленным операционной системой или SDK чипсета, которые абстрагируют вас от многих этих понятий.

Например, вы можете иметь API для включения уведомлений для некоторых характеристик, который вы просто вызываете и вам нет необходимости знать, что результатом этого вызова будет запись значения 0x0001 в дескриптор конфигурации характеристик клиента (CCCD) на сервере.

Важно помнить, что, хотя нет никаких запретов или ограничений на количество характеристик, содержащихся в сервисе, сервисы предназначены для группировки связанных характеристик, которые определяют конкретные функции в устройстве.

Например, технически возможно создать сервис под названием сервис влажности, который будет включать в себя характеристику влажности и характеристику температуры. Но гораздо более логичным решением будет создать два отдельных сервиса для каждой несвязанной функции (отображение текущей температуры и отображение текущей влажности).

Стоит отметить, что Bluetooth SIG приняла довольно-таки большое количество сервисов и характеристик, которые удовлетворяют большей части распространенных сценариев использования. Для этих одобренных сервисов существуют спецификации, помогающие разработчикам реализовать их вместе с обеспечением соответствия и взаимодействия с каждым сервисом.

Если устройство заявляет о совместимости с сервисом, оно должно полностью соответствовать спецификации сервиса, опубликованной Bluetooth SIG. Это важно, если вы хотите разработать устройство, которое будет гарантированно подключаться к устройствам, изготовленными другим производителем. Сервисы Bluetooth, принятые SIG, делают соединение предварительно согласованным между устройствами различных производителей.

Вы можете найти список одобренных сервисов здесь, и их спецификации здесь. Одобренные характеристики находятся по этому адресу.

5.4 Профили

Профили по своему определению гораздо шире сервисов. Они занимаются определением поведения как клиента, так и сервиса, когда дело касается сервисов, характеристик и даже соединений и требований безопасности. Сервисы и их спецификации, с другой стороны, касаются реализации этих сервисов и характеристик только на стороне сервера.

Также как и в случае с сервисами, существуют одобренные SIG профили с опубликованными спецификациями к ним. В спецификации профиля вы можете найти следующее:

• Определение ролей и взаимоотношений между GATT сервера и клиента.

• Требуемые сервисы.

• Требования сервисов.

• Как используются требуемые сервисы и характеристики.

• Детали требований к процессу установления соединения, включая параметры адвертайзинга и соединения.

• Соображения безопасности.

Ниже в качестве примера приведена диаграмма, взятая из спецификации на профиль кровяного давления. Она показывает отношения между ролями (сервер и клиент), сервисами и характеристиками внутри профиля.

Роли представлены в виде желтых прямоугольников, сервисы в виде оранжевых прямоугольников. Вы можете найти список профилей, одобренных SIG, здесь.

5.5 Пример GATT

Давайте посмотрим на пример использования GATT. В этом примере мы будем использовать файл GATT.xml, используемый в Silicon Labs Bluetooth Low Energy development framework (BGLib).

В этом XML-файле вы можете заметить следующее:

• Определены два сервиса:

  • Сервис общего профиля доступа (GAP) с UUID: 0x1800 (одобрен SIG).

  • Сервис замены кабеля с UUID: 0bd51666-e7cb-469b-8e4d-2742f1ba77cc (Собственный сервис, определенный разработчиком приложения или производителем чипсета. Обычно так называют реализацию UART средствами Bluetooth. Например, у Nordic Semi эту роль выполняет Nordic UART Service, а у Dialog Semiconductor - Dialog Debug Service).

• Сервис общего профиля доступа обязателен по спецификации и включает следующие обязательные характеристики:

  • Имя с UUID 0x2A00 и значением: Bluegiga CR Demo.

  • Окружение с UUID 0x2A01 и значением 0x4142.

  Описание значений окружения приведены здесь.

  Примечание: обычно создание и включение этого сервиса является задачей вендора чипсета и, обычно, разработчику предоставляется API для простой установки значений имени и окружения.

• Сервис замены кабеля имеет одну характеристику под названием данные.

  • Характеристика данных имеет UUID: e7add780-b042-4876-aae1-112855353cc1

  • Включены свойства, разрешающие запись в характеристику и индикацию.

5.6 Операции с атрибутами

Существует шесть различных типов операций, которые могут производиться над атрибутами:

• Команды: посылаются клиентом серверу и не требуют ответов.

• Запросы: посылаются клиентом серверу и требуют ответов. Существуют два типа запросов:

  • Запросы на поиск информации

  • Запросы на чтение

• Ответы: посылаются сервером клиенту в ответ на запрос.

• Уведомления: Посылаются сервером клиенту с целью оповестить об изменении значения характеристики. Для получения уведомлений клиент должен включить их для интересующих характеристик. Помните, что уведомления не требуют подтверждения о получении от клиента.

• Индикации: посылаются сервером клиенту. Во многом похожи на уведомления, но требуют подтверждения успешного приема клиентом.

  Примечание: настройки уведомлений и индикаций представлены в атрибуте дескриптора конфигурации характеристик клиента (CCCD). Запись 1 в этот атрибут включит уведомления, запись 2 включит индикации. Запись 0 отключит как уведомления, так и индикации.

• Подтверждения: посылаются клиентом серверу. Это пакеты, посылаемые с целью уведомить сервер об успешном приеме индикации клиентом.

5.6.1 Управление потоком и последовательность операций с атрибутами

Запросы последовательны по своей природе и требуют ответа от сервера перед отправкой нового запроса. Индикации имеют такое же требование: новая индикация не может быть отправлена до тех пор, пока не получено подтверждение о приеме предыдущей индикации.

Запросы и индикации являются взаимоисключающими с точки зрения требований к последовательности. То есть индикация может быть отправлена сервером до того как он ответит на запрос, который получил ранее.

Команды и уведомления отличаются, и не требуют управления потоком сообщений - они могут быть посланы в любое время. По этой причине, а также потому что сервер или клиент могут быть не в состоянии обработать эти пакеты, они считаются ненадежными. Запросы и индикации должны использоваться в случаях, когда надежность стоит во главе угла.

5.6.2 Чтение атрибутов

Чтение это запрос по своей природе, так как оно требует ответа. Существует несколько типов запросов на чтение, но наиболее важны следующие два:

• Запрос на чтение: простой запрос, ссылающийся на атрибут, который будет прочитан его дескриптором.

• Запрос на чтение части данных: похож на запрос на чтение, но содержит смещение, указывающее, с какого участка чтение должно начаться, возвращая часть значения. Этот тип чтения используется для чтения только части значения характеристики.

5.6.3 Запись атрибутов

Запись может быть командой или запросом. Ниже представлены наиболее популярные типы записи:

• Запрос на запись: как следует из названия, требует ответа от сервера, подтверждающего успешное получение данных.

• Команда на запись: не требует ответа от сервера.

• Упорядоченная запись (атомарное поведение операции): классифицируется как запрос и требует подтверждения от сервера. Они используются в случаях, когда требуется записать большое количество данных, не умещающееся в одно сообщение. Вместо того, чтобы записывать части сообщения и давать возможность кому-то прочитать некорректное неполное значение, применяются два типа запросов на запись, для того, чтобы иметь уверенность в безопасном выполнении операции:

  • Один или несколько запросов на подготовку к записи: каждый включает в себя смещение, с которым посылаемое значение должно быть записано в значение атрибута. Посылаемые значения также часто называют подготовленными значениями, и они хранятся в буфере на стороне сервера, еще не записанные в атрибут. Эта операция требует ответа со стороны сервера.

  • Один запрос на запись: используется для запроса сервера о выполнении или отмены записи принятых значений в атрибут. Требует ответа от сервера для того, чтобы клиент был уверен в том, что атрибут содержит целое и верное значение, посланное серверу.

5.6.4 Запрос на обмен MTU

Сервер и клиент согласуют общее значение MTU, использующееся для передачи данных в обоих направлениях. Запрос инициируется клиентом и может быть послан только один раз во время жизни соединения (согласно спецификации Bluetooth, version 5.0, Vol 3, Part F, Section 3.4.2.1).

Сервер отвечает особым пакетом, содержащим поддерживаемый им размер ATT_MTU. Итоговое значение будет выбрано равным меньшему из переданных между сервером и клиентом ATT_MTU.

Важно помнить, что различные версии BLE имеют разные поддерживаемые максимальные значения ATT_MTU.

5.7 Создание своего GATT

5.7.1 Общие рекомендации

Несмотря на то, что GATT это удивительно гибкий фреймворк, существуют несколько общих рекомендаций, которым нужно следовать при создании сервисов и характеристик для них:

• Убедитесь, что внедрены обязательные сервисы и их характеристики:

  • Сервис общего профиля доступа (GAP)

  • Заданы характеристики имени и окружения.

• Используйте одобренные Bluetooth SIG профили, сервисы и характеристики там, где это возможно. Это дает следующие преимущества:

  • Вы уменьшаете размер передаваемых пакетов, содержащих UUID сервисов и характеристик (включая пакеты адвертайзинга) ускоряете процедуру обнаружения и другие процедуры за счет использования 16-битных UUID вместо 128-битных.

  • Производители модулей и чипсетов обычно предоставляют примеры реализации этих сервисов в своих примерах и SDK - уменьшая нужное вам время на разработку.

  • Большее число сторонних устройств и приложений сможет взаимодействовать с вашим, тем самым расширяя число возможных пользовательских сценариев.

• Группируйте характеристики, отвечающие за смежный функционал, в один сервис.

• Избегайте создания сервисов, имеющий слишком большое количество характеристик. Хорошее разделение сервисов ускоряет процесс обнаружения характеристик и ведет к дружественному к пользователю модульному дизайну GATT.

В следующей главе мы рассмотрим практический пример, показывающий как разработать GATT для системы домашней автоматизации.

6. Урок создания GATT

Разработка GATT для вашего BLE устройства может быть очень сложной задачей. Для того, чтобы упростить ее, давайте пройдем полный урок создания GATT для простой системы домашней автоматизации.

Система домашней автоматизации это абстрактное нечто, но она поможет вам лучше понять шаги создания GATT для реального приложения, а не для какой-то обобщенной системы. Ниже показана схема с элементами системы умного дома и связями между ними.

Система состоит из множества устройств. Некоторые из них куплены в магазине, и мы не можем как-то изменить их прошивку, остальные подлежат модификации в соответствии с нашими нуждами.

6.1 Общее описание системы

Давайте опишем основные пользовательские сценарии для системы:

1. Владелец дома может использовать пульт дистанционного управления для включения и выключения светильника.

2. Владелец дома может наблюдать за изменениями показаний температуры и влажности на сенсоре окружающей среды.

3. Владелец дома получает уведомления об уровне заряда батареи всех элементов системы.

6.2 Элементы системы

Теперь давайте рассмотрим составляющие нашей системы.

1. Шлюз

   Шлюз будет выполнять роль центрального BLE устройства во время обмена данными со всеми устройствами кроме смартфона, где он будет выполнять роль периферийного устройства. Мы можем контролировать это устройство и спроектируем GATT для него.

   Команды для управления светильником будут поступать с пульта управления на шлюз, и с него на сам светильник.

2. Пульт управления
   Пульт управления это устройство, которое выполняет только периферийную роль, для него мы также спроектируем GATT.

3. Сенсор окружающей среды
   Это стандартное устройство, GATT которого мы не можем изменить, так что область нашего интереса будет ограничена чтением показаний с него (данные о текущей температуре и влажности).

4. Светильник

   Это еще одно стандартное устройство, которое мы не можем каким-либо образом изменить.

5. Смартфон

   Очередное стандартное устройство, мы будем использовать его для контроля системы.

6.3 Разработка GATT

Теперь мы пройдем пошагово весь процесс создания GATT, удовлетворяющего нашим требованиям.

6.3.1 Шаг 1: Документирование различных пользовательских сценариев

Несмотря на то, что GATT обычно больше сфокусирован на периферийной роли (так как обычно в роли сервера, предоставляющего данные, выступает периферийное устройство), центральное устройство также может выполнять роль сервера в особых случаях. Также, так как мы разрабатываем устройство, выполняющее обе роли (центральную и периферийную), это поможет нам понять, что должно произойти с каждой стороны, так как это повлияет на некоторые аспекты разработки системы и GATT.

6.3.1.1 Шлюз

Шлюз выполняет роль как центрального, так и периферийного устройства. Каждая из этих ролей используется для обеспечения связи с различными устройствами, входящими в состав системы. Основная задача шлюза как центрального устройства - считывать показания с множества периферийных устройств. Затем он, действуя в роли периферийного устройства, предоставляет собранные и обработанные данные другому центральному устройству (смартфону), который может передать эти данные на облачный сервер.

Рассмотрим пользовательские сценарии с точки зрения шлюза, для центральной и периферийной роли.

Периферийная роль

• Пульт управления уведомляет шлюз, когда кнопки на нем нажимаются, для включения и выключения светильника.

• Данные должны передаваться на облачный сервер через шлюз. Они представлены центральному устройству (например смартфону, имеющему доступ в интернет) в виде GATT-сервера в периферийной роли. Ниже перечень этих данных:

  • Показания температуры датчика окружающей среды

  • Показания влажности датчика окружающей среды

  • Статус светильника (включен или выключен)

  • Уровни заряда батареи пульта, светильника и датчика окружающей среды.

Центральная роль

Шлюз должен считывать некоторые данные, представленные устройствами, составляющими систему, и получать уведомления о других данных с этих устройств.

6.3.1.2 Пульт управления

Пульт управления выполняет одну функцию: управляет светильником. Он выполняет исключительно периферийную роль и должен предоставлять следующую информацию:

• При нажатии кнопки ВКЛ: уведомить шлюз о том, что была нажата эта кнопка.

• При нажатии кнопки ВКЛ: также уведомить шлюз о нажатии этой кнопки.

• Уровень заряда батареи: шлюз должен иметь возможность читать данные о заряде батареи пульта и получать уведомления о его изменении.

6.3.2 Шаг 2: Настройка сервисов, характеристик и прав доступа

На этом шаге мы сгруппируем характеристики в группы (сервисы), объединяющие характеристики со схожим функционалом и зададим разрешения для каждой из них.

6.3.2.1 Шлюз

У нас есть один GATT-сервер для шлюза в периферийной роли. Посмотрев еще раз на данные, которые нам нужно передавать, мы можем назначить им характеристики и сгруппировать их в следующие сервисы:

• Сервис датчика окружающей среды:

  • Характеристика показаний температуры датчика окружающей среды: Температура

    Права: Чтение, уведомление.

• Характеристика показаний влажности датчика окружающей среды: Влажность

  Права: Чтение, уведомление.

• Характеристика остаточного заряда аккумулятора: Уровень заряда

  Права: Чтение, уведомление.

• Сервис светильника:

  • Текущее состояние светильника Статус

    Права: Чтение, уведомление.

• Характеристика остаточного заряда аккумулятора: Уровень заряда

  Права: Чтение, уведомление.

• Сервис пульта дистанционного управления:

  • Характеристика остаточного заряда аккумулятора: Уровень заряда

    Права: Чтение, уведомление.

Помимо этих сервисов необходимо реализовать обязательный (согласно спецификации Bluetooth) сервис:

• GAP сервис:

  • Характеристика имя: имя устройства.

    Права: чтение.

  • Характеристика местоположения: описание места, где размещено устройство.

    Права: чтение.

6.3.2.2 Пульт управления

У нас есть один GATT-сервер для пульта управления. Мы можем назначить ему следующие сервисы и характеристики:

• GAP сервис (обязательный):

  • Характеристика имя: имя устройства.

    Права: чтение.

  • Характеристика местоположения: описание места, где размещено устройство.

    Права: чтение.

• Сервис аккумулятора:

  • Характеристика остаточного заряда аккумулятора: Уровень заряда

    Права: Чтение, уведомление.

• Сервис кнопок:

  • Характеристика кнопки ВКЛ

    Права: уведомление.

  • Характеристика кнопки ВКЛ

    Права: уведомление.

6.3.3. Шаг 3: Использование стандартных сервисов и характеристик

6.3.3.1. Шлюз

Сервисы датчика окружающей среды, светильника и пульта являются нашими собственными, так как не существует ни одного стандартного сервиса, который мы бы могли использовать для них. Однако у нас есть три устройства с аккумуляторами, заряд которых нам необходимо отображать и мы можем использовать стандартную характеристику уровня заряда. Мы будем использовать ее для каждого устройства в его сервисе в GATT шлюза. Также мы будем использовать обязательный GAP сервис.

6.3.3.2. Пульт управления

Для пульта управления мы можем использовать стандартный сервис уровня заряда батареи и обязательный GAP сервис.

6.3.4. Шаг 4: Присвоение UUID нашим сервисам и характеристикам

Для каждого нестандартного сервиса и характеристики мы можем использовать онлайн-инструмент для генерации UUID, например этот.

Распространенной практикой является выбор базового UUID для сервиса и увеличение значения третьего и четвертого старшего байта UUID для каждой последующей характеристики.

Для примера, возьмем следующий UUID для какого-либо сервиса:

00000001-1000-2000-3000-111122223333

И затем заменим выделенные байты на

0000000[N]-1000-2000-3000-111122223333, где N>1 - порядковый номер характеристики.

Единственное условие, которое накладывает ограничение на выбор UUID для наших сервисов и характеристик это условие несовпадения нашего UUID с базовым UUID Bluetooth SIG: XXXXXXXX-0000-1000-8000-00805F9B34FB.

Следование вышепредставленной методике выбора UUID немного упрощает понимание связей между сервисами и их характеристиками.

На таблицах ниже представлены наши сервисы, характеристики и их UUID для шлюза и пульта управления.

6.3.5. Шаг 5: Реализация сервисов и характеристик с использованием API SDK производителя платформы

Каждая платформа, встраиваемая или мобильная, имеет собственный интерфейс прикладного программирования (API, application programming interface) для реализации сервисов и характеристик. Задача читателя самостоятельно реализовать их для выбранного им устройства или приложения.

Всем привет!

Некоторое время назад мы с партнерами IT Академии Samsung запустили открытый онлайн-лекторий Samsung Innovation Campus по Интернету вещей. В видеолекциях для студентов и новичков мы решили дать правильное, с нашей точки зрения, представление об этой сфере. И это не про обывательское представление о том, что Интернет вещей - это умные чайники и говорящие холодильники и не про пафос цифровизации и мировых перспектив Индустрии 4.0 (тут без нас много сказано). Это про то, что Интернет вещей - это серьезная промышленная область с по-настоящему сложными, масштабными задачами.

О чем были прошедшие еженедельные лекции (записи доступны в YouTube), и о чем еще хотим рассказать в рамках этого небольшого открытого образовательного проекта, читайте под катом.

Интернет вещей в России - область молодая, и университеты еще не успели создать учебный материал для нее. Чтобы работать в IoT, требуются знания нескольких инженерных дисциплин. Но спустя несколько лет эксплуатации IoT-систем, на растущем рынке появилось понимание, почему важно учить кадры, и как усилия архитектора экономят огромные деньги на масштабах даже в сотни устройств.

Не всё гладко с методическими материалами и в целом взглядом на Интернет вещей. Это неудивительно, ведь тема обширная, и авторы пишут о ней в частном контексте своих компетенций и интересов. Например, популярен подход, при котором Интернет вещей рассматривается исключительно как отрасль телекома.

Нам более близка позиция организаторов конференции InoThings++, которая проходила в течение двух лет в 2018-2019 годах (записи выступлений спикеров здесь в свободном доступе на YouTube): каждый доклад раскрывал бизнес-, либо технологическую сторону Интернета вещей в России, а иногда и то, и другое вместе. Спикеры тщательно отбирались и были с конкретным опытом: сами участвовали в разработке и внедрении решений. Однако эти материалы сложны для новичков. Они рассчитаны на подготовленную аудиторию, которая не просто владеет терминологией, но и имеет представление о затрагиваемых технологиях. А есть ли что-то более простого уровня?

Samsung с 2017 года реализует образовательный проект IT Академия, в котором есть трек по Интернету вещей. Это годовой практико-ориентированный курс для студентов вузов-партнеров проекта, который состоит в основном из учебных кейсов и лабораторных работ. На данный момент среди партнеров - 22 вуза по всей России. Однако нам то и дело задают вопрос: как принять участие в проекте, если я - не студент вуза-партнера?

Концепция лектория

В этом году мы решили двигаться навстречу широкой публике и сделать открытый лекционный курс. Мы открыли онлайн IoT-лекторий и выстроили к нему последовательную программу с движением снизу вверх. К такому решению пришли не сразу, рассматривалось несколько классификаций:

1. По компонентам системы,

2. По навыкам: железо, софт, обработка данных,

3. По проектной работе и сферам, которые must-have, но они надпроектные (например, безопасность, дизайн, стандартизация).

Основной труд по разработке программы лектория взяла на себя Ксения Сизова - менеджер проектов компании RedBees. Именно практический опыт Ксении был для нас очень важен, она прекрасно знакома с этим бизнесом и его спецификой в России. Кроме того, у нее есть и методический опыт: уже второй год она курирует обучающую программу IoT AM - проект для студентов вузов Санкт-Петербурга, нацеленный на подготовку стартапов и бизнес-ориентированных команд.

Мы решили охватить примерно такой круг тем в следующем порядке:

1. Общий обзор систем IoT

2. Оконечные устройства

3. Транспортные сети

4. Программная часть

5. Облачные технологии

6. Жизненный цикл проекта

7. Безопасность

8. Дизайн и UX

9. Data Science

10. Стандартизация

Несложно заметить, что в целом этот список тем повторяет типичное устройство IoT-системы и общий круг вопросов, о которых так или иначе необходимо думать при ее создании.

Далее мы расскажем о реализации этого плана, и что удалось сделать в рамках лектория на настоящий момент.

Курс лекций

Все лекции доступны для просмотра в плейлисте Samsung Innovation Campus IoT Lectorium.

Лекция 1. Архитектура и типология систем IoT. Антон Куропятник (Woodenshark), Ксения Сизова (Red Bees)

Первую лекцию учебного курса вели Антон Куропятник, старший продукт-менеджер в компании Woodenshark (IoT R&D), и Ксения Сизова, руководитель проектов в компании Red Bees (IoT R&D).

В этой лекции Антон и Ксения кратко рассказали о том, где, как, зачем и почему применяется IoT, какие бывают IoT-системы, их компоненты и основные функции. Разобрали систему IoT от простого к сложному, разложили на примерах использования в обычной жизни и индустриальных направлениях.

Лекция 2. Как выбрать технологию IoT, чтобы выжать максимум от достоинств и не страдать от минусов. Антон Куропятник (Woodenshark), Ксения Сизова (Red Bees), Юрий Сизов (RedBees)

Во второй лекции к Антону и Ксении присоединился Юрий Сизов, генеральный директор компании Red Bees.

Наши лекторы остановились на первых двух компонентах сети IoT оконечные устройства и каналы передачи данных до базовой станции/граничного роутера. Кратко произвели обзор технологий и протоколов, применяемых в IoT, рассказали подробнее об их характеристиках, плюсах и минусах, а также основных трендах использования.

Лекция 3. Инфраструктура транспортных сетей. Роман Андреев (СПбГУТ).

Изучив первые два уровня IoT-системы, мы стали двигаться дальше, и одно занятие прицельно уделили телекоммуникациям. На этой лекции у нас был специальный гость: Роман Андреев, начальник Научно-образовательного центра Беспроводные инфотелекоммуникационные сети СПБГуТ им. проф. М.А. Бонч-Бруевича - одного из немногих отраслевых телеком-вузов в стране.

В ходе лекции были рассмотрены топологии 2G/3G/4G-сетей, основные производители оборудования и функциональные блоки сети, прохождение аутентификации и вызовов в сетях связи, ядро сети и радиочасть с учетом распределения частотных ресурсов. Если вы всегда мечтали узнать, как устроена антенна изнутри, то эта лекция для вас.

Лекция 4. Программная часть IoT: о чем нужно знать помимо железа. Дмитрий Чудинов (Red Bees)

Здесь мы провели эксперимент и устроили боевое крещение для студента. А почему бы и нет? Глядишь, других этот пример вдохновит. Свой дебют в нашем лектории совершил Дмитрий Чудинов, студент 4 курса, инженер-стажер в компании Red Bees (IoT R&D), выпускник платформы IoT AM. Дмитрий продемонстрировал широкое знание существующих платформ Интернета вещей и наличие опыта работы с ними.

В своей лекции Дмитрий рассказал об архитектуре программной части IoT, о том, как построить и собрать свою платформу, а также, какой джентльменский набор необходим разработчику софта для IoT решений, и с чего лично он рекомендует начать новичкам.

Лекция 5. Облачные технологии в решениях IoT. Кирилл Святов (УлГТУ)

Развивая тему облачных технологий, в лектории выступил Кирилл Святов, декан Факультета информационных систем и технологий УлГТУ (Ульяновск) - нашего вуза-партнера. На своей лекции Кирилл Валерьевич рассмотрел типовые архитектуры программных решений по работе с данными в IoT, технологии граничных и облачных вычислений на примере IBM Cloud. Вторая часть занятия представляла собой практикум: был реализован вариант построения службы по сбору, анализу и визуализации данных, получаемых от устройств интернета вещей с использованием code-less подхода на основе Node-RED в облачной среде IBM Cloud.

Очень полезное и очень насыщенное занятие с примером устройства - посудомоечной машины, отправляющей данные. Было объяснено многое - основы работы с IBM Cloud на примере сэмпла IBM Quickstart, продемонстрирована NoSQL база данных Cloudant с кратким комментарием о том, а в чем вообще суть этого подхода и в чем отличие от стандартных реляционных БД применительно к задачам IoT, и наконец, показан доступ к системе машинного обучения IBM Watson и работа в Jupyter Notebook. То есть проложен мостик и к другим направлениям Computer Science - у нас в IT Академии Samsung как раз есть учебный трек по AI.

Бонус: лекции о предметных областях

Наш курс мы иногда разбавляли и обзорными лекциями, дающими необходимый контекст. Ведь важно не только получить знания, но и узнать о практике применения этих знаний в той или иной предметной области.

"Интеллектуальные транспортные системы Умного города", Игорь Ежков (Softline)

С концепцией Умного города нас знакомил Игорь Ежков - руководитель направления Интеллектуальных транспортных систем компании Softline. Мы давно знакомы с Игорем Геннадьевичем, однажды вместе проводили с ним хакатон по NB-IoT на радиофаке УрФУ.

Что такое Умный город? Это умные перекрестки, светофоры, видеокамеры наблюдения, но и нечто большее: технологичный подход к урбанистике, который просто невозможно реализовать как набор разрозненных сервисов. Всё это дает эффект только в комплексе, когда данные собираются и визуализируются на единой платформе. Основной тезис, высказанный спикером, как раз в том и состоял - не нужно изобретать велосипед, изучайте зарубежный опыт в этой области, смотрите, какие готовые платформы есть.

Бонус: лекции-практикумы о технологиях

Другой вариант - лекция о конкретной технологии, будь то протокол связи, платформа или аппаратное устройство. Это очень классный формат, особенно если он сопровождается практикумом.

"Взаимодействие устройств по Bluetooth Low Energy", Олег Пехов (ТУСУР)

В Томском государственном университете систем управления и радиоэлектроники (ТУСУР) наша программа реализуется на факультете безопасности. Поэтому и неудивительно, что на лекции про BLE в рамках практикума был рассмотрен сниффер пакетов. Помимо этого, в лекции были рассмотрены принципы и особенности технологии Bluetooth Low Energy, ее отличие от классического Bluetooth, разновидности устройств и способы их подключения. Лекцию вел Олег Пехов, старший преподаватель кафедры комплексной информационной безопасности электронно-вычислительных систем.

"Платформа SmartThings для Умного дома", Татьяна Волкова (Исследовательский центр Samsung)

Автор этого текста тоже приняла участие в лектории. Я решила показать в стриме, как интегрировать ваше собственное устройство в платформу умного дома Samsung SmartThings. Устройство очень простое - умный светильник на базе ESP8266, подключаемый к платформе по WiFi. Звучит несложно, но занимает вся эта работа около 40 минут - нужно зарегистрировать ваше устройство внутри платформы, скомпилировать и загрузить прошивку, настроить схему авторизации устройства, сделать обмен ключами. Тут получился целый триллер. Не всё сработало с первого раза, но всё-таки заработало.

Дальнейшие планы

На данный момент наш лекторий находится примерно посередине. Какие лекции еще мы запланировали:

1. Экономика IoT-системы по состоянию на 2021

2. Жизненный цикл IoT-проекта

3. Кибербезопасность в IoT: примеры эксплоитов

4. Как известно, в аббревиатуре IoT буква S обозначает безопасность

5. Дизайн и UX в IoT-решениях

6. Краш-тест вашего IoT-проекта: оцениваем идею на жизнеспособность

7. Есть ли жизнь после релиза? Обслуживание IoT-системы

8. Data Science в IoT

9. Сертификация в IoT: стандарты, регуляторика и прочее

Вести их будут разные спикеры, в том числе, не побоимся этого слова, один монстр современного IoT-образования, но не будем пока раскрывать интригу: по завершении лектория, напишем еще один пост-апдейт.

Какие еще важные темы мы не затронули? Чего не хватает в этом тематическом плане? Пишите в комментариях ваши предложения - как бы вы составили идеальную программу лектория по Интернету вещей для начинающих?

Смотрите лекции в рамках стримов на YouTube-канале IT Академии Samsung и смотрите архив в плейлисте Samsung Innovation Campus IoT Lectorium. Задавайте вопросы нашим лекторам, пишите свои комментарии. А может быть, вы сами хотели бы выступить с лекцией по своей теме, которая пока не озвучена - мы готовы предоставить вам слово!

Татьяна Волкова, куратор трека по Интернету вещей социально-образовательной программы для вузов IT Академия Samsung

Содержание

Часть #1 (scanning)

Часть #2 (connecting/disconnecting)

Часть #3 (read/write)

Часть #4 (bonding), вы здесь

Впредыдущей статьемы разобрались с операциями чтения/записи, включения/выключения нотификаций и организации очереди команд. В этой статье мы поговорим осопряжении устройств(Прим. переводчика далее я буду использовать термин bonding).

Bonding

Некоторые устройства для правильной работы требуют bonding. Технически это обозначает, что генерируются ключи шифрования, обмениваются и хранятся, для безопасного обмена данными. При запуске процедуры bonding, Android может запросить у пользователя согласие, пин-код или кодовую фразу. При следующих подключениях, Android уже знает, что устройство сопряжено и обмен ключами шифрования происходит скрытно без участия пользователя. Использование bonding делает подключение к устройству более безопасным, так как соединение зашифровано.

Тема bonding плохо описана в документации Google, полностью непонятно, как приложение должно работать с bonding. Первое на что вы обратите внимание это методcreateBond(). Что интересно, в iOS такого метода нет вообще и фреймворкCoreBluetoothделает все за вас! Тогда зачем вызыватьcreateBond()? Кажется немного странным, вам заранее надо знать, какие устройства требуют bonding, а какие нет. Протокол Bluetooth был спроектирован так, что обычно устройства явно говорят им требуется или нет bonding. Я копнул немного глубже и поэкспериментировал. Чтобы разобраться с этим, ушло некоторое время, но в конце концов, все оказалось просто.

Принципы работы с bonding:

• Пусть Android сам работает с bonding.Android сделает bonding за вас, когда устройство скажет, что нужен bonding, или во время операции чтения/записи зашифрованной характеристики. В большинстве случаев не надо вызыватьcreateBond()самостоятельно (Прим. переводчика: мне пришлось это делать самостоятельно, из-за особенностей прошивки устройства. Кроме того, Samsung работает по-другому, чем другие вендоры);

• Нельзя запускать другие операции, в процессе работы bonding.Если вы будете запускать обнаружение сервисов или читать/писать характеристики, это приведет к ошибками и сбросу соединения. Просто дождитесь пока Android выполнит bonding;

• Продолжайте очередь операций после завершения bonding.Как только операция bonding завершилась, продолжайте выполнение операций из очереди;

• Если вы знаете, что делаете, и это необходимовы можете вызватьcreateBond()для запуска bonding с устройством самостоятельно. Но это должно быть исключением.

Что вызывает bonding?

Есть три причины, по которым запускается процесс bonding:

1. При соединении с устройством, оно сигнализирует, что требуется bonding, до любых других операций;

2. Характеристика может быть зашифрована для чтения или записи.При попытке прочитать или записать такую характеристику, запустится bonding. Если он пройдет удачно чтение/запись также выполнится, в случае ошибки bonding чтение/запись выполнится с ошибкойINSUFFICIENT_AUTHENTICATION. Такая же ошибка есть в iOS.

3. Вызапускаете процесс bonding самостоятельночерез вызовcreateBond(). Если этого требует ваше устройство, оно вероятно не будет совместимо с iOS, так как там нет аналогичного метода. Но формально в протоколе Bluetooth такое возможно.

Давайте обсудим каждый случай.

Bonding во время подключения

Если устройство требует bonding сразу после подключения, то при вызове колбекаonConnectionStateChangeсостояние bonding будетBOND_BONDING. Это означает что идет процесс bonding ивы не должны ничего делать в этот момент, например вызыватьdiscoverServices(), до тех пор пока процесс bonding не закончится! Иначе возможны неожиданные дисконнекты или ошибки обнаружения сервисов. Поэтому следует специально обрабатывать эту ситуацию вonConnectionStateChanged:

// Take action depending on the bond stateif(bondstate == BOND_NONE || bondstate == BOND_BONDED) {    // Connected to device, now proceed to discover it's services    ... } else if (bondstate == BOND_BONDING) {    // Bonding process has already started let it complete    Log.i(TAG, "waiting for bonding to complete");}

Чтобы следить, как идет процесс bonding, необходимо зарегистрировать колбекBroadcastReceiverдля интентаACTION_BOND_STATE_CHANGEDдо вызоваconnectGatt. Этот колбек будет вызываться несколько раз в процессе bonding.

context.registerReceiver(bondStateReceiver,                         new IntentFilter(ACTION_BOND_STATE_CHANGED));private final BroadcastReceiver bondStateReceiver = new BroadcastReceiver() {    @Override    public void onReceive(Context context, Intent intent) {        final String action = intent.getAction();        final BluetoothDevice device = intent.getParcelableExtra(BluetoothDevice.EXTRA_DEVICE);        // Ignore updates for other devices        if (bluetoothGatt == null || !device.getAddress().equals(bluetoothGatt.getDevice().getAddress()))            return;        // Check if action is valid        if(action == null) return;        // Take action depending on new bond state        if (action.equals(ACTION_BOND_STATE_CHANGED)) {            final int bondState = intent.getIntExtra(EXTRA_BOND_STATE, ERROR);            final int previousBondState = intent.getIntExtra(BluetoothDevice.EXTRA_PREVIOUS_BOND_STATE, -1);            switch (bondState) {                case BOND_BONDING:                    // Bonding started                    ...                    break;                case BOND_BONDED:                    // Bonding succeeded                    ...                    break;                case BOND_NONE:                    // Oh oh                    ...                    break;            }        }    }};

После завершения bonding, мы запускаем обнаружение сервисов (service discovery), если они еще не обнаружены, это можно проверить:

case BOND_BONDED:    // Bonding succeeded    Log.d(TAG, "bonded");    // Check if there are services    if(bluetoothGatt.getServices().isEmpty()) {        // No services discovered yet        bleHandler.post(new Runnable() {            @Override            public void run() {                Log.d(TAG, String.format("discovering services of '%s'", getName()));                boolean result = bluetoothGatt.discoverServices();                if (!result) {                    Log.e(TAG, "discoverServices failed to start");                }            }        });    }

Вот и все, что касается особенностей bonding при подключении.

Bonding при чтении/записи зашифрованных характеристик

Если bonding стартует при чтении/записи зашифрованной характеристики, то самая первая операция чтения/записи окончится с ошибкойGATT_INSUFFICIENT_AUTHENTICATION. На версиях Android-6, 7 вы получите эту ошибку вonCharacteristicRead/onCharacteristicWrite, при этом процесс bonding уже будет запущен внутри Android. С версии Android-8 ошибки не будет и Android самостоятельно повторит операцию после завершения bonding. Получается на Android-6, 7 надо повторить операцию чтения/записи самостоятельно. Итак, вам надо поймать ошибку и сделать повтор операции после bonding.

При получении такой ошибки, не продолжайте запуск операций:

public void onCharacteristicRead(BluetoothGatt gatt, final BluetoothGattCharacteristic characteristic, int status) {    // Perform some checks on the status field    if (status != GATT_SUCCESS) {        if (status == GATT_INSUFFICIENT_AUTHENTICATION ) {            // Characteristic encrypted and needs bonding,            // So retry operation after bonding completes            // This only happens on Android 5/6/7            Log.w(TAG, "read needs bonding, bonding in progress");            return;        } else {            Log.e(TAG, String.format(Locale.ENGLISH,"ERROR: Read failed for characteristic: %s, status %d", characteristic.getUuid(), status));            completedCommand();            return;        }    }...

После bonding проверяем, есть ли операция в процессе выполнения и повторяем ее:

case BOND_BONDED:    // Bonding succeeded    Log.d(TAG, "bonded");    // Check if there are services    ...    // If bonding was triggered by a read/write, we must retry it    if (Build.VERSION.SDK_INT < Build.VERSION_CODES.O) {        if (commandQueueBusy && !manuallyBonding) {            bleHandler.postDelayed(new Runnable() {                @Override                public void run() {                    Log.d(TAG, "retrying command after bonding");                    retryCommand();                }            }, 50);        }    }

Запуск bonding самостоятельно

Как я говорил выше, лучше не вызыватьcreateBondсамостоятельно, хотя сделать это, конечно можно. Спросите себя, это действительно необходимо? На iOS нет эквивалента методаcreateBond(), если этот метод единственный способ сделать bonding для вашего устройства, то скорее всего оно несовместимо с iOS. Это прямо указывается в документации iOS. Я перепробовал несколько десятков BLE устройств, и только в единственном случае я вызывалcreateBond()самостоятельно из-за исключительных обстоятельств.

При вызовеcreateBondсамостоятельно, также нельзя ничего делать, пока bonding не завершится и требуется регистрировать колбекBroadcastReceiverдля отслеживания процесса. Если устройство уже сопряжено (bonding завершился), тоcreateBond()вызовет ошибку, надо проверить состояние bonding перед вызовом.

Еще одна причина запускатьcreateBond()самостоятельно упростить повторное подключение. ОбъектBluetoothDeviceможно получить при помощи MAC-адреса, если устройство закешировано или сопряжено (bonding). Таким образом вам не придется снова сканировать устройство Может пригодиться! (Прим. переводчика: я как раз работал с таким вариантом подключения, его требовалось сделать полностью детерминированным, разбитым на подфазы, для точного понимания что происходит).

Удаление bonding

Как пользователь Android, я могу увидеть список сопряженных устройств в Bluetooth настройках. Там можно удалить устройство, bonding также будет удален.

Требуется некоторое время на удаление устройства.

Достаточно странно, что нет официального способа удалить bonding устройства программно. Это можно сделать, используя скрытый методremoveBond(), доступный через механизм рефлексии в Java:

try {    Method method = device.getClass().getMethod("removeBond", (Class[]) null);    result = (boolean) method.invoke(device, (Object[]) null);    if (result) {        Log.i(TAG, "Successfully removed bond");    }    return result;} catch (Exception e) {    Log.e(TAG, "ERROR: could not remove bond");    e.printStackTrace();    return false;}

Потеря bonding

Большинство BLE устройств поддерживают bonding только с одним смартфоном. Типичный сценарий, когда мы теряем bonding такой:

• Смартфон А делает bonding с устройством Х

• Смартфон B делает bonding с устройством Х

• Смартфон А переподключается к устройству Х, и теперь bonding потерян.

При реконнекте смартфон А получит состояние bondingBOND_NONEв колбекеBroadcastReceiver. Сравнивайте предыдущее состояние bonding, чтобы понять была потеря или нет:

case BOND_NONE:    if(previousBondState == BOND_BONDING) {       // Bonding failed       ...    } else {       // Bond lost       ...    }    disconnect();    break;

Если случилась потеря bonding, отключаемся от устройства, иначе будут происходить странные вещи и соединение с устройством не будет нормально работать. Когда вы делаете реконнект, Android снова запускает процедуру bonding. Тоже самое происходит и при обрыве связи.

Существует мелкий баг, о котором следует знать. При потере bonding, кажется нужнаодна секундадля того, чтобы Bluetooth стек обновил свое внутреннее состояние. Если сделать реконнект сразу после потери bonding, Android может сказать, что устройство все еще сопряжено, но на самом деле это будет не так. Сделайте задержку в одну секунду перед переподключением.

Pairing попап

Прим. переводчика: не нашел толковой замены слова pairing, спаривание - звучит неблагозвучно здесь.

Когда Android запускает процесс bonding, может появится всплывающее окно. Я говорю может, потому что некоторые вендоры используют свою логику показа этого попапа (Прим. переводчика: на моем Samsung-S9, после обновления до Android-10, это попап стал появляться всегда, при коннекте любого нового устройства, до этого обновления, такого не было). На смартфонах Google (или других вендоров, где код Android в этой части не изменялся), всплывающий попап появляется только при определенный условиях.

Pairing попап появляется на переднем фоне если:

• Устройство недавно было в режиме обнаружения;

• Устройство было обнаружено недавно;

• Устройство недавно было выбрано в сборщике устройств;

• Экран настроек Bluetooth виден.

Значение недавно означаетв течение последних 60 секунд. Условия выглядят непонятными, поэтому лучше посмотреть наисходный код. Если все эти условия не выполняются, то вместо попапа появится уведомление, которое большинство пользователей не замечает. Но если они заметят и нажмут на него, всплывающее окно сбивает с толку своей опцией доступа к контактам. Ужасный UI по-моему! Некоторые производители (справедливо) решили исправить такое поведение! На устройствах Samsung всплывающее окно-подтверждение (для подключений в режиме JustWorks) вообще не отображается, а всплывающие окна всегда появляются на переднем плане. При этом всплывающее окно открывается только при вводе PIN-кода или кодовой фразы. Никаких доступов к контактам и всегда передний план. Так намного лучше!

Так что, если вдруг вы захотите, чтобы всплывающее окно всегда отображалось на переднем плане, запускайте обнаружение на одну секунду перед подключением к устройству. Выглядит как хак, но это работает. Код ниже:

public void startPairingPopupHack() {    String manufacturer = Build.MANUFACTURER;    if(!manufacturer.equals("samsung")) {        bluetoothAdapter.startDiscovery();        callBackHandler.postDelayed(new Runnable() {            @Override            public void run() {                Log.d(TAG, "popup hack completed");                bluetoothAdapter.cancelDiscovery();            }        }, 1000);    }}

Важный момент здесь вы не должны запускать никакие BLE операции пока попап на экране. Подождите ответа от пользователя.

Если учтете все эти моменты, bonding будет работать как часики!

Подведение итогов

На этом мы завершаем цикл статей о BLE в Android (Прим. переводчика: я готовлю отдельную статью-заключение, где опишу свои подходы к работе с BLE устройствами на Android, небольшие ньюансы и решения для стабильной продолжительной работы с устройствами). Надеюсь эта информация будет полезной вам и сделает работу с BLE комфортнее. Чем больше знаешь про BLE, тем лучше работает ваше приложение. Успехов!

Не терпится поработать с BLE? Попробуйтемою библиотеку Blessed for Android. Она использует все подходы из этой серии статей и упрощает работу с BLE в вашем приложении.