Di cosa ho bisogno per creare il mio cloud personale per i dispositivi IoT?


18

Questo è un argomento a cui ho pensato per un po ', soprattutto perché il concetto di "IoT" è stato molto diffuso negli ultimi tempi.

Inizierò con ciò che intendo quando dico "IoT" . So che il termine IoT potrebbe significare cose diverse e che a volte viene utilizzato in modo improprio. Potrebbe essere un termine che non è chiaramente definito e può portare a grandi discussioni su cosa significhi esattamente, io stesso non conosco la definizione corretta e ampiamente accettata del termine. Quindi per me l'IoT è un concetto, un concetto che definisce la capacità di connettersi a un dispositivo incorporato in remoto tramite Internet o da un altro dispositivo incorporato o da un telefono cellulare . Così semplice.

In questo contesto, lo scopo della connessione non ha importanza, se è possibile connettere un dispositivo nel proprio ufficio con un altro a casa o se è possibile connettersi a un dispositivo a casa dal proprio telefono cellulare, tutto questo tramite Internet, quindi stiamo parlando di dispositivi IoT (i dispositivi integrati, non il telefono).

Quindi, dopo aver concordato cosa intendo per IoT, ora descriverò ciò che sto cercando di ottenere.

Quello che sto cercando di ottenere è proprio quello che descrivo nella mia definizione di IoT.

Voglio avere uno o più dispositivi integrati a casa collegati al mio router Internet, tramite Ethernet o Wi-Fi ed essere in grado di connettersi a loro in remoto con altri dispositivi incorporati in una posizione remota (e per telecomando intendo non sulla stessa rete) e forse anche per essere in grado di connettersi a loro con un'app di monitoraggio sul mio telefono

Ad esempio, potrei avere un semplice dispositivo incorporato che funge da interruttore di accensione / spegnimento collegato al mio apriporta del garage e un altro dispositivo incorporato che funge da grande pulsante rosso sulla mia scrivania al lavoro in modo da poter premere il pulsante rosso sulla mia scrivania e la porta del garage si apre.

Un altro esempio potrebbe essere quello di avere un dispositivo incorporato con funzionalità ADC in grado di monitorare la temperatura di casa mia e inviarmi un avviso quando raggiunge una soglia. La notifica potrebbe essere ricevuta da una semplice app Android o da un altro dispositivo incorporato con un piccolo schermo seduto sulla mia scrivania al lavoro.

Questi esempi possono essere sciocchi ma sono solo per illustrare i possibili scenari e i casi d'uso per quello che sto cercando di ottenere. Alla fine, l'idea è la stessa, collegare un dispositivo incorporato con un altro tramite Internet.

Un'altra cosa da chiarire è che lo scambio di dati tra questi dispositivi sarà molto leggero, solo un paio di byte ogni volta, non è necessario scambiare centinaia di kilobyte tra i dispositivi.

Inoltre, il tipo di "dispositivi incorporati" a cui mi riferisco sono dispositivi semplici ma capaci basati su microcontrollori cortex-m4 da 100 MHz o 200 MHz. E questo è importante chiarire perché non ci saranno librerie Linux o complesse in esecuzione su quei dispositivi. Alla fine, è un tale spreco di risorse e completamente inutile avere un potente processore che esegue Linux solo per accendere e spegnere una lampadina . In ogni caso, sto pianificando di utilizzare un BeagleBoard, un Raspberry Pi o qualsiasi altra scheda simile come dispositivi integrati. Solo microcontrollori perché non è necessaria più complessità di quella.

Non so molto sulle piattaforme IoT e su quei tipi di soluzioni complesse là fuori. Quando ho iniziato questo viaggio alla ricerca di un modo per connettere un dispositivo incorporato a un altro tramite Internet, mi sono imbattuto in un paio di siti con servizi IoT.

So che ci sono alcuni servizi cloud IoT come:

