Innholdsfortegnelse:
2025 Forfatter: John Day | [email protected]. Sist endret: 2025-01-13 06:58
Innledning
Denne artikkelen dokumenterer praktisk robusthet og videre utvikling av en tidligere Instructable: 'Pimping' din første IoT WiFi -enhet. Del 4: IoT, hjemmeautomatisering inkludert all nødvendig programvarefunksjonalitet for å muliggjøre en vellykket distribusjon i hjemmemiljø.
Introduksjon
Som nevnt ovenfor beskriver denne Instructable sammenføyningen av et tidligere IoT -eksempel med en pålitelig systemdesign som muliggjør vellykket håndtering av praktiske brukstilfeller som; Katastrofalt strømtap, MQTT -meglersvikt, WiFi N/W -feil, ekstern sensorkonfigurasjon, konfigurerbar rapporteringsstrategi for å redusere nettverkstrafikk og skreddersydd sensorkalibrering.
Totalt 6 enheter ble opprettet (se bilde 1 ovenfor) og distribuert rundt hjemmet mitt for å danne mitt første IoT -sensornettverk.
Instructable ser også en gjennomgang av MQTT -navnekonvensjonen som brukt i den første IoT Home Automation -serien som gir plass til en mer balansert, praktisk struktur som muliggjør enklere feilsøking av IoT -trafikk i et multi IoT -enhetsmiljø.
Det som følger er fullstendige designdetaljer for IoT -sensoren, inkludert; konstruksjon, kildekode, teststrategi og OpenHAB -konfigurasjoner.
Hvilke deler trenger jeg?
- 1 av ESP8266-01,
- 2 av 1uF elektrolytiske kondensatorer,
- 3 av 10K motstander,
- 1 av 330R motstand,
- 1 av 3 mm dia. LED,
- 1 av LD1117-33v, 3v3 LDO VReg. (Farnell her),
- 1 av DHT22 temperatur-/fuktighetssensor,
- 1 av Dual 4way 0,1 "kontakt,
- 1 av CAMDENBOSS RX2008/S-5 plastkapsling, potteboks, ABS, 38 mm, 23 mm (Farnell her),
- 1 av likestrømkontakt, plugg, 1 A, 2 mm, panelmontering (Farnell her),
- 1 av TO-220 Heatsink 24,4 ° C/W (Farnell her),
- Ulike varmekrympeslanger (gul, Ebay her),
- Ulike lengder IDC båndkabel,
- Kjøleribber,
- Veroboard,
- ESP8266-01 programmeringsenhet. Se her; Praktisk kretskonstruksjon med Strip Board, trinn 9 og fremover.
Hvilken programvare trenger jeg?
- Arduino IDE 1.6.9
- Arduino IDE konfigurert for å programmere ESP8266-01. Se her; Konfigurere Arduino IDE for å programmere ESP8266-01
Hvilke verktøy trenger jeg?
- Loddejern,
- Drill og forskjellige biter,
- Filer,
- Hacksag,
- Robust skrustikke,
- Varmepistol,
- DMM.
Hvilke ferdigheter trenger jeg?
- Et minimalt grep om elektronikk,
- Kunnskap om Arduino og dens IDE,
- Rudimentære fabrikasjonskunnskaper (lodding, hacking, arkivering, boring etc.),
- Litt tålmodighet,
- Litt forståelse for hjemmenettverket ditt.
Emner dekket
- Kretsoversikt
- Oversikt over programvaresystem
- Oversikt over programvare
- Sensorkalibrering
- MQTT -emnekonvensjon
- OpenHAB -konfigurasjon
- Tester designet
- Konklusjon
- Referanser brukt
Seriekoblinger
Til del 7: Study Lights Controller (omarbeidet). Del 7: IoT, hjemmeautomatisering
Til del 9: IoT Mains Controller. Del 9: IoT, hjemmeautomatisering
Trinn 1: Kretsoversikt
Bilde 1 ovenfor viser hele kretsutformingen for IoT -sensoren.
I hjertet av IoT-enheten er ESP8266-01 som er koblet til en DHT22 temperatur-/fuktighetssensor via en 10K opptrekksmotstand til GPIO2. En ekstern 5v kommer fra en koblet modusforsyning og mates til enheten gjennom en 2 mm DC panelmontert kontakt og reguleres lokalt med en LD1117-33v, 3v3 LDO spenningsregulator montert på en ekstern kjøleribbe med en BZP M3 panhodeskrue og mutter.
Designet inkluderer en 3 mm rød LED koblet til GPIO0 som brukes til å gi lokal indikasjon på statusen til IoT -enheten under oppstart eller eventuelle påfølgende feiltilstander. Den kan også brukes til å identifisere enheten ved manuell aktivering via openHAB -grensesnittet.
Hele designet passer pent inn i en ABS -boks som vist ovenfor på bilde 2 og ble lagt spesielt ut for å sikre at sensoren er så langt som mulig fra regulatoren for å forhindre forspenning på grunn av lokale varmeeffekter (bilde 7 ovenfor).
Kretskortet er et enkelt stykke veroboard, skåret i form og laget for å passe inn i skapet (bilde 3 ovenfor). Dette brettet er festet på plass med en M3 forsenket nylonskrue og to muttere som passer i flukt med undersiden av sensoren, slik at den kan sitte på en flat overflate.
Bilder 4 … 6 viser forskjellige konstruksjonstilstander.
Trinn 2: Oversikt over programvaresystem
Denne IoT -temperaturen og fuktighetsfølerenheten inneholder seks viktige programvarekomponenter som vist på bilde 1 ovenfor.
SPIFFS
Dette er innebygd SPI Flash Filing System og brukes til å holde følgende informasjon (se bilde 2 ovenfor);
- Ikoner og 'Sensor Configuration Home Page' html: Vises av IoT -enheten når den ikke kan koble til IoT WiFi -nettverket (vanligvis på grunn av feil sikkerhetsinformasjon) og gir brukeren mulighet til å ekstern konfigurere sensoren uten behov for å omprogrammere eller laste opp nytt SPIFFS-innhold.
- Sikkerhetsinformasjon: Denne inneholder informasjonen som brukes ved oppstart av IoT -enheten for å koble til IoT WiFi -nettverket og MQTT -megleren. Informasjon sendt via 'Sensor Configuration Home Page' skrives til denne filen ('secvals.txt').
- Kalibreringsinformasjon: Informasjonen i denne filen ('calvals.txt') brukes til å kalibrere innebygd temperatur-/fuktighetssensor hvis det er nødvendig. Kalibreringskonstanter kan bare skrives til IoT -enheten via MQTT -kommandoer fra en MQTT -megler.
Merk: For å sette opp enheten først, se her for fullstendig informasjon om hvordan du bruker SPIFFS med Arduino IDE.
mDNS -server
Denne funksjonaliteten påkalles når IoT -enheten ikke klarte å koble seg til WiFi -nettverket som en WiFi -stasjon og i stedet har blitt et WiFi -tilgangspunkt, noe som ligner på en innenlandsk WiFi -ruter. I tilfelle av en slik ruter vil du vanligvis koble til den ved å skrive inn IP -adressen til noe som 192.168.1.1 (vanligvis skrevet på en etikett festet i boksen) direkte i nettleserens nettleser, hvoretter du vil motta en påloggingsside for å gå inn brukernavnet og passordet slik at du kan konfigurere enheten.
For ESP8266 i AP -modus (tilgangspunktmodus) er enheten standard til IP -adressen 192.168.4.1, men med mDNS -serveren i gang trenger du bare å skrive inn det menneskelige navnet 'SENSORSVR.local' i nettleserens URL -linje for å se 'Startside for sensorkonfigurasjon'.
MQTT -klient
MQTT -klienten gir all nødvendig funksjonalitet til; koble til din IoT -nettverk MQTT -megler, abonner på temaene du ønsker og publiser nyttelast til et gitt emne. Kort sagt gir den IoT -kjernefunksjonalitet.
HTTP -webserver
Som nevnt ovenfor, hvis IoT -enheten ikke kan koble til WiFi -nettverket hvis SSID, P/W etc. er definert i sikkerhetsinformasjonsfilen i SPIFFS, blir enheten et tilgangspunkt. Når den er koblet til WiFi -nettverket som tilbys av tilgangspunktet, lar tilstedeværelsen av en HTTP -webserver deg direkte koble til enheten og endre konfigurasjonen ved bruk av en HTTP -nettleser. Formålet er å betjene 'Sensor Configuration Home Side 'webside som også finnes i SPIFFS.
WiFi -stasjon
Denne funksjonaliteten gir IoT -enheten muligheten til å koble til et hjemlig WiFi -nettverk ved hjelp av parametrene i sikkerhetsinformasjonsfilen, uten dette vil ikke din IoT -enhet kunne abonnere/publisere på MQTT -megleren
WiFi tilgangspunkt
Muligheten til å bli et WiFi -tilgangspunkt er et middel der IoT -enheten lar deg koble til den og gjøre konfigurasjonsendringer via en WiFi -stasjon og en nettleser (for eksempel Safari på Apple iPad).
Dette tilgangspunktet sender en SSID = "SENSOR" + de siste 6 sifrene i MAC -adressen til IoT -enheten. Passordet for dette lukkede nettverket heter fantasifullt 'PASSORD'
Trinn 3: Oversikt over programvare
Forord For å lykkes med å kompilere denne kildekoden trenger du følgende ekstra biblioteker;
PubSubClient.h
- Av: Nick O'Leary
- Formål: Lar enheten publisere eller abonnere på MQTT -emner med en gitt megler
- Fra:
DHT.h
- Av: Adafruit
- Formål: Bibliotek for DHT temperatur-/fuktighetssensor
- Fra:
Kodeoversikt
Programvaren bruker state-maskinen som vist på bilde 1 ovenfor (full kopi av kilden gitt nedenfor). Det er 5 hovedstater som nedenfor;
-
I DET
Denne initialiseringstilstanden er den første tilstanden som ble angitt etter oppstart
-
NOCONFIG
Denne tilstanden angis hvis en ugyldig eller manglende secvals.txt -fil oppdages etter oppstart
-
VENTER NV
Denne tilstanden er forbigående, angitt mens det ikke finnes noen WiFi -nettverkstilkobling
-
VENTENDE MQTT
Denne tilstanden er forbigående, angitt etter at en WiFi -nettverkstilkobling er opprettet, og mens det ikke er noen forbindelse til en MQTT -megler på det nettverket
-
AKTIV
Dette er den normale driftstilstanden som angis når både en WiFi -nettverkstilkobling og en MQTT -meglerforbindelse er etablert. Det er i denne tilstanden temperatur og fuktighet funksjonaliteten til sensoren er publisert til MQTT Broker
Hendelsene som kontrollerer overganger mellom tilstander er beskrevet på bilde 1 ovenfor. Overganger mellom stater styres også av følgende SecVals -parametere;
- Første MQTT -megler IP -adresse. I stiplet desimalform AAA. BBB. CCC. DDD
- 2. MQTT meglerhavn. I heltall -form.
- Tredje MQTT -meglerforbindelse prøver å gjøre før du bytter fra STA -modus til AP -modus. I heltall -form.
- Fjerde WiFi -nettverks -SSID. I fri form tekst.
- 5. WiFi -nettverkspassord. I fri form tekst.
Som nevnt ovenfor, hvis IoT -enheten ikke kan koble seg til en WiFi -stasjon som WiFi -nettverk som har SSID og P/W som er definert i secvals.txt i SPIFFS, vil IoT -enheten bli et tilgangspunkt. Når den er koblet til dette tilgangspunktet, vil den vise "Sensor Configuration Home Page" som vist ovenfor på bilde 2 (ved å skrive inn enten "SENSORSVR.local" eller 192.168.4.1 i nettleserens adresselinje). Denne hjemmesiden tillater omkonfigurering av sensoren via en HTTP -nettleser.
Ekstern tilgang mens den er i AKTIV
Når den er koblet til MQTT-megleren, er det også mulig å både kalibrere og omkonfigurere enheten via MQTT-emnepublikasjoner. Filen calvals.txt har R/W -tilgang og secvals.txt har skrivebeskyttet tilgang.
Brukerfeilsøking
Under oppstartsekvensen gir IoT -enhetsledningen følgende tilbakemelding om feilsøking
- 1 Kort blits: Ingen konfigurasjonsfil ligger i SPIFFS (secvals.txt)
- 2 korte blink: IoT -enheten prøver å koble seg til WiFi -nettverket
- Kontinuerlig belysning: IoT -enheten prøver å koble seg til MQTT Broker
- Av: Enheten er aktiv
- Merknad 1: "Hjemmeside for sensorkonfigurasjon" bruker ikke sikre stikkontakter og er derfor avhengig av at nettverket ditt er sikkert.
- Merknad 2: For å programmere hver IoT -enhet må MQTT -strengen redigeres før nedlasting. Dette er fordi nummeret til sensoren er innebygd i MQTT -emnestrengen. dvs. 'WFD/THSen/100/HumdStatus/1' for mine 6 enheter er de nummerert henholdsvis 1… 6.
Trinn 4: Sensorkalibrering
Når IoT -enheten slås på, leses en fil med navnet 'cavals.txt' fra SPIFFS som en del av oppstartsekvensen. Innholdet i denne filen er kalibreringskonstanter som angitt ovenfor på bilde 1. Disse kalibreringskonstantene brukes til å justere avlesningene hentet fra sensoren for å bringe dem på linje med en referanseenhet. Det er en ytterligere verdi som definerer en rapporteringsstrategi for enheten og er beskrevet nedenfor sammen med prosedyren som ble fulgt for å kalibrere sensorene.
Rapporteringsstrategi Denne parameteren bestemmer hvordan den eksterne sensoren rapporterer eventuelle parametriske endringer i omgivelsene lokalt. Hvis en verdi på 0 velges, vil den eksterne sensoren publisere eventuelle endringer den ser i temperatur- eller fuktighetsverdiene hver gang sensoren leses (ca. hvert 10. sekund). Enhver annen verdi vil forsinke publiseringen av en endring med 1… 60 minutter. Endring av denne parameteren gir mulighet for optimalisering av MQTT -nettverkstrafikk.
Temperaturkalibrering
For å kalibrere sensorene ble de plassert i nær fysisk nærhet til hverandre som vist ovenfor på bilde 2. Ved siden av dem plasserte jeg en DMM med et kalibrert termoelement festet (Fluke 87 V) og deretter overvåket utgangene fra hver enhet via OpenHAB -temperaturen trendside i løpet av et døgn for å få en god temperatursvingning. Jeg noterte meg både den statiske forskyvningen (forhøyet null 'C') og endringshastigheten for hver enhet (forsterkning eller stigning på grafen 'M') i forhold til verdien av verdien fra det kalibrerte termoelementet. Jeg beregnet deretter det enkle y = mx+c -forholdet (jeg fant at det var tilstrekkelig lineært til å være en nær tilnærming til en rettlinjet graf) og programmerte eventuelle nødvendige korreksjoner i kalibreringskonstantene via MQTTSpy.
Enhetene ble deretter overvåket i ytterligere 24 timer for å sikre at kalibreringen var vellykket. En indikasjon på hvilke som var temperatursporene på OpenHAB -temperaturtrendsiden, var alle ganske mye på hverandre.
Selvfølgelig, hvis du bare er interessert i en tilnærming til temperaturen, kan du la alle kalibreringsverdiene være standard.
Fuktighetskalibrering
Siden jeg ikke har noen midler til å registrere eller til og med kontrollere lokal luftfuktighet, kalibrerte jeg sensorene, og jeg brukte en lignende tilnærming som ovenfor, ved å plassere alle enhetene i umiddelbar fysisk nærhet (bilde 2) og ganske enkelt overvåke utgangen via OpenHAB Fuktighet tendens side. Jeg valgte deretter enhet nr. 1 som kalibreringsreferanse og kalibrerte alle enhetene i forhold til dette.
Trinn 5: MQTT -emnekonvensjon
Etter mye prøving og feiling bestemte jeg meg for temaet navngivningskonvensjon som er skissert i bilde 1 ovenfor.
Nemlig 'AccessMethod/DeviceType/WhichDevice/Action/SubDevice'
Det er ikke perfekt, men det gjør det mulig å bruke nyttige filtre for å se alle sensorutganger for en gitt parametrisk verdi, noe som gjør det enkelt å sammenligne som på bilde 2 ovenfor med MQTTSpy. Den støtter også rimelig utvidbare logiske grupperinger av funksjonalitet innenfor en gitt IoT -enhet.
Ved implementering av disse emnene i programvare brukte jeg hardkodede emnestrenger med faste, innebygde numeriske identifikatorer for hver enhet i motsetning til dynamisk generering av emnene ved kjøretid for å spare på RAM og holde ytelsen høy.
Merk: Hvis du ikke er sikker på hvordan du bruker MQTTSpy, se her 'Konfigurere en MQTT -megler. Del 2: IoT, hjemmeautomatisering '
Trinn 6: OpenHAB -konfigurasjon
Jeg endret OpenHAB -konfigurasjonen gitt i min tidligere Instructable (her) og lagt til i individuelle oppføringer for;
- Garasje,
- Hall,
- Stue,
- Kjøkken
- Gjesterom
- Hovedsoverom
Se nettstedskartet bilde 1 ovenfor.
For hver av disse oppføringene la jeg til individuelle nettstedskart som avslørte lokale omgivelsesverdier (se bilde 2 ovenfor);
- Temperatur
- Luftfuktighet
- Varmeindeks
Jeg inkluderte også en bryter for å kontrollere den lokale LED -en montert i sensoren.
Bilder 3… 5 viser individuelle spor i løpet av 24 timer for temperatur, fuktighet og RSSI (mottatt signalstyrkeindikasjon, i utgangspunktet et mål på hvor godt sensoren kan se WiFi -nettverket).
Bilde 6 gir et eksempel på en langsiktig fuktighetsutvikling i løpet av en uke.
Merk 1: Hvis du ikke er sikker på hvordan du bruker OpenHAB, se her 'Konfigurere og konfigurere OpenHAB. Del 6: IoT, hjemmeautomatisering '
Merknad 2: En kopi av det endrede nettstedskartet, regler og elementfiler, ikoner etc. er gitt nedenfor.
Trinn 7: Testing av designet
For det meste testet jeg IoT -enheten over MQTT -tilkoblingen med MQTT Spy, overvåket led -utgang og feilsøkingstrafikk på det serielle grensesnittet. Dette tillot meg å utøve alle de tilgjengelige abonnementstemaene og sjekke de publiserte svarene. Selv om dette ble oppnådd manuelt og til tider ble litt kjedelig, muliggjorde det 100% dekning.
Imidlertid viste hovedstatsmaskinen seg å være litt vanskelig å teste da den var avhengig av tilstedeværelse eller fravær av et WiFi -nettverk, som tilgang krever spesifikke parametersett. Det var rett og slett ikke praktisk å bruke hjemmenettverket til dette.
For å komme rundt dette problemet opprettet jeg mitt eget sett med dummy-nettverk ved hjelp av ESP8266-01 konfigurert som tilgangspunkter (bilde 1) med SSID-er på henholdsvis 'DummyNet1' og 'DummyNet2'. Ved å bruke kretsen på bilde 2 over lysdioden, ble det indikert om en IoT -enhet hadde koblet seg til den. Selv om dette ikke var en perfekt testløsning (dvs. at hvert av disse dummy WiFi -nettverkene ikke inneholdt en MQTT -server), var det mulig å teste state -maskinen fullt ut.
Jeg har tatt med en kopi av kildekoden nedenfor.
Trinn 8: Konklusjon
Generell
Programvaren i IoT -enhetene har fungert pålitelig i mange måneder, og har nå kommet meg etter strømbrudd i husholdningen (hovedsakelig forårsaket av meg selv). Totalt sett er de ganske robuste enheter som gir konsistente og nøyaktige data.
Forbedringer
I utviklingen av programvarerutiner for å lese og skrive til SPIFFS skrev jeg kode som i baksiden kan være litt mer avansert enn jeg hadde tenkt, ved å bruke tomromspekere, omforming og pekere til pekere. Selv om det er veldig fleksibelt og gjør jobben godt, kan jeg bruke JSON neste gang på en måte som ConfigFile.ino for å holde det litt enklere.
-
Arduino GIT HUB -kjerne
https://github.com/esp8266/Arduino
-
ConfigFile.ino kilde
https://github.com/esp8266/Arduino/tree/master/libraries/esp8266/examples/ConfigFile
Ønskeliste
Jeg hadde tenkt å bruke en mDNS -klient for å koble til megleren, men biblioteket var for flassende. Det er derfor det er nødvendig å spesifisere MQTT -meglerens IP -adresse i motsetning til 'MQTTSVR.local'. Skulle mDNS -biblioteket bli mer stabilt i fremtiden, legger jeg til denne funksjonen til enheten.
Det hadde vært fint å ha et middel for både nøyaktig overvåking og kontroll av luftfuktighet for å kalibrere sensorene mot. Imidlertid gir kalibreringsmetoden valgt gode relative avlesninger og virker rimelig nøyaktig i tråd med spesifikasjonen i DHT22 -databladet.
Til slutt, gitt kompleksiteten til programvaren, fant jeg ut å teste koden etter at en stor endring ble tidkrevende. Jeg kan vurdere automatisert testing på et senere tidspunkt.
Trinn 9: Referanser brukt
Jeg brukte følgende kilder for å sette denne instruksjonsboken sammen;
PubSubClient.h
- Av: Nick O'Leary
- Fra:
DHT.h
- Av: Adafruit
- Fra:
DHT22 Datablad