WiFi IoT temperatūras un mitruma sensors. Daļa: 8 IoT, mājas automatizācija: 9 soļi

2024 Autors: John Day | [email protected]. Pēdējoreiz modificēts: 2024-01-30 10:58

Preambula

Šajā rakstā ir dokumentēta iepriekšējās Instructable praktiskā izturība un turpmākā attīstība: jūsu pirmās IoT WiFi ierīces “pimping”. 4. daļa: IoT, mājas automatizācija, ieskaitot visu nepieciešamo programmatūras funkcionalitāti, lai nodrošinātu veiksmīgu izvietošanu mājas apstākļos.

Ievads

Kā minēts iepriekš, šajā pamācībā aprakstīts agrāka IoT piemēra apvienošana ar uzticamu sistēmas dizainu, kas ļauj veiksmīgi risināt praktiskas lietošanas gadījumus, piemēram; Katastrofāli enerģijas zudumi, MQTT Brokera kļūme, WiFi N/W kļūme, sensora pārkonfigurācija, konfigurējama ziņošanas stratēģija, lai samazinātu tīkla trafiku un pielāgotu sensoru kalibrēšanu.

Kopumā tika izveidotas 6 izslēgtas ierīces (skat. 1. attēlu) un izplatītas pa manām mājām, lai izveidotu pirmo IoT sensoru tīklu.

Instructable redz arī MQTT nosaukumu konvencijas pārskatīšanu, kas izmantota sākotnējā IoT mājas automatizācijas sērijā, dodot iespēju līdzsvarotākam, praktiskākam struktūrai, kas ļauj vienkāršāk atkratīt IoT trafiku vairāku IoT ierīču vidē.

Tālāk ir sniegta pilna IoT sensora dizaina informācija, ieskaitot; konstrukciju, pirmkodu, testēšanas stratēģiju un OpenHAB konfigurācijas.

Kādas detaļas man ir vajadzīgas?

1. 1 atlaide ESP8266-01,
2. 2 izslēgti 1uF elektrolītiskie kondensatori,
3. 3 off 10K rezistori,
4. 1 izslēgts 330R rezistors,
5. 1 no 3 mm diametra. LED,
6. 1 izslēgts LD1117-33v, 3v3 LDO VReg. (Farnell šeit),
7. 1 izslēgts DHT22 temperatūras/mitruma sensors,
8. 1 izslēgts Dual 4way 0,1 "savienotājs,
9. 1 atlaide CAMDENBOSS RX2008/S-5 plastmasas korpuss, kastīte, ABS, 38 mm, 23 mm (Farnell šeit),
10. 1 izslēgts līdzstrāvas savienotājs, kontaktdakša, 1 A, 2 mm, paneļa stiprinājums (Farnell šeit),
11. 1 off TO-220 radiators 24,4 ° C/W (Farnell šeit),
12. Dažādas termiski saraušanās caurules (dzeltenas, Ebay šeit),
13. Dažāda garuma IDC lentes kabelis,
14. Radiatora savienojums,
15. Veroboard,
16. Programmēšanas ierīce ESP8266-01. Skatīt šeit; Praktiska shēmas konstrukcija ar sloksnes dēli, 9. solis.

Kāda programmatūra man ir nepieciešama?

1. Arduino IDE 1.6.9
2. Arduino IDE ir konfigurēts programmēt ESP8266-01. Skatīt šeit; Arduino IDE iestatīšana ESP8266-01 programmēšanai

Kādi rīki man ir nepieciešami?

1. Lodāmurs,
2. Urbis un dažādi uzgaļi,
3. Faili,
4. Zāģis,
5. Stingrs netikums,
6. Siltuma lielgabals,
7. DMM.

Kādas prasmes man vajadzīgas?

1. Minimāla elektronikas izpratne,
2. Zināšanas par Arduino un tā IDE,
3. Elementāras ražošanas prasmes (lodēšana, zāģēšana, zāģēšana, vīlēšana, urbšana utt.),
4. Nedaudz pacietības,
5. Zināšanas par jūsu mājas tīklu.

Tēmas, uz kurām attiecas

1. Ķēdes pārskats
2. Programmatūras sistēmas pārskats
3. Programmatūras pārskats
4. Sensora kalibrēšana
5. Konvencija par tēmu nosaukšanu MQTT
6. OpenHAB konfigurācija
7. Dizaina pārbaude
8. Secinājums
9. Izmantotās atsauces

