11.6. Сервіси та характеристики#

Після того як GAP встановив відкрите з’єднання між двома пристроями, шар над ним – Generic Attribute Profile, GATT – має надати значення байтам, що передаються через це з’єднання. Вибір BLE тут незвичний. Там де TCP надає необроблений потік байтів і залишає застосунку вигадувати власне кадрування, GATT надає невелику базу даних ключ/значення, яку одна сторона розміщує, а інша читає, записує або підписується на неї.

Саме ця база даних займає більшу частину часу розробників BLE-застосунків. Що камера публікує на телефон, що вона відстежує на віддаленому датчику, як Bluetooth-клавіатура повідомляє хосту про натиснуту клавішу – все це значення характеристик у певній базі даних GATT.

11.6.1. Два виміри ролей, а не один#

Поширене джерело плутанини: peripheral / central і server / client – це два незалежні виміри, а не синоніми.

Peripheral і central – це ролі GAP, що встановлюються під час з’єднання. Peripheral анонсує себе і приймає підключення; central сканує і ініціює з’єднання. Це визначається в момент встановлення зв’язку і не змінюється.
Server і client – це ролі GATT, що встановлюються для кожної операції з характеристикою. Server розміщує характеристику; client читає, записує або підписується на неї.

Два виміри роз’єднані специфікацією. Peripheral є зазвичай server (монітор серцевого ритму публікує свої показники), а central є зазвичай client (телефон їх читає), але BLE допускає будь-яку комбінацію – peripheral може виявити характеристику на central, до якого щойно підключився, або одне з’єднання може розміщувати сервіси з обох боків одночасно.

Більшість застосунків для камер дотримуються стандартного поєднання (peripheral + server або central + client), тому решта цього розділу розглядає їх як один вимір, коли йдеться про стандартний випадок. Коли різниця важлива, обидва терміни вказуються явно.

11.6.2. Всередині бази даних#

База даних GATT – це дерево. Листки містять власне байти. Гілки групують пов’язані листки у логічно зрозумілі одиниці.

A tree with a top node labelled "GATT database". Below it, three Service nodes labelled "Generic Access (0x1800)", "Battery (0x180F)", and "Environmental Sensing (0x181A)". Each Service has child Characteristic nodes; the Battery service has "Battery Level (0x2A19)" with a child Descriptor "CCCD". The Environmental Sensing service has "Temperature (0x2A6E)" and "Humidity (0x2A6F)". — База даних GATT. Сервіси групують характеристики; характеристики несуть байти застосунку; дескриптори несуть метадані про характеристику.#

Є три види вузлів:

Service – логічна група пов’язаних значень. Bluetooth SIG публікує стандартні визначення сервісів для поширених випадків використання – Battery Service для рівня заряду, Environmental Sensing для температури / вологості / тиску, Heart Rate для моніторів серцевого ритму – тому звичайний застосунок на телефоні може розпізнати сервіс, якого він ніколи раніше не бачив. Застосунок також може визначати власні сервіси для речей, які SIG не стандартизував.
Characteristic – одне іменоване значення всередині сервісу. Battery service має одну характеристику – Battery Level, однобайтовий відсоток. Environmental Sensing має окремі характеристики для температури, вологості, тиску тощо. Характеристика є одиницею операцій GATT – ви читаєте характеристику, записуєте характеристику, підписуєтеся на характеристику.
Descriptor – метадані, прикріплені до характеристики. Деякі дескриптори стандартизовані – Client Characteristic Configuration Descriptor (CCCD) є найвідомішим, оскільки запис до нього – це спосіб, яким client повідомляє server «надсилайте мені сповіщення про цю характеристику». Інші визначаються користувачем і містять такі речі, як формат представлення або розширені властивості.

GATT server (зазвичай peripheral) оголошує свою базу даних один раз під час запуску, і вона не змінюється під час роботи. GATT client (зазвичай central) виявляє вміст бази даних після підключення – обходячи дерево, читаючи UUID сервісів, а потім характеристики всередині кожного.

11.6.3. UUID#

Кожен сервіс, характеристика та дескриптор має UUID (Universally Unique IDentifier), що ідентифікує що це таке за видом. UUID бувають трьох розмірів:

16-бітні. Зарезервовані для стандартів, визначених Bluetooth SIG. Battery Service – 0x180F. Battery Level (характеристика) – 0x2A19. Повний список опублікований на сайті assigned-numbers Bluetooth SIG за адресою https://www.bluetooth.com/specifications/assigned-numbers/.
32-бітні. Рідко використовуваний проміжний варіант.
128-бітні. Те, що використовують усі інші – постачальник або застосунок генерує один випадково і використовує для свого власного сервісу або характеристики. Камери, що визначають власний протокол, знаходяться тут.

Клас bluetooth.UUID приймає будь-який з трьох розмірів:

import bluetooth

BATTERY_SERVICE = bluetooth.UUID(0x180F)
CUSTOM_SERVICE = bluetooth.UUID("12345678-1234-5678-9abc-def012345678")

16-бітний UUID кодується в невеликий рекламний пакет, що є однією з причин переваги стандартних сервісів, коли такий існує – монітор серцевого ритму, що анонсує 0x180D (Heart Rate), коштує два байти; власний UUID коштує шістнадцять. Для застосунків, яким не потрібна стандартна сумісність, згенерований 128-бітний UUID є правильною відповіддю.

11.6.4. Що дають стандартизовані SIG сервіси#

Аргумент на користь використання стандартного сервісу простий: існуючі застосунки вже знають, як з ним спілкуватися. Пристрій, що анонсує Heart Rate service (0x180D) і надає характеристику Heart Rate Measurement (0x2A37), працює з кожним фітнес-застосунком на планеті без написання нового коду. Пристрій, що повторно реалізує ті самі дані з власними UUID, потребує власного застосунку-компаньйона та власного документа протоколу.

Стандарти мають свою ціну. Розкладка байтів всередині кожної характеристики визначена – SIG вирішив, що Heart Rate Measurement – це однобайтове поле прапорів, за яким іде або 8-бітне, або 16-бітне значення серцевого ритму, після якого необов’язково йдуть R-R інтервали – і відповідний пристрій повинен дотримуватися цього розкладання. Власні сервіси вільні від цього обмеження.

Практична відповідь для камер: використовуйте стандартний сервіс, коли він існує для типу даних, які ви маєте (Battery Service, Environmental Sensing), і визначайте власний з 128-бітним UUID для всього, що специфічно для вашого застосунку.

11.6.5. Об’єкти на стороні server та client#

Для однакових концептуальних будівельних блоків (service, characteristic, descriptor) кожна бібліотека GATT надає два паралельних набори об’єктів:

Об’єкти на стороні server – те, що peripheral оголошує, що він розміщує. У aioble: aioble.Service, aioble.Characteristic, aioble.Descriptor. Вони конструюються до початку реклами і реєструються за допомогою aioble.register_services().
Об’єкти на стороні client – те, що central виявляє на peer після підключення. У aioble: aioble.ClientService, aioble.ClientCharacteristic, aioble.ClientDescriptor. Вони обходяться через aioble.DeviceConnection.service() / services() після підключення.