Cu ceva timp în urmă, v-am prezentat . Articolul actual a fost inițial conceput ca o demonstrație a firmware-ului său și a sistemului de control. Dar pentru a explica logica de funcționare a termostatului și ceea ce am realizat, este necesar să conturăm întreaga conceptie în ansamblu.
Despre automatizare
În mod condiționat, întreaga automatizare poate fi împărțită în trei categorii:
Categoria 1 — dispozitive „inteligente” separate. Cumpărați de la diferiți producători becuri, ceainice etc. Avantaje: fiecare dispozitiv îmbunătățește funcționalitățile și crește confortul. Dezavantaje: pentru fiecare nou producător este necesară o aplicație proprie. Protocolele dispozitivelor de la diferiți producători sunt adesea incompatible între ele.
Categoria 2 — instalarea unui PC pe o placă unică sau compatibil x86. Acest lucru elimină limitările în ceea ce privește puterea de calcul, iar pe această mașină este instalat MajorDoMo sau orice altă distribuție server pentru managementul casei inteligente. Astfel, dispozitivele majorității producătorilor se conectează într-un spațiu informațional unic. Adică, apare propriul Server pentru casa inteligentă. Avantaje: compatibilitate sub un singur centru, ceea ce oferă posibilități extinse pentru gestionare. Dezavantaje: în cazul unei defectări a serverului, întregul sistem revine la stadiul 1, adică devine dezorganizată sau inutilizabilă.
Categoria 3 — cea mai hardcore opțiune. La etapa de renovare se instalează toate comunicațiile și se dublează toate sistemele. Avantaje: totul este adus la perfecțiune și atunci casa devine într-adevăr inteligentă. Dezavantaje: costuri extrem de mari în comparație cu categoriile 1 și 2, necesitatea de a planifica din timp totul și de a lua în considerare fiecare detaliu.
Majoritatea utilizatorilor aleg opțiunea 1, iar apoi trec treptat la opțiunea 2. Iar în continuare, cei mai perseverenti ajung la opțiunea 3.
Dar există o opțiune care poate fi numită sistem distribuit: fiecare dispozitiv individual va fi și server și client. Practic, este o încercare de a combina opțiunea 1 și opțiunea 2. Luând toate avantajele lor și excluzând dezavantajele, atingând un echilibru ideal.
Poate că cineva va spune că o astfel de variantă a fost deja dezvoltată. Dar aceste soluții sunt îngust definite; pentru persoanele care sunt bine pregătite în programare. Obiectivul nostru este de a reduce pragul de intrare în astfel de sisteme distribuite, atât în ceea ce privește dispozitivele finale, cât și în ceea ce privește integrarea dispozitivelor existente în sistemul nostru. În cazul termostatului, utilizatorul pur și simplu îndepărtează vechiul termostat, instalează unul inteligent și conectează senzorii pe care îi are deja. Fără nicio acțiune suplimentară.
Să analizăm integrarea în sistemul nostru printr-un exemplu.
Să presupunem că avem în rețea 8 module Sonoff. Unora dintre utilizatori le va fi suficient să controleze prin intermediul cloud-ului Sonoff (categora 1). Unii vor folosi firmware de terță parte și vor trece treptat la categoria 2. Majoritatea firmware-urilor de terță parte funcționează pe acelasi principiu: transmiterea datelor către un server MQTT. OpenHub, Majordomo sau orice altceva servesc unui singur scop – acela de a uni dispozitivele disparate într-un spațiu informațional unitar, fie în Internet, fie în rețeaua locală. Prin urmare, existența unui server este obligatorie. De aici reiese principală problemă – în cazul în care serverul cedează, întreaga sistemă încetează să funcționeze autonom. Pentru a preveni acest lucru, sistemele devin mai complexe, fiind adăugate metode manuale de control care dublă automatizarea în cazul unei defecțiuni a serverului.
Noi am ales o altă cale, în care fiecare dispozitiv este autosuficient. Astfel, serverul nu joacă un rol decisiv, ci doar extinde funcționalitatea.
Să revenim la experimentele noastre mentale. Să luăm din nou aceleași 8 module Sonoff și să instalăm firmware-ul Lytko în ele. În toate firmware-urile Lytko este implementată funcția . SSDP este un protocol de rețea, bazat pe un set de protocoale Internet, folosit pentru anunțarea și descoperirea serviciilor de rețea. Răspunsul la cerere poate fi atât standard, cât și extins. Am încorporat în acest răspuns, pe lângă funcțiile standard, crearea unei liste de dispozitive din rețea. Astfel, dispozitivele se găsesc singure și fiecare dintre ele va avea o asemenea listă. Exemplu de listă SSDP:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}După cum se vede în exemplu, lista include id-urile dispozitivelor, adresa IP în rețea, tipul blocului (în cazul nostru - termenostat bazat pe Sonoff). Această listă se actualizează o dată la două minute (această perioadă este suficientă pentru a răspunde la modificările dinamice ale numărului de dispozitive din rețea). Astfel, urmărim adăugarea, modificarea și deconectarea dispozitivelor fără vreo acțiune din partea utilizatorului. Această listă este trimisă către browser sau aplicația mobilă, iar scriptul generează automat pagina cu un număr specificat de blocuri. Fiecare bloc corespunde unui dispozitiv/senzor/controleur. Vizual, lista arată astfel:
Dar dacă la esp8266/esp32 sunt conectate alte radio-senzori prin cc2530 (ZigBee) sau nrf24 (MySensors)?
Despre proiecte
Pe piață există diverse sisteme distribuite. Sistemul nostru permite integrarea cu cele mai populare.
Mai jos sunt prezentate proiecte care, într-un fel sau altul, încearcă să schimbe situația cu necompatibilitatea dintre diferiți producători. Acestea, de exemplu, , sau . este legat de serverul MQTT, prin urmare nu este potrivit pentru exemplu.
Una dintre variantele de implementare MySensors este un gateway bazat pe ESP8266. Celelalte exemple sunt pe ESP32. În ele putem implementa principiul nostru de lucru pentru detectarea și crearea listei de dispozitive.
Să facem un alt experiment mental. Avem un gateway ZESP32 sau SLS Gateway sau MySensors. Cum putem să le unim într-un spațiu informațional comun? La funcțiile standard ale acestor gateway-uri, vom adăuga biblioteca protocolului SSDP. Atunci când ne adresăm acestui controller prin SSDP, acesta va adăuga la răspunsul standard lista de dispozitive conectate la el. Pe baza acestei informații, browserul va genera pagina. În mod general, aceasta va arăta astfel:
Interfața web
Aplicația PWA
"ssdpList":
{
"id": 94967291, // identificatorul unic al dispozitivului
"ip": "192.168.x.x", // adresa ip în rețea
"type": "thermostat" // tipul dispozitivului
},
{
"id": 94967292,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967293,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 13587532,
"type": "switch"
},
{
"id": 98412557,
"type": "smoke"
},
{
"id": 57995113,
"type": "contact_sensor"
},
{
"id": 74123668,
"type": "temperature_humidity_pressure_sensor"
},
{
"id": 74621883,
"type": "temperature_humidity_sensor"
}
Din exemplu, se poate observa că dispozitivele sunt adăugate independent unul de celălalt. Sunt conectate 3 termostate cu adrese IP proprii și 5 senzori diferiți cu ID-uri unice. Dacă senzorul este conectat la rețeaua Wi-Fi, acesta va avea propria adresă IP, iar dacă este conectat la un gateway, adresa IP a dispozitivului va fi adresa IP a gateway-ului.
Pentru a comunica cu dispozitivele, aplicăm WebSocket. Acest lucru permite minimizarea consumului de resurse în comparație cu cererile GET și obținerea informațiilor dinamice la conectare sau modificare.
Datele sunt preluate direct de la dispozitivul căruia îi aparține blocul, ocolind serverul. Astfel, în cazul defectării oricărui dispozitiv, sistemul continuă să funcționeze. Pe interfața web, dispozitivul dispărut din listă nu va fi doar ascuns. Dar un semnal de dispariție, dacă este necesar, va fi trimis sub formă de notificare în aplicația utilizatorului.
Prima încercare de implementare a acestei abordări a fost aplicația PWA. Aceasta permite stocarea bazei de blocuri pe dispozitivul utilizatorului și cererea doar a datelor necesare. Însă, din cauza particularităților structurii, această variantă este incompletă. Și singura soluție este aplicația nativă pentru Android și IOS, care este în prezent în dezvoltare activă. Implicit, aplicația va funcționa doar în rețeaua internă. Dacă este necesar, totul poate fi transferat la gestionarea externă. Astfel, atunci când utilizatorul părăsește rețeaua locală, aplicația trece automat la cloud.
Gestionarea externă — duplicarea completă a paginii. La activarea paginii, utilizatorul se poate loga pe server și gestiona dispozitivele printr-un panou personal. Astfel, Serverul extinde funcționalitatea, permițând gestionarea dispozitivelor din afara casei și fără a fi legat de redirecționarea porturilor sau IP dedicat.
Astfel, varianta descrisă mai sus este lipsită de dezavantajele abordării server, având în plus o serie de avantaje în termeni de flexibilitate în conectarea de noi dispozitive.
Despre termostat
Să analizăm sistemul de gestionare pe baza termostatului nostru.
Prevăzut:
- Reglarea temperaturii fiecărui termostat (afișată sub formă de bloc separat);
- Configurarea programului de funcționare a termostatului (dimineața, ziua, seara, noaptea);
- Selectarea rețelei Wi-Fi și conectarea dispozitivului la aceasta;
- Actualizarea dispozitivului "prin aer";
- Configurarea MQTT;
- Configurarea rețelei la care este conectat dispozitivul.
Pe lângă gestionarea prin interfața web, am prevăzut și o abordare clasică – prin apăsări pe ecran. La bord se află un monitor Nextion NX3224T024 de 2,4 inci. Alegerea a fost făcută datorită simplității de utilizare a acestui dispozitiv. În prezent, se dezvoltă un monitor propriu pe baza STM32. Funcționalitatea sa nu este cu nimic mai prejos decât cea a Nextion, dar va costa mai puțin, ceea ce va influența pozitiv prețul final al dispozitivului.
Ca orice ecran demn de respect al unui termostat, Nextion-ul nostru poate:
- seta temperatura dorită de utilizator (prin butoanele din dreapta);
- activa și dezactiva modul de funcționare conform programului (butonul N);
- afșa activitatea releului (săgeata din stânga);
- dispune de protecție pentru copii (apăsările fizice sunt blocate, până când încuietoarea este deblocat);
- afișa nivelul semnalului WiFi.
De asemenea, cu ajutorul monitorului se poate:
- alege tipul senzorului instalat de utilizator;
- gestiona funcția de protecție pentru copii;
- actualiza firmware-ul.
Prin clic pe bara WiFi, utilizatorul va afla informații despre rețeaua conectată. Codul QR este folosit pentru asocierea dispozitivului în firmware-ul HomeKit.
Demo de lucru cu ecranul:
Am dezvoltat cu trei termostate conectate.
Te vei întreba: "Care este particularitatea termostatului vostru?" În prezent, pe piață există o mulțime de termostate cu funcție Wi-Fi, programabilitate și control tactil. De asemenea, entuziaștii au scris module pentru interacțiunea cu majoritatea sistemelor populare de case inteligente (Majordomo, HomeAssistant etc.).
Termostatul nostru este compatibil cu aceste sisteme și dispune de toate funcțiile menționate anterior. Dar aspectul distinctiv este că termostatul este constant îmbunătățit, datorită flexibilității sistemului. Cu fiecare actualizare, funcționalitatea va fi extinsă. Pe lângă metoda standard de gestionare a sistemului (programabil), vom adăuga una adaptivă. Aplicația permite obținerea geolocației utilizatorului. Datorită acestui lucru, sistemul va schimba dinamic modurile de funcționare în funcție de locația acestuia. Iar modulul de vreme va permite să se adapteze la condițiile meteorologice.
Și extensibilitate. Oricine poate înlocui termostatul obișnuit cu al nostru, cu un minim de efort. Am selectat 5 dintre cei mai populari senzori disponibili pe piață și am adăugat suport pentru aceștia. Dar chiar și în cazul caracteristicilor exclusive ale senzorului, utilizatorul poate să-l conecteze la termostatul nostru. Pentru aceasta, va trebui să calibrați termostatul pentru a funcționa cu senzorul specific. Vă vom oferi instrucțiuni.
Atunci când conectați termostatul sau orice alt dispozitiv, acesta apare simultan în toate locurile: atât în interfața web, cât și în aplicația PWA. Adăugarea dispozitivului se face automat: este suficient să-l conectați la rețeaua Wi-Fi.
Sistemul nostru nu are nevoie de un server și, în cazul în care acesta eșuează, nu se transformă într-o dovleac. Chiar și în cazul eșecului unuia dintre componente, sistemul nu intră în modul de avarie. Controlerele, senzorii, dispozitivele - fiecare element este atât server, cât și client, deci este complet autonom.
Pentru cei interesați - rețelele noastre sociale: , , , , .
Email: shop@lytko.com
P.S. nu încurajăm renunțarea la server. De asemenea, avem suport pentru serverul MQTT și un cloud propriu. Scopul nostru este să ducem stabilitatea și fiabilitatea sistemului la un nou nivel de calitate. Astfel, serverul să nu fie un punct slab, ci să completeze funcționalitatea și să facă sistemul mai convenabil.
Sursa: habr.com
