¿Qué necesito para crear mi propia nube personal para dispositivos IoT?

Este es un tema en el que he estado pensando durante un tiempo, especialmente porque el concepto de "IoT" ha estado flotando mucho últimamente.

Comenzaré con lo que quiero decir cuando digo "IoT" . Sé que el término IoT podría significar cosas diferentes y que a veces se usa incorrectamente. Podría ser un término que no está claramente definido y puede conducir a grandes debates sobre qué significa exactamente, yo mismo no conozco la definición adecuada y ampliamente aceptada del término. Entonces, para mí, IoT es un concepto, un concepto que define la capacidad de conectarse a un dispositivo integrado de forma remota a través de Internet, ya sea desde otro dispositivo integrado o desde un teléfono celular . Tan sencillo como eso.

En este contexto, el propósito de la conexión no importa, si puede conectar un dispositivo en su oficina con otro en su hogar, o si puede conectarse a un dispositivo en su hogar desde su teléfono celular, todo esto a través de Internet, entonces estamos hablando de dispositivos IoT (los dispositivos integrados, no el teléfono).

Entonces, habiendo acordado lo que quiero decir con IoT, ahora describiré lo que estoy tratando de lograr.

Lo que intento lograr es precisamente lo que describo en mi definición de IoT.

Quiero tener uno o varios dispositivos integrados en casa conectados a mi enrutador de internet, ya sea por ethernet o wifi y poder conectarme a ellos de forma remota con otros dispositivos integrados en una ubicación remota (y por remoto no quiero decir que esté en la misma red) y tal vez también poder conectarme a ellos con una aplicación de monitoreo en mi teléfono

Por ejemplo, es posible que tenga un dispositivo integrado simple que actúa como un interruptor de encendido / apagado conectado a mi abre-puertas de garaje y otro dispositivo integrado que actúa como un gran botón rojo en mi escritorio en el trabajo para poder presionar el botón rojo en mi escritorio y se abre la puerta del garaje.

Otro ejemplo sería tener un dispositivo integrado con capacidades de ADC que pueda monitorear la temperatura de mi casa y enviarme una alerta cuando llegue a un umbral. La notificación podría ser recibida ya sea por una simple aplicación de Android o por otro dispositivo integrado con una pequeña pantalla en mi escritorio en el trabajo.

Estos ejemplos pueden ser tontos, pero son solo para ilustrar los posibles escenarios y los casos de uso de lo que estoy tratando de lograr. Al final, la idea es la misma: conectar un dispositivo integrado con otro a través de Internet.

Otra cosa para aclarar es que el intercambio de datos entre estos dispositivos será muy liviano, solo un par de bytes cada vez, no es que se necesiten cientos de kilobytes para intercambiarse entre dispositivos.

Además, el tipo de "dispositivos integrados" a los que me refiero son dispositivos simples pero capaces basados ​​en microcontroladores cortex-m4 de 100MHz o 200MHz. Y eso es importante de aclarar porque no habrá ninguna biblioteca Linux o compleja que se ejecute en esos dispositivos. Al final, es un desperdicio de recursos y completamente innecesario tener un procesador potente que ejecute Linux solo para encender y apagar una bombilla . En cualquier caso, planeo usar una BeagleBoard, Raspberry Pi o cualquier otra placa como esa como mis dispositivos integrados. Solo microcontroladores porque no se necesita más complejidad de la necesaria.

No sé mucho sobre las plataformas IoT y ese tipo de soluciones complejas que existen. Cuando comencé este viaje de encontrar una manera de conectar un dispositivo integrado con otro a través de Internet, me topé con un par de sitios con servicios de IoT.

Sé que hay algunos servicios en la nube de IoT como:

• Blynk
• Google Cloud Platform
• Plataforma ExoSite IoT
• Plataforma Ayla IoT

Sólo para nombrar unos pocos. Los principales problemas con ellos son el costo y la complejidad. Tienes que pagar para obtener esos servicios y también debes aprender cómo implementar todos los servicios que tienen, en caso de que los necesites a todos, y sus API y tal vez un montón de otras cosas que no me parecen necesarias. capaz de intercambiar algunos bytes entre dispositivos. Solo quiero algo más simple que eso, algo que pueda hacer yo mismo.

