🥇ShIoTiny: niiske ruumi ventilatsioon (näidisprojekt)

Põhiteesid või millest see artikkel räägib

Jätkame artiklite tsüklit teemal ShIoTiny — visuaalselt programmeeritav kontroller, mis põhineb kiibil ESP8266.

Selles artiklis räägitakse vannitoa ventilatsiooni juhtimise projekti näitel, kuidas koostada programm ShIoTiny.

Eelmised artiklid sarjast.

ShIoTiny: väike automatiseerimine, asjade internet või „kuus kuud enne puhkust”
ShIoTiny: sõlmed, sidemed ja sündmused või programmide joonistamise eripära

Lingid

Binaarsed firmware'id, kontrolleri skeem ja dokumentatsioon
Juhend ja sõlmede kirjeldus
MQTT brokki seadistamine cloudmqtt.com
MQTT juhtpaneel Androidile

Sissejuhatus

Mõistus ilma kogemuseta ei eksisteeri. See on tõde, mille on tõestanud aeg ja põlvkonnad. Seetõttu pole midagi paremat praktiliste oskuste õppimiseks kui proovida midagi ise teha. Ja näidised, mis näitavad, mida saab teha ja mida ei tasu proovida, tulevad siinkohal väga kasuks. Teiste vead ei suuda kindlasti ära hoida enda vigu, kuid võivad aidata vähendada viimaste arvu.

Eelnevad artiklid ja lugejate kirjad inspireerisid mind looma väikse näidisprojekti, et näidata, kuidas ShIoTiny moodulid ventileerimise juhtimist toimivad.

Algne idee, mille alusel kontroller ilmus, ShIoTiny — pumpamis- ja kastmissüsteem — ei pruugi kõigile sobida ega huvi pakkuda. Seetõttu võtsin näitena lihtsa ja paljudele kasuliku ventileerimise juhtimissüsteemi.

Rääkides sellest, ei ole projekti idee minu, vaid tõin selle siit ja seejärel kohandasin ShIoTiny.

Kõigepealt mõista, mida soovid

Parendamise protsess on lõputu. Just see omadus on tapnud palju häid ideid ja projekte. Arendaja jätkas, selle asemel et välja anda ehk mitte ideaalne, kuid töötav toode — parendamist. Ja ta parendas seda seni, kuni konkurendid möödusid temast, tuues turule ehk mitte ideaalse (ja sageli koguni kohutava), aga töötava lahenduse.

Seetõttu on väga oluline teada, kus projektis punkt paika panna. Teisisõnu, tuleb määratleda, mida me lõpuks alguses olevast saavutada tahame. Eesti keeles on dokumendi jaoks, mis koostatakse eesmärgiga kirjeldada millegi loomise teed, olemas suurepärane lühike ja sisukas sõna „plaan”, mida mõnikord nimetavad vale tõlgenduse tõttu „teekonnakaardiks” mitte professionaalsed tõlgid ja defektsed juhid. Aga las olla.

Meie plaan on järgmine. Oletame, et meil on ruum, kus õhuniiskus võib mõnikord tugevalt tõusta. Näiteks nagu vannituba või köök. Niiskus on ebameeldiv asi ja selle vastu saab võidelda juba iidsetest aegadest: ruumi õhutamine. Õhutamiseks on palju viise. Kuid me loobume eksootilistest ja vanamoelistest meetoditest, nagu näiteks orjad ventilaatoritega, ja piirdume tavalise ventilaatoriga. Ventilaatorid on odavamad ning neid on meie kandis lihtsam leida.

Ühesõnaga, me tahame ventilaatorit kontrollida: lülitada see sisse ja välja. Täpsemalt, me tahame, et see ise lülituks sisse ja välja, kui vaja.

Jääb selgeks teha: millistel tingimustel ventilaator peab sisse lülitama ja millistel tingimustel välja lülitama.

Siin on kõik selge: kui niiskus ületab teatud määra, siis ventilaator lülitub sisse ja tõmbab õhku välja; niiskus normaliseerub — ventilaator lülitub välja.

