Sensore di temperatura e umidità WiFi IoT. Parte: 8 IoT, Domotica: 9 passaggi

2024 Autore: John Day | [email protected]. Ultima modifica: 2024-01-30 10:04

Preambolo

Questo articolo documenta la pratica robustezza e lo sviluppo successivo di un precedente Instructable: "Pimping" del tuo primo dispositivo WiFi IoT. Parte 4: IoT, automazione domestica comprese tutte le funzionalità software necessarie per consentire l'implementazione di successo in un ambiente domestico domestico.

introduzione

Come accennato in precedenza, questo Instructable descrive l'unione di un precedente esempio di IoT con un design di sistemi affidabile che consente la corretta gestione di casi d'uso pratici come; Perdita di potenza catastrofica, guasto del broker MQTT, guasto WiFi N/W, riconfigurazione del sensore remoto, strategia di reporting configurabile per ridurre il traffico di rete e calibrazione del sensore su misura.

Sono stati creati un totale di 6 dispositivi off (vedi foto 1 sopra) e distribuiti in tutta la mia casa per formare la mia prima rete di sensori IoT.

The Instructable vede anche una revisione della convenzione di denominazione MQTT utilizzata nella serie iniziale di automazione domestica IoT, lasciando il posto a una struttura più equilibrata e pratica che consente il debug più semplice del traffico IoT in un ambiente multi dispositivo IoT.

Di seguito sono riportati i dettagli di progettazione completi del sensore IoT, inclusi; costruzione, codice sorgente, strategia di test e configurazioni OpenHAB.

Di quali parti ho bisogno?

1. 1 sconto su ESP8266-01,
2. 2 condensatori elettrolitici da 1uF,
3. 3 resistenze da 10K,
4. 1 off 330R resistore,
5. 1 fuori 3mm dia. GUIDATO,
6. 1 off LD1117-33v, 3v3 LDO VReg. (Farnell qui),
7. 1 sensore di temperatura/umidità DHT22,
8. 1 connettore doppio a 4 vie da 0,1 ",
9. 1 su CAMDENBOSS RX2008/S-5 Custodia in plastica, scatola per vasi, ABS, 38 mm, 23 mm (Farnell qui),
10. 1 connettore di alimentazione CC, spina, 1 A, 2 mm, montaggio a pannello (Farnell qui),
11. 1 off TO-220 Dissipatore di calore 24,4 °C/W (Farnell qui),
12. Vari tubi termorestringenti (giallo, Ebay qui),
13. Cavo a nastro IDC di varie lunghezze,
14. Composto del dissipatore di calore,
15. Veroboard,
16. Dispositivo di programmazione ESP8266-01. Vedere qui; Costruzione pratica di circuiti con strip board, dal passaggio 9 in poi.

Di che software ho bisogno?

1. Arduino IDE 1.6.9
2. Arduino IDE configurato per programmare ESP8266-01. Vedere qui; Configurazione dell'IDE Arduino per programmare ESP8266-01

Di quali strumenti ho bisogno?

1. Saldatore,
2. Trapano e punte varie,
3. File,
4. seghetto,
5. Vizio robusto,
6. pistola termica,
7. DMM.

Di quali competenze ho bisogno?

1. Una conoscenza minima dell'elettronica,
2. Conoscenza di Arduino e del suo IDE,
3. Abilità rudimentali di fabbricazione (saldatura, segatura, limatura, perforazione ecc.),
4. un po' di pazienza,
5. Una certa comprensione della tua rete domestica.

Argomenti trattati

1. Panoramica del circuito
2. Panoramica del sistema software
3. Panoramica del software
4. Calibrazione del sensore
5. Convenzione di denominazione degli argomenti MQTT
6. Configurazione OpenHAB
7. Testare il design
8. Conclusione
9. Riferimenti utilizzati

Link di serie

Alla parte 7: Studio del controller delle luci (rielaborato). Parte 7: IoT, automazione domestica

Alla Parte 9: Controller di rete IoT. Parte 9: IoT, automazione domestica

Passaggio 1: panoramica del circuito

L'immagine 1 sopra mostra il progetto completo del circuito per il sensore IoT.

Il cuore del dispositivo IoT è l'ESP8266-01 che è collegato a un sensore di temperatura/umidità DHT22 tramite un resistore di pull-up da 10K a GPIO2. Un 5v esterno viene fornito con un alimentatore in modalità commutata e alimentato al dispositivo tramite una presa per montaggio a pannello CC da 2 mm e regolato localmente con un regolatore di tensione LDO LD1117-33v, 3v3 montato su un dissipatore di calore esterno con una vite a testa bombata BZP M3 e un dado.

