11.6. Servisler ve karakteristikler

GAP iki cihazı açık bir bağlantı içinde bir araya getirdikten sonra, onun üzerindeki katman – Generic Attribute Profile, yani GATT – bu bağlantı üzerinden akan baytlara anlam kazandırmak zorundadır. BLE’nin buradaki tercihi sıra dışıdır. TCP ham bir bayt akışı sunup kendi çerçevelemesini icat etmeyi uygulamaya bırakırken, GATT bir tarafın barındırdığı, diğerinin ise okuduğu, yazdığı veya abone olduğu küçük bir anahtar/değer veritabanı sunar.

Uygulama tasarımcıları BLE ile geçirdikleri zamanın çoğunu bu veritabanını düşünerek harcar. Kameranın bir telefona yayımladığı şey, uzaktaki bir sensörde izlediği şey, bir Bluetooth klavyenin hangi tuşa basıldığını ana cihazına nasıl bildirdiği – hepsi bir yerlerdeki bir GATT veritabanında bulunan karakteristik değerleridir.

11.6.1. Tek değil, iki rol ekseni

Sık görülen bir kafa karışıklığı kaynağı: peripheral / central ve server / client eşanlamlı değil, iki bağımsız eksendir.

• Peripheral ve central, bağlantı sırasında belirlenen GAP rolleridir. Peripheral reklam yapar ve kendisine bağlanılır; central tarar ve bağlantıyı başlatır. Bu, bağlantı kurulduğu anda belirlenir ve değişmez.

• Server ve client, her karakteristik işlemi için belirlenen GATT rolleridir. Server karakteristiği barındırır; client onu okur, yazar veya ona abone olur.

İki eksen, spesifikasyon tarafından birbirinden ayrılmıştır. Bir peripheral genellikle server’dır (bir kalp atış hızı bandı ölçümlerini yayımlar) ve bir central genellikle client’tır (bir telefon onları okur), ancak BLE her kombinasyona izin verir – bir peripheral, henüz bağlandığı central üzerinde bir karakteristik keşfedebilir ya da tek bir bağlantı her iki tarafta da aynı anda servis barındırabilir.

Çoğu kamera uygulaması geleneksel eşleşmeye (peripheral + server ya da central + client) bağlı kalır, bu nedenle bu bölümün geri kalanı, anlatılan şey geleneksel durum olduğunda bunları tek bir eksen olarak ele alır. Ayrım önemli olduğunda her iki terim de açıkça belirtilir.

11.6.2. Veritabanının içinde

Bir GATT veritabanı bir ağaçtır. Yapraklar gerçek baytları taşır. Dallar, ilişkili yaprakları insan tarafından anlamlı birimler halinde gruplar.

Bir GATT veritabanı. Servisler karakteristikleri gruplar; karakteristikler uygulamanın baytlarını taşır; tanımlayıcılar karakteristik hakkında üst veri taşır.

Üç tür düğüm vardır:

• Bir servis, ilişkili değerlerin mantıksal bir grubudur. Bluetooth SIG, yaygın kullanım senaryoları için standart servis tanımları yayımlar – pil seviyesi için Battery Service, sıcaklık / nem / basınç için Environmental Sensing, kalp atış hızı monitörleri için Heart Rate – böylece bir telefondaki genel amaçlı bir uygulama daha önce hiç görmediği bir servisi tanıyabilir. Bir uygulama, SIG’in standartlaştırmadığı şeyler için kendi servislerini tanımlamakta da serbesttir.

• Bir karakteristik, bir servis içindeki adlandırılmış tek bir değerdir. Battery servisinde tek bir karakteristik bulunur – Battery Level, bir baytlık bir yüzde. Environmental Sensing’in sıcaklık, nem, basınç vb. için ayrı karakteristikleri vardır. Bir karakteristik, GATT işlemlerinin birimidir – bir karakteristiği okursunuz, bir karakteristiğe yazarsınız, bir karakteristiğe abone olursunuz.

• Bir tanımlayıcı, bir karakteristiğe iliştirilmiş üst veridir. Bazı tanımlayıcılar standartlaştırılmıştır – Client Characteristic Configuration Descriptor (CCCD) ünlü olanıdır; çünkü bir client’ın server’a “bu karakteristikte bana bildirim gönder” demesinin yolu ona yazmaktır. Diğerleri kullanıcı tanımlıdır ve sunum biçimi veya genişletilmiş özellikler gibi şeyler taşır.

