Como os dispositivos IoT de consumidor geralmente habilitam a conexão com a Internet?


15

Tanto quanto sei, existem 2 métodos gerais para habilitar o acesso remoto (Internet, não LAN) a dispositivos IoT:

  1. Por meio de um servidor que o dispositivo pesquisa periodicamente (por exemplo, MQTT )
  2. Acesso remoto direto

Suponho que o segundo método não seja simples, pois normalmente os dispositivos de consumo estão atrás de um roteador doméstico.

Minha pergunta é a seguinte: Aproximadamente qual a porcentagem de dispositivos IoT atualmente vendidos usa qual dos seguintes métodos para conectar-se a eles remotamente :

  1. Por meio de um servidor (o dispositivo consulta o servidor)
  2. Acesso remoto direto que requer a configuração manual de um roteador doméstico para ativar o encaminhamento de porta (ou de outra maneira que exponha o dispositivo)
  3. Acesso remoto direto, onde o dispositivo configura automaticamente o roteador via UPnP ou outro protocolo
  4. Acesso remoto direto usando o endereço IPv6 estático de um dispositivo que não requer configuração do roteador
  5. Outros métodos

Minha pergunta está relacionada a dispositivos IoT para consumidores, como lâmpadas, interruptores, fechaduras, termômetros etc. de fabricantes confiáveis ​​que são vendidos hoje e instalados em residências.

Atualizar:

Encontrei esta resposta por @ Aurora0001 para outra resposta neste site sobre perfuração, para permitir a comunicação direta entre 2 dispositivos residentes em redes internas diferentes (por exemplo, atrás de um roteador doméstico). Esta solução requer um servidor, mas apenas para o handshake inicial.

Eu acho que isso adicionaria outra opção ...


Pergunta interessante. Não tenho certeza se haverá estatísticas facilmente obtidas para descobrir as porcentagens - você precisa especificamente delas ou está apenas tentando entender quais métodos são mais comuns?
Aurora0001

5
Também MQTT não poll, ele abre uma conexão persistente para o corretor eo corretor, em seguida, envia mensagens de volta para baixo que apontam
hardillb

11
Eu acho que 99% das instalações deste ano usarão o (1), mas não têm nada para justificar o palpite.
Sean Houlihane

2
@Mawg Pesquisa de endereço reverso. Acessando um dispositivo em minha casa do trabalho.
Sean Houlihane

11
@Perspectivus, praticamente não há sobrecarga para um soquete aberto, ele envia um pacote keep alive muito pequeno (para informar ao corretor que ainda está lá) a uma taxa configurável, que enquanto for menor que 15 minutos de tempo TCP do soquete deve permanecer aberto indefinidamente.
hardillb

Respostas:


12

Eu acho que você encontrará uma porcentagem razoavelmente alta de "# 5, Outro", porque falta à lista uma das arquiteturas de IoT mais comuns dos consumidores: comunicações indiretas por meio de um gateway doméstico.

Todos os outros métodos que você descreve têm desvantagens em casa: são difíceis de configurar, não são seguros ou consomem muitos recursos caros do servidor. Um gateway doméstico evita esses problemas para os dispositivos individuais, expondo apenas um dispositivo à Internet.

O gateway típico serve a vários propósitos. Primeiro, é uma ponte de protocolo. Os dispositivos sem fio usam todos os tipos de protocolos de comunicação abertos e proprietários, incluindo Z-Wave, Zigbee, RF dedicado de 900 MHz, RF dedicado de 433 MHz, luz infravermelha, Bluetooth, BLE, ANT +, Crestron etc. Isso resolve todos os tipos de problemas de nicho, como custo por dispositivo, duração da bateria, redes mesh autoconfiguráveis, tempos de resposta rápidos, comunicações inseguras, configurações simples usando armazenamento mínimo, etc. Dessa forma, a maioria dos dispositivos IoT de consumo não está usando pacotes IP, mas fornece seus dados dentro de muito quadros menores para preservar a vida útil da bateria. O gateway converterá o protocolo proprietário em algo mais transportável e interoperável com uma rede baseada em IP.

Além disso, o gateway doméstico é um bom local para armazenar as regras do sistema. Se você ativar regras como "se você acender a luz no topo da escada, acenda também a luz da entrada, a menos que a luz da cozinha esteja acesa", você pode colocar as regras nos interruptores de luz, servidor web ou o gateway. A colocação das regras em cada interruptor de luz cria uma configuração frágil, difícil de configurar, alterar ou gerenciar. A execução das regras em um servidor centralizado introduz a latência porque a mensagem precisa ser traduzida para TCP, criptografada, enviada pela Internet, a ação deve ser recebida, descriptografada e traduzida de volta para o Zigbee. O gateway permite que o fornecedor resolva esses problemas, fornecendo um único ponto de gerenciamento para fazer backup e restauração, e o processador local para executar as regras rapidamente.

