¿Cómo suelen permitir los dispositivos IoT de consumo la conexión a Internet?


15

Hasta donde sé, hay 2 métodos generales para habilitar el acceso remoto (Internet, no LAN) a dispositivos IoT:

  1. A través de un servidor que el dispositivo sondea periódicamente (por ejemplo, MQTT )
  2. Acceso remoto directo

Supongo que el segundo método no es sencillo, ya que generalmente los dispositivos de consumo se encuentran detrás de un enrutador doméstico.

Mi pregunta es la siguiente: aproximadamente, qué porcentaje de dispositivos IoT vendidos actualmente usa cuál de los siguientes métodos para conectarse a ellos de forma remota :

  1. A través de un servidor (el dispositivo sondea el servidor)
  2. Acceso remoto directo que requiere configurar manualmente un enrutador doméstico para habilitar el reenvío de puertos (u otra forma que exponga el dispositivo)
  3. Acceso remoto directo donde el dispositivo configura automáticamente el enrutador a través de UPnP u otro protocolo
  4. Acceso remoto directo utilizando la dirección IPv6 estática de un dispositivo que no requiere la configuración del enrutador
  5. Otros métodos

Mi pregunta está relacionada con dispositivos IoT de consumo, como bombillas, interruptores de luz, cerraduras, termómetros, etc. de fabricantes confiables que se venden hoy y se instalan en hogares.

Actualizar:

Encontré esta respuesta por @ Aurora0001 a otra respuesta en este sitio sobre la perforación para permitir la comunicación directa entre 2 dispositivos que residen en diferentes redes internas (por ejemplo, detrás de un enrutador doméstico). Esta solución requiere un servidor, pero solo para el apretón de manos inicial.

Supongo que eso agregaría otra opción ...


Interesante pregunta. No estoy seguro de si habrá estadísticas fácilmente obtenibles para averiguar los porcentajes: ¿los necesita específicamente o simplemente está tratando de saber qué métodos son más comunes?
Aurora0001

55
También MQTT no sondeo, se abre una conexión persistente hacia el corredor y el corredor luego envía mensajes de marcha atrás que enlazan
hardillb

1
Supongo que el 99% de las instalaciones de este año usarán (1), pero no tienen nada que justifique la suposición.
Sean Houlihane

2
@Mawg Búsqueda de dirección inversa. Accediendo a un dispositivo en mi casa desde el trabajo.
Sean Houlihane

1
@Perspectivus, por qué, prácticamente no hay sobrecarga en un socket abierto, envía un paquete muy pequeño para mantener vivo (para que el corredor sepa que todavía está allí) a una velocidad configurable, que siempre que sea más corto que 15 minutos de tiempo de espera TCP fuera del socket debe permanecer abierto indefinidamente.
hardillb

Respuestas:


12

Creo que encontrará un porcentaje bastante alto de "# 5, Otro", porque a la lista le falta una de las arquitecturas de IoT de consumo más comunes: las comunicaciones indirectas a través de una puerta de enlace en el hogar.

Todos los demás métodos que describe tienen inconvenientes en el hogar: son difíciles de configurar, no son seguros o requieren muchos recursos costosos del servidor. Una puerta de enlace en el hogar evita esos problemas para los dispositivos individuales, exponiendo solo un dispositivo a Internet.

La puerta de enlace típica tiene varios propósitos. Primero, es un puente de protocolo. Los dispositivos inalámbricos usan todo tipo de protocolos de comunicaciones abiertos y patentados, incluidos Z-Wave, Zigbee, RF dedicado de 900 MHz, RF dedicado de 433 MHz, luz infrarroja, Bluetooth, BLE, ANT +, Crestron, etc. Estos resuelven todo tipo de problemas de nicho, como el costo por dispositivo, la duración de la batería, las redes de malla autoconfigurables, los tiempos de respuesta rápidos, las comunicaciones inseguras, las configuraciones simples que utilizan un almacenamiento mínimo, etc. De esta manera, la mayoría de los dispositivos IoT de consumo no utilizan paquetes IP, sino que entregan sus datos dentro de mucho Bastidores más pequeños para preservar la vida útil de la batería. La puerta de enlace convertirá el protocolo propietario en algo más transportable e interoperable con una red basada en IP.

Además, la puerta de enlace en el hogar es un buen lugar para almacenar las reglas del sistema. Si va a habilitar reglas como "si enciende la luz en la parte superior de las escaleras, también encienda la luz de la entrada, a menos que la luz de la cocina esté encendida", puede colocar las reglas en los interruptores de luz, una centralizada servidor web o la puerta de enlace. Poner las reglas en cada interruptor de luz crea una configuración frágil que es difícil de configurar, cambiar o administrar. La ejecución de las reglas en un servidor centralizado introduce latencia porque el mensaje debe traducirse a TCP, cifrarse, enviarse a través de Internet, la acción debe recibirse, descifrarse y traducirse nuevamente a Zigbee. La puerta de enlace permite al proveedor resolver estos problemas al proporcionar un único punto de administración para realizar copias de seguridad y restaurar, y un procesador local para ejecutar las reglas rápidamente.

