WiFi IoT hőmérséklet és páratartalom érzékelő. Rész: 8 IoT, otthoni automatizálás: 9 lépés

2025 Szerző: John Day | [email protected]. Utoljára módosítva: 2025-01-23 14:48

Preambulum

Ez a cikk dokumentálja egy korábbi Instructable gyakorlati megvalósítását és továbbfejlesztését: az első IoT WiFi -eszköz "Pimping" -ét. 4. rész: IoT, otthoni automatizálás, beleértve az összes szükséges szoftverfunkciót a sikeres otthoni környezetben történő telepítéshez.

Bevezetés

Amint fentebb említettük, ez az utasítás leírja egy korábbi IoT -példa összehozását egy megbízható rendszerkialakítással, amely lehetővé teszi a gyakorlati használati esetek sikeres kezelését, mint például; Katasztrofális áramkimaradás, MQTT Broker hiba, WiFi N/W hiba, távoli érzékelő újrakonfiguráció, konfigurálható jelentési stratégia a hálózati forgalom csökkentése és az egyedi érzékelő kalibrálás érdekében.

Összesen 6 kikapcsolt eszközt hoztak létre (lásd a fenti 1. ábrát), és szétosztották otthonomban, hogy létrehozzák az első IoT érzékelő hálózatomat.

Az Instructable az MQTT elnevezési konvenció felülvizsgálatát is látja, amelyet a kezdeti IoT Home Automation sorozatban használtak, és kiegyensúlyozottabb, praktikusabb struktúrát engedett meg, amely lehetővé teszi az IoT -forgalom egyszerűbb hibakeresését több IoT -eszköz környezetben.

Az alábbiakban az IoT -érzékelő teljes tervezési részletei szerepelnek, beleértve; konstrukció, forráskód, tesztelési stratégia és OpenHAB konfigurációk.

Milyen alkatrészekre van szükségem?

1. 1 kedvezmény ESP8266-01,
2. 2 db 1uF elektrolit kondenzátor,
3. 3 db 10K ellenállás,
4. 1 db 330R ellenállás,
5. 1 db 3 mm átmérőjű. VEZETTE,
6. 1 off LD1117-33v, 3v3 LDO VReg. (Farnell itt),
7. 1 kikapcsolás DHT22 hőmérséklet/páratartalom érzékelő,
8. 1 ki Dual 4way 0,1 "csatlakozó,
9. 1 kedvezmény CAMDENBOSS RX2008/S-5 műanyag ház, cserepes doboz, ABS, 38 mm, 23 mm (Farnell itt),
10. 1 db egyenáramú tápcsatlakozó, dugó, 1 A, 2 mm, panelra szerelhető (Farnell itt),
11. 1 off TO-220 hűtőborda 24,4 ° C/W (Farnell itt),
12. Különféle hőre zsugorodó csövek (sárga, Ebay itt),
13. Különböző hosszúságú IDC szalagkábel,
14. Hűtőborda -vegyület,
15. Veroboard,
16. ESP8266-01 programozó eszköz. Lásd itt; Praktikus áramköri felépítés szalaglappal, 9. lépés.

Milyen szoftverre van szükségem?

1. Arduino IDE 1.6.9
2. Az Arduino IDE az ESP8266-01 programozására van konfigurálva. Lásd itt; Az Arduino IDE beállítása az ESP8266-01 programozásához

Milyen eszközökre van szükségem?

1. Forrasztópáka,
2. Fúró és különféle fúrók,
3. Fájlok,
4. Fűrész,
5. Erős vice,
6. Hőfegyver,
7. DMM.

Milyen készségekre van szükségem?

1. Minimális elektronikai ismeretek,
2. Az Arduino és az IDE ismerete,
3. Kezdetleges gyártási készségek (forrasztás, fűrészelés, fűrészelés, fúrás stb.),
4. Némi türelem,
5. Némi megértés az otthoni hálózatról.

Érintett témák

1. Áramkör áttekintés
2. A szoftverrendszer áttekintése
3. Szoftver áttekintés
4. Érzékelő kalibrálása
5. MQTT Téma elnevezési egyezmény
6. OpenHAB konfiguráció
7. A tervezés tesztelése
8. Következtetés
9. Felhasznált hivatkozások