Bir GATT server (tipik olarak peripheral), veritabanını başlangıçta bir kez tanımlar ve veritabanı çalışırken değişmez. Bir GATT client (tipik olarak central), bağlandıktan sonra veritabanında ne olduğunu keşfeder – ağaçta dolaşır, bulduğu servislerin UUID’lerini, ardından her birinin içindeki karakteristikleri okur.

11.6.3. UUID’ler

Her servisin, karakteristiğin ve tanımlayıcının, ne tür bir şey olduğunu belirten bir UUID‘si (Universally Unique IDentifier) vardır. UUID’ler üç genişlikte gelir:

• 16 bit. Bluetooth SIG tarafından tanımlanan standartlar için ayrılmıştır. Battery Service 0x180F‘tir. Battery Level (bir karakteristik) 0x2A19‘dur. Tam liste, Bluetooth SIG’in atanmış numaralar sitesinde https://www.bluetooth.com/specifications/assigned-numbers/ adresinde yayımlanmaktadır.

• 32 bit. Nadiren kullanılan bir orta yol.

• 128 bit. Diğer herkesin kullandığı – bir satıcı veya uygulama rastgele bir tane üretir ve onu kendi özel servisi ya da karakteristiği için kullanır. Kendi protokolünü tanımlayan kameralar burada yer alır.

bluetooth.UUID sınıfı üç genişlikten herhangi birini kabul eder:

import bluetooth

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

16 bitlik bir UUID, küçük bir reklam yüküne kodlanır; bu da bir tane mevcut olduğunda standart servislerin neden tercih edilir olduğunun nedenlerinden biridir – 0x180D (Heart Rate) reklamı yapan bir kalp atış hızı bandı iki bayt tutar; özel bir UUID ise on altı bayt tutar. Standart birlikte çalışabilirliğe ihtiyaç duymayan uygulamalar için, üretilmiş 128 bitlik bir UUID doğru yanıttır.

11.6.4. SIG tarafından standartlaştırılmış servislerin size kazandırdıkları

Standart bir servis kullanmanın gerekçesi basittir: mevcut uygulamalar onunla nasıl konuşulacağını zaten bilir. Heart Rate servisini (0x180D) reklam eden ve Heart Rate Measurement karakteristiğini (0x2A37) sunan bir cihaz, kimse yeni kod yazmadan gezegendeki her fitness uygulamasıyla çalışır. Aynı veriyi özel UUID’lerle yeniden uygulayan bir cihaz, kendi eşlik eden uygulamasına ve kendi protokol belgesine ihtiyaç duyar.

Standartların bir bedeli vardır. Her karakteristiğin içindeki bayt düzenleri belirtilmiştir – SIG, Heart Rate Measurement’ın tek baytlık bir bayraklar alanı ardından 8 bitlik veya 16 bitlik bir kalp atış hızı değeri, isteğe bağlı olarak da R-R aralıkları olduğuna karar vermiştir – ve uyumlu bir cihazın bu düzenlere uyması gerekir. Özel servisler bu kısıtlamadan muaftır.

Kameralar için pragmatik yanıt: elinizdeki veri türü için bir tane mevcut olduğunda standart servisi kullanın (Battery Service, Environmental Sensing) ve uygulamanıza özgü herhangi bir şey için 128 bitlik bir UUID ile özel bir servis tanımlayın.

11.6.5. Server tarafı ve client tarafı nesneler

Aynı kavramsal yapı taşları (servis, karakteristik, tanımlayıcı) için her GATT kütüphanesi, paralel iki nesne kümesi sunar:

• Server tarafı nesneler – peripheral’ın barındırdığını beyan ettiği şeyler. aioble içinde: aioble.Service, aioble.Characteristic, aioble.Descriptor. Bunlar, reklam başlamadan önce oluşturulur ve aioble.register_services() ile kaydedilir.

• Client tarafı nesneler – central’ın bağlandıktan sonra eşte keşfettiği şeyler. aioble içinde: aioble.ClientService, aioble.ClientCharacteristic, aioble.ClientDescriptor. Bunlar, bağlandıktan sonra aioble.DeviceConnection.service() / services() aracılığıyla dolaşılır.