Hoolikas lugeja märkab kohe sõna „määratud”. Kelle määratud? Kuidas määratud?

Määrata läve niiskust saab mitmeti. Vaadake kaht meetodit: esimene — muutuva takistuse kaudu ja teine — võrgu kaudu MQTT protokolli kaudu. Igal meetodil on omad eelised ja puudused, mis käsitletakse hiljem.

Neile, kes ei saanud aru, selgitan, et „läve niiskus” on selline niiskuse tase, mille ületamisel tuleb ventilaator sisse lülitada.

Järgmine küsimus: kas anda kasutajale õigus ventilaator otse sisse lülitada? See tähendab, sõltumata niiskustasemest, nupule vajutamisel? Me kavandame sellist võimalust. Lõppude lõpuks võib ventilaatorit vajada mitte ainult suurema niiskuse korral, vaid ka ruumist näiteks ebameeldiva lõhna, mida rahvasuus nimetatakse „pahaks lõhnaks“, eemaldamiseks.

Nii et me mõistsime, mida soovime ja isegi veidi, kuidas see töötab. Loetleme lühidalt kõik meie ventilatsioonisüsteemi funktsioonid:

niiskustaseme künnise seadmine (kaks varianti);
niiskustaseme mõõtmine;
ventilaatori automaatne sisselülitamine;
ventilaatori automaatne väljalülitamine;
ventilaatori käsitsi sisselülitamine (nupule vajutamisel).

Nii et plaan on selge. On vajalik teostada kõik ülaltoodud funktsioonid meie programmis. Selle „plaani“ alusel me tegutseme. Alustuseks joonistame seadme struktuurskeemi.

Seadme struktuurskeem

Üldiselt on meil selliseid skeeme kaks. Esimene — variandi jaoks, kus niiskuse läviväärtus on määratud muutuva takistusega. Teine skeem — variandi jaoks, kus niiskuse läviväärtus on määratud võrgus läbi protokolli MQTT.

Kuna need skeemid erinevad vaid ühe elemendi — muutuva takistuse „niiskuse läviväärtuse seadistamine” — poolest, joonistame vaid ühe struktuurses skeemis. Loomulikult näeb struktuurne skeem vastavalt GOST-ile välja teistsugune. Kuid me ei tohiks keskenduda inseneride käsitööle, vaid noorele põlvkonnale. Seetõttu on visuaalsus olulisem.

Nii et, mida me jooniselt näeme? Ventilaator on ühendatud releega Relay1 kontrolleri ShIoTiny. Joonin tähelepanu, et ventilaator on seade, mis töötab kõrgel pingel. Seega, kui keegi soovib sellist teha — olge ettevaatlik. See tähendab, et vähemalt enne, kui panete oma sõrmed või mõõturid skeemi, lülitage välja vähemalt ventilaator. Ja teine tähelepanek. Kui teie ventilaator on võimsam kui 250 W, siis pole mõtet seda otse ShIoTiny ühendada — ainult läbi käivitaja.

Ventilaatoriga saime hakkama. Nüüd on nupu «manuaalne aktiveerimine» ventilaatorile. See on ühendatud sisendiga Sisend1. Siin polegi rohkem selgitada.

Temperatuuri ja niiskuse andur DHT-11 (või DHT-22 või nende analoogid). Selle ühendamiseks on kontrolleril ette nähtud spetsiaalne sisend ShIoTiny. Nagu pildilt näha — sellise anduri ühendamine ei valmista probleeme.

Ja lõpuks, muutuv takistus, mis määrab niiskuse lävitaseme. Täpsemalt — jagaja, mis koosneb muutuvast ja pidevast takistusest. Probleeme selle ühendamisega ei ole, kuid selgitan, et sisseehitatud A/D muundur on ESP8266 mõeldud maksimaalselt 1V. Seetõttu on vajalik pingejagaja umbes 5 korda.

Ära unusta, et seda jagajat ei vajata, kui niiskuse lävitaseme määrab võrgu kaudu MQTT protokolli abil.

Alustame seadme töö algoritmi koostamist ElDraw ShIoTiny toimetajas. Kuidas sinna pääseda, saab lugeda varasemates artiklites või juhendis, mille link on artikli alguses.