Sorozat linkek

A 7. részhez: Tanulmányi fényvezérlő (átdolgozva). 7. rész: IoT, otthoni automatizálás

A 9. részhez: IoT hálózati vezérlő. 9. rész: IoT, otthoni automatizálás

1. lépés: Áramkör áttekintése

A fenti 1. kép az IoT érzékelő teljes áramkörének kialakítását mutatja.

Az IoT eszköz középpontjában az ESP8266-01 található, amely a DHT22 hőmérséklet/páratartalom érzékelőhöz csatlakozik egy 10K felhúzó ellenálláson keresztül a GPIO2-hez. Egy külső 5 V-ot kapcsolt üzemmódú tápegységről szereznek be, és egy 2 mm-es DC panelre szerelhető aljzaton keresztül táplálják a készülékhez, és helyileg szabályozzák egy LD1117-33v, 3v3 LDO feszültségszabályzóval, amely egy külső hűtőbordára van felszerelve, BZP M3 serpenyőfejű csavarral és anyával.

A kialakítás tartalmaz egy 3 mm -es piros LED -et, amely a GPIO0 -hoz van csatlakoztatva, és amely helyi jelzést ad az IoT -eszköz állapotáról indításkor vagy bármely későbbi hiba esetén. Az eszköz azonosítására is használható az openHAB interfészen keresztül történő manuális aktiválással.

A teljes kialakítás szépen illeszkedik az ABS edénydobozba, amint az a 2. képen látható, és kifejezetten azért lett kialakítva, hogy az érzékelő a lehető legtávolabb legyen a szabályozótól, hogy megakadályozza a helyi fűtési hatások okozta torzítást (fenti 7. kép).

Az áramköri lap egy darab veroboard, formára vágva és illeszkedve a házba (fenti 3. kép). Ezt a táblát egy M3 süllyesztett nejloncsavarral és két anyával rögzítik, amelyek illeszkednek az érzékelő alsó oldalához, így sík felületen ülnek.

A 4… 6. Ábrákon az építés különböző állapotai láthatók.

2. lépés: A szoftverrendszer áttekintése

Ez az IoT hőmérséklet- és páratartalom -érzékelő eszköz hat kulcsfontosságú szoftverkomponenst tartalmaz, amint az a fenti 1. képen látható.

SPIFFS

Ez a fedélzeti SPI Flash Filing System, és a következő információk tárolására szolgál (lásd a fenti 2. ábrát);

• Ikonok és az „Érzékelő konfigurációjának kezdőlapja” html: Az IoT -eszköz szolgálja ki, ha nem tud csatlakozni az IoT WiFi -hálózatához (általában a helytelen biztonsági információk miatt), és lehetőséget biztosít a felhasználó számára az érzékelő távoli konfigurálásához új programozni vagy új SPIFFS tartalmat feltölteni.
• Biztonsági információk: Ez tartalmazza az IoT -eszköz bekapcsolásakor felhasznált információkat, hogy csatlakozzon az IoT WiFi hálózatához és az MQTT Brokerhez. A „Szenzorkonfiguráció honlapján” keresztül beküldött információk ebbe a fájlba íródnak („secvals.txt”).
• Kalibrációs információk: Az ebben a fájlban található információkat („calvals.txt”) a fedélzeti hőmérséklet/páratartalom érzékelő kalibrálására használjuk, ha szükséges. A kalibrálási állandók csak az MQTT bróker MQTT parancsain keresztül írhatók az IoT eszközre.

Megjegyzés: Az eszköz kezdeti beállításához tekintse meg a SPIFFS és az Arduino IDE együttes használatának részleteit.

mDNS szerver