La seguridad es un gran problema: los dispositivos IoT deben ser baratos, y los procesadores baratos no tienen grandes CPU y almacenamiento para funciones de cifrado seguras. Sin mencionar el deseo de evitar el gasto masivo de desarrollar protocolos cifrados de forma segura. Por lo tanto, implementan una seguridad muy débil (barata) en los dispositivos de consumo, o ninguna seguridad en absoluto. Para compensar esto, solo se comunican dentro de un rango muy limitado; solo tienen que llegar a la puerta de enlace del hogar. De esta manera, la puerta de enlace maneja las comunicaciones locales no seguras, y solo un dispositivo necesita la potencia de procesamiento y el almacenamiento necesarios para comunicarse con la nube a través de TLS.

Finalmente, la puerta de enlace puede proporcionar un punto único conveniente de interfaz humana para los dispositivos. La mayoría de las puertas de enlace exponen una interfaz web, lo que permite la configuración basada en GUI. Imagínese intentar configurar el código Morse para configurar una contraseña WiFi de 12 caracteres en un dispositivo usando solo un botón y un LED. Peor aún, imagine que el personal de soporte telefónico de su empresa habla con cada cliente a través de ese proceso.

Lamentablemente, esto todavía no responde a su pregunta directamente. Pero espero que la arquitectura de puerta de enlace sea la forma más común en que los dispositivos orientados al consumidor se conectan a Internet.

EDITAR: en respuesta a su comentario sobre las puertas de enlace en el hogar utilizadas para dispositivos IoT, hay algunos tipos básicos: propósito único dedicado, propósito múltiple dedicado y propósito general. Además de las interfaces a continuación, todas ellas tienen una interfaz Ethernet o WiFi para conectar mensajes hacia y desde una red IP.

Una puerta de enlace dedicada de un solo propósito solo habla a los dispositivos de un fabricante en particular. Los ejemplos más simples podrían ser un dongle USB que recibe datos de un solo dispositivo, como un dongle Fitbit. Otros ejemplos incluyen el puente Philips Hue (que se comunica solo con las bombillas Philips Hue); Liftmaster MyQ Gateway (que se comunica solo con los abridores de puertas de garaje Liftmaster, Chamberlain o Craftsman); o Harmony Hub (que se comunica con los controles remotos Logitech Harmony y parpadea IR a varios componentes de cine en casa).

Un ejemplo del concentrador multipropósito dedicado sería el concentrador SmartThings de Samsung. SmartThings vende una amplia variedad de dispositivos de automatización del hogar, pero solo hablan el protocolo SmartThings. El concentrador SmartThings también puede comunicarse con muchos otros controladores de dispositivos a través de IP, y tiene integración nativa con IFTTT.

Las puertas de enlace de propósito general pueden tener algunos componentes patentados, pero a menudo admiten múltiples interfaces y pueden servir como una interfaz principal inteligente para el hogar. Los ejemplos incluyen el Wink Hub (que se comunica con los dispositivos RF Zigbee, Z-Wave, Lutron y Kidde); Vera Edge (que se comunica con dispositivos Z-Wave e Insteon, y se extiende para comunicarse con dispositivos externos).

Finalmente, también hay algunos esfuerzos de código abierto muy activos en el dominio de domótica de uso general, incluidos Domoticz y OpenHAB. Estos son programas de software que admiten la comunicación con dispositivos IoT a través de dispositivos puente dedicados (como un dongle USB Z-Wave o una radio Zigbee), implementan reglas y ofrecen amplias capacidades de integración como IFTTT, MQTT y otros.


Gracias John ¿Puede proporcionar referencias a artículos generales o ejemplos específicos de tales puertas de enlace en el hogar?
Perspectivus

8

Prácticamente todos los productos de consumo que operan de esta manera requerirán un servidor externo para mediar el envío de mensajes desde un dispositivo externo a un dispositivo específico en el hogar. Incluso en el caso más obvio de exponer el puerto 22 en su Raspberry Pi, aún necesita (en general) un servicio DNS dinámico.

  1. El dispositivo inicia y mantiene una conexión persistente con el servidor. Esto no requiere configuración del enrutador, siempre que el enrutador proporcione acceso https a la web ...

Para todos los demás métodos, el dispositivo remoto debe poder encontrar el dispositivo en el hogar. Los protocolos punto a punto a veces utilizan el reenvío de puertos, ya que desean evitar una arquitectura cliente-servidor.

Es posible que un sistema, además, abra un puerto entrante usando UPnP, pero esto no debería ser necesario para las aplicaciones IoT. Esto podría aplicarse a las aplicaciones de juegos heredadas, pero se desmorona en cuanto hay más de un nodo presente en una IP pública.

Aunque IPv6 permite asociar un par de dispositivos, muchas redes no son compatibles hoy con IPv6 de extremo a extremo. Un servidor es necesario independientemente de proporcionar actualizaciones de firmware (a menos que el dispositivo esté obsoleto antes de que se venda).

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.