WiFi IoT temperatur- och fuktighetssensor. Del: 8 IoT, Hemautomation: 9 steg

2024 Författare: John Day | [email protected]. Senast ändrad: 2024-01-30 12:46

Inledning

Den här artikeln dokumenterar den praktiska robustheten och utvecklingen av en tidigare Instructable: 'Pimping' din första IoT WiFi -enhet. Del 4: IoT, Hemautomation inklusive all nödvändig mjukvarufunktionalitet för att möjliggöra framgångsrik distribution i hemmamiljö.

Introduktion

Som nämnts ovan beskriver denna instruktionsbok sammanförandet av ett tidigare IoT -exempel med en pålitlig systemdesign som möjliggör en framgångsrik hantering av praktiska användningsfall som t.ex. Katastrofal strömförlust, MQTT -mäklarfel, WiFi N/W -fel, fjärrsensorrekonfiguration, konfigurerbar rapporteringsstrategi för att minska nätverkstrafik och skräddarsydd sensorkalibrering.

Totalt 6 av enheter skapades (se bild 1 ovan) och distribuerades runt mitt hem för att bilda mitt första IoT -sensornätverk.

Instructable ser också en översyn av MQTT -namngivningskonventionen som används i den första IoT Home Automation -serien som ger plats för en mer balanserad, praktisk struktur som möjliggör enklare felsökning av IoT -trafik i en multi IoT -enhetsmiljö.

Det som följer är fullständiga designdetaljer för IoT -sensorn inklusive; konstruktion, källkod, teststrategi och OpenHAB -konfigurationer.

Vilka delar behöver jag?

1. 1 av ESP8266-01,
2. 2 av 1uF elektrolytkondensatorer,
3. 3 av 10K motstånd,
4. 1 av 330R motstånd,
5. 1 av 3 mm dia. LED,
6. 1 av LD1117-33v, 3v3 LDO VReg. (Farnell här),
7. 1 av DHT22 temperatur-/fuktighetssensor,
8. 1 av Dual 4way 0.1 "Connector,
9. 1 av CAMDENBOSS RX2008/S-5 plasthölje, kruka, ABS, 38 mm, 23 mm (Farnell här),
10. 1 av likströmskontakt, kontakt, 1 A, 2 mm, panelmonterad (Farnell här),
11. 1 av TO-220 kylfläns 24,4 ° C/W (Farnell här),
12. Olika värmekrympslangar (gul, Ebay här),
13. Olika längder IDC -bandkabel,
14. Kylfläns,
15. Veroboard,
16. ESP8266-01 programmeringsenhet. Kolla här; Praktisk kretskonstruktion med remskiva, steg 9 och framåt.

Vilken programvara behöver jag?

1. Arduino IDE 1.6.9
2. Arduino IDE konfigurerad för att programmera ESP8266-01. Kolla här; Konfigurera Arduino IDE för att programmera ESP8266-01

Vilka verktyg behöver jag?

1. Lödkolv,
2. Borr och olika bitar,
3. Filer,
4. Bågfil,
5. Robust skruv,
6. Värmepistol,
7. DMM.

Vilka färdigheter behöver jag?

1. Ett minimalt grepp om elektronik,
2. Kunskap om Arduino och dess IDE,
3. Rudimentära tillverkningskunskaper (lödning, hackning, arkivering, borrning etc.),
4. Lite tålamod,
5. Viss förståelse för ditt hemnätverk.

Ämnen som behandlas

1. Kretsöversikt
2. Programvaruöversikt
3. Programvaruöversikt
4. Sensorkalibrering
5. MQTT -ämnesnamnkonvention
6. OpenHAB -konfiguration
7. Testar designen
8. Slutsats
9. Referenser används

Serielänkar

Till del 7: Study Lights Controller (omarbetad). Del 7: IoT, Hemautomation

Till del 9: IoT Mains Controller. Del 9: IoT, Hemautomation

Steg 1: Kretsöversikt

Bild 1 ovan visar hela kretsdesignen för IoT -sensorn.

I hjärtat av IoT-enheten finns ESP8266-01 som är ansluten till en DHT22 temperatur-/fuktighetssensor via ett 10K uppdragningsmotstånd till GPIO2. En extern 5v levereras med ett växlat läge och matas till enheten via ett 2 mm DC-panelmonterat uttag och regleras lokalt med en LD1117-33v, 3v3 LDO-spänningsregulator monterad på en extern kylfläns med en BZP M3 panhuvudskruv och mutter.

