In che modo i dispositivi IoT consumer in genere abilitano la connessione a Internet?


15

Per quanto ne so ci sono 2 metodi generali per abilitare l'accesso remoto (Internet, non LAN) ai dispositivi IoT:

  1. Tramite un server che il dispositivo esegue periodicamente il polling (ad es. MQTT )
  2. Accesso remoto diretto

Suppongo che il secondo metodo non sia semplice poiché in genere i dispositivi consumer si trovano dietro un router domestico.

La mia domanda è questa: all'incirca quale percentuale di dispositivi IoT attualmente venduti utilizza quale dei seguenti metodi per connettersi a loro in remoto :

  1. Tramite un server (il dispositivo esegue il polling del server)
  2. Accesso remoto diretto che richiede la configurazione manuale di un router di casa per abilitare il port forwarding (o altro modo che espone il dispositivo)
  3. Accesso remoto diretto in cui il dispositivo configura automaticamente il router tramite UPnP o altro protocollo
  4. Accesso remoto diretto utilizzando l' indirizzo IPv6 statico di un dispositivo che non richiede la configurazione del router
  5. Altri metodi

La mia domanda è relativa ai dispositivi IoT di consumo, come lampadine, interruttori della luce, serrature, termometri, ecc. Di produttori fidati che vengono venduti oggi e installati nelle case.

Aggiornare:

Ho trovato questa risposta di @ Aurora0001 ad un'altra risposta su questo sito sulla perforazione per consentire la comunicazione diretta tra 2 dispositivi residenti in diverse reti interne (ad esempio dietro un router domestico). Questa soluzione richiede un server, ma solo per l'handshake iniziale.

Immagino che aggiungerebbe un'altra opzione ...


Domanda interessante. Non sono sicuro se ci saranno statistiche facilmente ottenibili per scoprire le percentuali: ne hai bisogno in particolare o stai solo cercando di capire quali metodi sono più comuni?
Aurora0001

5
Anche MQTT non esegue il polling, apre una connessione persistente al broker e il broker quindi invia i messaggi indietro su quel link
hardillb

1
Immagino che il 99% delle installazioni di quest'anno utilizzerà (1), ma non ho nulla per giustificare l'ipotesi.
Sean Houlihane,

2
@Mawg Ricerca indirizzo inverso. Accedere a un dispositivo a casa mia dal lavoro.
Sean Houlihane,

1
@Perspectivus perché, praticamente non ci sono spese generali per un socket aperto, invia un pacchetto keep-alive molto piccolo (per far sapere al broker che è ancora lì) a una velocità configurabile, che fintanto che è più breve di 15 minuti TCP timeout il socket dovrebbe rimanere aperto indefinitamente.
hardillbb

Risposte:


12

Penso che troverai una percentuale abbastanza alta di "# 5, Altro", perché all'elenco manca una delle architetture IoT consumer più comuni: le comunicazioni indirette tramite un gateway interno.

Tutti gli altri metodi che descrivi presentano degli svantaggi in casa: sono difficili da configurare, non sono sicuri o richiedono molte risorse server costose. Un gateway interno evita tali problemi per i singoli dispositivi, esponendo un solo dispositivo a Internet.

Il gateway tipico ha diversi scopi. Innanzitutto, è un protocollo bridge. I dispositivi wireless utilizzano tutti i tipi di protocolli di comunicazione aperti e proprietari, tra cui Z-Wave, Zigbee, RF dedicata a 900 MHz, RF dedicata a 433 MHz, luce infrarossa, Bluetooth, BLE, ANT +, Crestron, ecc. Questi risolvono tutti i tipi di problemi di nicchia, come costo per dispositivo, durata della batteria, reti mesh autoconfiguranti, tempi di risposta rapidi, comunicazioni non sicure, configurazioni semplici che utilizzano un minimo spazio di archiviazione, ecc. In questo modo la maggior parte dei dispositivi IoT consumer non utilizza pacchetti IP, ma consegna i propri dati all'interno di molti cornici più piccole per preservare la durata della batteria. Il gateway convertirà il protocollo proprietario in qualcosa di più trasportabile e interoperabile con una rete basata su IP.

Inoltre, il gateway interno è un buon posto per archiviare le regole del sistema. Se hai intenzione di abilitare regole come "se accendi la luce in cima alle scale, accendi anche la luce dell'ingresso, a meno che la luce della cucina non sia accesa", puoi posizionare le regole negli interruttori della luce, un sistema centralizzato web server o gateway. Mettere le regole in ogni interruttore della luce rende una configurazione fragile che è difficile da impostare, modificare o gestire. L'esecuzione delle regole in un server centralizzato introduce la latenza perché il messaggio deve essere tradotto in TCP, crittografato, inviato su Internet, l'azione deve essere ricevuta, decrittografata e tradotta in Zigbee. Il gateway consente al fornitore di risolvere questi problemi fornendo un unico punto di gestione per il backup e il ripristino e un processore locale per eseguire rapidamente le regole.

