gatt bluetooth что это
BLE & GATT или как отправить данные по Bluetooth.
Разрабатывая кормушку для кота, я в итоге прикрутил к ней блютус. Конечно, можно поставить на телефон обычный Bluetooth to Serial Terminal и спокойно слать нужные команды. Но так как мы не ищем простых путей, я решил написать свое приложение (на JS + Cordova) для общения с модулем HM-10. Однако, общение оказалось не таким простым, как c обычными Bluetooth устройствами. А все почему? Да потому что устройства BLE имеют немного другой принцип коммуникации.
Принцип работы BLE описан уже в его названии: Low Energy. Протокол подразумевает передачу данных короткими пакетами по необходимости, затем – выключение передатчика. Низкое энергопотребление частично достигается применением именно этого принципа. Вместо классического тандема в обычном Bluetooth, устройства BLE связываются друг с другом лишь при необходимости отправки или получения информации.
Протокол BLE строго структурирован по принципу своей коммуникации с другими устройствами. Вначале девайсы изучают доступные сервисы для отправки/принятия данных; неотъемлемая часть этих сервисов – их характеристики (characteristics), определяющие тип данных для будущей передачи. Характеристики, из соображений наглядности, могут иметь в своём составе описания-дескрипторы (descriptors), которые помогают определить тип данных. К примеру, разберём сервис под названием «Heart Rate Monitor» (монитор частоты сердцебиения) – среди его характеристик присутствуют такие, как «измерение пульса».
Большинство API для Bluetooth LE позволяют искать локальные устройства и определять доступные в них сервисы, характеристики и дескрипторы.
Термины и концепции протокола BLE
Предлагаю вашему вниманию краткий обзор ключевых терминов протокола BLE и его концепций. До начала работы над проектом BLE нужно понимать каждый из них.
Профиль общих атрибутов (GATT)
Профиль общих атрибутов (General Attribute Protocol, GATT) – это обязательный профиль с общими спецификациями отправки и приёма коротких порций данных, известных в Bluetooth Low Link под названием «атрибуты». Все нынешние профили приложений LE основаны на GATT. Институт стандартизации и разработки протокола – Bluetooth Special Interest Group уже задал для устройств BLE несколько профилей. Эти профили представляют собой спецификации, описывающие способ применения и взаимодействия с устройствами.
Протокол атрибутов (ATT)
Протокол атрибутов (он же Attribute Protocol, ATT) – основывается на GATT. ATT – оптимизированный протокол, созданный исключительно для устройств BLE. Принцип ATT – отсылать столь малое количество байтов, насколько это возможно. У каждого атрибута есть уникальный универсальный идентификатор, UUID. Он представляет собой стандартизированный 128-битный строковый ID, используемый для идентификации уникальной информации. Формат атрибутов, передаваемых как ATT, бывает двух типов: характеристики и сервисы:
Характеристика (Characteristic)
Характеристика содержит однозначный параметр, а также дескрипторы. Количество дескрипторов может быть равно нулю, то есть это не обязательная часть характеристики. Дескрипторы описывают значение характеристики.
Дескрипторы (Descriptors)
Дескрипторы представляют собой определённые атрибуты, которые описывают значение характеристики. Дескрипторы могут быть в виде понятных описаний на вполне человеческом языке, определять единицы измерений, а также задавать ряд допустимых значений.
Сервис (Service)
Сервис это совокупность характеристик. Список существующих профилей на основе GATT можно просмотреть здесь.
Работа с GATT в Cordova
Для большей наглядности взаимосвязи этих терминов приведем схему
Т.е. профайл устройства HM-10 имеет несколько сервисов, каждый из которых включает себя различные характеристики.
Пока не особо понятно, как мне теперь со всем этим работать. Естетсвенно, порыскав в гугле я начал пробовать все это на практике.
Вот наши сервисы: 
А вот наши характеристики: 
Однако это все я узнал немного позднее. Сначала я экспериментировал с передачей данных подключаясь к устройствам исходя из описания характеристик.
Мне нужно было найти такую характеристику, которая позволяла бы передавать и получать данные. Как я понял, описание этих характеристик и сервисов должно быть в тех документации к каждому BLE-устройству.
В принципе, этого мне было достаточно, для того чтобы передавать нужные команды и получать фидбек от устройства.
Если у Вас есть что добавить, уточнить или указать мне на неточности или ошибки, пишите комментарии. Потому что некоторые углубленные моменты для меня остались непонятны 🙂
В статье были исользованы материалы с хабра и оф сайта Bluetooth
Присоединяйтесь к нашим каналам FrontEndDev и Web Stack и моему личному блогу Sleepless Tech в Telegram, чтобы не пропустить самое интересное из мира Web!
Чтение GATT-характеристик Bluetooth устройства
Работая над своей ANE библиотекой для работы с Bluetooth LE в AIR приложении для iOS+OSX, обнаружил что помимо ваших собственных сервисов и характеристик для обмена информацией, у bluetooth-устройств есть стандартные. Статья о том, как считывать информацию с этих характеристик. Скажу сразу я не большой знаток bluetooth и всего что с ним связано, и для меня все это в новинку 🙂 Поехали…
Сервисы и характеристики OSX устройства
Сервис Continuity
Сервис Continuity служит для передачи данных между связанными Apple устройствами, подробнее здесь: www.apple.com/ru/ios/whats-new/continuity. Если будет время разобраться в формате передаваемых данных — напишу об этом отдельный пост.
Сервис 180A (Device Information)
В моем случае я получил значения:
С этими характеристиками было все просто, идем дальше.
Сервисы и характеристики iOS устройства
Сервис 7905F431-B5CE-4E99-A40F-4B1E122D00D0, это сервис центра уведомлений Apple, подробнее здесь: developer.apple.com/library/ios/documentation/CoreBluetooth/Reference/AppleNotificationCenterServiceSpecification/Specification/Specification.html. Будет время, попробую разобраться в формате данных и напишу отдельный пост по работе с bluetooth-сервисами устройств Apple.
Сервис 180F (Battery Service)
Сервис 180F — это информация о заряде батареи. Этот сервис имеет одну единственную характеристику 2A19, в описании которой сказано что характеристика имеет одно единственное поле формата uint8: 
Прочитать эту информацию в AIR приложении можно так:
Получим значение от 0 до 100, соответствующее уровню заряда батареи устройства.
Сервис 1805 (Current Time Service)
Характеристика 2A0F (Local Time Information)
Характеристика 2A0F имеет два поля:
Открываем описание первого поля Time Zone и видим что оно содержит в себе одно поле формата sint8.
Второе поле у сервиса 2A0F это Daylight Saving Time — информация о переходе на летнее время, формат: uint8.
Итак, чтобы прочитать характеристику 2A0F в AIR приложении используем следующий код:
В моем случае я получил значения:
Значение 12 в поле TimeZone соответствует временной зоне UTC+3:00, согласно XML файлу:
cкачать который можно в описании поля Time Zone нажав кнопку Download / View напротив имени поля.
Характеристика 2A2B (Current Time)
Характеристика 2A2B представляет текущее время на устройстве, и она имеет многоуровневую вложенность полей, ознакомиться с описаниями и форматами которых вы можете самостоятельно. Я приведу только код, для считывания полной информации о текущем времени устройства:
Здесь есть несколько важных моментов.
Первое: в примечаниях всех GATT спецификаций сказано:
Это значит что в ByteArray первым идет младший байт, в AIR это можно указать с помощью свойства endian:
Второе: поле fraction, как следует из описания — это 1/256я секунды, т.е. чтобы получить миллисекунды пишем код:
И третье: я так и не разобрался что такое Adjust Reason. Кто знает — поделитесь информацией :).
Сервер Bluetooth GATT
В этой статье описываются API-интерфейсы сервера Bluetooth Generic Attribute (GATT) для приложений универсальной платформы Windows (UWP) и приводится пример кода для основных задач сервера GATT.
В Package. appxmanifestнеобходимо объявить возможность «Bluetooth».
Важные API
Общие сведения
Как правило, Windows функционирует в роли клиента. Однако существует множество сценариев, когда операционная система Windows должна выполнять функции сервера Bluetooth GATT с низким энергопотреблением. Сюда относятся почти все сценарии для устройств интернета вещей, а также большинство сценариев обмена данными с использованием BLE. Все эти сценарии требуют, чтобы операционная система Windows функционировала как сервер GATT. Кроме того, эта технология обязательна для такого популярного сценария, как отправка уведомлений на ближайшие носимые устройства.
Операции сервера связаны с классами Service Provider и GattLocalCharacteristic. Эти два класса предоставляют функции, необходимые для объявления, реализации и предоставления иерархии данных на удаленном устройстве.
Определение поддерживаемых служб
Приложение может объявить одну или несколько служб, которые будут опубликованы в Windows. Каждая служба имеет уникальный идентификатор UUID.
Атрибуты и идентификаторы UUID
Каждая служба, характеристика и дескриптор имеет свой уникальный 128-битный идентификатор UUID.
Ко всем API-интерфейсам Windows применяется термин GUID, но в стандарте Bluetooth этот идентификатор определяется как UUID. В нашем случае эти два термина взаимозаменяемы, поэтому мы будем использовать термин UUID.
если атрибут является стандартным и определяется Bluetooth определяемым SIG, он также будет иметь соответствующий 16-разрядный короткий идентификатор (например, UUID уровня аккумулятора — 00002A19-0000-1000-8000-00805F9B34FB, а короткий идентификатор — 0x2A19). Эти стандартные идентификаторы UUID описаны в статьях GattServiceUuids и GattCharacteristicUuids.
Если ваше приложение реализует собственную службу, необходимо создать пользовательский UUID. это легко сделать в Visual Studio с помощью tools- > креатегуид (используйте вариант 5, чтобы получить его в формате «xxxxxxxx-xxxx-. XXXX «формат». Этот UUID можно использовать для объявления новых локальных служб, характеристик или дескрипторов.
Службы с ограниченным доступом
Перечисленные ниже службы зарезервированы системой и в настоящее время недоступны для публикации:
При попытке создать заблокированную службу вызов к CreateAsync вернет ошибку BluetoothError.DisabledByPolicy.
Генерируемые атрибуты
Перечисленные ниже дескрипторы автоматически генерируются системой в соответствии с классом GattLocalCharacteristicParameters, предоставленным в процессе создания характеристики:
Значение дескриптора Extended Properties определяется свойствами характеристики ReliableWrites и WritableAuxiliaries.
Попытка создать зарезервированный дескриптор вызывает исключение.
Примечание: широковещательная рассылка в настоящее время не поддерживается. Если задать свойство Broadcast GattCharacteristicProperty, будет создано исключение.
Создание иерархии служб и характеристик
Для создания и объявления определения основной корневой службы используется класс GattServiceProvider. Каждой службе требуется собственный объект ServiceProvider, в который передается GUID:
Основные службы находятся на верхнем уровне дерева GATT. Основные службы содержат характеристики и другие службы («включенные» или дополнительные).
Задайте обязательные характеристики и дескрипторы для службы:
Здесь также удобно объявлять обработчики событий для операций, поддерживаемых каждой характеристикой (см. рис. выше). Чтобы приложение правильно реагировало на запросы, необходимо определить и настроить обработчик событий для каждого типа запроса, поддерживаемого атрибутом. Если обработчик не зарегистрирован, система мгновенно выполняет запрос с ошибкой UnlikelyError.
Постоянные характеристики
Некоторые значения характеристик не меняются в течение всего жизненного цикла приложения. В этом случае рекомендуется объявить постоянную характеристику во избежание нежелательной активации приложения:
Публикация службы
После определения всех атрибутов службы необходимо опубликовать поддержку для этой службы. Публикация информирует операционную систему о том, что эта служба должна возвращаться, когда удаленные устройства выполняют поиск служб. Необходимо настроить два свойства: IsDiscoverable и IsConnectable.
Когда для службы заданы оба свойства, Discoverable и Connectable, система добавляет UUID этой службы в пакет объявления. Размер пакета объявления составляет всего 31 байт, и 16 из них занимает 128-битный UUID.
Примечание: когда служба публикуется на переднем плане и работа приложения приостанавливается, приложение должно вызвать функцию StopAdvertising.
Реагирование на запросы чтения и записи
Как упоминалось в разделе об объявлении требуемых характеристик, атрибут GattLocalCharacteristics поддерживает 3 типа событий: ReadRequested, WriteRequested и SubscribedClientsChanged.
Чтение
Когда удаленное устройство пытается прочитать значение характеристики и это значение не является постоянным, вызывается событие ReadRequested. Характеристика, для которой была вызвана операция чтения, а также аргументы, содержащие сведения об удаленном устройстве, передаются делегату:
запись
Когда удаленное устройство пытается записать значение в характеристику, вызывается событие WriteRequested с подробными сведениями об удаленном устройстве, соответствующей характеристике и самом значении:
Существует 2 типа операций записи: с ответом и без ответа. Чтобы определить, какую операцию записи выполняет удаленное устройство, используйте свойство GattWriteOption в объекте GattWriteRequest.
Отправка уведомлений подписанным клиентам
Отправка уведомлений — наиболее часто выполняемая операция сервера GATT. Уведомления выполняют важную функцию публикации данных на удаленных устройствах. В зависимости от конкретной ситуации можно отправлять уведомления всем подписанным клиентам или самостоятельно выбирать устройства для отправки нового значения:
Когда новое устройство подписывается на уведомления, вызывается событие SubscribedClientsChanged:
Примечание: приложение может определять максимальный размер уведомления для конкретных клиентов с помощью свойства MaxNotificationSize. Система применяет усечение к любым данным, размер которых превышает максимальное значение.
BLE под микроскопом (ATTы GATTы. )
BLE под микроскопом (ATTы GATTы. )
Уже прошло довольно большое время, с тех пор, когда вышла первая спецификация на Bluetooth 4.0. И, хотя тема BLE очень интересна, она до сих пор отталкивает многих разработчиков, из-за своей сложности. В своих предыдущих статьях я рассматривал в основном самый нижний уровень Link Layer и Physical Layer. Это позволяло не обращаться к таким сложным и запутанным понятиям как протокол атрибутов(ATT) и общий профиль атрибутов (GATT). Однако деваться некуда, не понимая их, невозможно разрабатывать совместимые устройства. Сегодня я хотел бы поделиться с вами этими знаниями. В своей статье я буду опираться на учебник для начинающих с сайта Nordic-а. Итак, давайте приступим.
Почему всё так сложно?
На мой взгляд, сразу было понятно, что управление устройствами через смартфоны — тема очень перспективная и долгоиграющая. Поэтому её решили структурировать сразу и по-максимуму. Что бы производители различных гаджетов не придумывали свои протоколы, которые потом будут не совместимы. Отсюда и сложность. Уже на первом этапе в протокол BLE попытались втиснуть всё что только было возможно. И не важно пригодится это в последствии или нет. Кроме того, предусмотрели возможность расширения списка устройств на будущее.
Давайте взглянем на картинку, где нарисована схема протокола BLE. Он состоит из нескольких слоев. Самый нижний, физический слой (PHY) отвечает за радиоканал устройства. Link Layer(LL) содержит всю последовательность байтов в передаваемом сообщении. В прошлых статьях мы изучали именно его. Host Controller Interface (HCI) — это протокол обмена между слоями или микросхемами BLE, если Controller и Host реализованы на разных чипах. За формирование пакетов, деление на кадры, контролем ошибок и сборку пакетов отвечает Logical Link Control and Adaptation Protocol (L2CAP). За шифрование пакетов отвечает Security Manager Protocol (SMP). Профиль общего доступа (GAP) отвечает за первоначальный обмен данными между устройствами, для определения «Who is who». К нему так же относятся scanning и advertising. В этой статье я остановлюсь на двух оставшихся частях протокола — GATT и ATT. GATT является надстройкой над ATT, поэтому они сильно переплетены.
Для упрощения повествования, я бы хотел обратиться к аналогии. Я её где то слышал и хотел бы поддержать. Представьте себе BLE устройство в качестве книжного шкафа с несколькими полками. Каждая полка — это отдельная тематика. К примеру, у нас есть полки с фантастикой, математикой, энциклопедиями. На каждой полке стоят книги с указанной темой. А в некоторых книгах есть даже бумажные закладки с записями. Кроме того, у нас есть небольшой бумажный каталог всех книг. Если помните школьные библиотеки — это узкий ящик с бумажными карточками. При такой аналогии шкаф — это профиль нашего устройства. Полки — это сервисы, книги — характеристики, а каталог — это таблица атрибутов. Закладки в книгах — это дескрипторы, о которых я так же расскажу позже, более подробно.
Все, кто разрабатывал устройства, знает, что во многих проектах есть похожие куски кода. Дело в том, что многие устройства имеют сходный функционал. К примеру, если устройства работают от аккумуляторов, то проблема зарядки и контроля их уровня, будет одинаковой. То же касается и датчиков. Собственно, объектно-ориентированный подход в программировании «предоставляет возможность создавать объекты, которые соединяют свойства и поведения в самостоятельный союз, который затем можно многоразово использовать». На мой взгляд, в BLE была предпринята попытка похожего подхода. Группой Bluetooth Special Interest Group (SIG) были разработаны профили. Устройства от разных производителей, имеющие одинаковые профили, должны без труда работать друг с другом. Профили в свою очередь состоят из сервисов, а сервисы из характеристик, дополняемых дескрипторами. В общем случае это может выглядеть так:
Для примера, рассмотрим схему профиля heart rate monitor (фитнес браслет). Он состоит из двух сервисов и нескольких характеристик. Из неё сразу становится понятна иерархия профиля. Характеристика контрольной точки сбрасывает общий подсчет расходов калорий в ноль.
1. Сервис сердечного ритма включает три характеристики (0x180D):
a) Обязательная характеристика частоты сердечных сокращений (0х2A37)
б) Опционная характеристика положения датчика тела (0x2A38)
в) Условная характеристика контрольной точки сердечного ритма (0x2A39)
2. Сервис обслуживания батареи (0x180F):
a) Обязательная характеристика уровня заряда батареи (0x2A19)
Для того, чтобы мы могли однозначно обращаться к элементам профиля (сервисам, характеристикам и дескрипторам) нужно все их как то пронумеровать. Для этой цели вводят такое понятие как Universally Unique ID (UUID) или Универсальный уникальный идентификатор. В скобках каждой строки как раз и указан UUID. И здесь есть одна особенность. Для UUID решили использовать код длиной 16 и 128 бит. Зачем, спросите вы? В протоколе BLE всё подчинено сохранению энергии. Поэтому размерность в 16 бит вполне разумна. Вряд ли в ближайшем будущем будет создано больше 65тыс. уникальных сервисов и характеристик. На данный момент всё что могли, уже посчитали (помните откуда это — «он и вас посчитал» :-)) Пронумерованные элементы профилей, сервисов, характеристик и дескрипторов вы можете посмотреть по ссылкам.
Однако, я думаю, все помнят историю с 4-мя байтами IPv4 адреса в интернете. Сначала думали что хватит, а теперь всё никак не перейдем на IPv6 адресацию. Что бы не повторять этой ошибки и дать простор шаловливым ручкам самодельщиков, SIG сразу решила ввести ещё и 128-ми битные UUID. Это лично мне напоминает нелицензионный диапазон 433МГц, который был дан на откуп всевозможным Кулибиным от радиоканала. В нашем случае, на откуп был отдан 128-ми битный идентификатор сервисов и характеристик. Это означает что мы, для своих сервисов и устройств, можем использовать практически любое 128 битное значение. Всё равно вероятность придумать одинаковый UUID стремится к нулю.
На самом деле, короткие 16-ти битные UUID имеют своё расширение до 128-ми битного значения. В спецификации это расширение называется Bluetooth Base UUID и имеет значение 00000000-0000-1000-8000-00805F9B34FB. Если, к примеру, 16-ти битный UUID аттрибута имеет значение 0x1234, то эквивалентный ему 128-ми битный UUID будет иметь значение 00001234-0000-1000-8000-00805F9B34FB. И даже приводится соответствующая формула:
128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID
Откуда взялось это магическое число, мне не известно. Если кто нибудь из читателей знает — пусть напишет в комментариях (Пользователь с ником Sinopteek уже сделал это. Смотрите комментарии). Что касается придумывания 128-ти битных UUID, то в принципе можно воспользоваться специальным генератором, который сделает это за вас.
ATTы GATTы.
Собственно дальше начинается самое интересное. Я напомню, что ATT основан на клиентском-серверном отношении. Сейчас мы рассматриваем устройство сервера. Он содержит такую информацию, как значения датчиков, состояние выключателя света, данные о местоположении и т.д. Теперь, когда все «участники нашего парада» пронумерованы, надо как то их размещать в памяти устройства. Для этого мы помещаем их в таблицу, которая называется таблицей атрибутов. Запомните это хорошенько. Это самое сердце BLE. Именно его мы и будем рассматривать в дальнейшем. Теперь каждую строчку мы будем называть аттрибутом. Эта таблица находится в глубине стека и, как правило, мы не имеем к ней прямого доступа. Мы её инициализируем и к ней обращаемся, но что там происходит внутри, от нас скрыто за семью печатями.
Рассмотрим картинку из спецификации, однако перед этим, хочу сразу обратить внимание на частую путаницу в терминах, а именно в дескрипторах. Роль дескриптора — дополнить описание характеристики. Когда надо расширить её возможности, тогда и применяют дескрипторы. Они так же являются аттрибутами, и так же, наравне с сервисами и характеристиками, располагаются в таблице аттрибутов. Мы подробно разберем их во второй части статьи. Однако иногда дескрипторами называют номер строки в таблице аттрибутов. Это надо иметь ввиду. Мы же, что бы не путаться, будем для этих целей использовать термин «указатель атрибута».
Итак атрибут — это дискретное значение, которое имеет следующие свойства, связанные с ним:
1. Указатель атрибута (Attribute Handle) — это индекс таблицы, соответствующий атрибуту
2. Тип атрибута (Attribute Type) — это UUID, который описывает его тип
3. Значение аттрибута (Attribute Value) — это данные, индексируемые указателем атрибута
4. Разрешения атрибутов (Attribute Permissions) — это часть атрибута, разрешения, которые не могут быть прочитаны или записаны с использованием протокола атрибутов
Как всё это понимать? Указатель аттрибута — это, условно говоря, его номер в нашей таблице.
Он позволяет клиенту ссылаться на атрибут в запросах чтения или записи. Мы можем нумеровать наши строчки (аттрибуты) от 0x0001 до 0xFFFF. В нашей ассоциации с книжным шкафом — это номер карточки в бумажном каталоге. Аналогично, как в каталоге библиотеки, карточки располагаются в порядке увеличения номера. Номер каждой последующей строчки должен быть больше предыдущей. Как и в библиотеке, иногда теряются некоторые карточки, так и у нас — в нумерации строк могут быть промежутки. Это допускается. Главное, что бы они шли по нарастающей.
Тип атрибута определяет что представляет собой данный атрибут. По аналогии с языком Си,
где есть булевые, числовые переменные и строки, так и здесь. По типу аттрибута мы узнаем
с чем мы имеем дело и как нам дальше с этим аттрибутом работать. Ниже мы рассмотрим некоторые специфичные типы аттрибутов. Например «сервисная декларация» (0х2800), «декларация характеристики» (0х2803), «декларация дескриптора» (0x2902).
Как это выглядит
Концепция GATT заключается в том, чтобы сгруппировать атрибуты в таблице атрибутов вместе в очень специфическом и логическом порядке. Давайте более внимательно рассмотрим профиль частоты сердечных сокращений, приведенный ниже. Самый левый столбик этой таблицы не обязательный. Он просто описывает нам чем является эта строчка (аттрибут). Все остальные столбцы нам уже знакомы.
В верхней части каждой группы мы всегда имеем атрибут объявления сервиса. Его тип всегда равен 0x2800, а указатель зависит от того, сколько атрибутов уже присутствует в таблице. Его разрешения всегда доступны только для чтения, без какой-либо проверки подлинности или авторизации. Об этих понятиях мы поговорим чуть позже. Значение — это еще один UUID, определяющий, что это за служба. В Таблице значение равно 0x180D, что определяется Bluetooth SIG как сервис частоты сердечных сокращений.
Вслед за объявлением сервиса, следует объявление характеристики. По форме оно аналогично объявлению сервиса. Его UUID всегда имеет значение 0x2803, а разрешения так же всегда доступны только для чтения без какой-либо проверки подлинности или авторизации. Давайте посмотрим на поле Attribute Value, которое включает некоторые данные. Оно всегда содержит указатель, UUID и набор свойств. Эти три элемента описывают последующее объявление значения характеристики. Указатель естественным образом обозначает место объявления значения характеристики в таблице атрибутов. UUID описывает, какой тип информации или значения мы можем ожидать. Например, значение температуры, состояние выключателя света или какое-либо другое произвольное значение. И наконец свойства, которые описывают, как можно взаимодействовать с характеристическим значением.
Тут нас поджидает ещё один подводный камень. Он связан с разрешениями аттрибутов и свойствами характеристик. Давайте мы посмотрим на картинку свойств битового поля из спецификации.
Как видите, здесь так же присутствуют поля, дающие возможности чтения и записи. Вы можете задаться вопросом, почему у нас есть разрешения на чтение/запись для атрибута и свойства
чтения/записи для значения характеристики? Разве они не должны быть всегда одинаковыми? Дело в том, что свойства для значения характеристики, фактически являются только рекомендациями для клиента, используемыми в ГАТТ и прикладных слоях. Это просто подсказки о том, что клиент может ожидать от атрибута объявления характеристики. Давайте с этим разберемся поподробнее. Какие виды разрешений существуют у аттрибута?
1. Разрешения доступа:
— чтение
— запись
— чтение и запись
2. Разрешение аутентификации:
— аутентификация требуется
— аутентификация не требуется
3. Разрешение авторизации:
— авторизация требуется
— авторизация не требуется
Главное отличие разрешения аттрибутов от свойств характеристик состоит в том, что первые относятся к серверам, а вторые к клиентам. У сервера может быть разрешено чтение значения характеристики, но при этом стоять требование аутентификации или авторизации. Поэтому при запросе клиентом свойств характеристики, мы получим, что чтение разрешено. Но при попытке чтения получим ошибку. Поэтому можно смело говорить о приоритете разрешений над свойствами. Знание о том, какие разрешения есть у аттрибута, мы, со стороны клиента, получить не можем.
Дескриптор
Вернемся к нашей таблице. После объявления значения характеристики, возможны следующие объявления аттрибутов:
1. Новое объявление характеристики (в сервисе может быть много характеристик)
2. Новая декларация сервиса (в таблице может быть их много)
3. Объявление дескриптора
В случае характеристики измерения частоты сердечных сокращений, в нашей таблице, объявление значения характеристики сопровождается объявлением дескриптора. Дескриптор — это атрибут с дополнительной информацией о характеристике. Существует несколько видов дескрипторов. О них мы подробно поговорим во второй части этой статьи. Сейчас же мы коснемся только дескриптора конфигурации характеристик клиента (Client Characteristic Configuration Descriptor — CCCD). Он имеет UUID равную 0х2902. При помощи этого дескриптора клиент имеет возможность включить на сервере индикацию или нотификацию. Разница между ними небольшая, но всё таки есть. Нотификация не требует подтверждения в получении со стороны клиента. Индикация же этого требует, хотя она и происходит на уровне GATT, не доходя до уровня приложения. Зачем так, спросите вы? Увы, это мне не ведомо. Скажу лишь, что специалисты Nordic-а рекомендуют использовать нотификацию. Тем более, что проверка целостности пакета (при помощи CRC) происходит в обоих случаях.
Заключение
В конце статьи я хотел бы сказать вот о чем. Последняя таблица несколько запутанна. Однако я остановился на ней из-за того, что она приводится в статье, на которую я опираюсь. Во второй части своей статьи я намерен углубиться в спецификацию BlueTooth 4.0. Там нас ждут более корректные схемы и рисунки. В третьей части, я хотел бы разобрать лог, полученный при помощи программы Wireshark от одного из гаджетов и увидеть «в живую» всю ту теорию, которую мы с вами изучаем.
Сотрудник Группы Компаний «Цезарь Сателлит»
Печерских Владимир