Standard per dispositivi WiFi non connessi a Internet?


10

Ho intenzione di fare molta automazione domestica. Per questo ospiterò una rete WiFi isolata privata alla quale saranno collegati tutti i miei dispositivi. I dispositivi saranno semplici luci, strisce LED RGB (smd5050 e ws2812b), termostati, ventole, apri finestre, regolatori dell'ombra delle finestre e prese normali. Inoltre, trasmettitori IR per simulare un telecomando per avviare TV ecc. E un trasmettitore 433 MHz per simulare un telecomando che può attivare / disattivare le prese standard telecomandate.

Ora mi chiedo se ci sono degli standard su quale tipo di interfaccia questi dispositivi dovrebbero esporre alla rete WiFi.

Ovviamente potrei fornire ad ogni dispositivo un semplice percorso http e poi scrivere applicazioni che capiscano la mia interfaccia, ma sarebbe bello se potessi implementare uno standard che mi permettesse di usare app e programmi che sono già stati scritti e capire lo standard .

Risposte:


7

Informazioni sui protocolli IoT, più comunemente HTTP, CoAP e MQTT vengono utilizzati per la comunicazione.

HTTP e CoAP sono adatti per il tipo REST di comunicazione client / server e server e MQTT supporta la comunicazione multiutente basata su pubblicazione e sottoscrizione, in cui l'origine può essere facilmente da server a client, da client a server e persino da client a client.

Rispondere alla domanda:

Utilizzare REST su HTTP o CoAP per comunicazioni one-to-one o MQTT per l'utilizzo del traffico multipunto.

Più dettagli

Dopo il commento qui sotto, ammetto che la mia risposta è stata abbastanza parziale, quindi ho esaminato e trovato un po 'di più:

Anche le comunicazioni hanno questo tipo di confusione di standard, se tutti calcolati:

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

Fonte: EU Butler Project - Problemi di comunicazione

Anche postscapes.com ha il seguente elenco basato su diversi aspetti:

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)

Come visto nella lista di ogni esempio, ce ne sono molti e sicuramente ce ne sono anche altri personalizzati e proprietari.

Dovresti aprire quel link e leggerlo, è strabiliante. Credo che potresti incontrare molti di questi progetti, almeno se i sensori sono di forma pesante, vale a dire. non solo componenti nel formato più puro, ma parti di alcuni ecosistemi già esistenti. In quei casi forse non puoi negoziare il modo in cui li interfaccia, devi solo selezionare tra ecosistemi.

Il problema giusto ora sembra essere quello di trovare un set di prodotti corretto o un set di set (gruppo di set di prodotti) con stack di protocollo identici o quasi corrispondenti tramite Wi-Fi, mentre si imposta l'obiettivo (tenere presente che l'infrarosso è una soluzione fuori da quest'area e lì sono molte altre soluzioni di rete wireless non Internet, che potresti ancora affrontare).

I criteri sarebbero identificare ciò che tutte le cose che potresti voler fare e quante pile potresti voler imparare in quel modo. Con l'apprendimento intendo che vuoi ancora giocare poco con i gadget ed essere consapevole di come funziona un determinato protocollo sotto il cofano.


1
"REST over http" è un po 'vago. Anche con questo in mente, ho potuto pensare a centinaia di modi diversi per progettare l'interfaccia, specialmente per i dispositivi che comprendono più di "on" e "off". Idealmente, fornirei solo l'indirizzo IP e il tipo di dispositivo e il resto sarebbe standardizzato. Esiste qualcosa del genere?
Forivin,

7

La mia raccomandazione è MQTT. Versatile, leggero e modulare, può anche funzionare su un ESP8266 (Hub e client). Il protocollo MQTT è disponibile per molte piattaforme da dispositivi mobili integrati e fino a sistemi operativi di grandi dimensioni come MAC, Windows e Linux.

Il protocollo ha un modello Publisher, Subscriber per la comunicazione. E un QoS in modo che un Hub possa ricordare se un abbonato ha ricevuto un messaggio da un editore. Quindi un dispositivo per dormire può alzarsi alla velocità quando si sveglia e cerca i suoi messaggi.

Eseguo il mio server MQTT su un piccolo Raspberry Pi Zero W, è come una carta di credito sul muro e per la logica utilizzo "Node Red" e ho iniziato a cercare OpenHAB per una soluzione più complicata.

Ho anche creato i miei dispositivi Arduino / MQTT per i miei dispositivi a 12 V CC e utilizzo un prodotto basato su ESP8266 per i miei dispositivi a 230 V CA.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.