Ezt a funkciót akkor hívják fel, ha az IoT eszköz nem tud WiFi állomásként csatlakozni a WiFi hálózatához, és ehelyett egy WiFi hozzáférési pont lett, valami hasonló a hazai WiFi útválasztóhoz. Egy ilyen útválasztó esetén általában úgy csatlakozna hozzá, hogy például a 192.168.1.1 (általában a dobozra ragasztott címkére nyomtatott) IP -címét közvetlenül a böngésző URL -sávjába írja be, amelyre belépési oldalt kaphat a belépéshez a felhasználónevet és jelszót, amely lehetővé teszi az eszköz konfigurálását.

Az ESP8266 AP módban (Hozzáférési pont mód) az eszköz alapértelmezés szerint a 192.168.4.1 IP -címet használja, azonban az mDNS szerver futásakor csak a böngésző URL -sávjába kell beírnia a „SENSORSVR.local” emberbarát nevet. 'Érzékelő konfigurációs kezdőlap'.

MQTT kliens

Az MQTT kliens minden szükséges funkciót biztosít; csatlakozzon az IoT hálózat MQTT brókeréhez, iratkozzon fel a választott témákra, és tegyen közzé hasznos terheléseket egy adott témában. Röviden, ez biztosítja az IoT alapvető funkcióit.

HTTP webszerver

Amint fentebb említettük, ha az IoT eszköz nem tud csatlakozni ahhoz a WiFi hálózathoz, amelynek SSID -je, P/W stb. A SPIFFS -ben tárolt biztonsági információs fájlban van definiálva, akkor az eszköz hozzáférési pont lesz. Miután csatlakozott a hozzáférési pont által biztosított WiFi hálózathoz, a HTTP webszerver jelenléte lehetővé teszi, hogy közvetlenül csatlakozzon az eszközhöz, és módosítsa annak konfigurációját egy HTTP webböngésző használatával, amelynek célja az „Érzékelő konfigurációs kezdőlap” kiszolgálása Oldal 'weboldal, amely szintén SPIFFS -ben található.

WiFi állomás

Ez a funkció lehetővé teszi, hogy az IoT eszköz csatlakozzon egy hazai WiFi hálózathoz a Biztonsági információ fájl paraméterei segítségével, e nélkül az IoT eszköze nem tud előfizetni/közzétenni az MQTT Broker szolgáltatást

WiFi hozzáférési pont

A WiFi hozzáférési ponttá válás azon eszköze, amellyel az IoT -eszköz lehetővé teszi, hogy csatlakozzon hozzá, és módosítsa a konfigurációt egy WiFi állomáson és egy böngészőn keresztül (például az Apple iPad Safari -ján).

Ez a hozzáférési pont egy SSID = "SENSOR" + az IoT eszköz MAC -címének utolsó 6 számjegyét sugározza. Ennek a zárt hálózatnak a jelszava ötletesen 'PASSWORD'

3. lépés: A szoftver áttekintése

Ennek a forráskódnak a sikeres fordításához a következő extra könyvtárakra lesz szüksége;

PubSubClient.h

• Szerző: Nick O'Leary
• Cél: Lehetővé teszi az eszköz számára, hogy közzétegyen vagy feliratkozzon az MQTT témákra egy adott brókerrel
• Innen:

DHT.h

• Szerző: Adafruit
• Cél: DHT hőmérséklet/páratartalom érzékelő könyvtára
• Innen:

Kód áttekintés

A szoftver a fenti 1. képen látható állapot-gépet használja (a forrás teljes másolata alább). Az alábbiakban 5 fő állapot van;

• BENNE

  Ez az inicializálási állapot az első állapot, amelyet a bekapcsolás után adtak meg

• NOCONFIG

  Ez az állapot akkor lép be, ha a bekapcsolás után érvénytelen vagy hiányzó secvals.txt fájlt észlel

• FÜGGŐBEN

  Ez az állapot átmeneti, és akkor lépett be, ha nincs WiFi hálózati kapcsolat

• FÜGGŐ MQTT

  Ez az állapot átmeneti, egy WiFi hálózati kapcsolat létrehozása után lép be, és bár nincs kapcsolat az adott hálózat MQTT -brókerével

• AKTÍV

  Ez a normál működési állapot, amelyet a WiFi hálózati kapcsolat és az MQTT Broker kapcsolat létrehozása után kell megadni. Ebben az állapotban az érzékelő hőmérséklet- és páratartalom -funkciója megjelenik az MQTT Brokerben