Esimene variant, kõige lihtsam

Alustame lihtsast: relee sisselülitamine Relay1 niiskuse lävitaseme ületamisel kindlaksmääratud ajaks.

Nagu näeme, pole midagi keerulist: kokku neli sõlme, välja arvatud kommentaarsõlmed. DHT11 — see on tegelikult temperatuuri ja niiskuse andur (võib vahetada välja DHT22).

Konstant CONST — niiskuse piiritase protsentides.

Komparaator — sõlm, mis võrdleb kahte arvu ja annab väljundis 1, kui määratud tingimus peab paika, ja 0, kui tingimus ei vasta.

Meie juhul on selliseks tingimuseks A>B, kus A — anduri mõõdetud niiskus, ning B — sama niiskuse piiritase.

Niipea, kui mõõdetud niiskus (A) ületab niiskuse piiritaseme (B), ilmub komparaatori väljundisse A>B 1 ja relee lülitub sisse. Ja vastupidi, kohe, kui niiskus normaliseerub (st A<=B), ilmub komparaatori väljundisse A>B ), ilmub 0 ja relee lülitub välja.

Kas kõik on selge? Kui ei, loe veel kord või vaata sõlmede töö kirjeldust juhendis.

Tõin välja, et andurist saadud andmed DHT11 uuendatakse umbes iga 10 sekundi järel. Seega ei saa relee sisse ja välja lülituda sagedamini kui üks kord 10 sekundi jooksul.

Kõik oleks hästi, aga me tahaksime määrata niiskuse piiritaseme muutuvatest takistidest. Pole midagi lihtsamat!

Lihtsalt asendame konstantse sõlme ADC sõlmega. Just ADC-ule me ühendasime muutuva takistiga pingelõhiku.

Pinged ADC sisendis muutub vahemikus 0 kuni 1 Volt. Aga niiskus anduri väljundis — muutub vahemikus 0 kuni 100%. Kuidas me neid võrreldame? Kõik on lihtne. ADC sõlm ShIoTiny ei mõõda lihtsalt pinget sisendis, vaid oskab seda skaaluda ja nihutada..

See tähendab, et ADC1 (ADC) väljunds on väärtus X, arvutatud valemi järgi

, kus — pinget ADC sisendis (vahemikus 0 kuni 1 V); k — vahemik (ADC vahemik) ja b- nihke (ADC nihke). Nii et kui seada k=100 ja b=0, siis pingete muutumisel vahemikus 0 kuni 1, väärtus X ADC sõlme väljundis muutub vahemikus 0 kuni 100. See tähendab, et numbriliselt on see võrdne niiskuse muutumise vahemikuga 0 kuni 100%.

Või lihtsamalt, pöörates muutuva vastupanu mootori, saab seada niiskuse lävendi vahemikus 0 kuni 100. Ainus ebamugavus on see, et puuduvad kuvamise seadmed. Kuid praktikas, kui teha muutuva takistuse mootori 6 jagu 0%, 20%, 40%, 60%, 80%, 100%) — siis on seda piisavalt, et seada niiskuse lävend.

Kuidas me saame seada koefitsiendid? k — vahemik (ADC vahemik) ja b- nihkejõud (ADC offset)? Jah, see on lihtne nagu lebamine! Klõpsake hiirekursoriga sõlmele ADC1 ja kohe avaneb seadistamise aken. Sellega saate määrata kõik, mida vajate. Meie juhtumi jaoks on see aken nagu pildil.

Nii et meil on lihtne töötav lahendus. Alustame selle täiustamist.
Muide, sellel lihtsaimal lahendusel on üks eelis – see ei vaja internetti. See on täiesti iseseisev.

Teine variant on nuppu ühendada.

Kõik töötab ja kõik on õnnelikud. Aga on probleem, et me ei saa sundida ventilatsiooni sisse lülitada. Oleme juba kokkuleppinud, et sisendisse Sisend1 kasutatakse nuppu, mis lülitab ventilaatori sundsisse ja -välja, ilma niiskuseandurile tähelepanu pööramata.
On aeg töötlema hakata seda nuppu meie skeemis-programmis.