Sēriju saites

7. daļai: Pētījuma gaismas kontrolieris (pārstrādāts). 7. daļa: IoT, mājas automatizācija

Uz 9. daļu: IoT tīkla kontrolleris. 9. daļa: IoT, mājas automatizācija

1. darbība: shēmas pārskats

1. attēlā parādīts IoT sensora pilns ķēdes dizains.

IoT ierīces centrā ir ESP8266-01, kas ir savienots ar DHT22 temperatūras/mitruma sensoru, izmantojot 10K uzvilkšanas pretestību GPIO2. Ārējais 5v tiek piegādāts ar barošanas avotu ar komutācijas režīmu un tiek piegādāts ierīcei caur 2 mm līdzstrāvas paneļa stiprinājuma kontaktligzdu un tiek lokāli regulēts ar LD1117-33v, 3v3 LDO sprieguma regulatoru, kas piestiprināts pie ārējā siltuma izlietnes ar BZP M3 pannas galvas skrūvi un uzgriezni.

Dizains ietver 3 mm sarkanu gaismas diodi, kas savienota ar GPIO0, ko izmanto, lai sniegtu vietējas norādes par IoT ierīces statusu palaišanas laikā vai jebkādiem turpmākiem kļūdas apstākļiem. To var arī izmantot, lai identificētu ierīci, manuāli aktivizējot to, izmantojot interfeisu openHAB.

Pilns dizains lieliski iekļaujas ABS kastē, kā parādīts iepriekš 2. attēlā, un tika īpaši izstrādāts, lai nodrošinātu, ka sensors atrodas pēc iespējas tālāk no regulatora, lai novērstu novirzes vietējo sildīšanas efektu dēļ (7. attēls iepriekš).

Shēmas plate ir viens verboarda gabals, sagriezts pēc formas un izgatavots tā, lai ietilptu korpusā (3. attēls iepriekš). Šī plāksne ir nostiprināta ar M3 iegremdētu neilona skrūvi un diviem uzgriežņiem, kas ir vienā līmenī ar sensora apakšpusi, tādējādi ļaujot tai sēdēt uz līdzenas virsmas.

4.… 6. attēlā parādīti dažādi būvniecības stāvokļi.

2. darbība. Programmatūras sistēmas pārskats

Šī IoT temperatūras un mitruma noteikšanas ierīce satur sešus galvenos programmatūras komponentus, kā parādīts 1. attēlā.

SPIFFS

Šī ir iebūvētā SPI zibspuldzes kartotēkas sistēma, un to izmanto šādas informācijas glabāšanai (skatīt 2. attēlu);

• Ikonas un “Sensora konfigurācijas sākumlapa” html: to nodrošina IoT ierīce, ja tā nevar izveidot savienojumu ar jūsu IoT WiFi tīklu (parasti nepareizas drošības informācijas dēļ) un nodrošina lietotājam iespēju attālināti konfigurēt sensoru bez nepieciešamības lai pārprogrammētu vai augšupielādētu jaunu SPIFFS saturu.
• Drošības informācija: tajā ir informācija, ko IoT ierīce ieslēdz, lai izveidotu savienojumu ar jūsu IoT WiFi tīklu un MQTT Broker. Informācija, kas iesniegta, izmantojot sensoru konfigurācijas sākumlapu, tiek ierakstīta šajā failā (“secvals.txt”).
• Kalibrēšanas informācija: šajā failā ietvertā informācija (“calvals.txt”) tiek izmantota, lai vajadzības gadījumā kalibrētu iebūvēto temperatūras/mitruma sensoru. Kalibrēšanas konstantes IoT ierīcē var ierakstīt tikai, izmantojot MQTT starpnieka MQTT komandas.

Piezīme. Lai sākotnēji iestatītu ierīci, skatiet šeit visu informāciju par to, kā izmantot SPIFFS ar Arduino IDE.

mDNS serveris