A segurança é um grande problema: os dispositivos de IoT precisam ser baratos, e os processadores baratos não têm grandes CPUs e armazenamento para funções de criptografia segura. Sem mencionar o desejo de evitar as enormes despesas do desenvolvimento de protocolos criptografados com segurança. Portanto, eles implementam segurança muito fraca (barata) nos dispositivos de consumo, ou nenhuma segurança. Eles compensam isso apenas se comunicando dentro de um intervalo muito limitado - eles só precisam acessar o gateway doméstico. Dessa forma, o gateway lida com as comunicações locais não seguras e apenas um dispositivo precisa da capacidade de processamento e armazenamento necessários para se comunicar com a nuvem por TLS.

Finalmente, o gateway pode fornecer um ponto único conveniente da interface humana para os dispositivos. A maioria dos gateways expõe uma interface da web, permitindo a configuração baseada em GUI. Imagine tentar configurar código Morse uma senha WiFi de 12 caracteres em um dispositivo usando apenas um botão e um LED. Pior, imagine a equipe de suporte por telefone da sua empresa falando com cada cliente nesse processo.

Infelizmente, isso ainda não responde diretamente à sua pergunta. Mas espero que a arquitetura do gateway seja a maneira mais comum de os dispositivos orientados ao consumidor se conectarem à Internet.

EDIT: em resposta ao seu comentário sobre gateways domésticos usados ​​para dispositivos de IoT, existem alguns tipos básicos: uso único dedicado, uso multiuso dedicado e uso geral. Além das interfaces abaixo, todos eles possuem uma interface Ethernet ou WiFi para conectar mensagens de e para uma rede IP.

Um gateway de uso único dedicado fala apenas aos dispositivos de um determinado fabricante. Os exemplos mais simples podem ser um dongle USB que recebe dados de um único dispositivo, como um dongle Fitbit. Outros exemplos incluem o Philips Hue Bridge (que se comunica apenas com lâmpadas Philips Hue); o Liftmaster MyQ Gateway (que se comunica apenas com os abridores de portas de garagem Liftmaster, Chamberlain ou Craftsman); ou o Harmony Hub (que se comunica com o Logitech Harmony remota e pisca o IR para vários componentes de home theater.)

Um exemplo do hub multifuncional dedicado seria o hub SmartThings da Samsung. O SmartThings vende uma ampla variedade de dispositivos de automação residencial, mas eles falam apenas o protocolo SmartThings. O hub SmartThings também pode se comunicar com muitos outros controladores de dispositivos via IP e possui integração IFTTT nativa.

Os gateways de uso geral podem ter alguns componentes proprietários, mas geralmente oferecem suporte a várias interfaces e podem servir como uma interface inicial inteligente principal. Exemplos incluem o Wink Hub (que se comunica com os dispositivos de RF Zigbee, Z-Wave, Lutron e Kidde); Vera Edge (que se comunica com os dispositivos Z-Wave e Insteon e se estende para se comunicar com dispositivos externos).

Finalmente, também existem alguns esforços de código aberto muito ativos no domínio de automação residencial de uso geral, incluindo Domoticz e OpenHAB. Estes são programas de software que oferecem suporte à comunicação com dispositivos IoT por meio de dispositivos bridge dedicados (como um dongle USB Z-Wave ou um rádio Zigbee), implementam regras e oferecem amplos recursos de integração, como IFTTT, MQTT e outros.


Obrigado John. Você pode fornecer referências a artigos gerais sobre ou a exemplos específicos desses gateways domésticos?
Perspectivus

8

Praticamente todos os produtos de consumo que operam dessa maneira exigirão um servidor externo para mediar o envio de mensagens de um dispositivo externo para um dispositivo específico em casa. Mesmo no caso mais óbvio de expor a porta 22 no seu Raspberry Pi, você ainda (geralmente) precisa de um serviço DNS dinâmico.

  1. O dispositivo inicia e mantém uma conexão persistente com o servidor. Isso não requer configuração do roteador, desde que o roteador forneça acesso https à Web ...

Para todos os outros métodos, o dispositivo do telefone remoto precisa ser capaz de encontrar o dispositivo doméstico. Os protocolos ponto a ponto às vezes usam o encaminhamento de porta, pois desejam evitar uma arquitetura cliente-servidor.

Além disso, é possível que um sistema abra uma porta de entrada usando UPnP, mas isso não deve ser necessário para aplicativos de IoT. Isso pode se aplicar a aplicativos de jogos herdados, mas se desfaz assim que mais de um nó está presente em um IP público.

Embora o IPv6 permita que um par de dispositivos seja associado, muitas redes não suportam o IPv6 de ponta a ponta hoje. Um servidor é necessário, independentemente de fornecer atualizações de firmware (a menos que o dispositivo esteja obsoleto antes de ser vendido).

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.