Il design include un led rosso da 3 mm collegato a GPIO0 che viene utilizzato per fornire un'indicazione locale dello stato del dispositivo IoT durante l'avvio o qualsiasi successiva condizione di errore. Può anche essere utilizzato per identificare il dispositivo mediante attivazione manuale tramite l'interfaccia openHAB.

Il design completo si inserisce perfettamente in una scatola di impregnazione in ABS come mostrato sopra nella figura 2 ed è stato disposto specificamente per garantire che il sensore sia il più lontano possibile dal regolatore per evitare la distorsione dovuta agli effetti di riscaldamento locale (figura 7 sopra).

Il circuito stampato è un unico pezzo di veroboard, tagliato su misura e realizzato per adattarsi all'involucro (figura 3 sopra). Questa scheda è fissata in posizione con una vite in nylon a testa svasata M3 e due dadi che si adattano a filo con la parte inferiore del sensore, consentendogli così di sedersi su una superficie piana.

Le immagini 4 … 6 mostrano vari stati di costruzione.

Passaggio 2: panoramica del sistema software

Questo dispositivo di rilevamento della temperatura e dell'umidità IoT contiene sei componenti software chiave come mostrato nella figura 1 sopra.

SPIFFS

Questo è il sistema di archiviazione flash SPI integrato e viene utilizzato per contenere le seguenti informazioni (vedi foto 2 sopra);

• Icone e 'Home Page di configurazione del sensore' html: Servito dal dispositivo IoT quando non è in grado di connettersi alla rete WiFi IoT (di solito a causa di informazioni di sicurezza errate) e fornisce all'utente un mezzo per configurare il sensore da remoto senza la necessità per riprogrammare o caricare nuovi contenuti SPIFFS.
• Informazioni sulla sicurezza: conserva le informazioni utilizzate all'accensione dal dispositivo IoT per connettersi alla rete WiFi IoT e al broker MQTT. Le informazioni inviate tramite la 'Home Page di configurazione del sensore' vengono scritte in questo file ('secvals.txt').
• Informazioni sulla calibrazione: le informazioni contenute in questo file ('calvals.txt') vengono utilizzate per calibrare il sensore di temperatura/umidità di bordo qualora fosse necessario. Le costanti di calibrazione possono essere scritte sul dispositivo IoT solo tramite comandi MQTT da un broker MQTT.

Nota: per configurare inizialmente il dispositivo, vedere qui per tutti i dettagli su come utilizzare SPIFFS con l'IDE Arduino.

Server mDNS

Questa funzionalità viene invocata quando il dispositivo IoT non è riuscito a connettersi alla tua rete WiFi come stazione WiFi e invece è diventato un punto di accesso WiFi simile a un router WiFi domestico. Nel caso di un router di questo tipo, ti connetteresti in genere inserendo l'indirizzo IP di qualcosa come 192.168.1.1 (di solito stampato su un'etichetta apposta sulla scatola) direttamente nella barra degli URL del tuo browser, dopodiché riceverai una pagina di accesso da inserire il nome utente e la password per consentire di configurare il dispositivo.

Per ESP8266 in modalità AP (modalità Access Point) il dispositivo ha l'indirizzo IP predefinito 192.168.4.1, tuttavia con il server mDNS in esecuzione è sufficiente inserire il nome descrittivo "SENSORSVR.local" nella barra dell'URL del browser per vedere il 'Pagina iniziale di configurazione del sensore'.

Cliente MQTT

Il client MQTT fornisce tutte le funzionalità necessarie a; connettiti al tuo broker MQTT di rete IoT, iscriviti agli argomenti di tua scelta e pubblica payload su un determinato argomento. In breve, fornisce funzionalità di base IoT.

Server Web

Come accennato in precedenza, se il dispositivo IoT non è in grado di connettersi alla rete WiFi il cui SSID, P/W ecc. è definito nel file Security Information contenuto in SPIFFS il dispositivo diventerà un Access Point. Una volta connesso alla rete WiFi fornita dall'Access Point, la presenza di un Web Server HTTP consente di connettersi direttamente al dispositivo e modificarne la configurazione tramite l'utilizzo di un Web Browser HTTP, lo scopo è quello di servire la "Sensor Configuration Home" Pagina web della pagina che si trova anche in SPIFFS.

