Zigbee: a rede das pequenas coisas
Zigbee: a rede das pequenas coisas
Em primeiro lugar, vou desfazer uma confusão muito comum: Zigbee e 802.15.4 não são sinônimos, apesar de aparecerem juntos quase sempre. IEEE 802.15.4 é a camada de enlace/física, assim como WiFi (802.11) e Ethernet do cabo azul (802.3). O Zigbee especifica o resto da pilha de rede.
Existem diversas pilhas fundadas em 802.15.4: Zigbee, XBee, DigiMesh, Thread, etc. Até TCP/IP cabe, desde que seja IPv6, conforme será abordado mais ao final do texto. Por outro lado, o Zigbee presume que o enlace é 802.15.4, então o Zigbee depende totalmente do 802.15.4 do ponto de vista técnico, embora o 802.15.4 pegue carona no Zigbee quando se trata de marketing.
802.15.4 é uma tecnologia PAN ("Personal Area Network"), com características que a distingue tanto do WiFi quanto do Bluetooth: baixa velocidade, baixo consumo de energia, resiliência da conexão, e extrema simplicidade do rádio. Foi feita sob medida para a "Internet das Coisas", muito antes de IoT virar um termo da moda.
O 802.15.4 provê as ferramentas para mesh networking, porém não implementa a malha. Isso fica a cargo da camada de rede, como o Zigbee. (Está sendo desenvolvido o padrão 802.15.5, que embutirá a capacidade de formar malhas.)
O Zigbee fornece uma pilha completa de rede, de alto a baixo. Até mesmo os tipos de dados das aplicações, e a forma de transmití-los, estão rigidamente definidos na especificação.
Apesar da sopa de letras, e do grande número de irritantes acrônimos começando com Z, podemos fazer uma comparação direta de cada bloco funcional com TCP/IP para facilitar o entendimento:
É importante notar que Zigbee é análogo ao TCP/IP, mas não é compatível com TCP/IP, então mensagens Zigbee não podem ser transmitidas diretamente pela Internet. Esta limitação pode vir a ser removida pelo dotdot (vide a seção 6LoWPAN mais para o final).
A camada de rede do Zigbee (NWK) é quem implementa a malha de rede (mesh networking). Existem três tipos de dispositivos nessa malha: coordenador (um e apenas um por rede), roteadores e end devices. A topologia de malha permite a uma rede Zigbee cobrir áreas enormes com facilidade.
Todo dispositivo Zigbee conectado a uma fonte permanente de energia pode ser um roteador — por exemplo, uma lâmpada "smart" ou uma chave conectada a uma fonte de 12V. Já um end device é provavelmente movido a bateria, célula solar ou energy harvesting — por exemplo, o controle remoto da lâmpada "smart". Os roteadores formam uma malha, enquanto os end devices estão atrelados a apenas um roteador a cada momento.
Outro detalhe da relação entre roteadores e end devices é que, como os últimos estão quase sempre desligados, os roteadores respondem por eles em algumas situações. Este é um diferencial do Zigbee, e também um complicador e alvo de críticas.
A camada de transporte Zigbee APS é análoga a TCP ou UDP. Assim como TCP/IP possui diversas portas, um dispositivo Zigbee possui diversos endpoints, o que permite diversas aplicações diferentes convivam num mesmo nó.
Na camada de aplicação, a diferença entre Zigbee e TCP/IP aumenta muito, porque em Zigbee tudo é detalhadamente especificado. Mas podemos traçar paralelos. O AF especifica o "envelope" das mensagens trocadas com uma aplicação. Poderíamos ter algo semelhante no TCP/IP se especificarmos que toda mensagem trafega sobre HTTP, é codificada em JSON e toda API é REST.
Cada aplicação é denominada "Application Object" ou AO, e pode haver várias, uma por endpoint, num mesmo dispositivo Zigbee, analogamente a uma máquina com vários servidores Web, cada um atendendo numa porta diferente, cada porta servindo uma API REST distinta.
O ZCL (Zigbee Cluster Library) seria equivalente a um "JSON Schema" bombado. Além de specificar os tipos e formatos de dados, o ZCL lista todos os atributos obrigatórios e opcionais para cada cluster. O cluster é equivalente ao perfil do Bluetooth, ou ao serviço do Bluetooth Low Energy. Todos os clusters oficialmente aprovados, que podem ser certificados pela Zigbee Alliance, estão listados na ZCL. Como se pode imaginar, é um documento longo, com 1600 páginas.
Neste aspecto o Zigbee lembra muito o GATT do Bluetooth Low Energy, embora os atributos ZCL sejam mais simples que o GATT em todos os aspectos. As aplicações não têm liberdade de ficar inventando protocolos ou formatos; elas têm de ser implementadas nos termos de uma lista de atributos.
Por exemplo, o cluster 0x402 (sensor de temperatura ambiente) possui um atributo obrigatório, cujo índice é sempre 0x00, de tipo int16, expresso em Celsius e escalonado em centésimos de grau. Nunca vai ser diferente disso! O valor 0x8000 (-327.68) é reservado para expressar temperatura indefinida (e.g. falha do sensor). Tudo isso pode ser consultado na ZCL e (assumindo que o sensor seja certificado) é muito simples implementar o cliente que lê dados do sensor.
É permitido desenvolver aplicações "apócrifas" (com listas de atributos que não constem de nenhuma especificação), porém elas não podem ser certificadas.
Se por um lado o ZCL (e o GATT) tiram liberdade, por outro eles facilitam muito a implementação das aplicações, mesmo as "apócrifas". Basta pegar uma aplicação de exemplo e modificar os atributos. O trabalho pesado de parsing já está implementado (na aplicação de exemplo ou no próprio firmware do dispositivo Zigbee).
O bloco ZDO (Zigbee Device Object) fornece uma série de serviços de base, como busca de dispositivos na rede, consulta aos clusters implementados num dispositivo, etc. No mundo TCP/IP, estes serviços são fornecidos por uma amálgama variável de protocolos (ICMP, DNS, etc.).
As redes Zigbee são seguras uma vez formadas, assim como as redes Bluetooth. O ponto fraco é a admissão de um dispositivo novo. A segurança é entremeada com as camadas de rede e de transporte; o análogo do mundo TCP/IP seria o IPSec. (O SSL/TLS do mundo TCP/IP, mais comumente utilizado que o IPSec, está na camada de aplicação.)
O maior problema do Zigbee é a interoperabilidade, principalmente no "pairing" (admissão na rede) e em detalhes da aplicação. Se um fabricante de dispositivos "Zigbee" testa seus produtos apenas entre si, e não os certifica (comum em produtos chineses), é fácil passar algum detalhe que prejudica ou mesmo impede a interoperabilidade.
Geralmente quem compra Zigbee começa comprando um kit (e.g. chaves, lâmpadas e um concentrador) de um único fabricante, e só vai descobrir que seu kit é "proprietário de fato" quando tentar adicionar uma lâmpada Philips Hue, que aliás é certificada no padrão.
Já no caso do Bluetooth, geralmente um fabricante vende apenas um tipo de dispositivo. É garantido que ele vai encontrar contrapartes de outros fabricantes, e se não funcionar, será devolvido. Também é comum que ao menos parte da pilha Bluetooth seja implementada no sistema operacional, que é um participante "neutro" do ecossistema.
Mesmo assim, todo mundo já teve alguma experiência problemática com Bluetooth, principalmente em se tratando do Bluetooth Classic (não o Low Energy). É o tipo de coisa que não acontece com TCP/IP. Aí entra a vantagem dos padrões totalmente abertos, revisados e implementados em código aberto por diversas pessoas ou entidades, e a antiguidade das implementações (TCP/IP tem 35 anos de estrada a mais que o Zigbee).
A coisa funciona de forma semelhante ao Bluetooth. Toda a documentação oficial do Zigbee é gratuita porém é preciso cadastrar-se no site da Zigbee Alliance. Ostentar o logotipo "Zigbee" num produto exige passar pelo processo de certificação. Documentos ainda em fase de elaboração só podem ser acessados por membros da associação, e mesmo o nível "bronze" de associação custa US$ 40k por ano.
Extrínseco ao Zigbee, mas igualmente impossível de evitar, é o contato forçado com os chips Zigbee, seus respectivos ecossistemas, e suas mazelas: documentação escassa, ferramentas apenas para Windows, ferramentas mal-feitas, licenças caríssimas, etc. (Nesse meio, não é difícil encontrar gente ainda usando Windows XP porque as ferramentas de desenvolvimento ou certificação têm problemas com versões mais recentes!)
Menciono estas coisas porque costuma ser um choque e um aborrecimento para quem está acostumado com software livre, e principalmente com a pilha TCP/IP, com suas RFCs e rascunhos publicamente disponíveis.
WiFi. A principal vantagem do WiFi é sua onipresença. Todo mundo tem, todo mundo sabe usar. Embora haja fartura de dispositivos IoT baseados em WiFi, definitivamente não é um tipo de rede realmente adequado para IoT.
Bluetooth Low Energy. O BLE não é capaz de formar redes em malha, mas vai receber este recurso num futuro próximo. Até onde sei, o número máximo de dispositivos será muito menor que no Zigbee (127 vs. 65000). A camada de aplicação é adequada para IoT. BLE é quase onipresente e uma vez que seja capaz de mesh networking torna-se o concorrente mais forte, na minha opinião. (Descontando-se, é claro, uma possível incompatibilidade com dispositivos velhos, pré-mesh. A promessa é que o mesh funcionará com qualquer dispositivo BLE 4.0... Isso veremos.)
DigiMesh. Pilha proprietária da empresa Digi, a mesma que produz a linha de circuitos XBee. É uma tecnologia mais parecida com Zigbee, com diversas simplificações interessantes, como por exemplo apenas um tipo de nó na malha (todos os nós são roteadores, não há coordenador central). Usa 802.15.4 como enlace.
XBee. Este nome gera confusão por significar coisas diferentes conforme o contexto. XBee é o nome comercial dos chips Zigbee/802.15.4 da Digi. Também é o nome de uma pilha de protocolos — a primeira versão da pilha XBee, muito popular no ecossistema Arduino, era parecida mas não 100% compatível com Zigbee. A segunda versão é alinhada com o Zigbee 3.0.
Z-Wave. Conceitualmente equivalente ao Zigbee, porém totalmente proprietário. Criado e comercializado pela Zensys. A especificação costumava ser fechada, mas está sendo paulatinamente aberta e convertida em padrão público (por exemplo, a camada de enlace virou o padrão ITU G.9959). O fato de ser proprietário acaba ajudando na interoperabilidade, reconhecidamente melhor que a do Zigbee.
Thread. É baseado em 802.15.4 e 6LoWPAN, proposto pela Nest Labs, aquela empresa de termostatos que foi comprada pelo Google. Não sei muitos detalhes sobre o mesmo, o atrativo é ser baseado em TCP/IP.
Apesar das camadas de rede e transporte do Zigbee serem totalmente diferentes do familiar TCP/IP, e de sistemas operacionais de uso geral não implementarem a pilha Zigbee, a boa notícia é que o desenvolvedor não precisa lidar com estes problemas. A implementação é fornecida pelo fabricante do chip, de uma forma ou de outra. É mais ou menos o que acontece no mundo Bluetooth, em particular no Low Energy.
Além da implementação estar semi-pronta, ela é pré-certificada, o que acelera e barateia muito o processo de certificação de um produto. O desenvolvedor deve escolher dentre três arquiteturas básicas:
Diversos fabricantes oferecem chips Zigbee, porém a Texas Instruments destaca-se pela facilidade de obtenção, baixo preço e principalmente pelo suporte, nas formas de documentação, código de exemplo e fórum de desenvolvedores.
No momento os chips mais comuns são CC2530 e CC2531. São "parentes" do chip Bluetooth CC2540 e possuem um microcontrolador de 8 bits baseado no 8051. A versão CC2531 é um dongle USB. A linha CC25xx é barata e fácil de encontrar. Pode rodar uma aplicação simples e possui até mesmo alguns pinos digitais e analógicos para conexão direta a sensores ou a outros chips. Também são fáceis de encontrar os apetrechos (CCDebugger, cabos, etc.) necessários para atualizar firmware e debugar.
A maior desvantagem desta linha é a necessidade do compilador IAR, cuja licença custa milhares de dólares. Uma segunda desvantagem é o baixo poder de processamento. Uma saída é baixar e instalar o firmware ZNP (processador de rede) e desenvolver a aplicação em outro processador de livre escolha. A própria TI vendia um kit de CC2530 com um microcontrolador MSP430 incluso.
A API do firmware ZNP é relativamente simples, mas está longe de ser trivial. Não se encontra muitas bibliotecas prontas. Para computadores de uso geral, existe a cc-znp escrita em Node.js. (A comunidade Node tem seus cacoetes, mas definitivamente não pode ser acusada de preguiçosa!) Fora isso, existem parcos exemplos em Java, além do código-fonte de exemplo da própria TI para o MSP430.
No mundo Arduino, as placas XBee da Digi têm a maior penetração.
A Texas Instruments também oferece os chips CC2538, CC2630 e CC2650 com microcontroladores ARM. São mais poderosos, e a própria TI oferece uma ferramenta gratuita de desenvolvimento, desobrigando a compra de licenças IAR. O chip CC2650 implementa Bluetooth LE e Zigbee ao mesmo tempo. Infelizmente, tais chips ainda são bem mais caros, difíceis de encontrar, não existem na versão USB dongle (embora o circuito possua os sinais USB, em tese pode-se soldar um cabo), e os apetrechos necessários para atualizar o firwmare são diferentes da linha CC253x.
Uma vantagem adicional destes últimos chips mais poderosos é que podem suportar TCP/IP, pois o sistema operacional Contiki pode ser instalado neles.
Por mais que o Zigbee fosse perfeito, sempre vai haver casos de uso onde seria melhor usar TCP/IP como pilha de rede, mas retendo as vantagens do 802.15.4. Um dispositivo IoT movido a TCP/IP é mais fácil de entender e interagir, e ele pode estar conectado diretamente à Internet (se isso é recomendável, é outra discussão).
A adaptação de TCP/IP ao 802.15.4 tem alguns desafios. O pequeno tamanho do pacote 802.15.4 (127 bytes) é o maior deles — o IPv6 exige que o enlace transporte 1280 bytes no mínimo. Também há a incumbência da camada de rede de formar a malha, algo que o TCP/IP "baunilha" não sabe fazer.
A RFC 4919 especifica a camada de adaptação 6LoWPAN. O padrão é abrangente o suficiente para adaptar IPv6 a Bluetooth Low Energy, além de Zigbee.
O 6LoWPAN especifica duas formas de formar a malha de rede: mesh-under e route-over. No primeiro tipo, o roteamento dentro da malha é feito pela própria camada de adaptação, proporcionando ao IPv6 a ilusão de trafegar numa "Ethernet" (RFC 4944). No segundo tipo, o roteamento ocorre de forma explícita na camada de rede, com a ajuda de um protocolo de roteamento apropriado (RFC 6550). Todos os nós ligados "na tomada" devem ser roteadores (analogamente ao modus operandi do Zigbee).
A pilha Thread (da Nest) é baeada em 6LoWPAN. O Zigbee IP também; basicamente o Zigbee IP faz algumas pré-escolhas que são deixadas em aberto no padrão 6LoWPAN, como os mecanismos de segurança e o roteamento (sempre route-over em Zigbee IP).
A ZigBee Alliance ainda não publicou detalhes sobre a tecnologia dotdot, mas promete ser algo semelhante ou mesmo compatível com o Thread, possibilitando o transporte de mensagens Zigbee/ZCL sobre TCP/IP e através da Internet.