Nupu vajutamise töötlusblokk on esile tõstetud oranži joonaga. See on nuppude vajutuste loenduri, mis nullitakse, kui selle väljund ületab ühe (roheline joon, sõlme väljund) CT).

Siin töötab kõik sama arusaadavalt nagu varem: loendur CT loendab nuppude vajutusi, mis on ühendatud sisendiga. Sisend1. See, the value of this counter increases by 1 with each button press.

As soon as this value reaches two (that is, more than 1), the comparator's output A>B will show 1. And this 1 will reset the counter CT to zero. This refers to the comparator, the lower one in the scheme!

Thus, our button has two states — 0 and 1. If we needed more states (3, 4, or even more) — we would simply change the constant CONST from one to another value.

So, we have two conditions for turning on the fan: exceeding the specified humidity level and a single button press. When either condition is met, the fan will turn on and will run until the button is pressed again JA or the humidity level returns to normal.

Of course, we could complicate the algorithm even further, but we won't do that — let's leave room for creativity for those interested.

Option three, we connect to the internet

Kõik, mida me kirjeldasime, on igati toimiv. Aga kuidas on lood mainega? Iga akne täis hipster-häkker-naerja naerab seda, kes keerab nuppu ja vajutab nuppu, mitte ei kasuta nutitelefoni! Nupu keeramine on „mitte moes“. Aga sõrme hõõrumine nutitelefonil, veretuks seda sõrme hõõrudes — vaat', see on hipster-häkker-naerja unistuste tipp (ma ei ole kunagi suutnud neid eristada — kui eksisin, palun andke andeks).

Aga olgem nende isikute suhtes leebed. Interneti kaudu juhtimisel on ka tõelisi eeliseid. Esiteks, see on visuaalne. On hulk rakendusi, mis on saadaval kõigile platvormidele, mis võimaldavad paaril puudutusel luua täiesti kasutatava juhtpaneeli meie kontroller-karlasun jaoks. Teiseks on see võimalus kaugelt jälgida ruumi õhuniiskuse seisundit. Ja kolmandaks, mitte ainult seda, mida ventilaator teeb — kas see pöörleb või mitte, vaid ka seda, milline niiskuse lävend on seatud. Ja kas ventilaator lülitus sisse automaatselt või käsitsi. Ühesõnaga, kõik, mida soovite.

Loomulikult on mõne ventilaatori jaoks palju head tahet — nii palju tähelepanu. Aga see on vaid näide.

Nii et, internetiühenduse loomiseks kasutame tehnoloogiat MQTT ja sama nime kandvat protokolli.
Kasutamiseks vajame MQTT-vahendajat. See on eriline server, mis teenindab MQTT-kliente, näiteks ShIoTIny ja teie nutitelefoni.

Selle tehnoloogia olemus MQTT on see, et iga klient avaldab MQTT-vahendajale (serverile) mis tahes andmeid kindla nimega (mida nimetatakse teema terminoloogias MQTT). Teised kliendid saavad tellida mis tahes andmeid nende nime kaudu (teema) ja saada uuesti avaldatud andmeid. See tähendab, et kogu andmevahetus toimub kliendi-vahendaja-kliendi põhimõttel.

Mina Ärge muretsege detailide üle. Internetis on palju artikleid ja õpetusi selle kohta, kuidas see toimib MQTT ja milliseid programme on juhtpaneelide loomiseks. Näitan lihtsalt, kuidas andmeid vastuvõtta ja avaldada kasutades ShIoTiny.

Brokernina kasutasin www.cloudmqtt.com, kuid põhimõte on igal pool sama.

Nii et oletame, et olete registreerunud MQTT-vahendajal. Üldiselt annab vahendaja teile (või nõuab välja mõtlema) kasutajanime ja parooli (autentimiseks), samuti pordi ühendamiseks. Ühendage ShIoTiny kellele MQTT brokeri saab teha kahel viisil — tavaline ühendus ja TLS (SSL).

