Комментарии 20
Планирую сначала сделать практическую, третью часть, ну а потом уже написать вторую, с погружением в спецификацию. Что бы во второй части не пропустить описание тех фреймов, что будут в третьей. Запутанно получилось, ну да ладно.
Про BLE есть хорошая бесплатная книга от Мохаммада Афане (https://www.novelbits.io/introduction-to-bluetooth-low-energy-book/)
Знаете, Solfar, а мне книга Мохаммада Афане понравилась. Спасибо за ссылку. С удовольствием полистал. На большую глубину она правда не претендует, да и к тому же на английском языке. Зато в популярной форме старается донести сложные понятия. Спасибо

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

Спасибо за отличный материал! Можете уточнить, HID — профили устройства, как-то задействованы? Они чем-то отличаются от GATT?
Честно говоря, я с HID BLE устройствами не работал. Знаю только что у NORDIC-а в примерах есть пара проектов HID устройств. Клавиатура и мышка. К тому же посмотрел в списке характеристик www.bluetooth.com/specifications/gatt/characteristics на сайте. Там есть две характеристики: HID Control Point (0x2A4C) и HID Information (0x2A4A). Так что для работы с HID устройствами, скорее всего, применяют ту же модель, что я изложил в статье. Либо используют сервисы с данным и характеристиками, либо на их основе создают свои собственные сервисы.
Есть стандарт HID over GATT. HID устройство представляется как набор атрибутов. Но я с этим профилем не работал.
Спасибо что постарались раскрыть тему BLE на хабре. Мне сложно оценивать понятность статьи для начинающих, потому что я имею некоторый опыт работы с BLE и знаю что там внутри. Но хотелось бы продолжить вашу аналогию с книжной полкой. Для вышестоящего уровня приложений нужны полки (сервисы) с книгами (характеристиками). Но на нижестоящем уровне на самом деле нет ни полок ни обложек. Есть только атрибуты (листы) у каждого из которых есть handle и прочее содержимое. Одна характеристика (книга) может состоять из нескольких атрибутов (листов), уложенных подряд. А книжная полка (сервис) может состоять из нескольких характеристик (книг) уложенных подряд. А вот листов в книге может быть несколько. Некоторые обязательные, например chacteristic declaration, своего рода «обложка» и основное содержимое characteristic value, и опциональные такие как characteristic user description (своего рода комментарии автора), client characteristic properties, и прочее.
Стараюсь понемногу. В русском сегменте интернета очень мало статей по BLE. Если бы специалисты не ленились и больше делились своими знаниями, то выиграли бы все. Спасибо за комментарий
Судя по описанию такая штука с описанием аттрибутов, типов и имен, появляется рано или поздно в любой системе описания данных. Ближайшая аналогия которую могу вспомнить — Active Directory.
И правда, хорошо что обо всем сразу подумали, чтобы не костыляли криворукие.
Формат UUID используемый в Bluetooth описывается в ISO/IEC 11578. Сам UUID состоит из 2 основных частей: времени и уникального идентификатора (MAC). Если не погружаться глубоко, то см. ru.wikipedia.org/wiki/UUID
Пропустив 00000000-0000-1000-8000-00805F9B34FB через сервис www.famkruithof.net/uuid/uuidgen?typeReq=1 мы получаем первый день Григорианского календаря — Friday, October 15, 1582 at 12:00:00 AM
А последняя часть — MAC-адрес ПК на котором был сгенерирован базовый UUID. Это был HP (на момент регистрации Compaq) https://macaddress.webwat.ch/hwaddr/00:80:5F#simname.
Спасибо. Очень рад, что получил ответ на давно мучавший меня вопрос. В статье я добавил одну строчку с указанием Вашего ника. Пусть народ просвещается.
Спасибо за интересную статью.
А нет ли у Вас ошибки в таблице атрибутов (раздел «Как это выглядит»)? Вы ниже пишете, что дескриптор конфигурации характеристик клиента (Client Characteristic Configuration Descriptor — CCCD) имеет UUID равную 0х2902, а в таблице для него стоит UUID «Standard UUIDservice» равный 0x2800.
Dmitro25, спасибо за то что увидели неточность. Я её так же видел :-), поэтому в заключении немного коснулся этого. Картинка не моя, она взята по этой ссылке: devzone.nordicsemi.com/nordic/short-range-guides/b/bluetooth-low-energy/posts/ble-characteristics-a-beginners-tutorial В картинке существует ошибка. Client Characteristic Configuration Descriptor (CCCD) имеет UUID равную 0х2902. Исправлять картинку я уже не стал.

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

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