Solo per citarne alcuni. I problemi principali con questi sono costi e complessità. Devi pagare per ottenere quei servizi e devi anche imparare come implementare tutti i servizi che hanno, nel caso in cui ne avessi bisogno, le loro API e forse un sacco di altre cose che non mi sembrano necessarie in grado di scambiare alcuni byte tra i dispositivi. Voglio solo qualcosa di più semplice di quello, qualcosa che posso fare da solo.

Puoi dire che implementare il mio "cloud", se è qualcosa che devo fare, non è semplice e talvolta è meglio usare quel tipo di servizi per semplicità, ma ci sono due ragioni principali che voglio sapere come implementare i miei servizi IoT.

Il motivo principale è che voglio farlo da solo. Non voglio fare affidamento su terzi per collegare i miei dispositivi tra loro e poiché svilupperò il codice e l'hardware per i miei dispositivi, è meglio creare anche i miei mezzi per collegarli come dispositivi IoT.

Il secondo motivo è imparare come farlo. Conoscendo tutte le cose necessarie di cui ho bisogno per raggiungere questo obiettivo, avrò una migliore comprensione del mondo dell'IoT.

Inoltre, voglio menzionare che sono abile in C e uso Linux come il mio sistema operativo quotidiano al lavoro e a casa mia, quindi per favore evita roba di Windows perché questo è inutile per me. Non ho paura di tutto ciò che devo implementare in C per i miei dispositivi embedded o su Linux per implementare tutto ciò che è necessario per raggiungere il mio obiettivo.

Quindi la mia domanda è: che cosa è necessario implementare e dove, per poter connettere due o più dispositivi embedded tra loro allo scopo di scambiare dati tra loro?

Questa domanda Cosa posso usare per creare un IoT sul nostro server? avere qualcosa di simile ma è chiuso e non ha risposte, presuppone anche che venga utilizzata un'infrastruttura cloud già esistente. Quindi non mi aiuta.

Quest'altro post Quali servizi IoT sono disponibili per archiviare / inviare / pubblicare dati generici nel cloud? ha una domanda simile ma l'OP chiede esplicitamente servizi IoT e sto cercando di evitarli.


2
In che modo un server è una "infrastruttura cloud esistente"? Un server è solo un computer. Un'infrastruttura cloud è molto di più.
user253751

1
Inoltre, quando abbiamo un IPv6 onnipresente potresti essere in grado di far dialogare i tuoi dispositivi IoT direttamente tra loro, senza bisogno di un server / cloud centrale.
user253751

Risposte:


10

Forse ho perso il punto della domanda, ma penso che questo sia un buon inizio per una risposta.

Hai bisogno di almeno tre cose.

  1. Un nodo di calcolo sempre attivo per aggregare i tuoi dati. Questo non deve essere potente, potrebbe essere un processo in esecuzione sul NAS o addirittura (in teoria) sul router. Per semplicità, supponiamo che sia un Raspberry Pi. Ciò potrebbe anche fornire eventuali protocolli radio fantasiosi che deciderai di supportare in futuro. Sebbene in teoria sia possibile eseguire peer-to-peer con tutti i nodi esposti a Internet, è più semplice nominarne uno come master e far sì che questo gestisca la raccolta e la pubblicazione dei dati (per l'app / l'utente). Naturalmente, anche l'hub può essere un nodo, in particolare se si utilizzano nodi WiFi moderatamente potenti.
  2. Uno stack software adatto per consentire agli endpoint di inviare i propri dati al nodo hub. è il genere di cose necessarie qui, oltre a un sistema operativo su cui eseguirlo.
  3. DNS e port forwarding per facilitare l'accesso al tuo server da Internet.

Quindi non dimenticare la sicurezza. In questo modo, sarai più vicino ad aprire tutto sulla tua rete domestica per attaccare. Forse solo un po ', ma è bene essere consapevoli del rischio. Puoi provare a prenderti cura, ma supponi che commetterai errori.


1
Non sono sicuro che questa sia la risposta che volevi. Dovrebbe aiutare a capire cosa devi chiedere però.
Sean Houlihane,

1
Grazie dell'aiuto!! Quindi, cosa intendi nel tuo primo punto è che ho bisogno di una sorta di hub o gateway?
m4l490n,