Stazione WiFi

Questa funzionalità offre al dispositivo IoT la possibilità di connettersi a una rete WiFi domestica utilizzando i parametri nel file Informazioni sulla sicurezza, senza questo il dispositivo IoT non sarà in grado di iscriversi/pubblicare al Broker MQTT

Punto di accesso WiFi

La possibilità di diventare un Access Point WiFi è un mezzo attraverso il quale il dispositivo IoT consente di connettersi ad esso e apportare modifiche alla configurazione tramite una stazione WiFi e un browser (come Safari sull'iPad di Apple).

Questo punto di accesso trasmette un SSID = "SENSOR" + le ultime 6 cifre dell'indirizzo MAC del dispositivo IoT. La password per questa rete chiusa è fantasiosamente denominata "PASSWORD"

Passaggio 3: panoramica del software

Preambolo Per compilare con successo questo codice sorgente avrai bisogno delle seguenti librerie extra;

PubSubClient.h

• Di: Nick O'Leary
• Scopo: consente al dispositivo di pubblicare o sottoscrivere argomenti MQTT con un determinato broker
• Da:

DHT.h

• Di: Adafruit
• Scopo: libreria per sensore di temperatura/umidità DHT
• Da:

Panoramica del codice

Il software utilizza la macchina a stati come mostrato nella figura 1 sopra (copia completa della fonte fornita di seguito). Ci sono 5 stati principali come di seguito;

• DENTRO

  Questo stato di inizializzazione è il primo stato in cui si entra dopo l'accensione

• NOCONFIG

  Questo stato viene inserito se dopo l'accensione viene rilevato un file secvals.txt non valido o mancante

• IN ATTESA NO

  Questo stato è transitorio, inserito mentre non esiste una connessione di rete WiFi

• MQTT. IN ATTESA

  Questo stato è transitorio, inserito dopo che è stata effettuata una connessione di rete WiFi e mentre non esiste alcuna connessione a un broker MQTT su quella rete

• ATTIVO

  Questo è il normale stato operativo a cui si accede una volta stabilita sia una connessione di rete WiFi che una connessione MQTT Broker. È durante questo stato che la funzionalità di temperatura e umidità del sensore viene pubblicata sul broker MQTT

Gli eventi che controllano le transizioni tra gli stati sono descritti nella figura 1 sopra. Le transizioni tra gli stati sono inoltre regolate dai seguenti parametri SecVals;

• Primo indirizzo IP del broker MQTT. In forma decimale puntata AAA. BBB. CCC. DDD
• 2a porta broker MQTT. In forma intera.
• 3° tentativo di connessione al broker MQTT prima di passare dalla modalità STA alla modalità AP. In forma intera.
• 4° SSID di rete WiFi. Nel testo in forma libera.
• 5a password di rete Wi-Fi. Nel testo in forma libera.

Come accennato in precedenza, se il dispositivo IoT non è in grado di connettersi come Stazione WiFi alla rete WiFi il cui SSID e P/W è definito in secvals.txt contenuto in SPIFFS il dispositivo IoT diventerà un punto di accesso. Una volta connesso a questo punto di accesso, servirà la "Home Page di configurazione del sensore" come mostrato sopra nella figura 2 (immettendo "SENSORSVR.local" o 192.168.4.1 nella barra degli indirizzi URL del browser). Questa home page consente la riconfigurazione del sensore tramite un browser

Accesso remoto in stato ATTIVO

Una volta connesso al Broker MQTT è inoltre possibile sia ricalibrare che riconfigurare il dispositivo tramite pubblicazioni tematiche MQTT. Il file calvals.txt ha accesso R/W e secvals.txt ha accesso di sola scrittura esposto.

Debug utente

Durante la sequenza di avvio il led del dispositivo IoT fornisce il seguente feedback di debug

• 1 Flash breve: nessun file di configurazione situato in SPIFFS (secvals.txt)
• 2 lampeggi brevi: il dispositivo IoT sta tentando di connettersi alla rete WiFi
• Illuminazione continua: il dispositivo IoT sta tentando di connettersi a MQTT Broker
• Spento: il dispositivo è attivo
• Nota 1: La 'Pagina iniziale di configurazione del sensore' non utilizza socket protetti e quindi si basa sulla sicurezza della rete.
• Nota 2: per programmare ogni dispositivo IoT, la stringa MQTT richiederà la modifica prima del download. Questo perché il numero del sensore è stato incorporato nella stringa dell'argomento MQTT. cioè. 'WFD/THSen/100/HumdStatus/1' per i miei 6 dispositivi sono numerati rispettivamente 1…6.

Passaggio 4: calibrazione del sensore

Quando il dispositivo IoT si accende, come parte della sequenza di avvio, viene letto da SPIFFS un file denominato "cavals.txt". I contenuti di questo file sono costanti di calibrazione come indicato sopra nella figura 1. Queste costanti di calibrazione vengono utilizzate per regolare le letture acquisite dal sensore per allinearle con un dispositivo di riferimento. C'è un ulteriore valore che definisce una strategia di reporting per il dispositivo ed è descritto di seguito insieme alla procedura seguita per calibrare i sensori.

Reporting StrategyQuesto parametro determina il modo in cui il sensore remoto segnala eventuali modifiche parametriche ambientali locali ad esso. Se viene selezionato il valore 0, il sensore remoto pubblicherà ogni modifica rilevata nei valori di temperatura o umidità ogni volta che viene letto il sensore (ogni 10 secondi circa). Qualsiasi altro valore ritarderà la pubblicazione di una modifica di 1…60 minuti. La modifica di questo parametro consente l'ottimizzazione del traffico di rete MQTT.

Calibrazione della temperatura

Per calibrare i sensori sono stati collocati in stretta vicinanza fisica l'uno con l'altro come mostrato sopra nella foto 2. Accanto a loro ho posizionato un DMM con una termocoppia calibrata collegata (Fluke 87 V) e quindi monitorato le uscite di ciascun dispositivo tramite la temperatura OpenHAB pagina delle tendenze nel corso di una giornata per ottenere un buon sbalzo di temperatura. Ho annotato sia l'offset statico (zero elevato 'C') che la velocità di variazione di ciascun dispositivo (guadagno, o pendenza del grafico 'M') rispetto a quello del valore proveniente dalla termocoppia calibrata. Ho quindi calcolato la semplice relazione y=mx+c (ho scoperto che era sufficientemente lineare da essere un'approssimazione di un grafico a linee rette) e programmato le correzioni necessarie nelle costanti di calibrazione tramite MQTTSpy.

