WiFi IoT temperatur- og luftfugtighedssensor. Del: 8 IoT, hjemmeautomatisering: 9 trin

2024 Forfatter: John Day | [email protected]. Sidst ændret: 2024-01-30 08:29

Præambel

Denne artikel dokumenterer den praktiske robusthed og videreudvikling af en tidligere Instructable: 'Pimping' din første IoT WiFi -enhed. Del 4: IoT, hjemmeautomatisering inklusive al den nødvendige softwarefunktionalitet for at muliggøre en vellykket implementering i hjemmet.

Introduktion

Som nævnt ovenfor beskriver denne instruktør sammenføjning af et tidligere IoT -eksempel med et pålideligt systemdesign, der muliggør en vellykket håndtering af praktiske anvendelsessager som f.eks. Katastrofalt strømtab, MQTT -mæglerfejl, WiFi N/W -fejl, ekstern sensorkonfiguration, konfigurerbar rapporteringsstrategi for at reducere netværkstrafik og skræddersyet sensorkalibrering.

I alt 6 off -enheder blev oprettet (se billede 1 ovenfor) og distribueret rundt i mit hjem for at danne mit første IoT -sensornetværk.

Instructable ser også en gennemgang af MQTT -navngivningskonventionen, som den blev brugt i den indledende IoT Home Automation -serie, der giver plads til en mere afbalanceret, praktisk struktur, der muliggør enklere fejlfinding af IoT -trafik i et multi IoT -enhedsmiljø.

Det følgende er fulde designdetaljer for IoT -sensoren inklusive; konstruktion, kildekode, teststrategi og OpenHAB -konfigurationer.

Hvilke dele har jeg brug for?

1. 1 fra ESP8266-01,
2. 2 off 1uF elektrolytkondensatorer,
3. 3 off 10K modstande,
4. 1 off 330R modstand,
5. 1 off 3 mm dia. LED,
6. 1 fra LD1117-33v, 3v3 LDO VReg. (Farnell her),
7. 1 off DHT22 temperatur/luftfugtighedssensor,
8. 1 off Dual 4way 0,1 "stik,
9. 1 off CAMDENBOSS RX2008/S-5 Plastic Encase, Potting Box, ABS, 38 mm, 23 mm (Farnell her),
10. 1 off DC -strømstik, stik, 1 A, 2 mm, panelmontering (Farnell her),
11. 1 off TO-220 Heatsink 24,4 ° C/W (Farnell her),
12. Forskellige varmekrympeslanger (gul, Ebay her),
13. Forskellige længder IDC båndkabel,
14. Kølelegeme,
15. Veroboard,
16. ESP8266-01 programmeringsenhed. Se her; Praktisk kredsløbskonstruktion med Strip Board, trin 9 og fremefter.

Hvilken software har jeg brug for?

1. Arduino IDE 1.6.9
2. Arduino IDE konfigureret til at programmere ESP8266-01. Se her; Opsætning af Arduino IDE til programmering af ESP8266-01

Hvilke værktøjer har jeg brug for?

1. Loddekolbe,
2. Bor og forskellige bits,
3. Filer,
4. Hacksav,
5. Robust skruestik,
6. Varmepistol,
7. DMM.

Hvilke færdigheder har jeg brug for?

1. Et minimalt greb om elektronik,
2. Kendskab til Arduino og dens IDE,
3. Rudimentære fremstillingsevner (lodning, hack-savning, arkivering, boring osv.),
4. Noget tålmodighed,
5. En vis forståelse for dit hjemmenetværk.

Emner dækket

1. Kredsløbsoversigt
2. Oversigt over softwaresystem
3. Softwareoversigt
4. Sensorkalibrering
5. MQTT -emnekonvention
6. OpenHAB -konfiguration
7. Test af designet
8. Konklusion
9. Referencer brugt

Serielinks

Til del 7: Study Lights Controller (omarbejdet). Del 7: IoT, hjemmeautomatisering

Til del 9: IoT Mains Controller. Del 9: IoT, hjemmeautomatisering

Trin 1: Oversigt over kredsløb

Billede 1 ovenfor viser hele kredsløbsdesignet for IoT -sensoren.

I hjertet af IoT-enheden er ESP8266-01, som er forbundet til en DHT22 temperatur-/fugtighedsføler via en 10K pull-up-modstand til GPIO2. En ekstern 5v kommer fra en switchet tilstandsforsyning og føres til enheden via en 2 mm DC panelmonteret stikkontakt og reguleres lokalt med en LD1117-33v, 3v3 LDO spændingsregulator monteret på en ekstern køleplade med en BZP M3 panhovedskrue og møtrik.

