{"id":55356,"date":"2020-01-18T00:00:00","date_gmt":"2020-01-17T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/lytko-obedinyaet"},"modified":"2020-02-18T14:03:28","modified_gmt":"2020-02-18T11:03:28","slug":"lytko-obedinyaet","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/news\/lytko-obedinyaet","title":{"rendered":"Lytko reune\u0219te","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Cu ceva timp \u00een urm\u0103, v-am prezentat termostatul inteligent<\/a><\/noindex>. Articolul actual a fost ini\u021bial conceput ca o demonstra\u021bie a firmware-ului s\u0103u \u0219i a sistemului de control. Dar pentru a explica logica de func\u021bionare a termostatului \u0219i ceea ce am realizat, este necesar s\u0103 contur\u0103m \u00eentreaga conceptie \u00een ansamblu.<\/p>\n

\"Lytko
\n<\/a><\/noindex><\/p>\n

Despre automatizare<\/h3>\n

\n\u00cen mod condi\u021bionat, \u00eentreaga automatizare poate fi \u00eemp\u0103r\u021bit\u0103 \u00een trei categorii:
\nCategoria 1<\/u> \u2014 dispozitive \u201einteligente\u201d separate. Cump\u0103ra\u021bi de la diferi\u021bi produc\u0103tori becuri, ceainice etc. Avantaje: fiecare dispozitiv \u00eembun\u0103t\u0103\u021be\u0219te func\u021bionalit\u0103\u021bile \u0219i cre\u0219te confortul. Dezavantaje: pentru fiecare nou produc\u0103tor este necesar\u0103 o aplica\u021bie proprie. Protocolele dispozitivelor de la diferi\u021bi produc\u0103tori sunt adesea incompatible \u00eentre ele.<\/p>\n

Categoria 2<\/u> \u2014 instalarea unui PC pe o plac\u0103 unic\u0103 sau compatibil x86. Acest lucru elimin\u0103 limit\u0103rile \u00een ceea ce prive\u0219te puterea de calcul, iar pe aceast\u0103 ma\u0219in\u0103 este instalat MajorDoMo sau orice alt\u0103 distribu\u021bie server pentru managementul casei inteligente. Astfel, dispozitivele majorit\u0103\u021bii produc\u0103torilor se conecteaz\u0103 \u00eentr-un spa\u021biu informa\u021bional unic. Adic\u0103, apare propriul Server pentru casa inteligent\u0103. Avantaje: compatibilitate sub un singur centru, ceea ce ofer\u0103 posibilit\u0103\u021bi extinse pentru gestionare. Dezavantaje: \u00een cazul unei defect\u0103ri a serverului, \u00eentregul sistem revine la stadiul 1, adic\u0103 devine dezorganizat\u0103 sau inutilizabil\u0103.<\/p>\n

Categoria 3<\/u> \u2014 cea mai hardcore op\u021biune. La etapa de renovare se instaleaz\u0103 toate comunica\u021biile \u0219i se dubleaz\u0103 toate sistemele. Avantaje: totul este adus la perfec\u021biune \u0219i atunci casa devine \u00eentr-adev\u0103r inteligent\u0103. Dezavantaje: costuri extrem de mari \u00een compara\u021bie cu categoriile 1 \u0219i 2, necesitatea de a planifica din timp totul \u0219i de a lua \u00een considerare fiecare detaliu.<\/p>\n

Majoritatea utilizatorilor aleg op\u021biunea 1, iar apoi trec treptat la op\u021biunea 2. Iar \u00een continuare, cei mai perseverenti ajung la op\u021biunea 3. <\/p>\n

Dar exist\u0103 o op\u021biune care poate fi numit\u0103 sistem distribuit: fiecare dispozitiv individual va fi \u0219i server \u0219i client. Practic, este o \u00eencercare de a combina op\u021biunea 1 \u0219i op\u021biunea 2. Lu\u00e2nd toate avantajele lor \u0219i excluz\u00e2nd dezavantajele, ating\u00e2nd un echilibru ideal. <\/p>\n

Poate c\u0103 cineva va spune c\u0103 o astfel de variant\u0103 a fost deja dezvoltat\u0103. Dar aceste solu\u021bii sunt \u00eengust definite; pentru persoanele care sunt bine preg\u0103tite \u00een programare. Obiectivul nostru este de a reduce pragul de intrare \u00een astfel de sisteme distribuite, at\u00e2t \u00een ceea ce prive\u0219te dispozitivele finale, c\u00e2t \u0219i \u00een ceea ce prive\u0219te integrarea dispozitivelor existente \u00een sistemul nostru. \u00cen cazul termostatului, utilizatorul pur \u0219i simplu \u00eendep\u0103rteaz\u0103 vechiul termostat, instaleaz\u0103 unul inteligent \u0219i conecteaz\u0103 senzorii pe care \u00eei are deja. F\u0103r\u0103 nicio ac\u021biune suplimentar\u0103.<\/p>\n

S\u0103 analiz\u0103m integrarea \u00een sistemul nostru printr-un exemplu. <\/p>\n

S\u0103 presupunem c\u0103 avem \u00een re\u021bea 8 module Sonoff. Unora dintre utilizatori le va fi suficient s\u0103 controleze prin intermediul cloud-ului Sonoff (categora 1). Unii vor folosi firmware de ter\u021b\u0103 parte \u0219i vor trece treptat la categoria 2. Majoritatea firmware-urilor de ter\u021b\u0103 parte func\u021bioneaz\u0103 pe acelasi principiu: transmiterea datelor c\u0103tre un server MQTT. OpenHub, Majordomo sau orice altceva servesc unui singur scop \u2013 acela de a uni dispozitivele disparate \u00eentr-un spa\u021biu informa\u021bional unitar, fie \u00een Internet, fie \u00een re\u021beaua local\u0103. Prin urmare, existen\u021ba unui server este obligatorie. De aici reiese principal\u0103 problem\u0103 \u2013 \u00een cazul \u00een care serverul cedeaz\u0103, \u00eentreaga sistem\u0103 \u00eenceteaz\u0103 s\u0103 func\u021bioneze autonom. Pentru a preveni acest lucru, sistemele devin mai complexe, fiind ad\u0103ugate metode manuale de control care dubl\u0103 automatizarea \u00een cazul unei defec\u021biuni a serverului. <\/p>\n

Noi am ales o alt\u0103 cale, \u00een care fiecare dispozitiv este autosuficient. Astfel, serverul nu joac\u0103 un rol decisiv, ci doar extinde func\u021bionalitatea.<\/p>\n

S\u0103 revenim la experimentele noastre mentale. S\u0103 lu\u0103m din nou acelea\u0219i 8 module Sonoff \u0219i s\u0103 instal\u0103m firmware-ul Lytko \u00een ele. \u00cen toate firmware-urile Lytko este implementat\u0103 func\u021bia SSDP<\/a><\/noindex>. SSDP este un protocol de re\u021bea, bazat pe un set de protocoale Internet, folosit pentru anun\u021barea \u0219i descoperirea serviciilor de re\u021bea. R\u0103spunsul la cerere poate fi at\u00e2t standard, c\u00e2t \u0219i extins. Am \u00eencorporat \u00een acest r\u0103spuns, pe l\u00e2ng\u0103 func\u021biile standard, crearea unei liste de dispozitive din re\u021bea. Astfel, dispozitivele se g\u0103sesc singure \u0219i fiecare dintre ele va avea o asemenea list\u0103. Exemplu de list\u0103 SSDP:<\/p>\n

\"ssdpList\": \n\t{\n\t\t\"id\": 94967291,  \n\t\t\"ip\": \"192.168.x.x\",\n                \"type\": \"termostat\"\n\t}, \n\t{\n\t\t\"id\": 94967282,\n\t\t\"ip\": \"192.168.x.x\",\n                \"type\": \"termostat\"\n\t}<\/code><\/pre>\n
\nDup\u0103 cum se vede \u00een exemplu, lista include id-urile dispozitivelor, adresa IP \u00een re\u021bea, tipul blocului (\u00een cazul nostru - termenostat bazat pe Sonoff). Aceast\u0103 list\u0103 se actualizeaz\u0103 o dat\u0103 la dou\u0103 minute (aceast\u0103 perioad\u0103 este suficient\u0103 pentru a r\u0103spunde la modific\u0103rile dinamice ale num\u0103rului de dispozitive din re\u021bea). Astfel, urm\u0103rim ad\u0103ugarea, modificarea \u0219i deconectarea dispozitivelor f\u0103r\u0103 vreo ac\u021biune din partea utilizatorului. Aceast\u0103 list\u0103 este trimis\u0103 c\u0103tre browser sau aplica\u021bia mobil\u0103, iar scriptul genereaz\u0103 automat pagina cu un num\u0103r specificat de blocuri. Fiecare bloc corespunde unui dispozitiv\/senzor\/controleur. Vizual, lista arat\u0103 astfel:<\/p>\n
\"Lytko
\n
\nDar dac\u0103 la esp8266\/esp32 sunt conectate alte radio-senzori prin cc2530 (ZigBee) sau nrf24 (MySensors)? <\/p>\n
Despre proiecte<\/h3>\n
\nPe pia\u021b\u0103 exist\u0103 diverse sisteme distribuite. Sistemul nostru permite integrarea cu cele mai populare. <\/p>\n
Mai jos sunt prezentate proiecte care, \u00eentr-un fel sau altul, \u00eencearc\u0103 s\u0103 schimbe situa\u021bia cu necompatibilitatea dintre diferi\u021bi produc\u0103tori. Acestea, de exemplu, SLS Gateway<\/a><\/noindex>, MySensors. <\/a><\/noindex> sau ZESP32<\/a><\/noindex>. ZigBee2MQTT <\/a><\/noindex> este legat de serverul MQTT, prin urmare nu este potrivit pentru exemplu. <\/p>\n
Una dintre variantele de implementare MySensors este un gateway bazat pe ESP8266. Celelalte exemple sunt pe ESP32. \u00cen ele putem implementa principiul nostru de lucru pentru detectarea \u0219i crearea listei de dispozitive. <\/p>\n
S\u0103 facem un alt experiment mental. Avem un gateway ZESP32 sau SLS Gateway sau MySensors. Cum putem s\u0103 le unim \u00eentr-un spa\u021biu informa\u021bional comun? La func\u021biile standard ale acestor gateway-uri, vom ad\u0103uga biblioteca protocolului SSDP. Atunci c\u00e2nd ne adres\u0103m acestui controller prin SSDP, acesta va ad\u0103uga la r\u0103spunsul standard lista de dispozitive conectate la el. Pe baza acestei informa\u021bii, browserul va genera pagina. \u00cen mod general, aceasta va ar\u0103ta astfel:<\/p>\n
\"Lytko
\nInterfa\u021ba web<\/i><\/p>\n
\"Lytko
\nAplica\u021bia PWA<\/i><\/p>\n
\"ssdpList\": \n{\n   \"id\": 94967291, \/\/ identificator unic al dispozitivului\n   \"ip\": \"192.168.x.x\", \/\/ adresa ip \u00een re\u021bea\n   \"type\": \"termostat\" \/\/ tipul dispozitivului\n},\n{\n   \"id\": 94967292,\n   \"ip\": \"192.168.x.x\",\n   \"type\": \"termostat\"\n},\n{\n   \"id\": 94967293,\n   \"ip\": \"192.168.x.x\",\n   \"type\": \"termostat\"\n},\n{  \n   \"id\": 13587532, \n   \"type\": \"switch\"  \n},\n{  \n   \"id\": 98412557, \n   \"type\": \"fum\"\n},\n{  \n   \"id\": 57995113, \n   \"type\": \"sensor_contact\"\n},\n{  \n   \"id\": 74123668,\n   \"type\": \"sensor_temperatura_umiditate_presiune\"\n},\n{\n    \"id\": 74621883, \n    \"type\": \"sensor_temperatura_umiditate\"\n}\n<\/code><\/pre>\n
\nDin exemplu, se poate observa c\u0103 dispozitivele sunt ad\u0103ugate independent unul de cel\u0103lalt. Sunt conectate 3 termostate cu adrese IP proprii \u0219i 5 senzori diferi\u021bi cu ID-uri unice. Dac\u0103 senzorul este conectat la re\u021beaua Wi-Fi, acesta va avea propria adres\u0103 IP, iar dac\u0103 este conectat la un gateway, adresa IP a dispozitivului va fi adresa IP a gateway-ului.<\/p>\n
Pentru a comunica cu dispozitivele, aplic\u0103m WebSocket. Acest lucru permite minimizarea consumului de resurse \u00een compara\u021bie cu cererile GET \u0219i ob\u021binerea informa\u021biilor dinamice la conectare sau modificare. <\/p>\n
Datele sunt preluate direct de la dispozitivul c\u0103ruia \u00eei apar\u021bine blocul, ocolind serverul. Astfel, \u00een cazul defect\u0103rii oric\u0103rui dispozitiv, sistemul continu\u0103 s\u0103 func\u021bioneze. Pe interfa\u021ba web, dispozitivul disp\u0103rut din list\u0103 nu va fi doar ascuns. Dar un semnal de dispari\u021bie, dac\u0103 este necesar, va fi trimis sub form\u0103 de notificare \u00een aplica\u021bia utilizatorului. <\/p>\n
Prima \u00eencercare de implementare a acestei abord\u0103ri a fost aplica\u021bia PWA. Aceasta permite stocarea bazei de blocuri pe dispozitivul utilizatorului \u0219i cererea doar a datelor necesare. \u00cens\u0103, din cauza particularit\u0103\u021bilor structurii, aceast\u0103 variant\u0103 este incomplet\u0103. \u0218i singura solu\u021bie este aplica\u021bia nativ\u0103 pentru Android \u0219i IOS, care este \u00een prezent \u00een dezvoltare activ\u0103. Implicit, aplica\u021bia va func\u021biona doar \u00een re\u021beaua intern\u0103. Dac\u0103 este necesar, totul poate fi transferat la gestionarea extern\u0103. Astfel, atunci c\u00e2nd utilizatorul p\u0103r\u0103se\u0219te re\u021beaua local\u0103, aplica\u021bia trece automat la cloud. <\/p>\n
Gestionarea extern\u0103 \u2014 duplicarea complet\u0103 a paginii. La activarea paginii, utilizatorul se poate loga pe server \u0219i gestiona dispozitivele printr-un panou personal. Astfel, Serverul extinde func\u021bionalitatea, permi\u021b\u00e2nd gestionarea dispozitivelor din afara casei \u0219i f\u0103r\u0103 a fi legat de redirec\u021bionarea porturilor sau IP dedicat.<\/p>\n
Astfel, varianta descris\u0103 mai sus este lipsit\u0103 de dezavantajele abord\u0103rii server, av\u00e2nd \u00een plus o serie de avantaje \u00een termeni de flexibilitate \u00een conectarea de noi dispozitive.<\/p>\n
Despre termostat<\/h3>\n
\nS\u0103 analiz\u0103m sistemul de gestionare pe baza termostatului nostru.<\/p>\n
Prev\u0103zut:<\/p>\n
    \n
  1. Reglarea temperaturii fiec\u0103rui termostat (afi\u0219at\u0103 sub form\u0103 de bloc separat);<\/li>\n
  2. Configurarea programului de func\u021bionare a termostatului (diminea\u021ba, ziua, seara, noaptea);<\/li>\n
  3. Selectarea re\u021belei Wi-Fi \u0219i conectarea dispozitivului la aceasta;<\/li>\n
  4. Actualizarea dispozitivului \"prin aer\";<\/li>\n
  5. Configurarea MQTT;<\/li>\n
  6. Configurarea re\u021belei la care este conectat dispozitivul.<\/li>\n<\/ol>\n
    \n\"Lytko
    \n
    \nPe l\u00e2ng\u0103 gestionarea prin interfa\u021ba web, am prev\u0103zut \u0219i o abordare clasic\u0103 \u2013 prin ap\u0103s\u0103ri pe ecran. La bord se afl\u0103 un monitor Nextion NX3224T024 de 2,4 inci. Alegerea a fost f\u0103cut\u0103 datorit\u0103 simplit\u0103\u021bii de utilizare a acestui dispozitiv. \u00cen prezent, se dezvolt\u0103 un monitor propriu pe baza STM32. Func\u021bionalitatea sa nu este cu nimic mai prejos dec\u00e2t cea a Nextion, dar va costa mai pu\u021bin, ceea ce va influen\u021ba pozitiv pre\u021bul final al dispozitivului.<\/p>\n
    \"Lytko
    \n
    \nCa orice ecran demn de respect al unui termostat, Nextion-ul nostru poate:<\/p>\n