Šī funkcija tiek izmantota, ja IoT ierīcei nav izdevies izveidot savienojumu ar jūsu WiFi tīklu kā WiFi staciju un tā vietā tā ir kļuvusi par WiFi piekļuves punktu, kas ir līdzīgs vietējam WiFi maršrutētājam. Šāda maršrutētāja gadījumā jūs parasti izveidojat savienojumu ar to, ievadot IP adresi, piemēram, 192.168.1.1 (parasti uzdrukāts uz lodziņa piestiprinātas etiķetes), tieši pārlūkprogrammas URL joslā, pēc kuras jūs saņemsiet pieteikšanās lapu, lai ievadītu lietotājvārdu un paroli, lai varētu konfigurēt ierīci.

Ja ESP8266 ir AP režīmā (piekļuves punkta režīms), ierīces noklusējuma IP adrese ir 192.168.4.1, tomēr, darbojoties mDNS serverim, pārlūkprogrammas URL joslā ir jāievada tikai cilvēkiem draudzīgs vārds “SENSORSVR.local”, lai redzētu 'Sensora konfigurācijas sākumlapa'.

MQTT klients

MQTT klients nodrošina visu nepieciešamo funkcionalitāti; izveidojiet savienojumu ar savu IoT tīkla MQTT brokeri, abonējiet izvēlētās tēmas un publicējiet konkrētās tēmas derīgās slodzes. Īsāk sakot, tas nodrošina IoT pamatfunkcijas.

HTTP tīmekļa serveris

Kā minēts iepriekš, ja IoT ierīce nevar izveidot savienojumu ar WiFi tīklu, kura SSID, P/W utt. Ir definēts drošības informācijas failā, kas atrodas SPIFFS, ierīce kļūs par piekļuves punktu. Kad ir izveidots savienojums ar piekļuves punkta nodrošināto WiFi tīklu, HTTP tīmekļa servera klātbūtne ļauj tieši izveidot savienojumu ar ierīci un mainīt tās konfigurāciju, izmantojot HTTP tīmekļa pārlūkprogrammu, kuras mērķis ir apkalpot sensoru konfigurācijas sākumlapu Page”tīmekļa lapa, kas tiek glabāta arī SPIFFS formātā.

WiFi stacija

Šī funkcionalitāte dod IoT ierīcei iespēju izveidot savienojumu ar vietējo WiFi tīklu, izmantojot drošības informācijas faila parametrus, bez tā jūsu IoT ierīce nevarēs abonēt/publicēt MQTT brokeri

WiFi piekļuves punkts

Iespēja kļūt par WiFi piekļuves punktu ir līdzeklis, ar kuru IoT ierīce ļauj jums izveidot savienojumu ar to un veikt izmaiņas konfigurācijā, izmantojot WiFi staciju un pārlūkprogrammu (piemēram, Safari Apple iPad ierīcē).

Šis piekļuves punkts pārraida SSID = "SENSOR" + IoT ierīces MAC adreses pēdējos 6 ciparus. Šī slēgtā tīkla parole ir iedomāti nosaukta par PASSWORD

3. darbība: programmatūras pārskats

Lai veiksmīgi apkopotu šo avota kodu, jums būs nepieciešamas šādas papildu bibliotēkas;

PubSubClient.h

• Autors: Niks O'Līrijs
• Mērķis: Ļauj ierīcei publicēt vai abonēt MQTT tēmas ar noteiktu starpnieku
• No:

DHT.h

• Autors: Adafruit
• Mērķis: DHT temperatūras/mitruma sensora bibliotēka
• No:

Koda pārskats

Programmatūra izmanto stāvokļa mašīnu, kā parādīts 1. attēlā (pilna avota kopija, kas norādīta zemāk). Ir 5 galvenie stāvokļi, kā norādīts zemāk;

• TAJĀ

  Šis inicializācijas stāvoklis ir pirmais stāvoklis, kas ievadīts pēc ieslēgšanas

• NOCONFIG

  Šis stāvoklis tiek ievadīts, ja pēc ieslēgšanas tiek konstatēts nederīgs vai trūkstošs fails secvals.txt

• GAIDA ZR

  Šis stāvoklis ir pārejošs, ievadīts, kamēr nav WiFi tīkla savienojuma

• GAIDA MQTT

  Šis stāvoklis ir pārejošs, tas tiek ievadīts pēc tam, kad ir izveidots WiFi tīkla savienojums, un, kamēr šajā tīklā nav savienojuma ar MQTT brokeri