La sicurezza è un grosso problema: i dispositivi IoT devono essere economici e i processori economici non hanno grandi CPU e spazio di archiviazione per funzioni di crittografia sicure. Per non parlare del desiderio di evitare le ingenti spese per lo sviluppo di protocolli crittografati in modo sicuro. Quindi implementano una sicurezza molto debole (economica) nei dispositivi dei consumatori, o nessuna sicurezza. Compensano ciò comunicando solo in un intervallo molto limitato: devono solo raggiungere il gateway interno. In questo modo, il gateway gestisce le comunicazioni non protette locali e solo un dispositivo necessita della potenza di elaborazione e dello spazio di archiviazione necessari per comunicare con il cloud su TLS.

Infine, il gateway può fornire un singolo punto conveniente di interfaccia umana ai dispositivi. La maggior parte dei gateway espone un'interfaccia Web, consentendo la configurazione basata sulla GUI. Immagina di provare a configurare una password WiFi di 12 caratteri in un codice Morse in un dispositivo usando solo un pulsante e un LED. Peggio ancora, immagina che il personale di supporto telefonico della tua azienda parli con ogni cliente attraverso quel processo.

Sfortunatamente, questo non risponde ancora direttamente alla tua domanda. Ma mi aspetto che l'architettura gateway sia il modo più comune in cui i dispositivi orientati al consumatore si connettono a Internet.

EDIT: in risposta al tuo commento sui gateway interni utilizzati per i dispositivi IoT, ci sono alcuni tipi di base: uso singolo dedicato, multiuso dedicato e scopo generale. Oltre alle interfacce seguenti, tutte hanno un'interfaccia Ethernet o WiFi per collegare i messaggi da e verso una rete IP.

Un gateway dedicato monouso parla solo ai dispositivi di un determinato produttore. Gli esempi più semplici potrebbero essere un dongle USB che riceve dati da un singolo dispositivo, come un dongle Fitbit. Altri esempi includono il bridge Philips Hue (che comunica solo con lampadine Philips Hue); Liftmaster MyQ Gateway (che comunica solo con gli apriporta per garage Liftmaster, Chamberlain o Craftsman); o Harmony Hub (che comunica con i telecomandi Logitech Harmony e fa lampeggiare IR ai vari componenti dell'home theater.)

Un esempio dell'hub multiuso dedicato sarebbe l'hub SmartThings di Samsung. SmartThings vende un'ampia varietà di dispositivi di automazione domestica, ma parlano solo il protocollo SmartThings. L'hub SmartThings può anche comunicare con molti altri controller di dispositivo tramite IP e ha l'integrazione IFTTT nativa.

I gateway per uso generale possono avere alcuni componenti proprietari, ma spesso supportano più interfacce e possono fungere da interfaccia principale per la casa intelligente. Gli esempi includono Wink Hub (che comunica con i dispositivi Zigbee, Z-Wave, Lutron e Kidde RF); Vera Edge (che comunica con i dispositivi Z-Wave e Insteon e si estende per comunicare con dispositivi esterni).

Infine, ci sono anche alcuni sforzi open source molto attivi nel dominio della domotica per uso generale, inclusi Domoticz e OpenHAB. Si tratta di programmi software che supportano la comunicazione con dispositivi IoT tramite dispositivi bridge dedicati (come un dongle USB Z-Wave o una radio Zigbee), implementano regole e offrono ampie funzionalità di integrazione come IFTTT, MQTT e altri.


Grazie John Potete fornire riferimenti ad articoli generali su o ad esempi specifici di tali gateway interni?
Perspectivus,

8

Praticamente tutti i prodotti di consumo che funzionano in questo modo richiedono un server esterno per mediare l'invio di messaggi da un dispositivo esterno a un dispositivo specifico in casa. Anche nel caso più ovvio di esporre la porta 22 sul tuo Raspberry Pi, hai ancora (generalmente) un servizio DNS dinamico.

  1. Il dispositivo avvia e mantiene una connessione persistente con il server. Ciò non richiede alcuna configurazione del router, a condizione che il router fornisca l'accesso https al Web ...

Per tutti gli altri metodi, il dispositivo portatile remoto deve essere in grado di trovare il dispositivo interno. I protocolli peer to peer a volte utilizzeranno il port forwarding poiché hanno il desiderio di evitare un'architettura client-server.

È inoltre possibile che un sistema apra una porta in entrata utilizzando UPnP, ma ciò non dovrebbe essere necessario per le applicazioni IoT. Ciò potrebbe applicarsi alle applicazioni di gioco legacy, ma cade non appena è presente più di un nodo su un IP pubblico.

Sebbene IPv6 consenta di associare una coppia di dispositivi, oggi molte reti non supportano IPv6 end-to-end. È necessario un server, indipendentemente dal fatto che fornisca gli aggiornamenti del firmware (a meno che il dispositivo non sia obsoleto prima di essere venduto).

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.