O que preciso para criar minha própria nuvem pessoal para dispositivos IoT?


18

Este é um assunto em que venho pensando há algum tempo, especialmente porque o conceito de "IoT" tem flutuado muito ultimamente.

Começarei com o que quero dizer quando digo "IoT" . Eu sei que o termo IoT pode significar coisas diferentes e que às vezes é mal utilizado. Pode ser um termo que não esteja claramente definido e possa levar a grandes discussões sobre o que exatamente significa. Eu mesmo não conheço a definição adequada e amplamente aceita do termo. Então, para mim, a IoT é um conceito, um conceito que define a capacidade de conectar-se a um dispositivo incorporado remotamente através da Internet, de outro dispositivo incorporado ou de um telefone celular . Tão simples como isso.

Nesse contexto, o objetivo da conexão não importa, se você pode conectar um dispositivo em seu escritório a outro em casa ou se pode conectar a um dispositivo em casa usando seu telefone celular, tudo isso através da Internet, então estamos falando de dispositivos IoT (os dispositivos incorporados, não o telefone).

Então, tendo concordado com o que quero dizer com IoT, descreverei agora o que estou tentando alcançar.

O que estou tentando alcançar é exatamente isso que descrevo na minha definição de IoT.

Quero ter um ou vários dispositivos incorporados em casa conectados ao meu roteador da Internet, por Ethernet ou Wi-Fi, e poder conectar-me a eles remotamente com outros dispositivos incorporados em um local remoto (e por remoto, quero dizer, não na mesma rede) e talvez também possa conectar-se a eles com um aplicativo de monitoramento no meu telefone

Por exemplo, eu posso ter um dispositivo incorporado simples atuando como um interruptor liga / desliga conectado ao abridor da porta da garagem e outro dispositivo incorporado atuando como um grande botão vermelho na minha mesa de trabalho, para que eu possa pressionar o botão vermelho na minha mesa e a porta da garagem se abre.

Outro exemplo seria ter um dispositivo incorporado com recursos de ADC que possa monitorar a temperatura da minha casa e me enviar um alerta quando atingir um limite. A notificação pode ser recebida por um aplicativo Android simples ou por outro dispositivo incorporado com uma pequena tela na minha mesa de trabalho.

Esses exemplos podem ser tolos, mas servem apenas para ilustrar os possíveis cenários e casos de uso para o que estou tentando alcançar. No final, a ideia é a mesma: conectar um dispositivo incorporado a outro através da Internet.

Outra coisa a esclarecer é que a troca de dados entre esses dispositivos será muito leve, apenas alguns bytes de cada vez, não é necessário que centenas de kilobytes sejam necessários para serem trocados entre os dispositivos.

Além disso, o tipo de "dispositivos incorporados" aos quais me refiro são dispositivos simples, mas capazes, baseados em microcontroladores de 100MHz ou 200MHz córtex-m4. E isso é importante para esclarecer, porque não haverá bibliotecas Linux ou complexas em execução nesses dispositivos. No final, é um desperdício de recursos e completamente desnecessário ter um processador poderoso executando o Linux apenas para ligar e desligar uma lâmpada . De qualquer forma, estou planejando usar um BeagleBoard, Raspberry Pi ou qualquer outra placa como essa como meus dispositivos incorporados. Apenas microcontroladores, porque não é necessária mais complexidade do que isso.

Não sei muito sobre plataformas IoT e esses tipos de soluções complexas por aí. Quando comecei essa jornada para descobrir uma maneira de conectar um dispositivo incorporado a outro através da Internet, deparei-me com alguns sites com serviços de IoT.

Eu sei que existem alguns serviços de nuvem IoT, como:

Só para citar alguns. Os principais problemas com esses são custo e complexidade. Você precisa pagar para obter esses serviços e também aprender como implementar todos os serviços que eles têm, caso precise de todos eles, e suas APIs e talvez um monte de outras coisas que não me parecem necessárias capaz apenas de trocar alguns bytes entre dispositivos. Eu só quero algo mais simples que isso, algo que eu possa fazer sozinho.

Você pode dizer que implementar minha própria "nuvem", se é algo que tenho que fazer, não é simples e às vezes é melhor usar esses tipos de serviços por uma questão de simplicidade, mas há duas razões principais pelas quais quero saber como implementar meus próprios serviços de IoT.

A principal razão é que eu quero fazer isso sozinho. Não quero contar com terceiros para conectar meus dispositivos e, como desenvolverei o código e o hardware para meus dispositivos, é melhor criar também meus próprios meios para conectá-los como dispositivos de IoT.

A segunda razão é aprender como fazê-lo. Ao conhecer todas as coisas necessárias para conseguir isso, terei um melhor entendimento sobre o mundo da IoT.

Além disso, quero mencionar que sou proficiente em C e uso o Linux como meu sistema operacional diário no trabalho e em minha casa, portanto, evite as coisas do Windows, porque isso é inútil para mim. Não tenho medo de nada que precise implementar em C para meus dispositivos incorporados ou no Linux para implementar o que for necessário para alcançar meu objetivo.