• AKTĪVS

  Tas ir normāls darbības stāvoklis, kas ievadīts, tiklīdz ir izveidots gan WiFi tīkla savienojums, gan MQTT Broker savienojums. Tieši šajā stāvoklī sensora temperatūras un mitruma funkcionalitāte tiek publicēta MQTT Broker

Notikumi, kas kontrolē pārejas starp stāvokļiem, ir aprakstīti 1. attēlā iepriekš. Pārejas starp valstīm nosaka arī šādi SecVals parametri;

• 1. MQTT brokera IP adrese. Punktveida decimālā formā AAA. BBB. CCC. DDD
• 2. MQTT brokeru osta. Vesela skaitļa formā.
• Trešais MQTT Broker savienojums mēģina izveidot pirms pārslēgšanās no STA režīma uz AP režīmu. Vesela skaitļa formā.
• 4. WiFi tīkla SSID. Brīvā formā.
• Piektā WiFi tīkla parole. Brīvā formā.

Kā minēts iepriekš, ja IoT ierīce nevar izveidot savienojumu ar WiFi staciju ar WiFi tīklu, kura SSID un P/W ir definēts failā secvals.txt, kas tiek glabāts SPIFFS, IoT ierīce kļūs par piekļuves punktu. Kad būs izveidots savienojums ar šo piekļuves punktu, tas parādīs 'Sensora konfigurācijas sākumlapu', kā parādīts 2. attēlā (pārlūkprogrammas URL adreses joslā ievadot 'SENSORSVR.local' vai 192.168.4.1). Šī mājas lapa ļauj pārkonfigurēt sensoru, izmantojot HTTP pārlūkprogrammu.

Attālā piekļuve, atrodoties AKTĪVĀ stāvoklī

Kad ir izveidots savienojums ar MQTT brokeri, ir iespējams gan atkārtoti kalibrēt, gan pārkonfigurēt ierīci, izmantojot MQTT tēmu publikācijas. Failam calvals.txt ir R/W piekļuve, un secvals.txt ir atklāta tikai rakstīšanas piekļuve.

Lietotāja atkļūdošana

Sāknēšanas secības laikā IoT ierīces vadība sniedz šādu atkļūdošanas atgriezenisko saiti

• 1 Īsa zibspuldze: SPIFFS (secvals.txt) nav konfigurācijas faila
• 2 Īsi mirgo: IoT ierīce mēģina izveidot savienojumu ar WiFi tīklu
• Nepārtraukts apgaismojums: IoT ierīce mēģina izveidot savienojumu ar MQTT Broker
• Izslēgts: ierīce ir aktīva
• 1. piezīme. Sensora konfigurācijas sākumlapā netiek izmantotas drošas kontaktligzdas, un tāpēc jūsu tīkls ir drošs.
• 2. piezīme. Lai ieprogrammētu katru IoT ierīci, pirms lejupielādes MQTT virkne būs jārediģē. Tas ir tāpēc, ka sensora numurs ir iestrādāts MQTT tēmas virknē. ti. “WFD/THSen/100/HumdStatus/1” manām 6 ierīcēm tās ir attiecīgi numurētas 1… 6.

4. solis: Sensora kalibrēšana

Kad IoT ierīce tiek ieslēgta, sāknēšanas secības ietvaros no SPIFFS tiek nolasīts fails ar nosaukumu "cavals.txt". Šī faila saturs ir kalibrēšanas konstantes, kā norādīts iepriekš 1. attēlā. Šīs kalibrēšanas konstantes tiek izmantotas, lai pielāgotu no sensora iegūtos rādījumus, lai tie atbilstu atsauces ierīcei. Ir vēl viena vērtība, kas nosaka ierīces ziņošanas stratēģiju, un tā ir aprakstīta zemāk kopā ar sensoru kalibrēšanas procedūru.

Ziņošanas stratēģija Šis parametrs nosaka, kā tālvadības sensors ziņo par visām lokālajām apkārtējās vides parametru izmaiņām. Ja ir izvēlēta vērtība 0, tālvadības sensors publicēs visas izmaiņas, ko tā redz temperatūras vai mitruma vērtībās katru reizi, kad sensors tiek nolasīts (apmēram ik pēc 10 sekundēm). Jebkura cita vērtība aizkavēs izmaiņu publicēšanu par 1… 60 minūtēm. Šī parametra modificēšana ļauj optimizēt MQTT tīkla trafiku.