I dispositivi sono stati quindi monitorati per altre 24 ore per garantire che la calibrazione fosse corretta. Un'indicazione di ciò era che le tracce della temperatura sulla pagina delle tendenze della temperatura di OpenHAB erano tutte praticamente una sopra l'altra.

Ovviamente se ti interessa solo un'approssimazione della temperatura puoi lasciare tutti i valori di calibrazione come default.

Calibrazione dell'umidità

Poiché non possiedo alcun mezzo per registrare accuratamente o anche controllare l'umidità ambientale locale, per calibrare i sensori ho utilizzato un approccio simile a quello di cui sopra, posizionando tutti i dispositivi in stretta vicinanza fisica (foto 2) e semplicemente monitorando la loro uscita tramite OpenHAB Umidità tende pagina. Ho quindi scelto il dispositivo n. 1 come riferimento di calibrazione e ho calibrato tutti i dispositivi relativi a questo.

Passaggio 5: Convenzione di denominazione degli argomenti MQTT

Dopo molti tentativi ed errori, ho optato per la convenzione di denominazione dell'argomento delineata nella foto 1 sopra.

Vale a dire, "Metodo di accesso/Tipo di dispositivo/Quale dispositivo/Azione/Sottodispositivo"

Non è perfetto ma consente l'applicazione di filtri utili per vedere tutte le uscite del sensore per un dato valore parametrico, consentendo così un facile confronto come nella foto 2 sopra con MQTTSpy. Supporta anche raggruppamenti logici ragionevolmente estensibili di funzionalità all'interno di un determinato dispositivo IoT.

Nell'implementare questi argomenti nel software ho utilizzato stringhe di argomenti codificate con identificatori numerici fissi e incorporati per ciascun dispositivo anziché generare dinamicamente gli argomenti in fase di esecuzione in modo da risparmiare sulla RAM e mantenere alte le prestazioni.

Nota: se non sei sicuro di come utilizzare MQTTSpy, consulta qui Impostazione di un broker MQTT. Parte 2: IoT, automazione domestica'

Passaggio 6: configurazione OpenHAB

Ho modificato la configurazione di OpenHAB fornita nel mio precedente Instructable (qui) e aggiunta in singole voci per;