Designen innehåller en 3 mm röd lysdiod ansluten till GPIO0 som används för att ge lokal indikation på IoT -enhetens status under uppstart eller efterföljande fel. Den kan också användas för att identifiera enheten genom manuell aktivering via openHAB -gränssnittet.

Hela designen passar snyggt in i en ABS -låda som visas ovan på bild 2 och utformades speciellt för att säkerställa att sensorn är så långt som möjligt från regulatorn för att förhindra förspänning på grund av lokala värmeeffekter (bild 7 ovan).

Kretskortet är en enda bit av veroboard, skuren i form och gjord för att passa in i höljet (bild 3 ovan). Detta kort är fixerat på plats med en M3 försänkt nylonskruv och två muttrar som passar i linje med sensorns undersida, vilket gör att den kan sitta på en plan yta.

Bilderna 4… 6 visar olika konstruktionstillstånd.

Steg 2: Översikt över programvarusystem

Denna IoT -temperatur- och fuktighetsavkännande enhet innehåller sex viktiga programvarukomponenter som visas på bild 1 ovan.

SPIFFS

Detta är det inbyggda SPI Flash Filing System och används för att hålla följande information (se bild 2 ovan);

• Ikoner och hemsidan 'Sensorkonfiguration': tillhandahålls av IoT -enheten när den inte kan ansluta till ditt IoT WiFi -nätverk (vanligtvis på grund av felaktig säkerhetsinformation) och ger användaren möjlighet att fjärrkonfigurera sensorn utan behov för att omprogrammera eller ladda upp nytt SPIFFS-innehåll.
• Säkerhetsinformation: Den innehåller informationen som används vid uppstart av IoT -enheten för att ansluta till ditt IoT WiFi -nätverk och MQTT Broker. Information som skickas via "Sensor Configuration Home Page" skrivs till den här filen ("secvals.txt").
• Kalibreringsinformation: Informationen i denna fil ('calvals.txt') används för att kalibrera inbyggd temperatur-/fuktighetssensor om det skulle behövas. Kalibreringskonstanter kan bara skrivas till IoT -enheten via MQTT -kommandon från en MQTT -mäklare.

Obs! För att först konfigurera enheten, se här för fullständig information om hur du använder SPIFFS med Arduino IDE.

mDNS -server

Denna funktionalitet åberopas när IoT -enheten misslyckades med att ansluta till ditt WiFi -nätverk som en WiFi -station och istället har blivit en WiFi -åtkomstpunkt något som liknar en inhemsk WiFi -router. När det gäller en sådan router ansluter du vanligtvis till den genom att ange IP -adressen till något som 192.168.1.1 (vanligtvis tryckt på en etikett fäst på rutan) direkt i webbläsarens URL -fält, varefter du skulle få en inloggningssida för att komma in användarnamnet och lösenordet så att du kan konfigurera enheten.

För ESP8266 i AP -läge (åtkomstpunktsläge) standardiseras enheten till IP -adressen 192.168.4.1, men med mDNS -servern igång behöver du bara ange det mänskliga namnet 'SENSORSVR.local' i webbläsarens URL -fält för att se 'Hemsida för sensorkonfiguration'.

MQTT -klient

MQTT -klienten tillhandahåller all nödvändig funktionalitet för att; anslut till din IoT -nätverk MQTT -mäklare, prenumerera på de ämnen du väljer och publicera nyttolast för ett visst ämne. Kort sagt tillhandahåller den IoT -kärnfunktionalitet.

HTTP -webbserver

Som nämnts ovan kommer enheten att bli en åtkomstpunkt om IoT -enheten inte kan ansluta till WiFi -nätverket vars SSID, P/W etc. definieras i säkerhetsinformationsfilen i SPIFFS. När den väl är ansluten till WiFi -nätverket som tillhandahålls av åtkomstpunkten, kan närvaron av en HTTP -webbserver direkt ansluta till enheten och ändra dess konfiguration med hjälp av en HTTP -webbläsare. Sidans webbsida som också finns i SPIFFS.

WiFi -station