Temperatūras kalibrēšana

Lai kalibrētu sensorus, tie tika novietoti tiešā fiziskā tuvumā viens otram, kā parādīts 2. attēlā. Gar tiem es ievietoju DMM ar pievienotu kalibrētu termopāri (Fluke 87 V) un pēc tam uzraudzīju katras ierīces izejas, izmantojot OpenHAB temperatūru tendences lapā dienas laikā, lai iegūtu labu temperatūras svārstību. Es atzīmēju gan statisko nobīdi (paaugstināta nulle “C”), gan katras ierīces izmaiņu ātrumu (ieguvums vai grafika “M” slīpums) attiecībā pret vērtību, kas nāk no kalibrētā termopāra. Pēc tam es aprēķināju vienkāršo y = mx+c sakarību (es atklāju, ka tā ir pietiekami lineāra, lai būtu tuvu taisnās līnijas grafikam) un ieprogrammēju visas nepieciešamās korekcijas kalibrēšanas konstantēs, izmantojot MQTTSpy.

Pēc tam ierīces tika uzraudzītas vēl 24 stundas, lai pārliecinātos, ka kalibrēšana bija veiksmīga. Norāde par to, kas bija temperatūras pēdas OpenHAB temperatūras tendenču lapā, bija gandrīz viena virs otras.

Protams, ja jūs interesē tikai temperatūras tuvināšana, visas kalibrēšanas vērtības varat atstāt kā noklusējuma vērtības.

Mitruma kalibrēšana

Tā kā man nav līdzekļu, lai precīzi reģistrētu vai pat kontrolētu vietējo apkārtējā gaisa mitrumu, lai kalibrētu sensorus, es izmantoju līdzīgu pieeju iepriekšminētajai, novietojot visas ierīces fiziskā tuvumā (2. attēls) un vienkārši uzraugot to izvadi, izmantojot OpenHAB Mitruma tendences lapa. Pēc tam es izvēlējos ierīci #1 kā kalibrēšanas atsauci un kalibrēju visas ierīces attiecībā pret šo.

5. solis: MQTT tēmu nosaukšanas konvencija

Pēc daudziem izmēģinājumiem un kļūdām es izšķīros par tēmu nosaukšanas konvenciju, kas aprakstīta 1. attēlā.

Proti, "AccessMethod/DeviceType/WhichDevice/Action/SubDevice"

Tas nav ideāls, taču tas ļauj izmantot noderīgus filtrus, lai redzētu visas sensora izejas noteiktā parametra vērtībā, tādējādi ļaujot viegli salīdzināt, kā parādīts 2. attēlā ar MQTTSpy. Tas arī atbalsta pietiekami paplašināmas loģiskas funkcionalitātes grupas noteiktā IoT ierīcē.

Īstenojot šīs tēmas programmatūrā, es izmantoju grūti kodētas tēmu virknes ar fiksētiem, iegultiem ciparu identifikatoriem katrai ierīcei, nevis dinamiski ģenerējot tēmas izpildes laikā, lai ietaupītu RAM un saglabātu augstu veiktspēju.

Piezīme. Ja neesat pārliecināts, kā izmantot MQTTSpy, skatiet šeit 'MQTT brokera iestatīšana'. 2. daļa: IoT, mājas automatizācija”

6. darbība: OpenHAB konfigurācija

Es mainīju OpenHAB konfigurāciju, kas norādīta iepriekšējā Instructable (šeit) un pievienota atsevišķos ierakstos;

• Garāža,
• Zāle,
• Dzīvojamā istaba,
• Virtuve
• Viesu guļamistaba
• Galvenā guļamistaba

Vietnes kartē skatiet 1. attēlu iepriekš.

Katram no šiem ierakstiem es pievienoju atsevišķas vietņu kartes, kas atklāja apkārtējās vides vērtības (skat. 2. attēlu);

• Temperatūra
• Mitrums
• Siltuma indekss

Es arī iekļāvu slēdzi, lai kontrolētu sensorā uzstādīto vietējo LED.

Attēlos 3… 5 ir redzamas individuālas tiešas pēdas 24 stundu laikā attiecībā uz temperatūru, mitrumu un RSSI (uztvertā signāla stipruma indikācija, būtībā mērījums, cik labi sensors var redzēt WiFi tīklu).

