Para mí está claro que el autor de otra publicación aquí es un experto, pero lanzar una sopa de estándares con el alfabeto no ayudará a las personas a comprender lo que se necesita, especialmente si se vincula a un sitio genérico como World Wide Web Consortium (W3C) o The XMPP Fundación de normas.
Hay muchos niveles para que funcionen los estándares de IoT. Muchos de ellos están bien establecidos en el mercado. La mayoría de los relevantes fueron mencionados en algunas de las publicaciones aquí, pero sin explicación. Diferentes grupos y protocolos intentan resolver diferentes problemas. Algunos de los grupos tienen un enfoque muy limitado y especializado. Otros intentan “hacerlo todo”. Comprender la noción de una “pila de protocolos” también es importante. Muchas de las palabras de moda que escuchas en realidad se refieren a una colección de protocolos.
Solo tenga en cuenta que IoT no es nuevo . Es una evolución de lo que vino antes. Algunos puntos rápidos, trabajando desde un dispositivo “IoT” hacia arriba.
- ¿Cuáles son algunos ejemplos de protocolos de internet?
- ¿Cuáles son los comandos básicos que puedo escribir en mi símbolo del sistema para verificar la red, la calidad de la red y su velocidad, etc.?
- ¿Por qué era necesario crear una capa de adaptación separada en la pila de protocolos IoT?
- ¿Por qué la oficina administrativa de Fyers utiliza un protocolo HTTP sin cifrar para el inicio de sesión del usuario?
- ¿El protocolo DASH7 está disponible a nivel comercial, y si no, por qué no?
(1) El dispositivo tiene que conectarse a una red cercana.
Wifi está ampliamente disponible en la mayoría de las ubicaciones, por lo que si un dispositivo no está demasiado preocupado por el consumo de energía, esa es probablemente la forma más fácil de conectarse.
Sin embargo, algunos dispositivos tienen muy poca potencia y muy poca capacidad de procesador. Wifi no es absolutamente una opción. Los “protocolos de RF” de IoT se han centrado en eso. 802.15.4 es el protocolo RF de bajo nivel que permite la comunicación de sensores conectados de muy baja potencia. Es un protocolo de malla. Hay muchas pilas de protocolos de malla que utilizan alguna versión de 802.15.4. :
Onda Z
ZigBee (la parte central de todos modos)
Hilo (nuevo pero usado por Nest / Google y tienen un gran trabajo yendo allí).
Por cierto, Z-Wave y Zigbee no usan direcciones IP. Hay un protocolo que trata con esto llamado 6LoWPAN (IPV6 para PAN inalámbricos de baja potencia). Thread usa 6LoWPAN y también algunos otros protocolos de malla que a la mayoría de las personas enfocadas en productos de consumo no les importan. Si desea que un dispositivo de baja potencia tenga una dirección IP, su pila de red es mejor para 6LoWPAN.
Entonces tienes Bluetooth Smart (anteriormente llamado BLE – Bluetooth Low Energy). Nuevamente, este no es UN protocolo, sino una colección completa de ellos, y no asigna una dirección IP a un dispositivo. Es más nuevo, pero estará en casi cualquier producto de consumo conectado que quiera interactuar directamente con un teléfono inteligente u otro dispositivo de computación personal. Tiene alto rendimiento y bajo consumo de energía. Definitivamente es una opción de conectividad “imprescindible” para la mayoría de los mercados.
(2) Una vez que el dispositivo está conectado, debe hacer algo útil. Existen los protocolos de “capa superior”, también llamados protocolos de sesión y capa de aplicación. Hacen las cosas realmente “geniales” desde el punto de vista de las aplicaciones, DESPUÉS de que haya cubierto la conectividad básica. Algunos ejemplos rápidos de grupos y estándares centrados en las cosas de la capa de aplicación:
AllSeen Alliance está produciendo los protocolos AllJoyn.
CoAP es como HTTP pero para dispositivos “restringidos” (capacidad limitada).
HAP es propiedad y forma parte de Apple HomeKit.
GATT es parte de BLE (y se usa en otros lugares). Es muy importante hacer que varios dispositivos trabajen juntos. Si sabe qué son uPNP y Zeroconf / Bonjour, GATT tiene una funcionalidad similar.
Algunos de los trabajos de comunicación de IoT más emocionantes que se están llevando a cabo en este momento son a este nivel. Aquí hay algo realmente importante que comprender: cada una de las diversas alianzas de red de IoT tiene sus propias formas específicas de hacer cosas de capa de aplicación. Mientras un dispositivo Z-Wave esté hablando con otro dispositivo Z-Wave, pueden usar cualquier esquema de capa de aplicación que la alianza Z-Wave haya definido para hacer “cosas útiles”. Ditto ZigBee y cualquier otro grupo que tenga su propia “pila completa” para la comunicación.
Sin embargo, si desea trabajar en un mundo de “múltiples alianzas”, debe admitir estos protocolos de aplicación estándar. La mayoría de las soluciones ponen esta funcionalidad en un puente, puerta de enlace o enrutador de IoT. Algunas compañías como SmartThings (ahora parte de Samsung) y Revolv (ahora parte de Nest) se centraron en este aspecto desde el principio, porque todas las casas de consumo real son probablemente casas de múltiples proveedores y consorcios.
Esto debería proporcionar una visión general decente de los protocolos de conectividad de dispositivos y puertas de enlace. Hay mucho más en una solución de IoT en el lado web de las cosas, incluida la capa de procesamiento de eventos en tiempo real, API de nube a nube (utilizada para “Works with Nest” y otras), etc.
Un comentario más: las API de nube a nube son la forma más rápida y fácil de interconectar múltiples grupos de dispositivos que son incompatibles pero que al menos tienen conectividad a Internet a través de un puente. Eso es exactamente lo que está haciendo “Works with Nest” en este momento.