Denna funktionalitet ger IoT -enheten möjlighet att ansluta till ett inhemskt WiFi -nätverk med parametrarna i säkerhetsinformationsfilen, utan detta kan din IoT -enhet inte prenumerera/publicera på MQTT -mäklaren

WiFi -åtkomstpunkt

Möjligheten att bli en WiFi -åtkomstpunkt är ett sätt på vilket IoT -enheten låter dig ansluta till den och göra konfigurationsändringar via en WiFi -station och en webbläsare (t.ex. Safari på Apple iPad).

Denna åtkomstpunkt sänder ett SSID = "SENSOR" + de sista 6 siffrorna i MAC -adressen för IoT -enheten. Lösenordet för detta stängda nätverk heter fantasifullt 'LÖSENORD'

Steg 3: Programöversikt

För att lyckas sammanställa denna källkod behöver du följande extrabibliotek;

PubSubClient.h

• Av: Nick O'Leary
• Syfte: Gör att enheten kan publicera eller prenumerera på MQTT -ämnen med en given mäklare
• Från:

DHT.h

• Av: Adafruit
• Syfte: Bibliotek för DHT -temperatur-/fuktighetssensor
• Från:

Kodöversikt

Programvaran använder tillståndsmaskinen enligt bild 1 ovan (fullständig kopia av källan nedan). Det finns 5 huvudtillstånd enligt nedan;

• I DET

  Detta initialiseringstillstånd är det första tillståndet som angavs efter uppstart

• NOCONFIG

  Detta tillstånd anges om en ogiltig eller saknad secvals.txt -fil upptäcks efter uppstart

• Väntar på NW

  Detta tillstånd är övergående, anges medan det inte finns någon WiFi -nätverksanslutning

• Väntande MQTT

  Detta tillstånd är övergående, anges efter att en WiFi -nätverksanslutning har gjorts och även om det inte finns någon anslutning till en MQTT -mäklare på det nätverket

• AKTIVA

  Detta är det normala driftsläget som anges när både en WiFi -nätverksanslutning och en MQTT Broker -anslutning har upprättats. Det är under detta tillstånd sensorns temperatur och fuktighet publiceras för MQTT -mäklaren

Händelserna som styr övergångar mellan tillstånd beskrivs i bild 1 ovan. Övergångar mellan stater styrs också av följande SecVals -parametrar;

• Första MQTT -mäklarens IP -adress. I prickig decimalform AAA. BBB. CCC. DDD
• 2: a MQTT -mäklarporten. I heltal.
• Tredje MQTT -mäklaranslutningen försöker göra innan man byter från STA -läge till AP -läge. I heltal.
• 4: e WiFi -nätverks -SSID. I fri form text.
• 5: e WiFi -nätverkslösenordet. I fri form text.

Som nämnts ovan om IoT -enheten inte kan ansluta som en WiFi -station till WiFi -nätverket som har SSID och P/W som definieras i secvals.txt som finns i SPIFFS blir IoT -enheten en åtkomstpunkt. När den väl är ansluten till den här åtkomstpunkten kommer den att visa "Sensorkonfigurationshemsidan" som visas ovan på bild 2 (genom att antingen ange "SENSORSVR.local" eller 192.168.4.1 i webbläsarens webbadressadressfält). Denna hemsida möjliggör omkonfigurering av sensorn via en HTTP -webbläsare.

Fjärråtkomst medan den är i AKTIVT tillstånd

När den väl är ansluten till MQTT-mäklaren är det också möjligt att både kalibrera och omkonfigurera enheten via MQTT-ämnespublikationer. Filen calvals.txt har R/W -åtkomst och secvals.txt har skrivåtkomst exponerad.

Användarfelsökning

Under uppstartsekvensen ger IoT -enhetens LED följande felsökningsfeedback

• 1 Kort blixt: Ingen konfigurationsfil finns i SPIFFS (secvals.txt)
• 2 Korta blinkningar: IoT -enheten försöker ansluta till WiFi -nätverket
• Kontinuerlig belysning: IoT -enheten försöker ansluta till MQTT Broker
• Av: Enheten är aktiv
• Obs 1: "Sensorkonfigurationshemsidan" använder inte säkra uttag och är därför beroende av att ditt nätverk är säkert.
• Not 2: För att programmera varje IoT -enhet måste MQTT -strängen redigeras innan den laddas ner. Detta beror på att sensorns nummer har inbäddats i MQTT -ämnessträngen. dvs. 'WFD/THSen/100/HumdStatus/1' för mina 6 enheter är de numrerade 1… 6 respektive.