1
Sì, hai bisogno di un gateway, o più di uno. Se hai un solo nodo, questo potrebbe ovviamente essere il tuo nodo. Ho modificato un po 'la mia risposta.
Sean Houlihane,

11

Dispositivi leggeri e tassi di data di un paio di byte richiedono l'utilizzo di MQTT , come è già stato menzionato. I nodi del sensore potrebbero essere basati su moduli ESP8266 autonomi che sono abbastanza potenti da ospitare un'implementazione client MQTT. Oppure puoi semplicemente usare questi moduli come modulo Wi-Fi controllato da comando AT insieme ai tuoi microcontrollori esterni.

Puoi implementare la tua soluzione MQTT su microcontrollori molto meno potenti come questo tizio che ha usato un Atmega48V con 4 kB di flash .

Puoi ospitare un broker sul tuo computer, anche se invece sarebbe più efficiente dal punto di vista energetico eseguire un Raspberry Pi. Ancora una volta, se ti piace la programmazione, puoi implementare il tuo broker MQTT. Personalmente ho trovato Mosquitto eccezionale per questo scopo.

Svantaggio che tutti i nodi del sensore avrebbero bisogno della connessione TCP / IP.


La soluzione a batteria potrebbe essere quella di utilizzare i nodi sensore / attuatore abilitati LoraWAN o ZigBee e implementare un gateway su un Raspberry / BeagleBone che può ospitare anche un semplice server Web a cui è possibile accedere dal telefono o da altri dispositivi.


In ogni caso, tutto si riduce per rendere il tuo hub, gateway o server accessibile al di fuori della tua rete privata. Esistono altri modi per farlo e la preoccupazione principale è sempre la sicurezza. Questa è la parte più rischiosa secondo me.

I requisiti di base sono riassunti abbastanza bene da @Sean.


Secondo la tua risposta e la risposta di @ Sean, vedo che ho bisogno di una sorta di hub o gateway. È assolutamente necessario? Voglio dire, non posso semplicemente collegarmi direttamente a qualsiasi nodo sapendo che è l'indirizzo IP o il nome host? Non è che sto cercando di evitare un hub o gateway, voglio solo capire se è necessario e perché. Grazie dell'aiuto!!
m4l490n,

Hai scoperto che Raspberry Pi è perfetto come dispositivo "sempre attivo"? Ho un piccolo HDD collegato al mio Pi che utilizzo come memoria di rete ma esito a lasciarlo sempre acceso. Va bene se lo faccio? (FWIW ho dei piccoli dissipatori di calore)
BruceWayne,

1
@ m4l490n L'uso di un hub o gateway rende più semplice. In questo modo è necessario impostare il port forwarding o tale solo per l'hub o il gateway. Se si desidera connettersi direttamente a tutti i dispositivi dietro il router, ad esempio è necessario impostare il port forwarding per ciascuno di essi. Più rischi quando si aprono più vie nella propria rete privata e più lavoro.
Bence Kaulics,


10

Hai messo in dubbio entrambe le risposte precedenti sulla necessità di un controller / hub. Considera che per far accadere le cose, hai bisogno di regole per esistere. Se si desidera premere un grande pulsante rosso per aprire una porta del garage, alcune regole devono legare il sensore (pulsante) all'azione desiderata (apertura della porta). Esistono due modi per farlo accadere: puoi inserire la regola direttamente nel pulsante oppure puoi inserire la regola in un computer separato.