Portanto, minha pergunta é: o que é necessário implementar e onde, para conectar dois ou mais dispositivos incorporados um ao outro com o objetivo de trocar dados entre eles?

Esta pergunta O que posso usar para criar uma IoT em nosso próprio servidor? possui algo semelhante, mas está fechado e não possui respostas, também pressupõe que uma infraestrutura em nuvem já existente seja usada. Então isso não me ajuda.

Esta outra postagem Quais serviços de IoT estão disponíveis para armazenamento / envio / publicação de dados genéricos na nuvem? tem uma pergunta semelhante, mas o OP está pedindo explicitamente serviços de IoT e estou tentando evitá-los.


2
Como um servidor é uma "infraestrutura em nuvem existente"? Um servidor é apenas um computador. Uma infraestrutura de nuvem é muito mais.
user253751

1
Observe também que, quando tivermos um IPv6 onipresente, é possível que seus dispositivos IoT conversem diretamente entre si, sem a necessidade de um servidor / nuvem central.
user253751

Respostas:


10

Talvez eu tenha esquecido o objetivo da pergunta, mas acho que este é um bom começo para uma resposta.

Você precisa de três coisas, no mínimo.

  1. Um nó de computação sempre ativo para agregar seus dados. Isso não precisa ser poderoso; pode ser um processo em execução no seu NAS ou mesmo (em teoria) no seu roteador. Para simplificar, suponha que seja um Raspberry Pi. Isso também pode fornecer qualquer protocolo de rádio sofisticado que você decida oferecer suporte no futuro. Embora, em teoria, você possa executar ponto a ponto com todos os nós expostos à Internet, é mais fácil nomear um como mestre e fazer com que ele lide com a coleta e publicação de dados (para o aplicativo / usuário). Obviamente, o hub também pode ser um nó, principalmente se você usar nós WiFi que são moderadamente poderosos.
  2. Uma pilha de software adequada para permitir que os terminais enviem seus dados para o nó do hub. é o tipo de coisa que você precisa aqui, além de um sistema operacional para executá-lo.
  3. DNS e encaminhamento de porta para facilitar o acesso ao servidor a partir da Internet mais ampla.

Então não esqueça de segurança. Ao fazer isso, você estará mais perto de abrir tudo em sua rede doméstica para atacar. Talvez apenas um pouco, mas é bom estar ciente do risco. Você pode tentar tomar cuidado, mas assuma que cometerá erros.


1
Não sei se essa é a resposta que você queria. No entanto, deve ajudar a descobrir o que você precisa perguntar.
Sean Houlihane 22/02

1
Obrigado por ajudar !! Então, o que você quer dizer com seu primeiro ponto é que eu preciso de algum tipo de hub ou gateway?
M4l490n

1
Sim, você precisa de um gateway ou mais de um. Se você tiver apenas um nó, esse obviamente pode ser o seu nó. Eu editei minha resposta um pouco.
Sean Houlihane 22/02

11

Os dispositivos leves e as taxas de data de alguns bytes solicitam o uso do MQTT , como já foi mencionado. Seus nós de sensor podem ser baseados em módulos ESP8266 independentes, poderosos o suficiente para hospedar uma implementação de cliente MQTT. Ou você pode simplesmente usar esses módulos como um módulo Wi-Fi controlado por comando AT junto com seus microcontroladores externos.

Você pode implementar sua própria solução MQTT em microcontroladores muito menos poderosos como esse cara que usou um Atmega48V com 4 kB de flash .

Você pode hospedar um corretor no seu computador, embora seja mais eficiente em termos de energia executar um Raspberry Pi. Novamente, se você gosta de codificar, pode implementar seu próprio broker MQTT. Pessoalmente, achei o Mosquitto ótimo para esse fim.

Desvantagem de que todos os nós dos sensores precisariam de conexão TCP / IP.


A solução que economiza bateria pode ser usar os nós de sensor / atuador habilitados para LoraWAN ou ZigBee e implementar um gateway em um Raspberry / BeagleBone, que também pode hospedar um servidor Web simples que pode ser acessado pelo telefone ou por outros dispositivos.


Em todos os casos, tudo se resume a tornar seu hub, gateway ou servidor acessível fora da sua rede privada. Existem mais maneiras de fazer isso e a principal preocupação é sempre a segurança. Esta é a parte mais arriscada na minha opinião.

Os requisitos básicos são bem resumidos pelo @Sean.


De acordo com a sua resposta e a resposta de @ Sean, vejo que preciso de algum tipo de hub ou gateway. Isso é absolutamente necessário? Quero dizer, não posso simplesmente me conectar diretamente a qualquer nó sabendo seu endereço IP ou nome de host? Não é que eu esteja tentando evitar um hub ou gateway, só quero entender se é necessário e por quê. Obrigado por ajudar !!
M4l490n

Você achou que o Raspberry Pi é bom como um dispositivo "sempre ativo"? Eu tenho um pequeno HDD conectado ao meu Pi que uso como armazenamento em rede, mas hesito em deixá-lo ligado o tempo todo. Tudo bem se eu fizer isso? (FWIW eu tenho pequenas dissipadores de calor sobre ele)
BruceWayne