Designet indeholder en 3 mm rød led forbundet til GPIO0, der bruges til at give lokal indikation af IoT -enhedens status under opstart eller enhver efterfølgende fejltilstand. Det kan også bruges til at identificere enheden ved manuel aktivering via openHAB -grænsefladen.

Det fulde design passer pænt ind i en ABS potteboks som vist ovenfor på billede 2 og blev lagt specielt ud for at sikre, at sensoren er så langt som muligt fra regulatoren for at forhindre forspænding på grund af lokale varmeeffekter (billede 7 ovenfor).

Printkortet er et enkelt stykke veroboard, skåret i form og lavet til at passe ind i kabinettet (billede 3 ovenfor). Dette bræt er fastgjort på plads med en M3 forsænket nylonskrue og to møtrikker, der passer ind i sensorens underside, hvilket gør det muligt at sidde på en flad overflade.

Billeder 4… 6 viser forskellige konstruktionstilstande.

Trin 2: Oversigt over softwaresystem

Denne IoT -temperatur- og fugtighedsregistreringsenhed indeholder seks nøglekonfigurationer som vist på billede 1 ovenfor.

SPIFFS

Dette er det indbyggede SPI Flash Filing System og bruges til at indeholde følgende oplysninger (se billede 2 ovenfor);

• Ikoner og 'Sensor Configuration Startside' html: Betjenes af IoT -enheden, når den ikke kan oprette forbindelse til dit IoT WiFi -netværk (normalt på grund af forkerte sikkerhedsoplysninger) og giver brugeren mulighed for ekstern konfiguration af sensoren uden behov at omprogrammere eller uploade nyt SPIFFS-indhold.
• Sikkerhedsoplysninger: Indeholder de oplysninger, der bruges ved opstart af IoT -enheden til at oprette forbindelse til dit IoT WiFi -netværk og MQTT Broker. Oplysninger indsendt via 'Sensor Configuration Startside' skrives til denne fil ('secvals.txt').
• Kalibreringsoplysninger: Oplysningerne i denne fil ('calvals.txt') bruges til at kalibrere den indbyggede temperatur/fugtighedsføler, hvis det er nødvendigt. Kalibreringskonstanter kan kun skrives til IoT -enheden via MQTT -kommandoer fra en MQTT -mægler.

Bemærk: For først at konfigurere enheden, se her for at få alle oplysninger om, hvordan du bruger SPIFFS med Arduino IDE.

mDNS -server

Denne funktionalitet påberåbes, når IoT -enheden ikke har kunnet oprette forbindelse til dit WiFi -netværk som en WiFi -station og i stedet er blevet et WiFi -adgangspunkt, der ligner en indenlandsk WiFi -router. I tilfælde af en sådan router ville du typisk oprette forbindelse til den ved at indtaste IP -adressen på noget som 192.168.1.1 (normalt trykt på en etiket påsat boksen) direkte i din browsers URL -bar, hvorefter du vil modtage en login -side for at indtaste brugernavnet og adgangskoden, så du kan konfigurere enheden.

For ESP8266 i AP -tilstand (Access Point -tilstand) er enheden standard til IP -adressen 192.168.4.1, men når mDNS -serveren kører, skal du kun indtaste det menneskelige navn 'SENSORSVR.local' i browserens URL -bjælke for at se 'Startside for sensorkonfiguration'.

MQTT -klient

MQTT -klienten giver al den nødvendige funktionalitet til; oprette forbindelse til din IoT -netværk MQTT -mægler, abonnere på de emner, du ønsker, og offentliggøre nyttelast til et givet emne. Det giver kort sagt IoT -kernefunktionalitet.

HTTP -webserver

Som nævnt ovenfor vil enheden blive et adgangspunkt, hvis IoT -enheden ikke kan oprette forbindelse til WiFi -netværket, hvis SSID, P/W osv. Er defineret i sikkerhedsinformationsfilen i SPIFFS. Når den er tilsluttet WiFi -netværket, der leveres af adgangspunktet, giver tilstedeværelsen af en HTTP -webserver dig mulighed for direkte at oprette forbindelse til enheden og ændre dens konfiguration ved hjælp af en HTTP -webbrowser, hvis formål er at betjene 'Sensor Configuration Home Side 'webside, som også findes i SPIFFS.

WiFi -station