Steg 4: Sensorkalibrering

När IoT -enheten startas läses en fil med namnet 'cavals.txt' från SPIFFS som en del av startsekvensen. Innehållet i denna fil är kalibreringskonstanter som anges ovan på bild 1. Dessa kalibreringskonstanter används för att justera avläsningarna från sensorn för att anpassa dem till en referensanordning. Det finns ytterligare ett värde som definierar en rapporteringsstrategi för enheten och beskrivs nedan tillsammans med proceduren som följs för att kalibrera sensorerna.

Rapporteringsstrategi Denna parameter avgör hur fjärrsensorn rapporterar eventuella parametriska förändringar i omgivningen. Om ett värde på 0 väljs kommer fjärrsensorn att publicera alla ändringar som det ser i temperatur- eller fuktighetsvärdena varje gång sensorn läses (ungefär var 10: e sekund). Alla andra värden kommer att försena publiceringen av en ändring med 1… 60 minuter. Genom att ändra denna parameter möjliggörs optimering av MQTT -nätverkstrafik.

Temperaturkalibrering

För att kalibrera sensorerna placerades de i nära fysisk närhet med varandra som visas ovan på bild 2. Vid sidan av dem placerade jag en DMM med ett kalibrerat termoelement anslutet (Fluke 87 V) och övervakade sedan utgångarna från varje enhet via OpenHAB -temperaturen trend sida under en dag för att få en bra temperatursvängning. Jag noterade både den statiska förskjutningen (förhöjd noll 'C') och förändringshastigheten för varje enhet (förstärkning eller lutning för grafen 'M') i förhållande till värdet från det kalibrerade termoelementet. Jag beräknade sedan det enkla y = mx+c -förhållandet (jag fann att det var tillräckligt linjärt för att vara en nära approximation till en raklinjediagram) och programmerade alla nödvändiga korrigeringar i kalibreringskonstanterna via MQTTSpy.

Enheterna övervakades sedan i ytterligare 24 timmar för att säkerställa att kalibreringen lyckades. En indikation på vilka var temperaturspåren på OpenHAB -temperaturtrendsidan låg alla ganska mycket ovanpå varandra.

Naturligtvis, om du bara är intresserad av en approximation till temperaturen kan du lämna alla kalibreringsvärden som standard.

Luftfuktighetskalibrering

Eftersom jag inte har några möjligheter att exakt registrera eller till och med kontrollera lokal luftfuktighet, för att kalibrera sensorerna, använde jag en liknande metod som ovan, genom att placera alla enheter i nära fysisk närhet (bild 2) och helt enkelt övervaka deras utmatning via OpenHAB Fuktighet tenderar sida. Jag valde sedan enhet nr 1 som kalibreringsreferens och kalibrerade alla enheter i förhållande till detta.

Steg 5: MQTT -ämnesnamnkonvention

Efter mycket försök och fel bestämde jag mig för ämnesnamnkonventionen som beskrivs i bild 1 ovan.

Nämligen 'AccessMethod/DeviceType/WhichDevice/Action/SubDevice'

Det är inte perfekt men det gör det möjligt att använda användbara filter för att se alla sensorutgångar för ett givet parametriskt värde, vilket möjliggör enkel jämförelse som på bild 2 ovan med MQTTSpy. Det stöder också rimligt utökbara logiska grupperingar av funktioner inom en given IoT -enhet.

Vid implementering av dessa ämnen i programvara använde jag hårdkodade ämnessträngar med fasta, inbäddade numeriska identifierare för varje enhet i motsats till att dynamiskt generera ämnena vid körning för att spara på RAM och hålla prestanda hög.

Obs! Om du inte är säker på hur du använder MQTTSpy, se här 'Konfigurera en MQTT -mäklare. Del 2: IoT, Hemautomation '

Steg 6: OpenHAB -konfiguration

Jag ändrade OpenHAB -konfigurationen i min tidigare Instructable (här) och lade till i enskilda poster för;

