Para disa kohësh ju prezantuam . Ky artikull fillimisht ishte menduar si një demonstrim i firmuerit dhe sistemit të tij të kontrollit. Por për të shpjeguar logjikën e termostatit dhe atë që kemi zbatuar, është e nevojshme të përvijojmë të gjithë konceptin në tërësi.
Rreth automatizimit
Në mënyrë konvencionale, i gjithë automatizimi mund të ndahet në tre kategori:
Kategoria 1 - pajisje të veçanta "të zgjuara". Ju blini llamba, çajniqe, etj. nga prodhues të ndryshëm. Pro: Çdo pajisje zgjeron aftësitë dhe rrit komoditetin. Kundër: Çdo prodhues i ri kërkon aplikimin e tij. Protokollet e pajisjeve nga prodhues të ndryshëm shpesh nuk janë në përputhje me njëri-tjetrin.
Kategoria 2 — instalimi i një PC me një bord ose të përputhshëm me x86. Kjo heq kufizimet në fuqinë kompjuterike dhe MajorDoMo ose çdo shpërndarje tjetër serveri për menaxhimin e një shtëpie inteligjente është instaluar në këtë makinë. Kështu, pajisjet nga shumica e prodhuesve janë të lidhur në një hapësirë të vetme informacioni. ato. Shfaqet Serveri juaj për një shtëpi inteligjente. Pro: përputhshmëria nën një qendër të vetme, e cila ofron aftësi të zgjeruara të menaxhimit. Kundër: nëse serveri dështon, i gjithë sistemi kthehet në fazën 1, d.m.th. copëzohet ose bëhet i padobishëm.
Kategoria 3 - opsioni më i fortë. Në fazën e riparimit, të gjitha komunikimet vendosen dhe të gjitha sistemet janë dyfishuar. Pro: gjithçka është sjellë në përsosmëri dhe më pas shtëpia bëhet vërtet e zgjuar. Disavantazhet: jashtëzakonisht e shtrenjtë në krahasim me kategoritë 1 dhe 2, nevoja për të menduar paraprakisht për gjithçka dhe për të marrë parasysh çdo detaj të vogël.
Shumica e përdoruesve zgjedhin opsionin një dhe më pas kalojnë pa probleme në opsionin dy. Dhe më pas ato më këmbëngulësit arrijnë opsionin 3.
Por ekziston një opsion që mund të quhet një sistem i shpërndarë: çdo pajisje individuale do të jetë njëkohësisht një server dhe një klient. Në thelb, kjo është një përpjekje për të marrë dhe kombinuar opsionin 1 dhe opsionin 2. Merrni të gjitha të mirat e tyre dhe eliminoni të këqijat, për të kapur mesataren e artë.
Ndoshta dikush do të thotë se një opsion i tillë tashmë është zhvilluar. Por vendime të tilla janë të fokusuara ngushtë; për njerëzit e ditur në programim. Qëllimi ynë është të ulim pengesat për hyrjen në sisteme të tilla të shpërndara, si në formën e pajisjeve fundore ashtu edhe në formën e integrimit të pajisjeve ekzistuese në sistemin tonë. Në rastin e një termostati, përdoruesi thjesht heq termostatin e tij të vjetër, instalon një të zgjuar dhe lidh sensorët e tij ekzistues me të. Pa asnjë hap shtesë.
Le të shohim integrimin në sistemin tonë duke përdorur një shembull.
Le të imagjinojmë se kemi 8 module Sonoff në rrjetin tonë. Për disa përdorues, kontrolli nëpërmjet resë Sonoff (kategoria 1) do të jetë i mjaftueshëm. Disa do të fillojnë të përdorin firmware të palëve të treta dhe do të kalojnë pa probleme në kategorinë 2. Pjesa më e madhe e firmuerit të palëve të treta funksionon në të njëjtin parim: transferimi i të dhënave në një server MQTT. OpenHub, Majordomo ose ndonjë tjetër i shërbejnë një qëllimi - për të bashkuar pajisjet e ndryshme në një hapësirë të vetme informacioni të vendosur ose në internet ose në një rrjet lokal. Prandaj, prania e një Serveri është e detyrueshme. Këtu lind problemi kryesor - nëse Serveri dështon, i gjithë sistemi ndalon së punuari në mënyrë autonome. Për të parandaluar këtë, sistemet bëhen më komplekse, shtohen metoda të kontrollit manual që kopjojnë automatizimin në rast të dështimit të serverit.
Ne morëm një rrugë të ndryshme, ku çdo pajisje është e vetë-mjaftueshme. Kështu, Serveri nuk luan një rol vendimtar, por vetëm zgjeron funksionalitetin.
Le të kthehemi te eksperimenti i mendimit. Le të marrim përsëri të njëjtat 8 module Sonoff dhe të instalojmë firmware Lytko në to. Të gjithë firmware-et Lytko kanë funksionin . SSDP është një protokoll rrjeti i bazuar në paketën e protokolleve të internetit për reklamimin dhe zbulimin e shërbimeve të rrjetit. Përgjigja ndaj një kërkese mund të jetë ose standarde ose e zgjatur. Përveç funksioneve standarde, ne kemi përfshirë në këtë përgjigje krijimin e një liste të pajisjeve në rrjet. Kështu, vetë pajisjet e gjejnë njëra-tjetrën dhe secila prej tyre do të ketë një listë të tillë. Shembull i fletës SSDP:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Siç mund ta shihni nga shembulli, lista përfshin ID-të e pajisjes, adresën IP në rrjet, llojin e njësisë (në rastin tonë, një termostat i bazuar në Sonoff). Kjo listë përditësohet një herë në dy minuta (kjo periudhë është e mjaftueshme për t'iu përgjigjur ndryshimeve dinamike në numrin e pajisjeve në rrjet). Në këtë mënyrë, ne gjurmojmë pajisjet e shtuara, ndryshuara dhe çaktivizuara pa asnjë veprim të përdoruesit. Kjo listë dërgohet në shfletuesin ose aplikacionin celular dhe vetë skripti gjeneron një faqe me një numër të caktuar blloqesh. Çdo bllok korrespondon me një pajisje/sensor/kontrollues. Vizualisht lista duket kështu:
Por, çka nëse sensorë të tjerë radio janë të lidhur me esp8266/esp32 nëpërmjet cc2530 (ZigBee) ose nrf24 (MySensors)?
Rreth projekteve
Ekzistojnë sisteme të ndryshme të shpërndara në treg. Sistemi ynë ju lejon të integroheni me më të njohurit.
Më poshtë janë projektet që në një mënyrë ose në një tjetër përpiqen të ndryshojnë situatën me papajtueshmërinë e prodhuesve të ndryshëm me njëri-tjetrin. Kjo është, për shembull, , ose . është i lidhur me një server MQTT, kështu që nuk është i përshtatshëm për shembull.
Një opsion për zbatimin e MySensors është një portë e bazuar në ESP8266. Pjesa tjetër e shembujve janë në ESP32. Dhe në to mund të zbatoni parimin tonë të funksionimit të zbulimit dhe krijimit të një liste pajisjesh.
Le të bëjmë një tjetër eksperiment mendimi. Ne kemi një portë ZESP32 ose SLS Gateway, ose MySensors. Si mund të kombinohen ato në një hapësirë të vetme informacioni? Ne do të shtojmë bibliotekën e protokollit SSDP në funksionet standarde të këtyre portave. Kur aksesoni këtë kontrollues nëpërmjet SSDP, ai do të shtojë një listë të pajisjeve që janë të lidhura me të në përgjigjen standarde. Bazuar në këtë informacion, shfletuesi do të gjenerojë një faqe. Në përgjithësi do të duket kështu:
Ndërfaqja në ueb
Aplikimi 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"
}
Shembulli tregon se pajisjet shtohen në mënyrë të pavarur nga njëra-tjetra. Janë lidhur 3 termostate me adresat e tyre IP dhe 5 sensorë të ndryshëm me ID unike. Nëse sensori është i lidhur me një rrjet Wi-Fi, ai do të ketë IP-në e vet; nëse është i lidhur me një portë, atëherë adresa IP e pajisjes do të jetë adresa IP e portës.
Ne përdorim WebSocket për të komunikuar me pajisjet. Kjo ju lejon të minimizoni kostot e burimeve në krahasim me marrjen e kërkesave dhe marrjen e informacionit në mënyrë dinamike kur lidheni ose ndryshoni.
Të dhënat merren direkt nga pajisja së cilës i përket blloku, duke anashkaluar serverin. Kështu, nëse ndonjë nga pajisjet dështon, sistemi vazhdon të funksionojë. Ndërfaqja e internetit thjesht nuk shfaq pajisjen që mungon nga lista. Por një sinjal për humbjen, nëse është e nevojshme, do të vijë në formën e një njoftimi në aplikacionin e përdoruesit.
Përpjekja e parë për të zbatuar këtë qasje ishte një aplikacion PWA. Kjo ju lejon të ruani një bazë blloku në pajisjen e përdoruesit dhe të kërkoni vetëm të dhënat e nevojshme. Por për shkak të veçorive të strukturës, ky opsion është i paplotë. Dhe ka vetëm një rrugëdalje - një aplikacion vendas për Android dhe IOS, i cili aktualisht është në zhvillim aktiv. Si parazgjedhje, aplikacioni do të funksionojë vetëm në rrjetin e brendshëm. Nëse është e nevojshme, mund të transferoni gjithçka në kontrollin e jashtëm. Pra, kur përdoruesi largohet nga rrjeti lokal, aplikacioni kalon automatikisht në cloud.
Kontroll i jashtëm - dublikim i plotë i faqes. Kur faqja aktivizohet, përdoruesi mund të hyjë në server dhe të menaxhojë pajisjet përmes llogarisë së tij personale. Kështu, Serveri zgjeron funksionalitetin e tij, duke ju lejuar të menaxhoni pajisjet ndërsa jeni jashtë shtëpisë dhe të mos jeni i lidhur me përcjelljen e portit ose një IP të dedikuar.
Kështu, opsioni i mësipërm nuk ka disavantazhet e qasjes së serverit, dhe gjithashtu ka një numër avantazhesh në formën e fleksibilitetit në lidhjen e pajisjeve të reja.
Rreth termostatit
Le të shohim sistemin e kontrollit duke përdorur termostatin tonë si shembull.
Ofrohet:
- Kontrolli i temperaturës për çdo termostat (shfaqet si një bllok i veçantë);
- Vendosja e orarit të funksionimit të termostatit (mëngjes, pasdite, mbrëmje, natë);
- Zgjedhja e një rrjeti Wi-Fi dhe lidhja e një pajisjeje me të;
- Përditësimi i pajisjes "në ajër";
- Vendosja e MQTT;
- Konfiguro rrjetin me të cilin është lidhur pajisja.
Përveç kontrollit përmes ndërfaqes në internet, ne siguruam atë klasik - duke klikuar në ekran. Ekziston një monitor Nextion NX3224T024 2.4 inç në bord. Zgjedhja ra mbi të për shkak të lehtësisë së punës me pajisjen. Por ne po zhvillojmë monitorin tonë të bazuar në STM32. Funksionaliteti i tij nuk është më i keq se ai i Nextion, por do të kushtojë më pak, gjë që do të ketë një ndikim pozitiv në çmimin përfundimtar të pajisjes.
Si çdo ekran i termostatit që respekton veten, Nextion ynë mund:
- vendosni temperaturën e kërkuar nga përdoruesi (duke përdorur butonat në të djathtë);
- aktivizoni dhe çaktivizoni mënyrën e planifikuar të funksionimit (butoni H);
- funksionimi i stafetës së ekranit (shigjeta në të majtë);
- ka mbrojtje për fëmijët (klikimet fizike bllokohen derisa të hiqet bllokimi);
- shfaq fuqinë e sinjalit WiFi.
Përveç kësaj, duke përdorur monitorin mund të:
- zgjidhni llojin e sensorit të instaluar nga përdoruesi;
- menaxhoni funksionin e bllokimit të fëmijëve;
- përditësoni firmware-in.
Duke klikuar në shiritin WiFi, përdoruesi do të mësojë informacione rreth rrjetit të lidhur. Kodi QR përdoret për të çiftuar pajisjen në firmuerin HomeKit.
Demo e punës me ekranin:
Ne kemi zhvilluar me tre termostate te lidhur.
Ju mund të pyesni, "Çfarë të veçantë ka termostati juaj?" Tani në treg ka shumë termostate me funksion Wi-Fi, funksionim të planifikuar dhe kontroll me prekje. Dhe entuziastët kanë shkruar module për të bashkëvepruar me sistemet më të njohura të shtëpive inteligjente (Majordomo, HomeAssistant, etj.).
Termostati ynë është i pajtueshëm me sisteme të tilla dhe i ka të gjitha sa më sipër. Por veçoria dalluese është se termostati po përmirësohet vazhdimisht, falë fleksibilitetit të sistemit. Me çdo përditësim funksionaliteti do të zgjerohet. Në metodën standarde të menaxhimit të sistemit (sipas një plani), ne do të shtojmë një përshtatës. Aplikacioni ju lejon të merrni vendndodhjen gjeografike të përdoruesit. Falë kësaj, sistemi do të ndryshojë dinamikisht mënyrat e funksionimit në varësi të vendndodhjes së tij. Dhe moduli i motit do t'ju lejojë të përshtateni me kushtet e motit.
Dhe zgjerimi. Çdokush mund të zëvendësojë termostatin e tij konvencional ekzistues me tonin. Me përpjekje minimale. Ne kemi zgjedhur 5 nga sensorët më të njohur në treg dhe kemi shtuar mbështetjen për ta. Por edhe nëse sensori ka karakteristika ekskluzive, përdoruesi do të jetë në gjendje ta lidhë atë me termostatin tonë. Për ta bërë këtë, do t'ju duhet të kalibroni termostatin për të punuar me një sensor specifik. Ne do të japim udhëzime.
Kur lidhni një termostat ose ndonjë pajisje tjetër, ai shfaqet njëkohësisht kudo: si në ndërfaqen e internetit ashtu edhe në aplikacionin PWA. Shtimi i një pajisjeje ndodh automatikisht: thjesht duhet ta lidhni atë me rrjetin Wi-Fi.
Sistemi ynë nuk ka nevojë për Server dhe nëse dështon, nuk kthehet në kungull. Edhe nëse një nga komponentët dështon, sistemi nuk fillon të funksionojë në një skenar emergjence. Kontrollorët, sensorët, pajisjet - çdo element është njëkohësisht një Server dhe një klient, prandaj plotësisht autonom.
Për të interesuarit, rrjetet tona sociale: , , , , .
E-mail: [email mbrojtur]
PS Ne nuk ju inkurajojmë të braktisni serverin. Ne gjithashtu mbështesim një server MQTT dhe kemi renë tonë. Qëllimi ynë është të sjellim stabilitetin dhe besueshmërinë e sistemit në një nivel krejtësisht të ri. Kështu që Serveri nuk është një pikë e dobët, por plotëson funksionalitetin dhe e bën sistemin më të përshtatshëm.
Burimi: www.habr.com