1
@ m4l490n O uso de um hub ou gateway torna mais simples. Dessa forma, você deve configurar o encaminhamento de porta ou outro somente para o hub ou gateway. Se você quiser se conectar diretamente a todos os dispositivos atrás do roteador, precisará configurar o encaminhamento de portas para cada um, por exemplo. Mais riscos à medida que você abre mais caminhos para sua rede privada e mais trabalho.
Bence Kaulics


10

Você questionou as duas respostas anteriores sobre a necessidade de um controlador / hub. Considere que, para que as coisas aconteçam, você precisa de regras para existir. Se você deseja pressionar um grande botão vermelho para abrir uma porta da garagem, alguma regra deve vincular o sensor (botão) à ação desejada (abrir a porta). Existem duas maneiras de fazer isso acontecer: você pode colocar a regra diretamente no botão ou em um computador separado.

Vamos pensar mais sobre a solução direta. Se você ensinar o botão sobre a porta da garagem, seu botão conterá as regras internamente. O botão precisa do ID da porta da garagem, portanto, se você substituir a porta da garagem, o botão não funcionará. Se o botão estiver em sua mesa e sua casa usar uma rede proprietária, ele precisará saber o endereço do gateway da sua casa e o endereço da porta. O botão precisa conhecer o protocolo específico para sinalizar a abertura da porta - todos os fabricantes fabricam botões compatíveis que conhecem todos os sinais da porta? O botão não pode fazer mais nada a menos que você o reprograme - você tem um programador flash para o chip do botão, e esse programa é compatível com outros dispositivos? Se você deseja que a porta da garagem se abra e, 5 minutos depois, feche, seu botão precisa de todas as complexidades de manter um relógio em tempo real. Seu botão não saberá o estado da porta, dificultando saber se você está fechando ou abrindo a porta. E como você faz backup das regras para que, se o botão for quebrado, o botão de substituição possa fazer o trabalho? No lado positivo, parece barato: você não precisa de um computador separado.

Com um controlador, as coisas são diferentes. Todas as mensagens de todos os sensores são entregues ao controlador. Cada sensor é simples: envie o sinal para o controlador. O controlador pode aplicar as entradas necessárias a regras muito complexas: pode verificar o sensor de luz do sol e não acender as luzes externas, a menos que esteja escuro, ou não usar os aspersores se a precipitação média do mês estiver acima da média e a temperatura atual está cinco graus abaixo da média. O controlador pode acompanhar o estado. Isso pode ser importante se você deseja um botão "fechar a porta da garagem", mas não um botão "abrir a porta da garagem" (quando estou fora de casa, raramente quero abrir a porta, mas definitivamente quero fechá-la, se estiver acidentalmente deixada em aberto.)

O controlador pode fornecer o local para drivers de dispositivos que sabem ouvir botões e outros drivers que sabem falar com portas. O controlador pode ser mais atualizável para novos dispositivos e tipos de dispositivos do que um pequeno chip escondido dentro de um botão.

O controlador também pode ter uma lógica mais complexa para tarefas de infraestrutura, como entrega de mensagens, oferecendo certos níveis de serviço. Por exemplo, o protocolo MQTT permite três níveis diferentes: tente entregar a mensagem uma vez, entregue repetidamente até que seja vista pelo menos uma vez ou entregue uma e apenas uma vez.

O controlador oferece um local arquitetonicamente lógico para consolidar todas as mensagens de e para um gateway de comunicação, permitindo o uso de uma interface externa. Isso significa que seu botão e seu telefone podem enviar sinais e as regras podem descobrir que qualquer um deles pode abrir a porta da garagem. O gateway também pode fornecer a segurança. Você não precisa colocar o botão e a porta da garagem na internet; você pode colocá-los em redes isoladas privadas e usar o gateway para transmitir os sinais. O controlador também fornece um ponto único para fazer backup de todas as regras do seu sistema.

As desvantagens do controlador são latência adicionada e complexidade extra. Surpreendentemente, um controlador não faz o custo subir consideravelmente. Você pode implementar um controlador em um Raspberry Pi por menos do que o custo de um interruptor de luz médio remotamente controlável. Não descarte a ideia apenas com base no custo.


Bem, parece que ter um HUB, ou controlador, é altamente desejável, especialmente se eu precisar de uma funcionalidade baseada em regras em todos os meus dispositivos de IoT que possam permitir aproveitar ao máximo toda a rede.
M4l490n

Portanto, se eu entendi corretamente, posso ter conexão ponto a ponto, desde que não precise de regras complexas ou mesmo de uma rede complexa de dispositivos IoT, e isso também pressupõe que os dispositivos IoT não terão interoperabilidade com outras marcas e que, por exemplo, um botão estará sempre amarrado ao mesmo abridor de porta.
M4l490n

Caso contrário, se mais flexibilidade e funcionalidade forem necessárias, eu deveria ter um HUB. Isso está correto?
M4l490n

Sim, esse é um resumo preciso. Praticamente todo mundo acaba precisando de algum tipo de hub / controlador. Existem muitas opções para hubs, comerciais e de código aberto.
John Deters
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.