Az állapotok közötti átmenetet szabályozó eseményeket a fenti 1. kép írja le. Az állapotok közötti átmenetet a következő SecVals paraméterek is szabályozzák;

• 1. MQTT Broker IP -cím. Pontozott tizedes formában AAA. BBB. CCC. DDD
• 2. MQTT bróker port. Egész alakban.
• A 3. MQTT Broker kapcsolat megkísérli az STA módról AP módra való váltást. Egész alakban.
• 4. WiFi hálózati SSID. Szabad formában.
• 5. WiFi hálózati jelszó. Szabad formában.

Amint azt fentebb említettük, ha az IoT -eszköz nem képes WiFi állomásként csatlakozni a WiFi -hálózathoz, annak SSID -je és P/W -je a SPIFFS -ben tárolt secvals.txt fájlban van megadva, az IoT -eszköz hozzáférési pont lesz. Miután csatlakozott ehhez a hozzáférési ponthoz, a 2. képen látható módon megjeleníti az „Érzékelő konfigurációs kezdőlapját” (a „SENSORSVR.local” vagy a 192.168.4.1 kód megadásával a böngésző URL -címsorába). Ez a honlap lehetővé teszi az érzékelő újrakonfigurálását egy HTTP böngészőn keresztül.

Távoli hozzáférés ACTIVE állapotban

Miután csatlakozott az MQTT Broker-hez, lehetőség van az eszköz újrakalibrálására és újrakonfigurálására az MQTT témakörben. A calvals.txt fájl R/W hozzáféréssel rendelkezik, a secvals.txt pedig csak írási hozzáféréssel rendelkezik.

Felhasználói hibakeresés

A rendszerindítási folyamat során az IoT eszköz led a következő hibakeresési visszajelzést adja

• 1 Rövid villanás: Nincs konfigurációs fájl az SPIFFS fájlban (secvals.txt)
• 2 Rövid villanások: Az IoT eszköz WiFi -hálózathoz próbál csatlakozni
• Folyamatos megvilágítás: Az IoT eszköz megpróbál csatlakozni az MQTT Brokerhez
• Ki: A készülék aktív
• 1. megjegyzés: Az „Érzékelő konfigurációs kezdőlap” nem használ biztonságos aljzatokat, ezért a hálózat biztonságára támaszkodik.
• 2. megjegyzés: Az egyes IoT -eszközök programozásához az MQTT karakterláncot szerkeszteni kell a letöltés előtt. Ennek oka az, hogy az érzékelő száma be lett ágyazva az MQTT téma karakterláncába. azaz. 'WFD/THSen/100/HumdStatus/1' a 6 eszközömnél 1… 6 -os számmal vannak ellátva.

4. lépés: Az érzékelő kalibrálása

Amikor az IoT eszköz bekapcsol, a rendszerindítási folyamat részeként a „cavals.txt” nevű fájlt olvassa be a SPIFFS fájlból. Ennek a fájlnak a tartalma az 1. képen látható kalibrálási állandók. Ezeket a kalibrálási állandókat használjuk az érzékelőtől kapott értékek beállításához, hogy összhangba hozzuk azokat egy referenciaeszközzel. Van még egy érték, amely meghatározza az eszköz jelentési stratégiáját, és az alábbiakban ismertetjük az érzékelők kalibrálására vonatkozó eljárással együtt.

Jelentési stratégia Ez a paraméter határozza meg, hogy a távoli érzékelő hogyan jelentse a környezeti paraméterek helyi változásait. Ha 0 értéket választ, a távérzékelő minden alkalommal, amikor az érzékelőt leolvassa (kb. 10 másodpercenként) közzéteszi a hőmérséklet- vagy páratartalom -értékekben tapasztalt változásokat. Minden más érték 1… 60 perccel késlelteti a módosítás közzétételét. Ennek a paraméternek a módosítása lehetővé teszi az MQTT hálózati forgalom optimalizálását.

Hőmérséklet kalibrálása