Puede decir que implementar mi propia "nube", si eso es algo que tengo que hacer, no es simple y, a veces, es mejor usar ese tipo de servicios en aras de la simplicidad, pero hay dos razones principales por las que quiero saber cómo hacerlo. implementar mis propios servicios de IoT.

La razón principal es que quiero hacerlo yo mismo. No quiero depender de un tercero para conectar mis dispositivos entre sí y dado que desarrollaré el código y el hardware para mis dispositivos, entonces me parece mejor crear también mis propios medios para conectarlos como dispositivos IoT.

La segunda razón es aprender a hacerlo. Al conocer todas las cosas necesarias que necesito para lograr esto, tendré una mejor comprensión del mundo de IoT.

Además, quiero mencionar que soy competente en C y uso Linux como mi sistema operativo cotidiano en el trabajo y en mi hogar, así que evite las cosas de Windows porque eso es inútil para mí. No tengo miedo de nada que tenga que implementar en C para mis dispositivos integrados o en Linux para implementar lo que sea necesario para lograr mi objetivo.

Entonces, mi pregunta es, ¿qué es necesario implementar y dónde, para poder conectar dos o más dispositivos integrados entre sí con el fin de intercambiar datos entre ellos?

Esta pregunta ¿Qué puedo usar para crear un IoT en nuestro propio servidor? tiene algo similar pero está cerrado y no tiene ninguna respuesta, también supone que se utilizará una infraestructura de nube ya existente. Entonces no me ayuda.

Esta otra publicación ¿Qué servicios de IoT están disponibles para almacenar / enviar / publicar datos genéricos en la nube? tiene una pregunta similar, pero el OP pregunta explícitamente por los servicios de IoT y estoy tratando de evitarlos.

Tal vez me perdí el punto de la pregunta, pero creo que este es un buen comienzo para responder.

Necesitas tres cosas, como mínimo.

1. Un nodo informático siempre activo para agregar sus datos. Esto no necesita ser poderoso, podría ser un proceso que se ejecuta en su NAS, o incluso (en teoría) en su enrutador. Por simplicidad, suponga que es una Raspberry Pi. Esto también podría proporcionar cualquier protocolo de radio elegante que decida admitir en el futuro. Aunque en teoría podría ejecutarse de igual a igual con todos los nodos expuestos a Internet, es más fácil designar a uno como maestro y hacer que se encargue de la recopilación y publicación de datos (para la aplicación / usuario). Por supuesto, el concentrador también puede ser un nodo, especialmente si utiliza nodos WiFi que son moderadamente potentes.
2. Una pila de software adecuada para permitir que los puntos finales envíen sus datos a su nodo central. mqtt es el tipo de cosas que necesita aquí, además de un sistema operativo para ejecutarlo.
3. DNS y reenvío de puertos para facilitar el acceso a su servidor desde Internet más amplio.

Entonces no olvides la seguridad. Al hacer esto, estará más cerca de abrir todo en su red doméstica para atacar. Tal vez solo un poco, pero es bueno ser consciente del riesgo. Puede intentar y tener cuidado, pero suponga que cometerá errores.

Los dispositivos livianos y las tasas de fecha de un par de bytes requieren el uso de MQTT , como ya se ha mencionado. Sus nodos de sensor podrían basarse en módulos ESP8266 independientes que son lo suficientemente potentes como para albergar una implementación de cliente MQTT. O simplemente puede usar estos módulos como un módulo Wi-Fi controlado por comando AT junto con sus microcontroladores externos.

Puede implementar su propia solución MQTT en microcontroladores mucho menos potentes como este tipo que ha usado un Atmega48V con 4 kB de flash .

Puede alojar un corredor en su computadora, aunque sería más eficiente en términos de energía ejecutar un Raspberry Pi. Nuevamente, si le gusta la codificación, puede implementar su propio agente MQTT. Personalmente, encontré Mosquitto genial para este propósito.

Desventaja de que todos sus nodos sensores necesitarían una conexión TCP / IP.

La solución amigable con la batería podría ser usar nodos de sensores / actuadores habilitados para LoraWAN o ZigBee e implementar una puerta de enlace en una Raspberry / BeagleBone que también puede alojar un servidor web simple al que se pueda acceder desde su teléfono u otros dispositivos.

