BLE beacons na prática: iBeacon vs. Eddystone

Se há coisa que programadores aprendem a lidar ao longo da vida é o equilíbrio entre o caos e o controle. Um software caótico é aquele que não implementa padrões que controlem tanto o ciclo de desenvolvimento quanto a execução das regras de negócio. No outro lado, onde há um extremo controle, as coisas ficam engessadas. O uso excessivo de padrões tende a estagnar ou desacelerar o desenvolvimento e manutenção de sistemas que ainda não atingiram a maturidade.

Por estes motivos, equilibrar as coisas e utilizar padrões estabelecidos pelo mercado é o melhor caminho para manter tudo funcionando e também para manter a sanidade mental. Seja no backend, frontend, banco de dados, devops, segurança ou redes, os protocolos estão sempre presentes. E o mesmo ocorre no IoT, onde a comunicação entre as partes é o cerne do paradigma.

Como já demonstrei neste outro artigo que escrevi sobre como os BLE Beacons podem modernizar uma plataforma, as funcionalidades destes pequenos carinhas expandem as possibilidades criativas de um produto ou serviço. Podemos identificar quando um usuário se aproximou de um objeto, quando entrou em uma determinada área e até mesmo triangular sua posição dentro de uma área mapeada e usar isso de n formas diferentes.

Tudo isso é implementado através da troca de informações entre dispositivos que emitem sinais e outros dispositivos que recebem estes sinais. Como você deve imaginar, regras de negócio que dependem de “coisas” distribuídas podem se tornar caóticas se não padronizadas, e quando falamos em comunicação sem fio, entender os padrões permite com que os dispositivos entendam o que os outros estão comunicando.

Os protocolos mais conhecidos dos BLE beacons são 3: iBeacon, Eddystone e AltBeacon. Este artigo abordará as características e diferenças dos 2 primeiros.

iBeacon

O primeiro protocolo estabelecido para BLE beacons foi o iBeacon, da pioneira Apple, lançado em 2013, em uma conferência da empresa. O protocolo foi utilizado em BLE beacons que emitiam pacotes acessíveis a smartphones rodando apenas, no princípio, iOS. Entretanto, como os beacons implementam tecnologia BLE (Bluetooth Low Energy), os pacotes são abertos a qualquer dispositivo bluetooth 4.0 ou superior. Ainda, com o passar do tempo, a comunidade criou bibliotecas capazes de fazer com que outros dispositivos fora da linha de produção da Apple entendessem como trabalhar com o iBeacon.

O propósito da Apple foi acenar para a indústria do varejo e mostrar como eles poderiam modernizar a experiência do usuário usando IoT através da possibilidade de identificar a aproximação do usuário em uma determinada área. A partir daí, o dispositivo poderia executar uma tarefa programada ao identificar o evento. Isso era possível graças aos 3 tipos de dados compartilhados em seus pacotes:

Na imagem acima, disponibilizada na documentação oficial do iBeacon, temos os dados de:

• UUID: faz o papel do identificador universal que representa o proprietário do beacon
• Major: sub-id do UUID
• Minor: sub-id de Major

Em um pacote emitido pelo iBeacon, seguindo o exemplo da imagem, caso o dado de UUID seja D9B9…A95C, Major 3 e Minor 20, significa que o usuário entrou no alcance de um BLE locado no setor de utilitários da loja de Londres pertencente ao proprietário do UUID.

Dois pontos chamaram atenção para este método: (1) sem necessidade de conexão com a internet para realizar a identificação e disparar um gatilho via app e (2) possibilitar o chamado indoor location, que promove a fácil detecção da localização do usuário mesmo sem internet, em ambientes fechados e com múltiplos andares, características onde a tecnologia GPS encara problemas para funcionar adequadamente até os dias de hoje.

Eddystone

Buscando expandir seus serviços de IoT, a Google não ficou atrás da Apple e lançou o Eddystone. Este protocolo, além de ter um nome mais original (😬), entrega mais possibilidades para os desenvolvedores que o utilizam. Eis suas especificações:

• UID: implementa um único identificador universal para o dispositivo emissor
• URL: como o próprio nome diz, emite uma URL
• TLM: referente à telemetria do dispositivo
• EID: implementa um identificador universal criptografado

O UID, apesar de parecer similar ao UUID do iBeacon, implementa o método de forma diferente. Enquanto o iBeacon usa um identificador do proprietário do dispositivo e outros 2 sub-ids, o UID do Eddystone implementa um identificador especificamente para o beacon. Dessa forma, o dispositivo pode ser identificado individualmente, porém, sem opções de mescla de ids.

O pacote de URL emite uma URL única curta e foi descrita pensando no que o Google chamava de “Web Física”. A ideia do Google ao implementar o pacote de URL era integrar com o Nearby, aplicação Android que recebia pacotes do protocolo Eddystone e decidia o que fazer com eles. Utilizando URL, o Nearby mostrava notificações ao usuário exibindo as páginas transmitidas via protocolo (uma tentativa de concorrer com o iBeacon). Entretanto, isso foi descontinuado por conta do alto número de spams relatados pelos usuários de Android. Não apenas o Nearby foi descontinuado, como toda a mobilização do Google em prol do uso de BLE beacons. O Google Beacon Platform e o Google Proximity Beacon API também foram enterrados junto com a tentativa de popularização da web física (apesar de algumas funcionalidades ainda estarem disponíveis).

Na TLM o desenvolvedor pode anexar os dados referentes a outros dispositivos conectados ao beacon, como: nível de bateria, sensor de luminosidade, movimento, entre outros.

Por fim, o EID utiliza métodos de criptografia para dificultar ataques a nível lógico contra a infraestrutura beacon (abordarei ataques aos beacons em outro artigo).

Conclusão

O primeiro passo para utilizar esta tecnologia BLE beacon é entender que há diferenças grandes entre os protocolos e cabe ao desenvolvedor analisar a melhor alternativa para cada necessidade — e nisso espero que este artigo tenha lhe ajudado (:

O segundo passo para utilizar beacons na prática é identificar leitura ou realizar emissões de sinais utilizando algum dispositivo. Para isso, se você, assim como eu, não tem interesse em reinventar a roda, as diversas comunidades que adotaram o uso de BLE beacons criaram bibliotecas incríveis que possibilitam a gerência dos estados de diversos protocolos (iBeacon, Eddystone, Alt Beacon, Facebook Bluetooth Beacon, etc …). Depende apenas do programador criar abstrações que as utilize para executar uma determinada regra de negócio.

Agora, o que falta é colocar a mão na massa (: E se precisar de alguma ajuda, não esqueça de me chamar.