Kõik need parameetrid ShIoTiny sisestatakse vahekaardile Võrgustik, jaotises MQTT serveriga ühendus.

Kui teie MQTT-vahendajat ei nõua autentimist — siis jätke kasutajanimi ja parool tühjaks (jätke need väljad tühjaks).

Parameeter MQTT teema eesliide vajab eraldi selgitust.

MQTT parameetrite eesliide on string, mis lisatakse teema nimele (teema) MQTT brokeris publikatsiooni ja tellimise ajal. Eesliite seadmiseks MQTT eesliide oma kontrolleri jaoks tuleb lihtsalt sisestada väljale "MQTT teema eesliide» («MQTT teema eesliide". Eesliide algab alati kaldkriipsuga («/»)! Kui te ei sisesta kaldkriipsu, lisatakse see automaatselt. Eesliides ei tohi kasutada märke «#» ja «+». Teisi piiranguid ei ole.

Näiteks, kui avaldate parameetri "status" (või tellite selle), ja teie eesliide on määratud "/shiotiny/", siis avaldatakse see parameeter brokeris nime all "/shiotiny/status". Kui teil on määratud tühi eesliide, algavad kõik parameetrid brokeris kaldkriipsuga («/»): «status" avaldatakse kui "/status».

Seega, eeldame, et olete registreerunud MQTT-vahendajal ja saanud kasutajanime, parooli ja portaali. Seejärel olete need parameetrid määranud vahekaardile Võrgustik, jaotises MQTT serveriga ühendus kontrolleri ShIoTiny.

Eeldame, et eesliide on seatud väärtusele "/room/».

Alustame sellega, et avaldame kõigi võtmeparameetrite oleku: relee Relee1, käsitsi sisselülitamise oleku, automaatse sisselülitamise oleku ja lõpuks, niiskustaseme läve ja praegused tasemed. Ja boonusena — toa temperatuur. Kuidas seda teha, vaadake jooniselt.

Kuidas näeme, erinevus eelmisest variandist on ainult sõlmed «MQTT Publish». Arvestades prefiksi, avaldatakse järgmised parameetrid:

Kuidas näeme, kogu süsteemi olek on meil nagu peopesal!

Aga me tahame mitte ainult näha, vaid ka juhtida. Mida teha? Väga lihtne. Me loobume niiskustaseme läve seadmisest läbi ADC ja muutuva takistiga ning seadistame selle niiskustaseme otse MQTT nutitelefonist!

Eemaldame ADC sõlme skeemist ja lülitame sisse kolm uut sõlme: FLASH store, FLASH restore ja MQTT describe.

Sõlme funktsioon MQTT describe on ilmselge: see saab parameetri /room/trigHset (niiskustaseme läve) koos MQTT vahendajalt. Aga mida ta teeb andmetega edasi? Ta lihtsalt annab need üle sõlmele FLASH store, mis omakorda salvestab need andmed energiat mittekaotavasse mällu nimega trigH. Pärast seda loeb sõlm FLASH restore energiata mälust andmed nimega trigH ja ja toimub, me teame juba.

Miks sellised keerukused? Miks ei saa lihtsalt saadud andmeid otse võrdlejale anda?

Nagu ütles kaaslane Š. Holmes — see on elementaarne! Keegi ei garanteeri, et teie seade pärast sisselülitamist ühendub MQTT brokeri. Niiskust tuleb mõõta. Ja ventilaator tuleks sisse lülitada. Kuid ilma teabeta niiskustaseme piirväärtuse kohta on see võimatu! Seetõttu meie seade lülitamisel tõmbab varem salvestatud niiskuse piirväärtuse vahetuks mälust ja kasutab seda otsusteks. Kui ühendus saab loodud MQTT-brokkeriga ja keegi jagab uut väärtust /room/trigHset, siis kasutatakse seda uut väärtust.

Edasi võite välja mõelda mida iganes. Näiteks, lisada niiskuse kõrval ka temperatuuri jälgimine. Või lisada 'nutikad' valgustuse juhtimise võimalused (meil on veel kaks releed ja kaks sisendit kasutamata). Kõik on teie kätes!