Acum ceva timp v-am prezentat . Acest articol a fost inițial conceput ca o demonstrație a firmware-ului și a sistemului său de control. Dar pentru a explica logica termostatului și ceea ce am implementat, este necesar să conturăm întregul concept în ansamblu.
Despre automatizare
În mod convențional, toate automatizările pot fi împărțite în trei categorii:
Categoria 1 — dispozitive „inteligente” separate. Achiziționați becuri, ceainice etc. de la diferiți producători. Pro: Fiecare dispozitiv extinde capacitățile și sporește confortul. Contra: Fiecare producător nou necesită propria sa aplicație. Protocoalele dispozitivelor de la diferiți producători nu sunt adesea compatibile între ele.
Categoria 2 — instalarea unui PC cu o singură placă sau compatibil x86. Acest lucru elimină restricțiile privind puterea de calcul și MajorDoMo sau orice altă distribuție de server pentru gestionarea unei case inteligente este instalată pe această mașină. Astfel, dispozitivele de la majoritatea producătorilor sunt conectate într-un singur spațiu de informații. Acestea. Apare propriul server pentru o casă inteligentă. Avantaje: compatibilitate sub un singur centru, care oferă capabilități de management îmbunătățite. Contra: dacă serverul eșuează, întregul sistem revine la etapa 1, adică. devine fragmentat sau devine inutil.
Categoria 3 - cea mai hardcore opțiune. În etapa de reparație, toate comunicațiile sunt stabilite și toate sistemele sunt duplicate. Pro: totul este adus la perfecțiune și atunci casa devine cu adevărat inteligentă. Dezavantaje: extrem de scump comparativ cu categoriile 1 si 2, nevoia de a gandi totul din timp si de a tine cont de fiecare mic detaliu.
Majoritatea utilizatorilor aleg opțiunea unu și apoi trec fără probleme la opțiunea a doua. Și apoi cei mai persistenti ajung la varianta 3.
Dar există o opțiune care poate fi numită sistem distribuit: fiecare dispozitiv individual va fi atât un server, cât și un client. În esență, aceasta este o încercare de a lua și combina opțiunea 1 și opțiunea 2. Luați toate avantajele lor și eliminați contra, pentru a prinde media de aur.
Poate cineva va spune că o astfel de opțiune a fost deja dezvoltată. Dar astfel de decizii sunt concentrate îndeaproape; pentru oameni pricepuți în programare. Scopul nostru este de a reduce bariera de intrare în astfel de sisteme distribuite, atât sub formă de dispozitive finale, cât și sub forma integrării dispozitivelor existente în sistemul nostru. În cazul unui termostat, utilizatorul pur și simplu își scoate vechiul termostat, instalează unul inteligent și conectează senzorii existenți la acesta. Fara nici un pas suplimentar.
Să ne uităm la integrarea în sistemul nostru folosind un exemplu.
Să ne imaginăm că avem 8 module Sonoff în rețeaua noastră. Pentru unii utilizatori, controlul prin cloud-ul Sonoff (categoria 1) va fi suficient. Unii vor începe să folosească firmware terță parte și vor trece fără probleme în categoria 2. Cea mai mare parte a firmware-ului terță parte funcționează pe același principiu: transferul de date pe un server MQTT. OpenHub, Majordomo sau oricare altul servesc unui singur scop - de a uni dispozitive disparate într-un singur spațiu de informații situat fie pe Internet, fie într-o rețea locală. Prin urmare, prezența unui Server este obligatorie. Aici apare problema principală - dacă serverul eșuează, întregul sistem încetează să funcționeze autonom. Pentru a preveni acest lucru, sistemele devin mai complexe, se adaugă metode de control manual care dublează automatizarea în cazul unei defecțiuni a serverului.
Am luat o cale diferită, în care fiecare dispozitiv este autosuficient. Astfel, Serverul nu joacă un rol decisiv, ci doar extinde funcționalitatea.
Să revenim la experimentul de gândire. Să luăm din nou aceleași 8 module Sonoff și să instalăm firmware Lytko în ele. Toate firmware-urile Lytko au această funcție . SSDP este un protocol de rețea bazat pe suita de protocoale Internet pentru publicitate și descoperirea serviciilor de rețea. Răspunsul la o solicitare poate fi standard sau extins. Pe lângă funcțiile standard, am inclus în acest răspuns crearea unei liste de dispozitive din rețea. Astfel, dispozitivele în sine se găsesc între ele și fiecare dintre ele va avea o astfel de listă. Exemplu de fișă SSDP:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}După cum puteți vedea din exemplu, lista include ID-urile dispozitivelor, adresa IP din rețea, tipul de unitate (în cazul nostru, un termostat bazat pe Sonoff). Această listă este actualizată o dată la două minute (această perioadă este suficientă pentru a răspunde modificărilor dinamice ale numărului de dispozitive din rețea). În acest fel, urmărim dispozitivele adăugate, modificate și dezactivate fără nicio acțiune a utilizatorului. Această listă este trimisă în browser sau în aplicația mobilă, iar scriptul în sine generează o pagină cu un anumit număr de blocuri. Fiecare bloc corespunde unui dispozitiv/senzor/controler. Din punct de vedere vizual, lista arată astfel:
Dar ce se întâmplă dacă alți senzori radio sunt conectați la esp8266/esp32 prin cc2530 (ZigBee) sau nrf24 (MySensors)?
Despre proiecte
Pe piață există diverse sisteme distribuite. Sistemul nostru vă permite să vă integrați cu cele mai populare.
Mai jos sunt proiecte care într-un fel sau altul încearcă să schimbe situația cu incompatibilitatea diferiților producători între ei. Acesta este, de exemplu, , sau . este legat de un server MQTT, deci nu este potrivit pentru exemplu.
O opțiune pentru implementarea MySensors este un gateway bazat pe ESP8266. Restul exemplelor sunt pe ESP32. Și în ele puteți implementa principiul nostru de funcționare de detectare și creare a unei liste de dispozitive.
Să facem un alt experiment de gândire. Avem un gateway ZESP32 sau SLS Gateway sau MySensors. Cum pot fi combinate într-un singur spațiu informațional? Vom adăuga biblioteca de protocoale SSDP la funcțiile standard ale acestor gateway-uri. Când accesați acest controler prin SSDP, acesta va adăuga o listă de dispozitive care sunt conectate la acesta la răspunsul standard. Pe baza acestor informații, browserul va genera o pagină. În general, va arăta astfel:
Interfață web
Aplicația PWA
"ssdpList":
{
"id": 94967291, // уникальный идентификатор устройства
"ip": "192.168.x.x", // ip адрес в сети
"type": "thermostat" // тип устройства
},
{
"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"
}
Exemplul arată că dispozitivele sunt adăugate independent unul de celălalt. Sunt conectate 3 termostate cu propriile adrese IP și 5 senzori diferiți cu ID-uri unice. Dacă senzorul este conectat la o rețea Wi-Fi, acesta va avea propriul IP; dacă este conectat la un gateway, atunci adresa IP a dispozitivului va fi adresa IP a gateway-ului.
Folosim WebSocket pentru a comunica cu dispozitivele. Acest lucru vă permite să minimizați costurile cu resursele în comparație cu obținerea cererilor și obținerea de informații în mod dinamic atunci când vă conectați sau schimbați.
Datele sunt preluate direct de pe dispozitivul căruia îi aparține blocul, ocolind serverul. Astfel, dacă vreunul dintre dispozitive eșuează, sistemul continuă să funcționeze. Interfața web pur și simplu nu afișează dispozitivul lipsă din listă. Dar un semnal despre pierdere, dacă este necesar, va veni sub forma unei notificări în aplicația utilizatorului.
Prima încercare de a implementa această abordare a fost o aplicație PWA. Acest lucru vă permite să stocați o bază de bloc pe dispozitivul utilizatorului și să solicitați doar datele necesare. Dar din cauza particularităților structurii, această opțiune este incompletă. Și există o singură cale de ieșire - o aplicație nativă pentru Android și IOS, care este în prezent în curs de dezvoltare activă. În mod implicit, aplicația va funcționa numai în rețeaua internă. Dacă este necesar, puteți transfera totul către control extern. Deci, atunci când utilizatorul părăsește rețeaua locală, aplicația trece automat la cloud.
Control extern - duplicarea completă a paginii. Când pagina este activată, utilizatorul se poate conecta la server și poate gestiona dispozitivele prin contul personal. Astfel, Serverul își extinde funcționalitatea, permițându-vă să gestionați dispozitivele în afara casei și să nu fiți legat de port forwarding sau de un IP dedicat.
Astfel, opțiunea de mai sus nu are dezavantajele abordării serverului și, de asemenea, are o serie de avantaje sub formă de flexibilitate în conectarea dispozitivelor noi.
Despre termostat
Să ne uităm la sistemul de control folosind termostatul nostru ca exemplu.
Furnizat:
- Controlul temperaturii pentru fiecare termostat (afisat ca bloc separat);
- Setarea programului de funcționare a termostatului (dimineața, după-amiaza, seara, noaptea);
- Selectarea unei rețele Wi-Fi și conectarea unui dispozitiv la aceasta;
- Actualizarea dispozitivului „over the air”;
- Configurarea MQTT;
- Configurați rețeaua la care este conectat dispozitivul.
Pe lângă controlul prin interfața web, am oferit-o pe cea clasică - făcând clic pe afișaj. Există un monitor Nextion NX3224T024 de 2.4 inchi la bord. Alegerea a căzut asupra lui datorită ușurinței de a lucra cu dispozitivul. Dar dezvoltăm propriul monitor bazat pe STM32. Funcționalitatea sa nu este mai rea decât cea a Nextion, dar va costa mai puțin, ceea ce va avea un impact pozitiv asupra prețului final al dispozitivului.
Ca orice ecran cu termostat care se respectă, Nextion nostru poate:
- setați temperatura cerută de utilizator (folosind butoanele din dreapta);
- porniți și opriți modul de funcționare programat (butonul H);
- funcționarea releului afișajului (săgeata din stânga);
- are protecție pentru copii (clicurile fizice sunt blocate până când încuietoarea este scoasă);
- afișează puterea semnalului WiFi.
În plus, folosind monitorul puteți:
- selectați tipul de senzor instalat de utilizator;
- gestionați funcția de blocare pentru copii;
- actualizați firmware-ul.
Făcând clic pe bara WiFi, utilizatorul va afla informații despre rețeaua conectată. Codul QR este folosit pentru a asocia dispozitivul în firmware-ul HomeKit.
Demo de lucru cu afișajul:
Ne-am dezvoltat cu trei termostate conectate.
Puteți întreba: „Ce este special la termostatul dvs.?” Acum pe piață există multe termostate cu funcție Wi-Fi, funcționare programată și control tactil. Și pasionații au scris module pentru a interacționa cu cele mai populare sisteme de casă inteligentă (Majordomo, HomeAssistant etc.).
Termostatul nostru este compatibil cu astfel de sisteme și are toate cele de mai sus. Dar caracteristica distinctivă este că termostatul este în mod constant îmbunătățit, datorită flexibilității sistemului. Cu fiecare actualizare, funcționalitatea se va extinde. La metoda standard de management al sistemului (după un program), vom adăuga una adaptivă. Aplicația vă permite să obțineți geolocalizarea utilizatorului. Datorită acestui fapt, sistemul va schimba dinamic modurile de operare în funcție de locația sa. Iar modulul meteo vă va permite să vă adaptați la condițiile meteo.
Și extensibilitate. Oricine își poate înlocui termostatul convențional existent cu al nostru. Cu efort minim. Am selectat 5 dintre cei mai populari senzori de pe piață și am adăugat suport pentru aceștia. Dar chiar dacă senzorul are caracteristici exclusive, utilizatorul îl va putea conecta la termostatul nostru. Pentru a face acest lucru, va trebui să calibrați termostatul pentru a funcționa cu un anumit senzor. Vă vom oferi instrucțiuni.
La conectarea unui termostat sau a oricărui alt dispozitiv, acesta apare simultan peste tot: atât în interfața web, cât și în aplicația PWA. Adăugarea unui dispozitiv are loc automat: trebuie doar să-l conectați la rețeaua Wi-Fi.
Sistemul nostru nu are nevoie de un Server, iar dacă eșuează, nu se transformă într-un dovleac. Chiar dacă una dintre componente se defectează, sistemul nu începe să funcționeze într-un scenariu de urgență. Controlere, senzori, dispozitive - fiecare element este atât un Server, cât și un client, deci complet autonom.
Pentru cei interesați, rețelele noastre de socializare: , , , , .
E-mail: [e-mail protejat]
PS Nu vă încurajăm să abandonați serverul. De asemenea, acceptăm un server MQTT și avem propriul nostru cloud. Scopul nostru este să aducem stabilitatea și fiabilitatea sistemului la un nivel cu totul nou. Pentru ca Serverul să nu fie un punct slab, ci să completeze funcționalitatea și să facă sistemul mai convenabil.
Sursa: www.habr.com