Para një kohë të shkurtër, ne ju prezantuam . Artikulli aktualisht është menduar si një demostrim i programit të tij dhe sistemit të menaxhimit. Por për të shpjeguar logjikën e funksionimit të termostatit dhe atë që kemi realizuar, është e nevojshme të përshkruajmë gjithashtu konceptin në tërësi.
Për automatizimin
Kushtimisht, e gjithë automatizimi mund të ndahen në tri kategori:
Kategoria 1 — pajisje të veçanta "smart". Ju blini nga prodhues të ndryshëm llamba, kafetiera etj. Avantazhet: secila pajisje zgjeron mundësitë dhe rrit komoditetin. Disavantazhet: për çdo prodhues të ri nevojitet aplikacioni i vet. Protokollet e pajisjeve nga prodhues të ndryshëm shpeshherë nuk janë të përputhshme me njëra-tjetrën.
Kategoria 2 — instalimi i një PC me një tabelë ose të përshtatshëm me x86. Kjo heq kufizimet në fuqinë llogaritëse, dhe në këtë aparat instalohet MajorDoMo ose çdo distro tjetër server për menaxhimin e shtëpisë së mençur. Kështu, pajisjet e shumicës së prodhuesve lidhen në një hapësirë informative të përbashkët. Pra, krijohet serveri juaj për shtëpinë e mençur. Avantazhet: përputhshmëria nën një qendër të vetme, e cila ofron mundësi të zgjeruara për menaxhim. Disavantazhet: në rastin e dështimit të serverit, e gjithë sistemi kthehet në fazën 1, dmth. bëhet e ndarë, ose e padobishme.
Kategoria 3 — opsioni më ekstrem. Në fazën e rinovimit, të gjitha komunikimet vendosen dhe të gjitha sistemet dublohen. Avantazhet: gjithçka arrihet në ideal e kështu shtëpia bëhet vërtet e mençur. Disavantazhet: kostoja e lartë krahasuar me kategoritë 1 dhe 2, nevoja për të parashikuar gjithçka paraprakisht dhe për të marrë parasysh çdo detaj.
Shumica e përdoruesve zgjedhin opsionin e parë dhe pastaj kalojnë gradualisht në opsionin e dytë. Ndërsa më pas, ata më të qëndrueshëm arrijnë në opsionin 3.
Por ekziston një opsion, i cili mund të quhet sistem i shpërndarë: çdo pajisje e veçantë do të jetë dhe server dhe klient. Në thelb, kjo është një përpjekje për të marrë dhe bashkuar opsionin 1 dhe opsionin 2. Të merret të gjitha përparësitë e tyre dhe të përjashtohen disavantazhet, për të kapur një mesatare të artë.
Mund të ndodhë, që dikush të thotë se ky opsion është tashmë zhvilluar. Por këto zgjidhje janë të orientuara ngushtë; për njerëzit të njohur me programimin. Qëllimi ynë është të ulin shkallën e hyrjes në këto sisteme të shpërndara si në formën e pajisjeve përfundimtare, ashtu edhe në formën e integrimit të pajisjeve ekzistuese në sistemin tonë. Në rastin e termostatit, përdoruesi thjesht heq termostatin e tij të vjetër,_instalon atë të mençur dhe lidh sensorët që ka me të. Pa ndonjë veprim të mëtejshëm.
Le të shqyrtojmë integrimin në sistemin tonë me një shembull.
Imagjinojmë se kemi 8 module Sonoff në rrjet. Disa përdorues do të jenë të mjaftueshëm për të menaxhuar përmes re Sonoff (kategoria 1). Disa do të përdorin softuer të jashtëm dhe do të kalojnë gradualisht në kategorinë 2. Shumica e firmuerëve të jashtëm funksionojnë sipas të njëjtit parim: transmetimi i të dhënave në serverin MQTT. OpenHub, Majordomo ose ndonjë shërbim tjetër shërben për një qëllim të vetëm - të bashkojë pajisjet e shpërndara në një hapësirë informacioni të integruar, e cila ndodhet ose në internet, ose në një rrjet lokal. Prandaj, ekzistenca e një Serveri është e domosdoshme. Nga këtu lind problemi kryesor - në rastin e dështimit të Serverit, e gjithë sistema ndalon së funksionuari autonomisht. Për të parandaluar këtë, sistemet komplikohet, duke shtuar metoda manuale të menaxhimit, të cilat dyfishojnë automatikën në rast dështimi të Serverit.
Ne kemi ndjekur një rrugë tjetër, ku çdo pajisje është e pavarur. Kështu, Serveri nuk luan një rol të rëndësishëm, përveçse zgjeron funksionalitetin.
Le të kthehemi në eksperimentin mendor. Sërish të marrim të njëjtat 8 module Sonoff dhe të instalojmë në to firmuerin Lytko. Në të gjitha firmuerët Lytko është implementuar funksioni . SSDP - një protokoll rrjeti, i bazuar në një grup protokolesh të Internetit, që shërben për shpalljen dhe zbulimin e shërbimeve rrjeti. Përgjigjja në kërkesë mund të jetë standarde ose e zgjeruar. Ne e kemi vendosur në këtë përgjigje, përveç funksioneve standarde, krijimin e një liste pajisjesh në rrjet. Kështu, pajisjet gjejnë njëra-tjetrën, dhe secila prej tyre do të ketë një listë të tillë. Një shembull i listes SSDP:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Siç shihet nga shembulli, lista përfshin id e pajisjeve, adresën ip në rrjet, llojin e njësisë (në rastin tonë - termostat i bazuar në Sonoff). Kjo listë përditësohet një herë në dy minuta (kjo periudhë është e mjaftueshme për të reaguar ndaj ndryshimeve dinamike në numrin e pajisjeve në rrjet). Kështu, ne monitorojmë shtimin, ndryshimin dhe shkëputjen e pajisjeve pa ndonjë veprim nga ana e përdoruesit. Kjo listë dërgohet në shfletuesin ose aplikacionin mobil, dhe skripti vetë formon një faqe me numrin e specifikuar të njësive. Çdo njësia korrespondon me një pajisje/sensorr/kontrollues. Vizualisht lista duket kështu:
Por nëse esp8266/esp32 janë të lidhur me sensorrë të tjerë radio përmes cc2530 (ZigBee) ose nrf24 (MySensors)?
Rreth projekteve
Në treg ka sisteme të ndryshme të shpërndara. Sistemi ynë lejon integrimin me sistemet më të njohura.
Më poshtë janë projekte që në një farë mënyre përpiqen të ndryshojnë situatën me moskompatibilitetin e prodhuesve të ndryshëm me njëri-tjetrin. Këto, për shembull, janë , ose . është e lidhur me serverin MQTT, prandaj nuk përshtatet për shembullin.
Një nga mënyrat e realizimit të MySensors është një portë e bazuar në ESP8266. shembujt e tjerë janë në ESP32. Në to mund të implementojmë parimin tonë të funksionimit për të zbuluar dhe krijuar një listë pajisjesh.
Le të kryejmë një eksperiment tjetër mendor. Kemi një portë ZESP32 ose SLS Gateway, ose MySensors. Si mund t'i bashkojmë ato në një hapësirë të vetme informacioni? Në funksionet standarde të këtyre porteve do t'i shtojmë bibliotekën e protokollit SSDP. Kur i qasen këtij kontrolluesi përmes SSDP, ai do t'i shtojë përgjigjes standarde një listë pajisjesh që janë lidhur me të. Bazuar në këtë informacion, shfletuesi do të formojë një faqe. Në përgjithësi, kjo do të duket kështu:
Ndërfaqja Web
PWA-aplikacion
"ssdpList":
{
"id": 94967291, // identifikues unik i pajisjes
"ip": "192.168.x.x", // adresa ip në rrjet
"type": "thermostat" // lloji i pajisjes
},
{
"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"
}
Nga shembulli shihet se pajisjet shtohen në mënyrë të pavarur nga njëra-tjetra. Janë lidhur 3 termostatë me adresat e tyre ip dhe 5 sensore të ndryshëm me id të veçantë. Nëse sensori është i lidhur në rrjetin Wi-Fi, ai do të ketë ip të tij, nëse është i lidhur me portën, atëherë adresa ip e pajisjes do të jetë ajo e portës.
Për komunikimin me pajisjet ne përdorim WebSocket. Kjo ndihmon për të minimizuar shpenzimet e burimeve krahasuar me kërkesat get dhe për të marrë informacion dinamikisht gjatë lidhjes ose ndryshimit.
Të dhënat merren drejtpërdrejt nga ajo pajisje, e cila i përket bllokut, duke anashkaluar serverin. Në këtë mënyrë, në rast të mosfunksionimit të ndonjë pajisje, sistemi vazhdon të funksionojë. Në ndërfaqen web vetëm pajisja e humbur nuk do të shfaqet në listë. Por sinjali për humbjen, nëse është e nevojshme, do të vijë si një njoftim në aplikacionin e përdoruesit.
Përpjekja e parë për të realizuar një qasje të tillë ishte aplikacioni PWA. Ky aplikacion mundëson ruajtjen e bazës së bllokut në pajisjen e përdoruesit dhe kërkon vetëm të dhënat e nevojshme. Por për shkak të veçorive të strukturës, ky variant është i pamjaftueshëm. Dhe zgjidhja është një aplikacion natyror për Android dhe IOS, i cili tani është në zhvillim aktiv. Në parazgjedhje, aplikacioni do të funksionojë vetëm në rrjetin e brendshëm. Nëse është e nevojshme, gjithçka mund të kalojë në menaxhimin e jashtëm. Kështu, kur përdoruesi largohet nga rrjeti lokal, aplikacioni automatikisht kalon në cloud.
Menaxhimi nga jashtë është një kopjim i plotë i faqeve. Kur aktivizohet faqja, përdoruesi mund të hyjë në server dhe të menaxhojë pajisjet përmes llogarisë personale. Kështu, Serveri zgjeron funksionalitetin, duke lejuar menaxhimin e pajisjeve përtej shtëpisë dhe duke e bërë të pavendosur lidhjen me portet ose adresat IP të dedikuara.
Në këtë mënyrë, varianti i përshkruar më lart është pa disavantazhet e qasjes server dhe ka një sërë përfitimesh si fleksibiliteti i lidhjes së pajisjeve të reja.
Për termostatin
Le të shqyrtojmë sistemin e menaxhimit duke përdorur termostatin tonë si shembull.
Parashikohet:
- Rregullimi i temperaturës së secilit termostat (shfaqet si një bllok i veçantë);
- Caktoni orarin e punës së termostatit (mëngjes, ditë, mbrëmje, natë);
- Zgjedhja e rrjetit Wi-Fi dhe lidhja e pajisjes me të;
- Përditësimi i pajisjes "në ajër";
- Caktoni MQTT;
- Caktoni rrjetin me të cilin është lidhur pajisja.
Përveç menaxhimit përmes ndërfaqes web, është parashikuar menaxhimi klasik — me prekje të ekranit. Në bord është një monitor Nextion NX3224T024 2.4 inç. Zgjedhja ra mbi të për shkak të thjeshtësisë së përdorimit të pajisjes. Por është në zhvillim një monitor i vetëpërgatitur mbi bazën e STM32. Funksionaliteti i tij nuk është aspak më i keq se ai i Nextion, por do të kushtojë më pak, që do të ndikojë pozitivisht në çmimin përfundimtar të pajisjes.
Si çdo ekran i nderuar i termostatit, Nextion ynë di të:
- vendosë temperaturën e nevojshme për përdoruesin (me butonat në të djathtë);
- aktivizojë dhe çaktivizojë modalitetin e punës sipas orarit (butoni H);
- tregojë funksionimin e releve (shigjeta në të majtë);
- ka mbrojtje nga fëmijët (bllokohen prekje fizike, derisa bllokimi të jetë hequr);
- tregon nivelin e sinjalit WiFi.
Për më tepër, me anë të monitorit mund të:
- zgjidhni llojin e sensorit të instaluar te përdoruesi;
- menaxhoni funksionin e mbrojtjes nga fëmijët;
- përditësoni firmware-in.
Kur përdoruesi klikon në barin WiFi, ai merr informacion mbi rrjetin e lidhur. Kodi QR përdoret për përshtatjen e pajisjes në firmware-in e HomeKit.
Demo e funksionimit me ekranin:
Ne kemi zhvilluar me tre termostata të lidhur.
Do të pyesni: "Çfarë ka të veçantë termostati juaj?" Tani në treg ka një mori termostatash me funksion Wi-Fi, punë sipas orarit, menaxhim me prekje. Dhe entuziastët kanë shkruar module për ndërveprimin me shumicën e sistemeve të njohura të shtëpisë inteligjente (Majordomo, HomeAssistant, etj.).
Termostati ynë është i pajtueshëm me këto sisteme dhe ka të gjitha karakteristikat e përmendura më lart. Por veçoria dalluese është se termostati vazhdimisht përmirësohet, falë fleksibilitetit të sistemit. Me çdo përditësim, funksionaliteti do të zgjerohesh. Në metodën standard të menaxhimit të sistemit (sipbasedërit me orar), ne do të shtojmë një metodë adaptuese. Aplikacioni lejon të merrni gjeolokacionin e përdoruesit. Falë këtij, sistemi do të ndryshojë dinamikisht modet e tij të funksionimit në varësi të vendndodhjes së tij. Po ashtu, moduli i motit do t'i përshtatet kushteve të motit.
Dhe zgjerueshmëria. Çdokush mund ta zëvendësojë termostatin e zakonshëm me të tonin. Me përpjekje minimale. Ne kemi zgjedhur pesë sensorët më të njohur që janë në treg dhe kemi shtuar mbështetje për ta. Por madje edhe në rastin e karakteristikave ekskluzive të sensorit, përdoruesi mund ta lidhë atë me termostatin tonë. Për këtë, do të nevojitet kalibrimi i termostatit për të punuar me sensorin specifik. Ne do të ofrojmë udhëzime.
Duke lidhur termostatin ose çdo pajisje tjetër, ajo shfaqet automatikisht në të gjitha: si në ndërfaqen web, ashtu edhe në aplikacionin PWA. Shtimi i pajisjes ndodh automatikisht: mjafton vetëm ta lidhni atë me rrjetin Wi-Fi.
Sistemi ynë nuk ka nevojë për një Server, dhe në rast të dështimit të tij nuk shndërrohet në një pumpë. Edhe në rastin e dështimit të një nga përbërësve, sistemi nuk fillon të punojë sipas skenarëve të emergjencës. Kontrollerët, sensorët, pajisjet — çdo element është njëkohësisht Server dhe klient, prandaj është plotësisht autonom.
Për ata që janë të interesuar — rrjetet tona sociale: , , , , .
Email: shop@lytko.com
P. S. Ne nuk po inkurajojmë të heqim dorë nga Serveri. Ne gjithashtu ofrojmë mbështetje për serverin MQTT dhe kemi një re tonën. Qëllimi ynë është ta çojmë stabilitetin dhe besueshmërinë e sistemit në një nivel kualitativisht të ri. Që Serveri të mos jetë pika e dobët, por të plotësojë funksionalitetin dhe ta bëjë sistemin më të rehatshëm.
Burimi: habr.com
