Pak një kohë më parë, ne ju paraqitëm . Artikulli aktual është menduar fillimisht si një demonstrim i firmware dhe sistemit të menaxhimit të tij. Por për të shpjeguar logjikën e punës së termostatit dhe atë që kemi realizuar, është e nevojshme të përshkruajmë gjithashtu tërë konceptin në përgjithësi.
Rreth automatizimit
Në mënyrë të thjeshtë, gjithë automatizimi mund të ndahet në tri kategori:
Kategoria 1 — pajisje “të mençura” të veçanta. Ju bleni llamba, kënetë etj. nga prodhues të ndryshëm. Avantazhet: çdo pajisje zgjeron mundësitë dhe rrit komoditetin. Disavantazhet: për çdo prodhues të ri nevojitet aplikacioni i tij. Protokollat e pajisjeve nga prodhues të ndryshëm shpesh nuk janë të përputhshme me njëri-tjetrin.
Kategoria 2 — instalimi i një PC me një kartelë ose i pajtueshëm me x86. Kjo e heq kufizimin e fuqisë procesoru, dhe në këtë makinë instalohet MajorDoMo ose çfarëdo shpërndarje serveri tjetër për menaxhimin e shtëpisë inteligjente. Në këtë mënyrë, pajisjet e shumicës së prodhuesve ndërlidhen në një hapësirë informacioni të përbashkët. Kështu, shfaqet një Server për shtëpinë inteligjente. Avantazhet: përputhshmëria nën një qendër të vetme, e cila ofron mundësi të zgjeruara për menaxhim. Disavantazhet: në rast të prishjes/kolapsit të serverit e gjithë sistemi kthehet në fazën 1, dmth bëhet e shpërndarë, ose bëhet e pa dobishme.
Kategoria 3 — varianti më ekstrem. Në fazën e riparimit parashikohen të gjitha komunikimet dhe janë dubluar të gjithë sistemet. Avantazhet: gjithçka dërgohet në ideal dhe atëherë shtëpia bëhet vërtet e mençur. Disavantazhet: çmimi ekstremisht i lartë krahasuar me kategoritë 1 dhe 2, nevoja për të parashikuar gjithçka në mënyrë të avancuar dhe për të marrë parasysh çdo detaj.
Shumica e përdoruesve zgjedhin variantin e parë dhe më pas kalojnë ngadalë në variantin e dytë. Pastaj, ata më të qëndrushëm arrijnë variantin 3.
Por ekziston një variant, i cili mund të quhet sistem i shpërndarë: çdo pajisje e veçantë do të jetë njëkohësisht server dhe klient. Në thelb, kjo është një përpjekje për të marrë dhe për të bashkuar variantin 1 dhe variantin 2. Të merren të gjitha avantazhet e tyre dhe të përjashtohen disavantazhet, për të kapur një mesatare të artë.
Ndoshta dikush do të thotë se një variant i tillë është tashmë zhvilluar. Por këto zgjidhje janë të ngushta; për njerëzit që janë të njohur me programimin. Qëllimi ynë është të ulim pragun e hyrjes në këto sisteme të distribuuara, si në formën e pajisjeve përfundimtare, ashtu edhe në integrimin e pajisjeve ekzistuese në sistemin tonë. Në rastin e termostatit, përdoruesi thjesht heq termostatin e tij të vjetër, instalon një të zgjuar dhe lidh sensorët që ka me të. Pa asnjë veprim shtesë.
Le të shqyrtojmë integrimin në sistemin tonë me një shembull.
Të imagjinojmë se në rrjetin tonë ka 8 module Sonoff. Disa përdorues do të jenë të mjaftueshëm për menaxhimin përmes sistemit të re Sonoff (kategoria 1). Disa do të fillojnë të përdorin një firmware të tretë dhe ngadalë do të kalojnë në kategorinë 2. Shumica e firmware-ve të treta funksionojnë sipas një parimi të njëjtë: transferimi i të dhënave në serverin MQTT. OpenHub, Majordomo ose çdo shërbim tjetër shërbejnë për një qëllim – të bashkojnë pajisjet e shpërndara në një hapësirë informative të vetme, e cila ndodhet ose në Internet, ose në një rrjet lokal. Pra, pranimi i një Serveri është i detyrueshëm. Kështu, ndodh problemi kryesor – në rast të dështimit të Serverit, e gjithë sistemi ndalon së funksionuari autonomisht. Për të parandaluar këtë, sistemet komplikohet, metodo të dorës shtohen, të cilat dyfishojnë automatizimin në rast dështimi të Serverit.
Ne shkuam në një rrugë tjetër, ku çdo pajisje është e vetë-mjaftueshme. Kështu, Serveri nuk ka një rol vendimtar, por thjesht zgjeron funksionalitetin.
Tema e eksperimenteve mendore. Le të marrë përsëri ato 8 module Sonoff dhe të instalojmë firmware-n Lytko. Në të gjitha firmware-t Lytko është implementuar funksioni . SSDP – një protocol rrjetor, i bazuar në një grup protokolesh të Internetit, i cili shërben për shpalljen dhe zbulimin e shërbimeve rrjetore. Përgjigjja ndaj kërkesës mund të jetë standarde ose e zgjeruar. Ne kemi përfshirë në këtë përgjigje përveç funksioneve standarde krijimin e një liste të pajisjeve në rrjet. Kështu, pajisjet e gjejnë njëra-tjetrën, dhe çdo një prej tyre do të ketë një listë të tillë. Shembulli i listës SSDP:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Si e duket nga shembulli, lista përfshin identifikuesit e pajisjeve, adresën IP në rrjet, llojin e bllokut (në rastin tonë — termostati me bazë Sonoff). Kjo listë përditësohet njëherë çdo dy minuta (këto intervale janë të mjaftueshme për t'u përgjigjur ndaj ndryshimeve dinamike në numrin e pajisjeve në rrjet). Kështu, ne ndjekim shtimin, ndryshimin dhe çaktivizimin e pajisjeve pa ndonjë veprim nga ana e përdoruesit. Kjo listë dërgohet në shfletuesin ose aplikacionin mobil, dhe skripta e formon vetë faqen me numrin e përcaktuar të blloqeve. Çdo bllok i përgjigjet një pajisjeje/sensori/kontrolluesi. Vizualisht, lista duket kështu:
Por nëse esp8266/esp32 janë të lidhura me sensore të tjerë radio përmes cc2530 (ZigBee) ose nrf24 (MySensors)?
Për projektet
Në treg ekzistojnë sisteme të ndryshme të shpërndara. Sistemi ynë lejon integrimin me sistemet më të njohura.
Më poshtë janë projekte që përpiqen të ndryshojnë situatën me papajtueshmërinë midis prodhuesve të ndryshëm. Këto janë, për shembull, , ose . i lidhur me serverin MQTT, prandaj nuk i përshtatet shembullit.
Një nga opsionet për zbatimin e MySensors është një gateway e bazuar në ESP8266. Të tjerat janë mbi ESP32. Në to mund të integrohet principi ynë për zbulimin dhe krijimin e listës së pajisjeve.
Le të kryejmë një eksperiment tjetër imagjinues. Kemi një gateway ZESP32 ose SLS Gateway, ose MySensors. Si mund t’i bashkojmë ata në një hapësirë informative të vetme? Bëjmë hapësirë për funksionet standarde të këtyre gateway-ve duke shtuar bibliotekën e protokollit SSDP. Kur adresohet ky kontrollues përmes SSDP, ai do të shtojë në përgjigjen standarde një listë pajisjesh që janë të lidhura me të. Në bazë të kësaj informacioni, shfletuesi do të formojë një faqe. Në formë të përgjithshme, do të duket kështu:
Ndërfaqja Web
Aplikacioni PWA
"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 duket se pajisjet shtohen ndaras nga njëra-tjetra. Janë të lidhura 3 termostatë me adresa IP të veçanta dhe 5 sensora të ndryshëm me identitete unike. Nëse sensori është i lidhur me rrjetin Wi-Fi, ai do të ketë IP-në e tij, nëse është i lidhur me portën, atëherë adresa IP e pajisjes do të jetë adresa IP e portës.
Për komunikimin me pajisjet përdorim WebSocket. Kjo lejon të minimizojmë kostot e burimeve në krahasim me kërkesat GET dhe të marrim informacion në mënyrë dinamike gjatë lidhjes ose ndryshimit.
Të dhënat merren drejtpërdrejt nga pajisja e cila i përket bllokut, duke anashkaluar serverin. Si rezultat, në rast dështimi të ndonjë prej pajisjeve sistemi vazhdon të funksionojë. Në ndërfaqen web, thjesht nuk shfaqet pajisja që ka humbur nga lista. Por sinjali për humbjen, nëse është e nevojshme, do të vijë në formë njoftimi në aplikacionin e përdoruesit.
Përpjekja e parë për të realizuar një qasje të tillë ishte aplikacioni PWA. Kjo lejon ruajtjen e bazës së bllokut në pajisjen e përdoruesit dhe kërkimin e vetëm të dhënave të nevojshme. Por për shkak të veçorive të strukturës, ky variant është i paplotë. Dhe zgjidhja është një aplikacion natyral për Android dhe iOS, i cili tani është në zhvillim aktiv. Sipas parimit, aplikacioni do të punojë vetëm në rrjetin e brendshëm. Nëse është e nevojshme, gjithçka mund të kalojë në menaxhim të jashtëm. Kështu, kur përdoruesi largohet nga rrjeti lokal, aplikacioni automatikisht kalon në cloud.
Menaxhimi i jashtëm — një kopje e plotë e faqes. Kur aktivizohet faqja, përdoruesi mund të kyçet në server dhe të menaxhojë pajisjet përmes kabinetit personal. Kështu, serveri zgjeron funksionalitetin, duke lejuar menaxhimin e pajisjeve nga jashtë shtëpisë dhe pa qenë i lidhur me përcjelljen e porteve ose IP të dedikuar.
Kështu, varianti i përshkruar më sipër është i lirë nga disavantazhet e qasjes serverike dhe ka një numër avantazhesh në formë fleksibiliteti të lidhjes së pajisjeve të reja.
Për termostatin
Le të shqyrtojmë sistemin e menaxhimit duke marrë si shembull termostatin tonë.
Parashikohet:
- Rregullimi i temperaturës për çdo termostat (shfaqet në formën e një blloku të veçantë);
- Cakto 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';
- Cakto MQTT;
- Konfigurimi i rrjetit, të cilit i është lidhur pajisja.
Përveç menaxhimit përmes ndërfaqes web, ofrohet edhe ajo tradicionale — me prekjen e ekranit. Në bord ndodhet monitori Nextion NX3224T024 prej 2.4 inç. Zgjedhja ra mbi këtë për shkak të lehtësisë së punës me pajisjen. Por është në zhvillim një monitor i ri mbi bazën e STM32. Funksionaliteti i tij nuk është aspak më i dobët se ai i Nextion, por do të kushtojë më lirë, që do të ndikojë pozitivisht në çmimin përfundimtar të pajisjes.
Si çdo ekran termostati që respekton vetveten, Nextion ynë di:
- të vendosë temperaturën e nevojshme për përdoruesin (me butona në të djathtë);
- të aktivizojë dhe çaktivizojë modalitetin e punës sipas orarit (butoni H);
- të tregojë punën e releve (shigjeta në të majtë);
- të ketë mbrojtje nga fëmijët (pengohen prekjet fizike, derisa çelësi të jetë hequr);
- të tregojë nivelin e sinjalit WiFi.
Përveç kësaj, me ndihmën e monitorit mund të:
- zgjidhni tipin e sensorit të instaluar nga përdoruesi;
- menaxhoni funksionin e mbrojtjes nga fëmijët;
- përditësoni firmware-in.
Me klikimin mbi barin WiFi, përdoruesi merr informacion për rrjetin e lidhur. Kodi QR përdoret për lidhjen e pajisjes në firmware-in e HomeKit.
Demo e punës me ekranin:
Ne zhvilluam me tre termostata të lidhur.
Do të pyesni: “Cila është veçoria e termostatit tuaj?” Tani në treg ka shumë termostata 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ë kompatibil me këto sisteme dhe ka të gjitha funksionet e lartpërmendura. Por veçoria e dallueshme është se termostati përmirësohet vazhdimisht, falë fleksibilitetit të sistemit. Me çdo përditësim, funksionaliteti do të zgjerohet. Në mënyrën standard të menaxhimit të sistemit (sipër orarit), ne do të shtojmë një menaxhim adaptiv. Aplikacioni lejon marrjen e gjeolokacionit të përdoruesit. Falë kësaj, sistemi do të ndryshojë dinamikisht modalitetet e punës në varësi të vendndodhjes së tij. Dhe moduli i motit do të lejojë përshtatjen me kushtet atmosferike.
Dhe shkallëzimi. Çdokush që dëshiron mund të zëvendësojë termostatit të tij të zakonshëm me tonin. Me përpjekje minimale. Ne zgjodhëm 5 sensorët më të njohur të disponueshëm në treg dhe i shtuam mbështetje. Por edhe në rast karakteristikash ekskluzive të sensorit, përdoruesi mund ta lidha atë me termostatit tonë. Për këtë do të nevojitet të kalibrohet termostatit për të punuar me sensorin specifik. Ne do të ofrojmë udhëzime.
Duke lidhur termostatit ose çdo pajisje tjetër, ajo shfaqet automatikisht kudo: dhe në ndërfaqen web dhe në aplikacionin PWA. Shtimi i pajisjes ndodh automatikisht: mjafton ta lidha atë me rrjetin Wi-Fi.
Sistemi ynë nuk kërkon një Server, dhe në rast të dështimit të tij nuk shndërrohet në një pumpkin. Edhe në rast të dështimit të njërit nga komponentët, sistemi nuk fillon të punojë sipas një skenari emergjent. Kontrollorët, sensorët, pajisjet — çdo element është njëkohësisht Server dhe klient, prandaj është plotësisht autonom.
Për ata të interesuar — rrjetet tona sociale: , , , , .
Posta: shop@lytko.com
P. S. ne nuk inkurajojmë heqjen dorë nga Serveri. Ne gjithashtu kemi mbështetje për serverin MQTT dhe kemi cloud tonin. Qëllimi ynë është të çojmë stabilitetin dhe besueshmërinë e sistemit në një nivel cilësor të ri. Që Serveri të mos jetë pika e dobët, por të plotësojë funksionalitetin dhe ta bëjë sistemin më të përshtatshëm.
Burimi: habr.com