Az érzékelők kalibrálásához a fizikai ábrán látható, közvetlen közelükben helyezkedtek el, amint az a 2. ábrán látható. Melléjük egy DMM -et helyeztem el kalibrált hőelemmel (Fluke 87 V), majd az OpenHAB hőmérsékleten keresztül figyeltem az egyes eszközök kimeneteit. trendoldalt egy nap folyamán, hogy jó hőmérséklet -ingadozást érjen el. Megjegyeztem mind a statikus eltolódást (emelkedett nulla "C"), mind az egyes eszközök változási sebességét (erősítés vagy meredekség az "M" grafikonon) a kalibrált hőelemből származó értékhez képest. Ezután kiszámítottam az egyszerű y = mx+c összefüggést (azt találtam, hogy elég lineáris ahhoz, hogy közel legyen az egyenes vonalú gráfhoz), és az MQTTSpy segítségével programoztam a szükséges korrekciókat a kalibrálási állandókba.

Az eszközöket ezután további 24 órán keresztül ellenőriztük, hogy a kalibrálás sikeres legyen. Annak jelzése, hogy az OpenHAB hőmérsékleti trendoldalán lévő hőmérséklet -nyomok nagyjából egymásra épültek -e.

Természetesen, ha csak a hőmérséklet közelítése érdekli, akkor hagyja az összes kalibrálási értéket alapértelmezettként.

Páratartalom kalibrálás

Mivel nincs módom a helyi környezeti páratartalom pontos rögzítésére vagy akár szabályozására, az érzékelők kalibrálására, a fentiekhez hasonló megközelítést alkalmaztam, az összes eszközt közvetlen fizikai közelségbe helyezve (2. kép), és egyszerűen figyelemmel kísérve a kimenetüket az OpenHAB -on keresztül Páratartalom hajlamos oldal. Ezután az 1. számú eszközt választottam kalibrációs referenciaként, és ehhez képest kalibráltam az összes eszközt.

5. lépés: Az MQTT téma elnevezési egyezménye

Sok próbálkozás és hiba után ráálltam a fenti 1. képen vázolt témanevezési konvencióra.

Nevezetesen: „AccessMethod/DeviceType/WhichDevice/Action/SubDevice”

Nem tökéletes, de lehetővé teszi hasznos szűrők alkalmazását az összes érzékelő kimenetének megtekintéséhez egy adott paraméteres értékhez, így lehetővé teszi a könnyű összehasonlítást, mint a fenti 2. képen az MQTTSpy -vel. Támogatja a funkcionalitás ésszerűen bővíthető logikai csoportosítását is egy adott IoT -eszközön belül.

Ezeknek a témaköröknek a szoftverben történő megvalósításakor minden eszközhöz kemény kódolású témaköröket használtam, rögzített, beágyazott numerikus azonosítókkal, szemben a témák dinamikus generálásával futás közben, hogy megtakarítsam a RAM -ot és magas teljesítményt tartsak fenn.

Megjegyzés: Ha nem biztos benne, hogyan kell használni az MQTTSpy programot, olvassa el itt az MQTT -bróker beállítása című részt. 2. rész: IoT, otthoni automatizálás”

6. lépés: OpenHAB konfiguráció

Módosítottam az OpenHAB konfigurációt, amelyet a korábbi Instructable -ben (itt) adtam meg, és hozzáadtam az egyes bejegyzésekhez;

• Garázs,
• Előszoba,
• Nappali,
• Konyha
• Vendég hálószoba
• Fő hálószoba

Az oldaltérképen lásd a fenti 1. képet.

Mindegyik bejegyzéshez hozzáadtam a helyi környezeti értékeket feltáró egyedi webhelytérképeket (lásd a fenti 2. képet);

• Hőfok
• páratartalom
• Hő index

Tartottam egy kapcsolót is az érzékelőbe szerelt helyi led vezérléséhez.

A 3… 5. Ábrákon 24 órás egyéni élő nyomok láthatók a hőmérséklet, a páratartalom és az RSSI (Received Signal Strength Indication, alapvetően annak mértéke alapján, hogy az érzékelő mennyire jól látja a WiFi hálózatot).