6. attēlā sniegts piemērs par ilgtermiņa mitruma tendenci nedēļas laikā.

1. piezīme. Ja neesat pārliecināts, kā izmantot OpenHAB, skatiet šeit 'OpenHAB iestatīšana un konfigurēšana. 6. daļa: IoT, mājas automatizācija”

2. piezīme. Modificētās vietnes kartes, noteikumu un vienumu failu, ikonu uc kopija ir sniegta zemāk.

7. darbība: dizaina pārbaude

Lielākoties es pārbaudīju IoT ierīci, izmantojot MQTT savienojumu ar MQTT Spy, pārraugot led izeju un atkļūdošanas trafiku sērijas saskarnē. Tas ļāva man izmantot visas pieejamās abonētās tēmas un pārbaudīt publicētās atbildes. Lai gan tas tika panākts manuāli un reizēm kļuva mazliet garlaicīgs, tas nodrošināja 100% pārklājumu.

Tomēr galvenā stāvokļa mašīna izrādījās nedaudz sarežģīta, lai to pārbaudītu, jo tā paļāvās uz WiFi tīkla esamību vai neesamību, kuram piekļuvei ir nepieciešamas īpašas parametru kopas. Šim nolūkam vienkārši nebija praktiski izmantot mājas tīklu.

Lai novērstu šo problēmu, es izveidoju savu fiktīvo tīklu komplektu, izmantojot ESP8266-01, kas konfigurēts kā piekļuves punkti (1. attēls) ar SSD attiecīgi “DummyNet1” un “DummyNet2”. Izmantojot 2. attēlā redzamo ķēdi virs gaismas diodes, tika norādīts, vai ar to ir pievienota IoT ierīce. Lai gan tas nebija ideāls testēšanas risinājums (ti, katrā no šiem fiktīvajiem WiFi tīkliem nebija MQTT servera), bija iespējams pilnībā pārbaudīt stāvokļa iekārtu.

Tālāk esmu iekļāvis avota koda kopiju.

8. solis. Secinājums

Vispārīgi

IoT ierīcēs esošā programmatūra jau daudzus mēnešus ir darbojusies droši, atgūstoties no mājsaimniecības strāvas padeves pārtraukumiem (galvenokārt to izraisīju es). Kopumā tās ir diezgan izturīgas ierīces, kas sniedz konsekventus un precīzus datus.

Uzlabojumi

Izstrādājot programmatūras rutīnas, lai lasītu un rakstītu SPIFFS, es uzrakstīju kodu, kas aizmugurē var būt nedaudz progresīvāks, nekā biju iecerējis, izmantojot tukšas norādes, pārstrādāšanu un norādes uz norādēm. Lai gan tas ir ļoti elastīgs un veic darbu labi, nākamreiz es varu izmantot JSON kaut ko līdzīgu ConfigFile.ino, lai tas būtu nedaudz vienkāršāks.

• Arduino GIT HUB Core

  https://github.com/esp8266/Arduino

• ConfigFile.ino Avots

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

Vēlmju saraksts

Es biju nodomājis izmantot mDNS klientu, lai izveidotu savienojumu ar Brokeri, taču bibliotēka bija pārāk nestabila. Šī iemesla dēļ ir jānorāda MQTT Broker IP adrese, nevis “MQTTSVR.local”. Ja mDNS bibliotēka nākotnē kļūs stabilāka, es pievienoju šo iespēju ierīcei.

Būtu jauki, ja būtu līdzekļi gan precīzai apkārtējās vides mitruma kontrolei, gan kontrolei, lai kalibrētu sensorus. Tomēr teikts, ka izvēlētā kalibrēšanas metode dod labus relatīvos rādījumus un šķiet samērā precīza saskaņā ar DHT22 datu lapas specifikāciju.

Visbeidzot, ņemot vērā programmatūras sarežģītību, es atklāju, ka koda pilnīga pārbaude pēc būtiskām izmaiņām kļuva laikietilpīga. Es varētu apsvērt automātisku testēšanu vēlāk.

9. darbība. Izmantotās atsauces

Es izmantoju šādus avotus, lai saliktu šo pamācību;

PubSubClient.h

• Autors: Niks O'Līrijs
• No:

DHT.h

• Autors: Adafruit
• No:

DHT22 datu lapa