Tezele principale sau despre ce este acest articol
Continuăm seria de articole despre ShIoTiny — un controler programabil vizual bazat pe cipul ESP8266.
În acest articol se discută despre un exemplu de proiect de control al ventilației în baie sau în altă încăpere cu umiditate ridicată și despre cum se construiește programul pentru ShIoTiny.
Articolele anterioare din serie.
Linkuri
Introducere
Fără experiență nu există înțelegere. Este o adevăr vechi demonstrat de timp și generații. Așadar, nu există nimic mai bun pentru a învăța abilități practice decât încercările de a face ceva de unul singur. Iar exemplele care arată ce se poate face și ce nu ar trebui să încerci sunt extrem de utile. Greșelile altora, evident, nu pot preveni apariția propriilor greșeli, dar pot ajuta la reducerea numărului acestora.
Întrebările și mesajele cititorilor articolelor anterioare m-au impulsionat să creez un mic proiect-exemplu de control al ventilației pentru a arăta cum funcționează nodurile ShIoTiny.
Ideea inițială pe baza căreia a fost creat controlerul ShIoTiny — stația de pompare și irigare — nu va fi relevantă pentru toată lumea și nu va interesa pe toată lumea. De aceea, am ales un sistem de control al ventilației, ușor de înțeles și util multora, ca exemplu.
Voi spune că ideea proiectului nu este a mea, iar și apoi am adaptat-o la ShIoTiny.
Începe prin a înțelege ce vrei
Procesul de perfecționare este infinit. Și exact această caracteristică a distrus multe idei și proiecte bune. Dezvoltatorul, în loc să lanseze un lucru poate nu ideal, dar funcțional — a continuat să-l perfecționeze. Și a perfecționat până când concurenții l-au depășit, lansând soluții poate nu ideale (dar adesea total inadecvate), dar funcționale.
Prin urmare, este foarte important să știm unde să punem punctul în proiect. Cu alte cuvinte, trebuie să definim ce dorim să obținem la finalul proiectului din ceea ce avem la început. În limba română, pentru documentul care se elaborează tocmai cu scopul de a descrie drumul de realizare a ceva, există un cuvânt scurt și concis „plan”, pe care traducătorii mai puțin capabili și managerii ineficienți l-au început să îl numească inexplicabil „hartă de traseu”. Dar să le dăm uitării.
Planul nostru va fi astfel. Să presupunem că avem o încăpere în care umiditatea poate crește semnificativ din când în când. De exemplu, o baie sau o bucătărie. Umiditatea este un lucru neplăcut și metoda de a lupta cu ea este la fel de veche ca lumea: aerisirea încăperii. Există multe metode de aerisire. Dar, probabil, ne vom abține de la metodele exotice și învechite, cum ar fi negrii cu evantaie și ne vom concentra pe un ventilator obișnuit. Ventilatoarele sunt mai ieftine și mai ușor de găsit în zona noastră.
Cu alte cuvinte, vrem să controlăm ventilatorul: să-l pornim și să-l oprim în funcție de necesitate. Mai precis, dorim ca acesta să se pornească și să se oprească de la sine, atunci când este necesar.
Rămâne de stabilit: în ce condiții ventilatorul trebuie să se pornească și în ce condiții — să se oprească.
Aici totul este evident: dacă umiditatea depășește un anumit prag stabilit — ventilatorul pornește și extrage aerul; când umiditatea revine la normal — ventilatorul se oprește.
Cineva atent va observa imediat cuvântul „stabilit”. De cine este stabilit? Cum este stabilit?
Pragul de umiditate poate fi setat în mai multe moduri. Vom analiza două dintre ele: primul — cu ajutorul unei rezistențe variabile și al doilea — prin rețea folosind protocolul MQTT. Fiecare dintre aceste metode are avantaje și dezavantaje, care vor fi discutate în continuare.
Pentru cei care nu au înțeles, explic că „umiditatea de prag” este acel nivel de umiditate, la depășirea căruia este necesară pornirea ventilatorului.
Următorul întrebări: ar trebui să oferim utilizatorului dreptul de a porni ventilatorul direct? Adică, indiferent de nivelul umidității, prin apăsarea unui buton? Vom oferi această opțiune. Ventilatorul poate fi necesar nu doar atunci când umiditatea este ridicată, ci și pentru a elimina din cameră, de exemplu, mirosurile neplăcute, cunoscute popular ca „duhoare”.
Deci, am înțeles ce dorim și chiar și puțin despre cum va funcționa. Să enumerăm pe scurt toate funcțiile sistemului nostru de control al ventilației:
- stabilirea unui nivel de umiditate de praj cu două variante;
- măsurarea nivelului de umiditate;
- pornire automată a ventilatorului;
- oprire automată a ventilatorului;
- pornire manuală a ventilatorului (prin apăsarea unui buton).
Deci, planul este clar. Este necesar să implementăm toate funcțiile enumerate mai sus în programul nostru. Pe baza acestui „plan”, vom acționa. La început, vom desena schema structurii dispozitivului.
Schema structurale a dispozitivului
În general, vom avea două astfel de scheme. Prima — pentru varianta în care nivelul de umiditate este setat printr-un rezistor variabil. A doua schemă — pentru varianta în care nivelul de umiditate este setat prin rețea prin protocolul MQTT.
Dar deoarece aceste scheme vor diferi cu un singur element — rezistorul variabil „stabilirea nivelului de umiditate”, vom desena doar o schemă structurală. Sigur, schema structurală conform standardului GOST arată diferit. Dar ne orientăm nu pe ingineri-veterani, ci pe generația tânără. De aceea, claritatea este mai importantă.
Deci, ce vedem în desen? Ventilatorul este conectat la relai Relay1 controlerului ShIoTiny. Vreau să subliniez că ventilatorul este un dispozitiv care funcționează cu tensiune înaltă. Așa că, dacă cineva vrea să realizeze singur așa ceva — fiți prudenți. Adică, cât mai puțin, înainte de a vă introduce degetele sau aparatele de măsură în schemă — deconectați cel puțin ventilatorul. Și o a doua observație. Dacă ventilatorul dumneavoastră are o putere mai mare de 250W, atunci nu-l conectați direct la ShIoTiny — doar printr-un starter.
Am rezolvat problema ventilatorului. Acum, butonul „pornire manuală” a ventilatorului. Acesta este conectat la intrarea Input1. Aici nu este mai nimic de explicat.
Senzor de temperatură și nivel de umiditate DHT-11 (sau DHT-22 sau analogii). O intrare specială pe controller este prevăzută pentru conectarea acestuia ShIoTiny. Așa cum se vede în imagine — conectarea unui astfel de senzor nu prezintă probleme.
Și, în sfârșit, rezistența variabilă care stabilește nivelul de umiditate. Mai exact — un divizor format din rezistențe variabile și constante. Nu sunt probleme cu conexiunea sa, dar voi explica că ADC-ul încorporat pe ESP8266 este proiectat pentru un maxim de 1 Volt. De aceea este necesar un divizor de tensiune de aproximativ 5 ori.
Și încă o dată, reamintesc că acest divizor nu este necesar dacă nivelul de umiditate este setat prin rețea utilizând protocolul MQTT.
Să începem să elaborăm algoritmul de funcționare a dispozitivului în editorul ElDraw ShIoTiny. Cum se poate accesa acest editor, poate fi citit în articolele anterioare sau în instrucțiuni, linkul fiind disponibil la începutul articolului.
Opțiunea întâi, cea mai simplă
Să începem cu ceva simplu: activarea releului Relay1 la depășirea nivelului de umiditate pentru o perioadă specificată.
După cum vedem, nu este nimic complicat: doar patru noduri, fără a lua în considerare nodurile-commentarii. DHT11 — este senzorul de temperatură și umiditate (poate fi schimbat cu DHT22).
Constanta CONST — nivelul de umiditate, exprimat în procente.
Comparatorul — este un nod care compară două numere și emite 1 la ieșire, dacă condiția specificată este îndeplinită și 0 dacă condiția nu este îndeplinită.
În cazul nostru, această condiție va fi A>B, unde A — nivelul de umiditate măsurat de senzor, iar B — nivelul de umiditate de prag menționat anterior.
De îndată ce nivelul de umiditate măsurat (A) depășește nivelul de umiditate de prag (B), comparatorul va emite imediat 1 și releul se va activa. Și invers, de îndată ce nivelul de umiditate revine la normal (adică A>B A<=B va emite 0 și releul se va dezactiva.), comparatorul va emite imediat 1 și releul se va activa. Și invers, de îndată ce nivelul de umiditate revine la normal (adică A>B Este clar? Dacă nu este prea clar — citiți încă o dată sau consultați descrierea funcționării nodurilor din instrucțiuni.
Voi menționa că datele de la senzor
se actualizează cam o dată la 10 secunde. Prin urmare, releul nu va putea să se activeze și să se dezactiveze mai des decât o dată la 10 secunde. DHT11 Totul ar fi în regulă, dar ne-am dorit să stabilim nivelul de umiditate de prag cu ajutorul unui potentiometru. Nu este nimic mai simplu!
Pur și simplu înlocuim nodul-constant cu un nod ADC. Deoarece la ADC am conectat divizorul de tensiune cu potentiometru.
Vom schimba pur și simplu nodul constant pe nodul ADC. De fapt, la ADC am conectat un divisor de tensiune cu un rezistor variabil.
Tensiunea pe intrarea ADC variază de la 0 la 1 Volt. În schimb, umiditatea la ieșirea senzorului variază de la 0 la 100%. Cum le comparăm? Foarte simplu. Nodul ADC în ShIoTiny nu măsoară doar tensiunea de la intrare, ci știe și să o scaleze și să o transleze..
Adică la ieșirea nodului ADC1 va fi valoarea X, calculată după formula
, unde 
— tensiunea de la intrarea ADC (de la 0 la 1V); k — intervalul (ADC range) și b— deplasarea (ADC offset). Astfel, dacă setăm k=100 și b=0, atunci când variază 
în intervalul de la 0 la 1, valoarea X de la ieșirea nodului ADC va varia în intervalul de la 0 la 100. Cu alte cuvinte, numeric egal cu intervalul de schimbare a umidității de la 0 la 100%.
Sau, pe scurt, rotind un potențiometru, putem seta nivelul pragu de umiditate de la 0 la 100. Singura problemă este că nu există dispozitive de afișare. Dar, în practică, dacă potențiometrul are 6 divizii 0%, 20%, 40%, 60%, 80%, 100%) — este suficient pentru a seta nivelul pragu de umiditate.
Cum putem seta coeficientele k — intervalul (ADC range) și b— deplasarea (ADC offset)? E simplu ca bună ziua! Dați click cu mouse-ul pe nodul ADC1 și imediat vi se va deschide o fereastră de configurare. În aceasta puteți seta tot ce aveți nevoie. Pentru cazul nostru, va fi o astfel de fereastră, ca în imagine.
Deci, avem o soluție de bază funcțională. Vom începe să o îmbunătățim.
În plus, această soluție simplă are un avantaj — nu are nevoie de internet. Este complet autonomă.
Varianta a doua, conectăm un buton.
Totul funcționează și toată lumea este fericită. Dar a apărut o problemă, nu putem activa ventilația forțată. Am stabilit deja că la intrare Input1 va fi conectat un buton care va porni și opri ventilatorul forțat, fără a ține cont de senzorul de umiditate.
A venit timpul să procesăm acest buton în schema noastră programATICĂ.
Blocul de procesare a apăsării butonului este evidențiat cu o linie portocalie. Reprezintă un contor al apăsărilor butonului, care se resetează la zero atunci când valoarea de la ieșirea sa depășește unu (linia verde, ieșirea nodului CT).
Totul funcționează la fel de simplu ca înainte: contorul CT numără apăsările butonului conectat la intrare. Input1Adică valoarea de la ieșirea acestui contor crește cu 1 la fiecare apăsare a butonului.
De îndată ce această valoare devine egală cu două (adică mai mare decât 1), imediat la ieșirea comparatorului. A>B aparește 1. Și acest 1 va reseta contorul CT la zero. Se referă la comparator, cel de jos din schemă!
Astfel, butonul nostru are două stări — 0 și 1. Dacă am avea nevoie de mai multe stări (3 sau 4 sau chiar mai multe) — ar fi suficient să schimbăm constanta CONST de la unu la o altă valoare.
Deci, avem două condiții pentru a porni ventilatorul: depășirea unui anumit nivel de umiditate și apăsarea o singură dată a butonului. Când oricare dintre condiții este îndeplinită, ventilatorul se va porni. Și va funcționa până când butonul va fi apăsat din nou Și nivelul de umiditate revine la normal.
Desigur, putem complica și mai mult algoritmul, dar nu o vom face — vom lăsa loc pentru creativitate celor interesați.
A treia variantă, ne conectăm la internet
Tot ce am descris — este absolut funcțional. Dar ce zicem de impresii? Orice hipster-hacker cu acnee va râde de cineva care rotește un buton și apasă un buton, în loc să controleze cu smartphone-ul! A roti butonul este «neinteresant». Dar a glisa degetul pe smartphone, până la sângerare — iată, este apogeul dorințelor hipsterului-hacker (nu am fost niciodată în stare să-i deosebesc, așa că, dacă am greșit, scuze).
Dar să fim indulgenți cu aceste personalități. Controlul prin internet are și avantaje reale. În primul rând, este vizibilitate. Există o mulțime de aplicații pentru toate platformele care permit, cu câteva click-uri, să creezi un panou de control foarte util pentru controllerul nostru. În al doilea rând, permite monitorizarea de la distanță a nivelului de umiditate din încăpere. Și, în al treilea rând, poți vedea nu doar ce face ventilatorul — se învârte sau nu, dar și care este nivelul pragul setat de umiditate. Și dacă ventilatorul s-a pornit automat sau manual. În general, tot ce doriți.
Desigur, pentru un ventilator este multă atenție — dar acesta este doar un exemplu.
Așadar, pentru a ne conecta la internet, vom folosi tehnologia MQTT și protocolul omonim.
Pentru a folosi această tehnologie, avem nevoie de un broker MQTT. Acesta este un server special care deserveste clienți MQTT, de exemplu ShIoTIny și smartphone-ul dvs.
Esenta tehnologiei MQTT constă în faptul că fiecare client publică pe brokerul MQTT (server) date arbitrare sub un nume specific (numit topic în terminologie MQTT). Alți clienți se pot abona la datele dorite conform numelui lor (topic) și pot primi datele publicate recent. Cu alte cuvinte, tot schimbul de date se face pe principiul client-broker-client.
Eu nu voi insista asupra detaliilor. Pe internet există o mulțime de articole și tutoriale despre cum funcționează MQTT și ce programe există pentru a crea panouri de control. Voi arăta cum putem primi și publica date prin intermediul ShIoTiny.
Ca broker, am folosit , dar principiul este același peste tot.
Deci, să presupunem că te-ai înregistrat pe brokerul MQTT. De obicei, brokerul îți va oferi (sau îți va cere să găsești) un nume de utilizator și o parolă (pentru autentificare), precum și un port pentru conectare. Poți conecta ShIoTiny la brokerului MQTT în două moduri — conectare standard și prin TLS (SSL).
Toate aceste parametrii în ShIoTiny sunt introduse pe fila Networking, secțiunea MQTT Connection to server.
Dacă brokerul tău broker MQTT nu necesită autentificare — nu introduce numele de utilizator și parola (lasă aceste câmpuri goale).
Parametru prefixul topicului MQTT necessită explicații separate.
Prefixul parametrilor MQTT este un șir adăugat la numele temei (topic) la publicare și abonare pe brokerul MQTT. Pentru a seta prefixul MQTT pentru controlerul tău, trebuie să-l introduci pur și simplu în câmpul de introducere „Prefixul temei MQTT» («prefixul topicului MQTT”). Prefixul începe întotdeauna cu o bară oblică («/»)! Dacă nu introduci bara oblică în câmpul de introducere — aceasta va fi adăugată automat. În prefix nu pot fi folosite simboluri «#» și «+». Nu există alte restricții.
De exemplu, dacă publici parametrul „status” (sau te abonezi la el), iar prefixul tău este setat ca „/shiotiny/”, atunci pe broker acest parametru va fi publicat sub numele „/shiotiny/status”. Dacă ai setat un prefix gol, atunci toate parametrii de pe broker vor începe cu o bară oblică («/»): «status” se va publica ca „/status».
Deci, să presupunem că te-ai înregistrat pe brokerul MQTT și ai obținut numele de utilizator, parola și portul. Apoi ai introdus acești parametrii pe fila Networking, secțiunea MQTT Connection to server controlerului ShIoTiny.
Să presupunem că prefixul este stabilit la „/room/».
Să începem cu publicarea stării tuturor parametrilor cheie: relee Realay1, starea activării manuale, starea activării automate și, în final, nivelurile de umiditate pragu și curent. Și un bonus — temperatura din cameră. Cum să faci asta, vezi în imagine.
Așa cum vedem, diferența față de versiunea anterioară este doar nodurile „MQTT Publish”. Având în vedere prefixul, se publică următorii parametrii:
După cum vedem, starea sistemului este la îndemână!
Dar nu vrem doar să vedem, ci și să gestionăm. Ce să facem? Foarte simplu. Ne vom abține de la instalarea unui nivel de umiditate de prag prin ADC și un rezistor variabil și vom seta acest nivel de umiditate de prag direct MQTT de pe smartphone!
Eliminăm modul ADC din schemă și conectăm alte trei module noi: FLASH store, FLASH restore și MQTT describe.
Funcția modulului MQTT describe este evidentă: primește parametrul /room/trigHset (nivelul de umiditate de prag) de la brokerul MQTT. Dar ce face cu datele mai departe? Pur și simplu le returnează modulei FLASH store, care, la rândul său, salvează aceste date în memoria non-volatilă sub numele de trigH. După aceea, modulul FLASH restore citește din memoria non-volatilă datele sub numele trigH și ceea ce se întâmplă mai departe știm deja.
De ce sunt necesare aceste complexe? De ce nu putem pur și simplu să dăm datele primite direct comparatorului?
Așa cum spunea tovarășul S. Holmes — este elementar! Nimeni nu garantează că, după activarea dispozitivului dvs., acesta se va conecta la brokerului MQTT. Și umiditatea trebuie măsurată. Și ventilatorul trebuie pornit. Dar fără informații despre nivelul de umiditate de prag, este imposibil! De aceea, dispozitivul nostru, la activare, extrage nivelul de umiditate de prag salvat anterior din memoria non-volatilă și îl folosește pentru a lua decizii. Iar când se va stabili conexiunea cu brokerul MQTT și cineva va publica o nouă valoare /room/trigHset, atunci se va folosi această nouă valoare.
Mai departe, puteți inventa orice doriți. De exemplu, pe lângă umiditate, să monitorizati și temperatura. Sau să adăugați un sistem de iluminat „inteligent” (avem încă două relee și două intrări nefolosite). Totul este în mâinile dvs!
Concluzie
Iată că am discutat despre câteva exemple de implementare a celui mai simplu controler bazat pe ShIoTiny. Poate că va fi util cuiva.
Ca de obicei, sugestii, dorințe, întrebări, greșeli tipografice și altele — pe e-mail: shiotiny@yandex.ru
Sursa: habr.com