A 6. kép példát mutat egy hosszú távú páratartalom alakulására egy hét alatt.

1. megjegyzés: Ha nem biztos benne, hogyan kell használni az OpenHAB -ot, olvassa el itt az OpenHAB beállítása és konfigurálása című részt. 6. rész: IoT, otthoni automatizálás”

2. megjegyzés: Az alábbiakban a módosított webhelytérkép, szabályok és elemfájlok, ikonok stb. Másolata található.

7. lépés: A terv tesztelése

Nagyrészt az IoT eszközt teszteltem az MQTT kapcsolaton keresztül az MQTT Spy segítségével, figyelemmel kísérve a led kimenetet és a hibakeresési forgalmat a soros interfészen. Ez lehetővé tette számomra, hogy gyakoroljak az összes feliratkozott témát, és ellenőrizzem a közzétett válaszokat. Bár ezt manuálisan sikerült elérni, és időnként kissé unalmassá vált, ez lehetővé tette a 100% -os lefedettséget.

A fő állapotgép azonban kissé bonyolultnak bizonyult a teszteléshez, mivel egy WiFi hálózat jelenlétére vagy hiányára támaszkodott, amelynek eléréséhez speciális paraméterkészletekre van szükség. Egyszerűen nem volt praktikus erre használni az otthoni hálózatot.

Ennek a problémának a kiküszöbölésére létrehoztam saját álhálózat-készletemet az ESP8266-01 segítségével, hozzáférési pontként konfigurálva (1. kép), a „DummyNet1” és „DummyNet2” SSID azonosítókkal. A 2. ábra szerinti áramkör használata a LED fölött jelezte, hogy IoT -eszköz csatlakozott -e hozzá. Bár ez nem volt tökéletes tesztelési megoldás (azaz ezek a dummy WiFi hálózatok nem tartalmaztak MQTT szervert), lehetséges volt az állapotgép teljes körű tesztelése.

Az alábbiakban mellékeltem a forráskód másolatát.

8. lépés: Következtetés

Tábornok

Az IoT -eszközök szoftvere hosszú hónapok óta megbízhatóan működik, és felépül a háztartási áramkimaradásokból (főleg magam okozta). Összességében meglehetősen robusztus eszközök, amelyek következetes és pontos adatokat szolgáltatnak.

Fejlesztések

A SPIFFS -be való olvasáshoz és íráshoz szükséges szoftverrutinok kidolgozásakor olyan kódot írtam, amely utólag látva kissé fejlettebb lehet, mint terveztem, üres mutatókat, átdolgozást és mutatókat használva. Bár nagyon rugalmas és jól végzi a dolgát, legközelebb a JSON -t használhatom a ConfigFile.ino mintájára, hogy egy kicsit egyszerűbb legyen.

• Arduino GIT HUB Core

  https://github.com/esp8266/Arduino

• ConfigFile.ino Forrás

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

Kívánság lista

Szándékomban állt mDNS klienst használni a Brókerhez való csatlakozáshoz, de a könyvtár túl gyenge volt. Ezért szükséges megadni az MQTT Broker IP -címét az „MQTTSVR.local” helyett. Ha a jövőben az mDNS könyvtár stabilabbá válik, hozzáadom ezt a lehetőséget az eszközhöz.

Jó lett volna a környezeti páratartalom pontos felügyeletére és szabályozására szolgáló eszköz az érzékelők kalibrálására. Ez azonban azt jelenti, hogy a választott kalibrálási módszer jó relatív értékeket ad, és ésszerűen pontosnak tűnik a DHT22 adatlap specifikációjával összhangban.

Végül, tekintettel a szoftver összetettségére, azt találtam, hogy a kód teljes tesztelése egy nagy változás után időigényes. Később fontolóra vehetem az automatikus tesztelést.

9. lépés: Felhasznált hivatkozások

A következő források felhasználásával hoztam össze ezt az utasítást;

PubSubClient.h

• Szerző: Nick O'Leary
• Innen:

DHT.h

• Szerző: Adafruit
• Innen:

DHT22 Adatlap