En todos los casos, todo se reduce a hacer que su hub, puerta de enlace o servidor sea accesible fuera de su red privada. Hay más formas de hacerlo y la principal preocupación es siempre la seguridad. Esta es la parte más arriesgada en mi opinión.

@Sean resume bastante bien los requisitos básicos.

Ha cuestionado ambas respuestas anteriores sobre la necesidad de un controlador / concentrador. Considere que para que las cosas sucedan, necesita reglas para existir. Si desea presionar un botón rojo grande para abrir una puerta de garaje, alguna regla debe vincular el sensor (botón) a la acción deseada (abrir la puerta). Hay dos formas de hacer que eso suceda: puede poner la regla directamente en el botón, o puede poner la regla en una computadora separada.

Pensemos más en la solución directa. Si enseña el botón sobre la puerta del garaje, entonces su botón contiene las reglas internamente. El botón necesita la ID de la puerta del garaje, por lo que si reemplaza la puerta del garaje, el botón no funciona. Si el botón está en su escritorio y su casa utiliza una red patentada, el botón debe conocer tanto la dirección de la puerta de enlace de su hogar como la dirección de la puerta. El botón necesita conocer el protocolo específico para indicar que se abra la puerta: ¿todos los fabricantes hacen botones compatibles que conozcan todas las señales de la puerta? El botón no puede hacer nada más a menos que lo reprograme: ¿tiene un programador flash para el chip del botón y es ese programador compatible con cualquier otro dispositivo? Si desea que la puerta del garaje se abra y 5 minutos más tarde se cierre, su botón necesita todas las complejidades de mantener un reloj en tiempo real. Su botón no sabrá el estado de la puerta, por lo que es difícil saber si está cerrando la puerta o abriéndola. ¿Y cómo hace una copia de seguridad de las reglas para que si su botón se rompe, su botón de reemplazo pueda hacer el trabajo? En el lado positivo, suena barato: no necesita una computadora separada.

Con un controlador, las cosas son diferentes. Todos los mensajes de todos los sensores se entregan al controlador. Cada sensor es simple: envíe la señal al controlador. Luego, el controlador puede aplicar cualquier entrada necesaria para reglas muy complejas: puede verificar el sensor de luz solar y no encender las luces exteriores a menos que esté oscuro, o no hacer funcionar los rociadores si la precipitación promedio del mes es superior al promedio y la temperatura actual está cinco grados por debajo del promedio. El controlador puede realizar un seguimiento del estado. Esto podría ser importante si desea un botón de "cerrar la puerta del garaje" pero no un botón de "abrir la puerta del garaje" (cuando estoy fuera de casa, rara vez quiero abrir la puerta, pero definitivamente quiero cerrarla si está accidentalmente dejado abierto)

El controlador puede proporcionar el lugar para los controladores de dispositivos que saben escuchar los botones y otros controladores que saben hablar a las puertas. El controlador puede ser más actualizable a nuevos dispositivos y tipos de dispositivos que un pequeño chip escondido dentro de un botón.

El controlador también puede tener una lógica más compleja para tareas de infraestructura, como entregar mensajes al ofrecer ciertos niveles de servicio. Por ejemplo, el protocolo MQTT permite tres niveles diferentes: intente entregar el mensaje una vez, entregarlo repetidamente hasta que se haya visto al menos una vez, o entregarlo una vez y solo una vez.

El controlador ofrece un lugar arquitectónicamente lógico para consolidar todos los mensajes hacia y desde una puerta de enlace de comunicaciones, lo que permite el uso de una interfaz externa. Esto significa que su botón y su teléfono pueden enviar señales, y las reglas pueden determinar que cualquiera de los dos puede abrir la puerta del garaje. La puerta de enlace también puede proporcionar la seguridad. No tiene que poner su botón y la puerta de su garaje en Internet; puede ponerlos a ambos en redes privadas aisladas y usar la puerta de enlace para transportar las señales. El controlador también proporciona un único punto para hacer una copia de seguridad de todas las reglas de su sistema.

Las desventajas del controlador son latencia agregada y complejidad adicional. Sorprendentemente, un controlador no hace que el costo aumente considerablemente. Puede implementar un controlador en una Raspberry Pi por menos del costo de un interruptor de luz promedio controlable de forma remota. No descarte la idea solo por el costo.