¿Estándares para dispositivos WiFi no conectados a Internet?


10

Estoy planeando hacer mucha automatización del hogar. Para ello, alojaré una red WiFi privada aislada a la que se conectarán todos mis dispositivos. Los dispositivos serán luces simples, tiras de LED RGB (smd5050 y ws2812b), termostatos, ventiladores, abridores de ventanas, controladores de persianas y salidas normales. Además, transmisores IR para simular un control remoto para encender televisores, etc. Y un transmisor de 433MHz para simular un control remoto que puede alternar tomas de control remoto estándar.

Ahora me pregunto si hay algún estándar sobre qué tipo de interfaz deberían exponer estos dispositivos a la red WiFi.

Por supuesto, podría dar a cada dispositivo una ruta http simple y luego escribir aplicaciones que entiendan mi interfaz, pero sería bueno si pudiera implementar un estándar que me permitiera usar aplicaciones y programas que ya se han escrito y entienden el estándar .

Respuestas:


7

Acerca de los protocolos de IoT, más comúnmente HTTP, CoAP y MQTT se utilizan en la comunicación.

HTTP y CoAP son adecuados para el tipo de comunicación REST de cliente (s) a servidor y MQTT admite la comunicación multiusuario basada en publicación y suscripción, donde el origen puede ser fácilmente de servidor a cliente, de cliente a servidor e incluso de cliente a cliente.

Respondiendo la pregunta:

Use REST sobre HTTP o CoAP para comunicaciones uno a uno o MQTT para uso de tráfico multipunto.

Más detalles

Después del comentario a continuación, admito que mi respuesta fue bastante parcial, así que examiné y encontré un poco más:

Incluso las comunicaciones tienen este tipo de desorden de normas, si se calculan todas:

http://www.slideshare.net/butler-iot/butler-project-overview-13603599

Fuente: Proyecto EU Butler - Problemas de comunicación

También postscapes.com tiene la siguiente lista basada en diferentes aspectos:

1  Infrastructure (ex: 6LowPAN, IPv4/IPv6, RPL)
2  Identification (ex: EPC, uCode, IPv6, URIs)
3  Comms / Transport (ex: Wifi, Bluetooth, LPWAN)
4  Discovery (ex: Physical Web, mDNS, DNS-SD)
5  Data Protocols (ex: MQTT, CoAP, AMQP, Websocket, Node)
6  Device Management (ex: TR-069, OMA-DM)
7  Semantic (ex: JSON-LD, Web Thing Model)
8  Multi-layer Frameworks (ex: Alljoyn, IoTivity, Weave, Homekit)

Como se ve en la lista de cada ejemplo, hay muchos de ellos y seguramente también hay otros más personalizados y propietarios.

Debes abrir ese enlace y leerlo, es alucinante. Creo que puede encontrar en su (s) proyecto (s) muchos de estos, al menos si los sensores tienen una forma muy compacta, es decir. no solo componentes en el formato más puro, sino partes de algunos ecosistemas ya existentes. En esos casos, tal vez no pueda negociar la forma en que los conecta, solo tiene que seleccionar entre ecosistemas.

El problema correcto ahora parece ser encontrar el conjunto de productos o conjuntos de conjuntos correctos (grupo de conjuntos de productos) con pilas de protocolos idénticas o casi coincidentes a través de wifi, a medida que establece el objetivo (teniendo en cuenta que el infrarrojo es una solución fuera de esta área y allí) hay muchas otras soluciones de redes inalámbricas que no son de Internet, que aún puede enfrentar).

Los criterios serían identificar qué cosas puede querer hacer, y cuántas pilas puede querer aprender de esa manera. Al aprender quiero decir que todavía quieres jugar poco con los gadgets y saber cómo funciona cierto protocolo bajo el capó.


1
"REST over http" es un poco vago. Incluso con eso en mente, podría pensar en cientos de formas diferentes de diseñar la interfaz, especialmente para dispositivos que entienden más que "encendido" y "apagado". Lo ideal sería proporcionar la dirección IP y el tipo de dispositivo y el resto estaría estandarizado. ¿Existe algo así?
Forivin

7

Mi recomendación es MQTT. Versátil, ligero y modular, incluso puede ejecutarse en un ESP8266 (Hub y cliente). El protocolo MQTT está disponible para muchas plataformas, desde dispositivos móviles integrados y hasta sistemas operativos grandes y gordos como MAC, Windows y Linux.

El protocolo tiene un modelo de editor y suscriptor para la comunicación. Y una QoS para que un Hub pueda recordar si un suscriptor ha recibido un mensaje de un editor. Por lo tanto, un dispositivo para dormir puede ponerse al día cuando se despierta y busca mensajes.

Ejecuto mi servidor MQTT en una pequeña Raspberry Pi Zero W, es como una tarjeta de crédito en la pared y, para la lógica, uso "Node Red" y he comenzado a buscar en OpenHAB una solución más complicada.

También he construido mis propios dispositivos Arduino / MQTT para mis dispositivos de 12 V CC y utilizo un producto basado en ESP8266 para mis dispositivos de 230 V CA.

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.