• Garage,
• Hall,
• Vardagsrum,
• Kök
• Gästrum
• Huvudsovrum

Se sidkartan på bild 1 ovan.

För var och en av dessa poster har jag lagt till individuella webbplatskartor som visar lokala omgivningsvärden (se bild 2 ovan);

• Temperatur
• Fuktighet
• Värmeindex

Jag inkluderade också en omkopplare för att styra den lokala lysdioden monterad i sensorn.

Bilder 3 … 5 visar individuella spår under 24 timmar för temperatur, luftfuktighet och RSSI (mottagen signalstyrkaindikation, i grunden ett mått på hur väl sensorn kan se WiFi -nätverket).

Bild 6 ger ett exempel på en långsiktig fukttrend under en vecka.

Obs 1: Om du inte är säker på hur du använder OpenHAB, se här 'Konfigurera och konfigurera OpenHAB. Del 6: IoT, Hemautomation '

Not 2: En kopia av den modifierade webbplatskartan, regler och objektfiler, ikoner etc. ges nedan.

Steg 7: Testa designen

För det mesta testade jag IoT -enheten över MQTT -anslutningen med MQTT Spy, övervakade led -utdata och felsök trafik på det seriella gränssnittet. Detta tillät mig att använda alla tillgängliga ämnen som prenumererade och kontrollera de publicerade svaren. Även om detta uppnåddes manuellt och ibland blev lite tråkigt, möjliggjorde det 100% täckning.

Huvudstatsmaskinen visade sig dock vara lite knepig att testa eftersom den förlitade sig på närvaron eller frånvaron av ett WiFi -nätverk, vars åtkomst kräver specifika parameteruppsättningar. Det var helt enkelt inte praktiskt att använda hemnätverket för detta.

För att komma runt det här problemet skapade jag min egen uppsättning dummy-nätverk med hjälp av ESP8266-01 konfigurerade som åtkomstpunkter (bild 1) med SSID för "DummyNet1" respektive "DummyNet2". Att använda kretsen i bild 2 ovanför lysdioden gav en indikation om en IoT -enhet hade anslutit till den. Även om detta inte var en perfekt testlösning (dvs. var och en av dessa dummy WiFi -nätverk inte innehöll en MQTT -server) var det möjligt att testa tillståndsmaskinen fullständigt.

Jag har inkluderat en kopia av källkoden nedan.

Steg 8: Slutsats

Allmän

Programvaran i IoT -enheterna har fungerat pålitligt i många månader nu och återhämtat sig från hushållsavbrott (främst orsakat av mig själv). Sammantaget är de ganska robusta enheter som ger konsekvent och korrekt data.

Förbättringar

Vid utvecklingen av programvarurutiner för att läsa och skriva till SPIFFS skrev jag kod som i baksidan kan vara lite mer avancerad än jag hade tänkt mig, med tomrumspekare, omarbetning och pekare till pekare. Även om det är väldigt flexibelt och gör jobbet bra, kan jag nästa gång använda JSON något i stil med ConfigFile.ino för att hålla det lite enklare.

• Arduino GIT HUB Core

  https://github.com/esp8266/Arduino

• ConfigFile.ino -källa

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

Önskelista

Jag hade tänkt använda en mDNS -klient för att ansluta till mäklaren men biblioteket var för fläckigt. Det är därför det är nödvändigt att ange MQTT -mäklarens IP -adress i motsats till 'MQTTSVR.local'. Skulle mDNS -biblioteket bli mer stabilt i framtiden lägger jag till den här funktionen till enheten.

Det hade varit trevligt att ha ett sätt att både noggrant övervaka och kontrollera luftfuktigheten för att kalibrera sensorerna mot. Emellertid ger den valda kalibreringsmetoden bra relativa avläsningar och verkar rimligt korrekt i enlighet med specifikationen i DHT22 -databladet.

Slutligen, med tanke på programvarans komplexitet, fann jag att det var tidskrävande att testa koden efter en stor förändring. Jag kan överväga automatiserad testning vid ett senare tillfälle.

Steg 9: Referenser används

Jag använde följande källor för att sätta ihop denna instruerbara;

PubSubClient.h

• Av: Nick O'Leary
• Från:

DHT.h

• Av: Adafruit
• Från:

DHT22 -datablad