Hola a todos. Mi nombre es Nicole. Hoy llegué un poco tarde porque estuve muy ocupada en el trabajo y pasé demasiado tiempo libre jugando con todas las nuevas tecnologías web y API de navegador, y hoy estoy aquí para llevar a través de mi experiencia con la API Web Bluetooth.
Los navegadores se han construido en torno a la idea de que solicitarían datos de un servidor y los renderizarían. Por lo tanto, los navegadores siempre han sido excelentes para renderizar datos. Pero siempre fue bastante difícil interactuar con dispositivos que estaban junto al navegador. Ahora, con todo el movimiento de aplicaciones web progresivas, con el proyecto Fugu, hemos visto un par de nuevas API, hemos visto web USB, web serial API, web HID API, y así sucesivamente, y todas intentan llenar esta brecha entre el navegador y los dispositivos periféricos.
Ahora, veamos algunos conceptos básicos. Bluetooth es una tecnología inalámbrica estándar para intercambiar datos que utiliza la misma frecuencia que LAN inalámbrica, pero envía cantidades muy pequeñas de datos a distancias bastante cortas. Si ahora piensas en esa experiencia antigua, defectuosa y frustrante que tuviste con tus primeros teléfonos inteligentes o tus primeros teléfonos móviles, tengo muy buenas noticias para ti, porque eso era el antiguo Bluetooth, Bluetooth 4.0. También tenemos BLE, que significa Bluetooth de baja energía, y ese es un estándar completamente nuevo que se construyó específicamente para dispositivos IoT, por lo que es muy eficiente en energía y también funciona a distancias bastante largas. Y con Web Bluetooth, siempre hablamos de BLE, porque es un estándar que se implementó. Entonces, Bluetooth normalmente funciona así. Tendrías un dispositivo central que es el dispositivo más capaz en términos de CPU y uso de batería, y luego tendrías dispositivos periféricos. Ahora, también nos referimos a ellos como el cliente y el servidor, y es muy importante que puedas conectar un dispositivo central a varios dispositivos periféricos, pero un dispositivo periférico solo puede estar conectado a un dispositivo central al mismo tiempo. Esa también es la razón por la que, por ejemplo, no puedes conectar tus auriculares y tu reloj inteligente al mismo teléfono inteligente, pero no puedes conectar tus auriculares a dos teléfonos inteligentes al mismo tiempo. Eso simplemente no es posible. Ahora, como parte de BLE, el grupo de interés especial de Bluetooth introdujo GATT, el perfil genérico de atributos, y básicamente es la forma en que el dispositivo periférico expone sus datos al cliente. Tendrías el servidor GATT que contiene una lista de servicios GATT, cada servicio es simplemente un grupo de características, y ahora, una característica identifica un valor y también define qué operaciones se pueden realizar en ese valor. Por ejemplo, si tienes un nivel de batería, tiene sentido que puedas leer el nivel de batería y también quieres ser notificado cuando el nivel de batería cambie en el dispositivo, pero no tiene sentido que sea escribible porque no puedes simplemente sobrescribir el nivel de batería y esperar que sea mágicamente 100 por ciento, si ese fuera el caso, nuestros problemas de energía, problemas de cambio climático se resolverían. Pero no es así. Pero si tienes la dirección de vuelo de un dron, por ejemplo, ahí sí tiene sentido o es crucial que puedas controlar la dirección, que no puedas controlar tu dron. Necesita ser escribible. Ahora, un valor GATT es una estructura de datos de bajo nivel, es solo un conjunto de bytes. Si ahora miras el lado derecho, aquí tengo la implementación de un servidor GTT del Playbulb Sphere, que es una bombilla de luz BLE, y tenemos los servicios, tenemos las características, y es muy importante mencionar que los servicios y características no se identifican realmente por sus nombres, sino por UUID. Hay una lista de UUID estándar mantenidos por el grupo de interés especial de Bluetooth que cubren casos de uso comunes como información sobre el dispositivo o niveles de batería, por lo que sabemos que en cada dispositivo, el servicio, o digamos el servicio 180F, sería el servicio de batería, pero también tenemos servicios no estándar como en ese ejemplo el servicio de luz y la característica de luz, y ahí podemos utilizar UUID de 128 bits, por lo que son largos y únicos, o podemos elegir UUID de 16 bits que aún no están especificados, en ese caso tenemos FF0F para el servicio de luz y FFFC para la característica. La parte complicada ahora es cómo se estructuran esos valores. Los dos primeros son bastante básicos, es básicamente una cadena codificada en UTF-8. El nivel de batería es la representación decimal de nuestro byte, por lo que 5a sería el 90 por ciento, y ahora para las características personalizadas, tenemos que recurrir a la documentación, y en la mayoría de los casos no hay documentación, pero en nuestro caso, tenemos documentación, por lo que sabemos que el Playbulb Sphere tiene cuatro bytes, cuatro LED dentro de la bombilla de luz, y con el valor de cada byte, puedes controlar la intensidad de uno de esos LED, y lo interesante ahora es que con rojo, verde y azul, básicamente podemos crear cualquier color que tengamos en el espacio de color RGB. Ahora que tenemos los conceptos básicos, veamos la API web. La API web es bastante sencilla.
Comments