Denne funktionalitet giver IoT -enheden mulighed for at oprette forbindelse til et hjemligt WiFi -netværk ved hjælp af parametrene i sikkerhedsinformationsfilen, uden dette vil din IoT -enhed ikke kunne abonnere/udgive til MQTT Broker

WiFi -adgangspunkt

Muligheden for at blive et WiFi -adgangspunkt er et middel, hvorved IoT -enheden giver dig mulighed for at oprette forbindelse til den og foretage konfigurationsændringer via en WiFi -station og en browser (f.eks. Safari på Apple iPad).

Dette adgangspunkt udsender et SSID = "SENSOR" + de sidste 6 cifre i MAC -adressen på IoT -enheden. Adgangskoden til dette lukkede netværk hedder fantasifuldt 'PASSWORD'

Trin 3: Oversigt over software

Preamble For at kunne kompilere denne kildekode skal du bruge følgende ekstra biblioteker;

PubSubClient.h

• Af: Nick O'Leary
• Formål: Gør det muligt for enheden at udgive eller abonnere på MQTT -emner med en given mægler
• Fra:

DHT.h

• Af: Adafruit
• Formål: Bibliotek til DHT temperatur-/fugtighedsføler
• Fra:

Kodeoversigt

Softwaren gør brug af statsmaskinen som vist på billede 1 ovenfor (fuld kopi af kilden angivet nedenfor). Der er 5 hovedtilstande som nedenfor;

• I DET

  Denne initialiseringstilstand er den første tilstand, der indtastes efter opstart

• NOCONFIG

  Denne tilstand indtastes, hvis der efter opstart registreres en ugyldig eller manglende secvals.txt -fil

• VENTENDE NV

  Denne tilstand er forbigående, indtastet, mens der ikke findes nogen WiFi -netværksforbindelse

• VENTENDE MQTT

  Denne tilstand er forbigående, indtastes efter at der er oprettet en WiFi -netværksforbindelse, og mens der ikke findes nogen forbindelse til en MQTT -mægler på dette netværk

• AKTIV

  Dette er den normale driftstilstand, der indtastes, når både en WiFi -netværksforbindelse og en MQTT Broker -forbindelse er etableret. Det er i denne tilstand, temperatur og fugtighedsfunktionalitet for sensoren offentliggøres til MQTT Broker

Begivenhederne, der styrer overgange mellem stater, er beskrevet i billede 1 ovenfor. Overgange mellem stater er også styret af følgende SecVals -parametre;

• 1. MQTT Broker IP -adresse. I stiplet decimalform AAA. BBB. CCC. DDD
• 2. MQTT -mæglerhavn. I heltal form.
• 3. MQTT -mæglerforbindelse forsøger at oprette, før der skiftes fra STA -tilstand til AP -tilstand. I heltal form.
• 4. WiFi -netværks -SSID. I fri form tekst.
• 5. WiFi -netværksadgangskode. I fri form tekst.

Som nævnt ovenfor, hvis IoT -enheden ikke kan oprette forbindelse som WiFi -station til WiFi -netværket, hvis SSID og P/W er defineret i secvals.txt, der opbevares i SPIFFS, bliver IoT -enheden et adgangspunkt. Når den er forbundet til dette adgangspunkt, vil den vise 'Sensor Configuration Home Page' som vist ovenfor i Pic 2 (ved at indtaste enten 'SENSORSVR.local' eller 192.168.4.1 i din browsers URL -adresselinje). Denne hjemmeside tillader omkonfiguration af sensoren via en HTTP -browser.

Fjernadgang, mens den er i AKTIV tilstand

Når den først er forbundet til MQTT-mægleren, er det også muligt at både kalibrere og omkonfigurere enheden via MQTT-emnepublikationer. Filen calvals.txt har R/W -adgang, og secvals.txt har skrivebeskyttet adgang blotlagt.

Brugerfejl

Under opstartsekvensen giver IoT -enheds -LED følgende fejlfindingsfeedback

• 1 Kort flash: Ingen konfigurationsfil findes i SPIFFS (secvals.txt)
• 2 korte blink: IoT -enheden forsøger at oprette forbindelse til WiFi -netværket
• Kontinuerlig belysning: IoT -enhed forsøger at oprette forbindelse til MQTT Broker
• Slukket: Enheden er aktiv
• Bemærk 1: 'Hjemmesiden til sensorkonfiguration' bruger ikke sikre stikkontakter og er derfor afhængig af, at dit netværk er sikkert.
• Note 2: For at programmere hver IoT -enhed skal MQTT -strengen redigeres, før den downloades. Dette skyldes, at sensorens nummer er blevet integreret i MQTT -emnestrengen. dvs. 'WFD/THSen/100/HumdStatus/1' for mine 6 enheder er de nummereret henholdsvis 1… 6.