• Box auto,
• Sala,
• Salotto,
• Cucina
• Stanza degli ospiti
• Camera da letto principale

Nella mappa del sito vedere la foto 1 sopra.

Per ciascuna di queste voci ho aggiunto singole mappe del sito che espongono i valori ambientali locali (vedi foto 2 sopra);

• Temperatura
• Umidità
• Indice di calore

Ho incluso anche un interruttore per controllare il led locale montato all'interno del sensore.

Le immagini 3 …5 mostrano tracce individuali in tempo reale nel periodo di 24 ore per temperatura, umidità e RSSI (Indicazione della potenza del segnale ricevuto, in pratica una misura di quanto bene il sensore può vedere la rete WiFi).

La figura 6 fornisce un esempio di andamento dell'umidità a lungo termine nel periodo di una settimana.

Nota 1: se non sei sicuro di come utilizzare OpenHAB, vedi qui Impostazione e configurazione di OpenHAB. Parte 6: IoT, automazione domestica'

Nota 2: Di seguito viene fornita una copia della mappa del sito modificata, dei file delle regole e degli elementi, delle icone ecc.

Passaggio 7: test del design

Per la maggior parte ho testato il dispositivo IoT sulla connessione MQTT con MQTT Spy, monitorando l'uscita dei led e il debug del traffico sull'interfaccia seriale. Questo mi ha permesso di esercitare tutti gli argomenti sottoscritti disponibili e controllare le risposte pubblicate. Sebbene ciò sia stato ottenuto manualmente e a volte sia diventato un po' noioso, ha consentito una copertura del 100%.

Tuttavia, la macchina a stati principale si è rivelata un po' difficile da testare in quanto si basava sulla presenza o assenza di una rete WiFi, il cui accesso richiedeva set di parametri specifici. Semplicemente non era pratico usare la rete domestica per questo.

Per aggirare questo problema ho creato il mio set di reti fittizie utilizzando ESP8266-01 configurato come punti di accesso (foto 1) con SSID rispettivamente di "DummyNet1" e "DummyNet2". Usando il circuito nella foto 2 sopra il led ha dato un'indicazione se un dispositivo IoT si era connesso ad esso. Sebbene questa non fosse una soluzione di test perfetta (cioè ognuna di queste reti WiFi fittizie non conteneva un server MQTT) è stato possibile testare completamente la macchina a stati.

Ho incluso una copia del codice sorgente di seguito.

Passaggio 8: conclusione

Generale

Il software nei dispositivi IoT ha funzionato in modo affidabile per molti mesi ora recuperando dalle interruzioni di corrente domestica (principalmente causate da me). Nel complesso sono dispositivi piuttosto robusti che forniscono dati coerenti e accurati.

Miglioramenti

Nello sviluppo di routine software per leggere e scrivere su SPIFFS ho scritto codice che a posteriori potrebbe essere un po' più avanzato di quanto avessi voluto, utilizzando puntatori void, rifusione e puntatori a puntatori. Sebbene sia molto flessibile e svolga bene il lavoro, la prossima volta potrei usare JSON qualcosa sulla falsariga di ConfigFile.ino per renderlo un po' più semplice.

• Arduino GIT HUB Core

  https://github.com/esp8266/Arduino

• Sorgente ConfigFile.ino

  https://github.com/esp8266/Arduino/tree/master/libraries/esp8266/examples/ConfigFile

Lista dei desideri

Avevo intenzione di utilizzare un client mDNS per connettermi al Broker, ma la libreria era troppo debole. Questo è il motivo per cui è necessario specificare l'indirizzo IP del broker MQTT anziché 'MQTTSVR.local'. Se la libreria mDNS diventa più stabile in futuro, aggiungerò questa funzionalità al dispositivo.

Sarebbe stato bello avere un mezzo per monitorare e controllare accuratamente l'umidità ambientale per calibrare i sensori. Tuttavia, detto questo, il metodo di calibrazione scelto fornisce buone letture relative e sembra ragionevolmente accurato in linea con le specifiche nella scheda tecnica DHT22.

Infine, data la complessità del software, ho scoperto che testare completamente il codice dopo una modifica importante stava richiedendo molto tempo. Potrei prendere in considerazione test automatizzati in un secondo momento.

Passaggio 9: riferimenti utilizzati

Ho usato le seguenti fonti per mettere insieme questo Instructable;

PubSubClient.h

• Di: Nick O'Leary
• Da:

DHT.h

• Di: Adafruit
• Da:

Scheda tecnica DHT22