Conceptos básicos del Bluetooth BLE
Material requerido.
 |
Un ESP32 |
Bluetooth
BlueTooth es un estándar inalámbrico de comunicación entre dispositivos electrónicos, al que, sin duda, todos los que estáis leyendo esto, estáis acostumbrados a usar porque viene en todos los móviles celulares desde hace generaciones.
Hay dos sabores de Bluetooth básicos:
El modelo conceptual detrás de cada uno de ellos es completamente distinto y por eso vamos a dedicar una pequeña introducción a describir ese modelo aquí, porque es imprescindible comprender la organización y la jerarquía del BlueTooth BLE para poder programar un servidor o cliente (Que por supuesto se llaman de otra manera para que no se fácil y todo parezca mucho más complicado de lo que realmente es)
El Bluetooth Classic tiene un modelo como el mecanismo de un chupete:
En el Bluetooth BLE, la cosa es un poco más complicada, aunque se mantiene la idea de servidores que ofrecen información y clientes que la buscan, pero que ahora se llaman de otro modo (Por joder). Además, el bluetooth BLE se ha diseñado para consumir el mínimo posible, pero también eso supone que el alcance va a ser inferior al Bluetooth Classic
Para entender Bluetooth BLE tienes que comprender que el modelo se ha refinado mucho y se ha jerarquizado y estructurado, para ofrecer una colección de servicios y características que amplíen el uso de la norma Bluetooth y eso naturalmente significa complicar un poco más el asunto.
Para crear e iniciar el servidor BLE, vamos a necesitar hacer todas estas tareas:
Por eso tenemos que empezar hablando de un conjunto de nuevos acrónimos que harán que todo parezca super difícil, pero que va, son ideas bastante frecuentes en el mundo cliente servidor, pero adaptadas y con diferente nombre. Por eso nos conviene empezar hablando de uno de esos nuevos acrónimos: GAP protocol
Protocolo GAP
GAP viene de General Access Protocol (Protocolo de acceso general) y se encarga de que tu dispositivo vea los servidores y se puedan conectar. Para ello el GAP define varios roles para los nodos Bluetooth, que pueden ser:
Los roles Peripheral y Central devices son los mas importantes y frecuentes en BLE y lo curioso de este modelo, es que por regla general, el cliente es computacionalmente más potente que el servidor, al revés de lo que es habitual en el modelo típico Cliente /Servidor en uso en las redes TCPIP.
Cuando un Peripheral quiere conectar con un Central, usa el protocolo GAP para establecer la conexión. Habrá un intercambio de paquetes entre ambos hasta que la conexión queda fijada y ahora se activa el protocolo GATT para realizar la transmisión de información.
Protocolo GATT
Los dispositivos BLE se reconocen y conectan entre si mediante GAP y luego se transmiten información mediante GATT, (Generic Attribute Profile) , y es quien se encarga fijar los procedimientos para que se puedan enviar y recibir datos entre dos dispositivos conectados con BLE, siempre que previamente se haya establecido la comunicación con GAP.
El mecanismo de conexión GATT es muy similar al modelo cliente / servidor al que estamos acostumbrados en la informática de servidores, y cualquier periferal puede ser considerado un servidor y un Central un cliente (Este es uno de esos casos en los que uno no puede dejar de pensar que los que pusieron los nombres eran imbéciles o con ganas de complicarlo todo)
Una vez que ya hemos establecido la comunicación con GAP, El protocolo GATT establece el método de comunicación y ahora nos falta entender que la comunicación se hace sobre Perfiles, Servicios y características (¿????)
Perfiles, Servicios y características
Si has trabajado algo con MQTT o JSON y similares, estarás familiarizado con las estructuras jerárquicas de datos, que, aunque inicialmente parecen complicadas, en realidad, contribuyen mucho a que haya un flujo organizado jerárquicamente de datos, que se puedan intercambiar entre dispositivos muy diferentes, con diferentes sistemas operativos, idiomas, y características, de forma sencilla y eficaz.
Lo que hace BLE es algo parecido orientado a conexiones a corta distancia, entre unos dispositivos bastante bien conocidos (Como relojes, teléfono, tablets, Pcs, cardiometros etc.) y otros no tanto. Y para ello define un modelo de datos que, aunque parece rarísimo no es para tanto.
Profiles: Son conjuntos de servicios definidos en directivas del Bluetooth SIG (Special interest Group) que clasifica servicios como (Sensores de presión sanguínea, o reproductores de Audio, niveles de batería y demás)
Services: Aquí es donde vienen los datos de sensores, por ejemplo, que a su vez tienen subcategorías, llamadas properties, values y descriptors.
Characteristics: Por ejemplo, un Sensor como el BME280, tiene disponibles lecturas de temperatura, humedad y presión barométrica. Cada uno de esos sensores a su vez dispone de propiedades y lecturas del valor correspondiente. Y aunque no es el caso podría tener un descriptor que anuncia su disponibilidad a los centrales que se conecten. Se trata de una estructura jerárquica similar a otras que ya hemos visto en Prometec:
UUIDs
En Bluetooth BLE, absolutamente cada Servicio, Característica y descriptor, necesita un identificador único que lo diferencie del resto y a eso le llamamos UUID (Universally Unique Identifier), que es un número de 128 bits y que debe ser único para cada uno de esos elementos Bluetooth BLE.
Si vamos a hacer una aplicación propia necesitamos generar un UIID por cada servicio, característica y propiedad que definamos. Afortunadamente hay disponibles generadores aleatorios de UUIDs en Internet.
Y con todas estas extrañas (Y extravagantes) ideas nuevas metidas en nuestra mollera, podemos ya presentar el esquema general de cómo poner en marcha un servicio BLE.
Iniciando un Servidor Bluetooth BLE
Lo primero que vamos a hacer es cargar en nuestro ESP32 el programa de ejemplo que tenemos en:
\\Archivo\Ejemplos\Es32 BLE Ardunino\BLE_Server
Vamos a arrancar el servidor de ejemplo que viene con nuestro ESP32 BLE, pero antes vamos a buscar en ese programa la línea:
BLEDevice::init("Long name works now");
Que es el nombre que va a publicar en el BLE y que puedes cambiar por lo que quieras. En mi caso le voy a llamar (Sorprendentemente) Prometec.
BLEDevice::init("Prometec");
Ahora vamos a buscar la línea:
pCharacteristic->setValue("Hello World says Neil");
Que es donde ponemos el valor de la característica que hemos definido y pones lo que se os ocurra. Por ejemplo:
pCharacteristic->setValue("Pues, aqui. Probando el BLE, oyes");
Compila y carga el programa, y ya podemos descargar alguna aplicación de Explorador BLE, como nRF Connect for Mobile o bien el mas sencillo BLE Scanner. Yo voy a usar el primero, y al arrancar verás los dispositivos BLE disponibles,
Si pinchas (En mi caso ) a Prometec se conectará. Verás que se despliega un segundo menú, mostrándote atributos y servicios:
Cada una de esas líneas que ves, se puede desplegar para mostrar mas información. Si le das al Unknown service, se desplegará información al respecto y veremos el valor que pusimos más arriba (Pensando en este momento), y el identificador de la característica que pusimos en el programa: beb5483e-36e1-4688-b7f5-ea07361b26a8
Así que parece que nuestro servidor BLE funciona después de todo. Lo vamos a dejar aquí por hoy y en la próxima sesión veremos el programa en mas detalle .