Trin 4: Sensorkalibrering

Når IoT -enheden tændes, læses en fil med navnet 'cavals.txt' fra SPIFFS som en del af startsekvensen. Indholdet i denne fil er kalibreringskonstanter som angivet ovenfor på billede 1. Disse kalibreringskonstanter bruges til at justere de aflæsninger, der er hentet fra sensoren, for at bringe dem på linje med en referenceenhed. Der er en yderligere værdi, der definerer en rapporteringsstrategi for enheden og er beskrevet nedenfor sammen med den procedure, der følges for at kalibrere sensorerne.

Rapporteringsstrategi Denne parameter bestemmer, hvordan fjernsensoren rapporterer eventuelle parametriske ændringer i omgivelserne lokalt. Hvis der vælges en værdi på 0, vil fjernsensoren offentliggøre enhver ændring, den ser i temperatur- eller fugtighedsværdierne, hver gang sensoren læses (ca. hvert 10. sekund). Enhver anden værdi forsinker offentliggørelsen af en ændring med 1… 60 minutter. Ændring af denne parameter muliggør optimering af MQTT -netværkstrafik.

Temperaturkalibrering

For at kalibrere sensorerne blev de placeret tæt på hinanden som vist ovenfor på billede 2. Ved siden af dem anbragte jeg en DMM med et kalibreret termoelement tilsluttet (Fluke 87 V) og derefter overvåget output fra hver enhed via OpenHAB -temperaturen trendside i løbet af et døgn for at få et godt temperatursving. Jeg noterede mig både den statiske forskydning (forhøjet nul 'C') og ændringshastigheden for hver enhed (forstærkning eller hældning af grafen 'M') i forhold til værdien fra det kalibrerede termoelement. Jeg beregnede derefter det simple y = mx+c forhold (jeg fandt, at det var tilstrækkeligt lineært til at være en nær tilnærmelse til en lige linjediagram) og programmerede eventuelle nødvendige korrektioner i kalibreringskonstanterne via MQTTSpy.

Enhederne blev derefter overvåget i yderligere 24 timer for at sikre, at kalibreringen var vellykket. En indikation af, hvilke temperaturspor der var på OpenHAB -temperaturtrendsiden, var alle stort set oven på hinanden.

Selvfølgelig, hvis du kun er interesseret i en tilnærmelse til temperaturen, kan du efterlade alle kalibreringsværdierne som standard.

Fugtighedskalibrering

Da jeg ikke har nogen midler til nøjagtigt at registrere eller endda kontrollere lokal luftfugtighed, for at kalibrere sensorerne, brugte jeg en lignende fremgangsmåde som ovenstående ved at placere alle enhederne i fysisk nærhed (billede 2) og blot overvåge deres output via OpenHAB Fugtighed tendens side. Jeg valgte derefter enhed nr. 1 som kalibreringsreference og kalibrerede alle enheder i forhold til dette.

Trin 5: MQTT -emnekonvention

Efter meget forsøg og fejl besluttede jeg mig for emnet navngivningskonventionen beskrevet i billede 1 ovenfor.

Nemlig 'AccessMethod/DeviceType/WhichDevice/Action/SubDevice'

Det er ikke perfekt, men det gør det muligt at anvende nyttige filtre for at se alle sensorudgange for en given parametrisk værdi, hvilket giver mulighed for let sammenligning som i billede 2 ovenfor med MQTTSpy. Det understøtter også rimeligt udvidelige logiske grupperinger af funktionalitet inden for en given IoT -enhed.

Ved implementering af disse emner i software brugte jeg hårdt kodede emnestrenge med faste, integrerede numeriske identifikatorer for hver enhed i modsætning til dynamisk at generere emnerne i løbetid for at spare på RAM og holde ydeevnen høj.

Bemærk: Hvis du ikke er sikker på, hvordan du bruger MQTTSpy, se her 'Opsætning af en MQTT -mægler. Del 2: IoT, hjemmeautomatisering '

Trin 6: OpenHAB -konfiguration

Jeg ændrede OpenHAB -konfigurationen i min tidligere Instructable (her) og tilføjede i individuelle poster for;