Pensiamo di più alla soluzione diretta. Se insegnate il pulsante sulla porta del garage, il pulsante contiene le regole internamente. Il pulsante richiede l'ID della porta del garage, quindi se si sostituisce la porta del garage, il pulsante non funziona. Se il pulsante si trova sulla tua scrivania e la tua casa utilizza una rete proprietaria, il pulsante deve conoscere sia l'indirizzo del gateway di casa sia l'indirizzo della porta. Il pulsante deve conoscere il protocollo specifico per segnalare l'apertura della porta: tutti i produttori producono pulsanti compatibili che conoscono tutti i segnali della porta? Il pulsante non può fare nient'altro a meno che non lo si riprogrammi: si dispone di un programmatore flash per il chip del pulsante in posa, e quel programmatore è compatibile con altri dispositivi? Se vuoi che la porta del garage si apra e 5 minuti dopo si chiuda, il tuo pulsante ha bisogno di tutte le complessità per mantenere un orologio in tempo reale. Il tuo pulsante non conoscerà lo stato della porta, rendendo difficile sapere se stai chiudendo la porta o aprendola. E come si esegue il backup delle regole in modo che se il pulsante si rompe, il pulsante di sostituzione può fare il lavoro? Tra i lati positivi, sembra economico: non è necessario un computer separato.

Con un controller, le cose sono diverse. Tutti i messaggi da tutti i sensori vengono recapitati al controller. Ogni sensore è semplice: invia il segnale al controller. Il controller può quindi applicare tutti gli input necessari a regole molto complesse: può controllare il sensore di sole e non accendere le luci esterne a meno che non sia buio, o non far funzionare gli irrigatori se la piovosità media per il mese è superiore alla media e la temperatura attuale è di cinque gradi inferiore alla media. Il controller può tenere traccia dello stato. Questo potrebbe essere importante se vuoi un pulsante "Chiudi la porta del garage" ma non un pulsante "Apri la porta del garage" (quando sono lontano da casa, raramente voglio aprire la porta, ma sicuramente voglio chiuderla se lo è lasciato accidentalmente aperto.)

Il controller può fornire il posto ai driver di dispositivo che sanno ascoltare i pulsanti e altri driver che sanno parlare alle porte. Il controller potrebbe essere più aggiornabile a nuovi dispositivi e tipi di dispositivo rispetto a un piccolo chip nascosto all'interno di un pulsante.

Il controller può anche avere una logica più complessa per le attività di infrastruttura come la consegna di messaggi offrendo determinati livelli di servizio. Ad esempio, il protocollo MQTT consente tre diversi livelli: prova a consegnare il messaggio una volta, consegnalo ripetutamente fino a quando non viene visto almeno una volta o consegnalo una volta e una sola volta.

Il controller offre una posizione architettonicamente logica per consolidare tutta la messaggistica da e verso un gateway di comunicazione, consentendo l'utilizzo di un'interfaccia esterna. Ciò significa che il pulsante e il telefono possono entrambi inviare segnali e le regole possono capire che uno dei due è autorizzato ad aprire la porta del garage. Il gateway può anche fornire la sicurezza. Non è necessario mettere il pulsante e la porta del garage su Internet; puoi metterli entrambi su reti isolate private e usare il gateway per trasportare i segnali. Il controller fornisce anche un unico punto per eseguire il backup di tutte le regole del sistema.

Gli svantaggi del controller sono la latenza aggiunta e la complessità aggiuntiva. Sorprendentemente, un controller non fa aumentare sensibilmente i costi. È possibile implementare un controller su un Raspberry Pi a un costo inferiore al costo di un interruttore della luce controllabile a distanza medio. Non scartare l'idea sulla base del solo costo.


Bene, sembra che avere un HUB o un controller sia altamente desiderabile, soprattutto se ho bisogno di una funzionalità basata su regole su tutti i miei dispositivi IoT che potrebbe consentire di ottenere il massimo da tutta la rete.
m4l490n,

Quindi, se ho capito bene, posso avere una connessione peer-to-peer a condizione che non ho bisogno di regole complesse o anche di una complessa rete di dispositivi IoT e questo presupporrà anche che i dispositivi IoT non avranno alcuna interoperabilità con altre marche e che ad esempio un pulsante saranno sempre legate allo stesso apriporta.
m4l490n,

Altrimenti, se sono necessarie maggiore flessibilità e funzionalità, allora dovrei avere un HUB. È corretto?
m4l490n,

Sì, è un riassunto accurato. Praticamente tutti finiscono per aver bisogno di una sorta di hub / controller. Ci sono molte opzioni per gli hub, sia commerciali che open source.
John Deters,
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.