• Garage,
• Hal,
• Stue,
• Køkken
• Gæstesoveværelse
• Soveværelse

Se sitekortet billede 1 ovenfor.

For hver af disse poster tilføjede jeg individuelle sitemaps, der viser lokale omgivelsesværdier (se billede 2 ovenfor);

• Temperatur
• Fugtighed
• Varmeindeks

Jeg inkluderede også en switch til at styre den lokale LED monteret i sensoren.

Billeder 3 … 5 viser individuelle levende spor i løbet af 24 timer for temperatur, fugtighed og RSSI (modtaget signalstyrkeindikation, grundlæggende et mål for, hvor godt sensoren kan se WiFi -netværket).

Billede 6 giver et eksempel på en langsigtet fugtighedstendens i løbet af en uge.

Bemærk 1: Hvis du ikke er sikker på, hvordan du bruger OpenHAB, se her 'Opsætning og konfiguration af OpenHAB. Del 6: IoT, hjemmeautomatisering '

Note 2: En kopi af det ændrede sitemap, regler og elementfiler, ikoner osv. Er angivet nedenfor.

Trin 7: Test af designet

For det meste testede jeg IoT -enheden over MQTT -forbindelsen med MQTT Spy, overvågede led -output og fejlfindingstrafik på det serielle interface. Dette gjorde det muligt for mig at udøve alle de tilgængelige abonnementsemner og kontrollere de offentliggjorte svar. Selvom dette blev opnået manuelt og til tider blev lidt kedeligt, aktiverede det 100% dækning.

Hovedstatsmaskinen viste sig imidlertid at være lidt vanskelig at teste, da den var afhængig af tilstedeværelsen eller fraværet af et WiFi -netværk, hvis adgang kræver særlige parametersæt. Det var simpelthen ikke praktisk at bruge hjemmenetværket til dette.

For at komme uden om dette problem oprettede jeg mit eget sæt dummy-netværk ved hjælp af ESP8266-01 konfigureret som adgangspunkter (billede 1) med SSID'er for henholdsvis 'DummyNet1' og 'DummyNet2'. Brug af kredsløbet i billede 2 over lysdioden gav en indikation om en IoT -enhed havde tilsluttet den. Selvom dette ikke var en perfekt testløsning (dvs. hvert af disse dummy WiFi -netværk ikke indeholdt en MQTT -server) var det muligt at teste statsmaskinen fuldt ud.

Jeg har inkluderet en kopi af kildekoden herunder.

Trin 8: Konklusion

Generel

Softwaren i IoT -enhederne har arbejdet pålideligt i mange måneder nu og er kommet sig efter husholdningsstrømafbrydelser (hovedsageligt forårsaget af mig selv). Samlet set er de ret robuste enheder, der giver konsekvente og præcise data.

Forbedringer

Ved udviklingen af softwarerutiner til at læse og skrive til SPIFFS skrev jeg kode, som i baghovedet kan være lidt mere avanceret, end jeg havde tiltænkt, ved hjælp af tomrumspunkter, omarbejdning og pointer til pointer. Selvom det er meget fleksibelt og udfører arbejdet godt, kan jeg næste gang bruge JSON som noget i retning af ConfigFile.ino for at holde det lidt enklere.

• Arduino GIT HUB Core

  https://github.com/esp8266/Arduino

• ConfigFile.ino kilde

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

Ønskeliste

Jeg havde tænkt mig at bruge en mDNS -klient til at oprette forbindelse til mægleren, men biblioteket var for flosset. Derfor er det nødvendigt at angive MQTT Broker IP -adressen i modsætning til 'MQTTSVR.local'. Skulle mDNS -biblioteket blive mere stabilt i fremtiden, tilføjer jeg denne funktion til enheden.

Det ville have været rart at have et middel til både nøjagtig overvågning og kontrol af luftfugtighed til at kalibrere sensorerne mod. Imidlertid giver den valgte kalibreringsmetode gode relative aflæsninger og virker rimelig nøjagtig i overensstemmelse med specifikationen i DHT22 -databladet.

I betragtning af softwarens kompleksitet fandt jeg det tidskrævende at teste koden fuldstændigt efter en større ændring. Jeg kan overveje automatiseret test på et senere tidspunkt.

Trin 9: Anvendte referencer

Jeg brugte følgende kilder til at sammensætte denne instruktør sammen;

PubSubClient.h

• Af: Nick O'Leary
• Fra:

DHT.h

• Af: Adafruit
• Fra:

DHT22 Datablad