Duela denbora pixka bat aurkeztu genuen . Artikulu hau hasiera batean bere firmwarearen eta kontrol sistemaren erakusgarri izan zen. Baina termostatoaren logika eta inplementatu duguna azaltzeko, beharrezkoa da kontzeptu osoa bere osotasunean azaltzea.
Automatizazioari buruz
Ohikoki, automatizazio guztiak hiru kategoriatan bana daitezke:
1. kategoria β Gailu "adimendunak" bereiziak. Fabrikatzaile ezberdinei bonbillak, teontziak eta abar erosten dituzu. Alde onak: Gailu bakoitzak gaitasunak zabaltzen ditu eta erosotasuna areagotzen du. Alde txarrak: Fabrikatzaile berri bakoitzak bere aplikazioa behar du. Fabrikatzaile ezberdinetako gailuen protokoloak askotan ez dira bateragarriak elkarren artean.
2. kategoria β plaka bakarreko PC edo x86 bateragarria instalatzea. Honek konputazio-potentziaren murrizketak kentzen ditu, eta MajorDoMo edo etxe adimendun bat kudeatzeko beste edozein zerbitzari banaketa instalatuta dago makina honetan. Horrela, fabrikatzaile gehienen gailuak informazio-espazio bakarrean konektatzen dira. Horiek. Etxe adimendun baterako zure zerbitzaria agertzen da. Alde onak: bateragarritasuna zentro bakar baten pean, kudeaketa-gaitasun hobeak eskaintzen dituena. Alde txarrak: zerbitzariak huts egiten badu, sistema osoa 1. fasera itzultzen da, hau da. zatikatu egiten da edo alferrikakoa bihurtzen da.
3. kategoria - aukerarik gogorrena. Konponketa fasean, komunikazio guztiak ezartzen dira eta sistema guztiak bikoiztu egiten dira. Alde onak: dena perfekziora eramaten da eta orduan etxea benetan adimentsu bihurtzen da. Desabantailak: oso garestia 1 eta 2 kategoriekin alderatuta, dena aldez aurretik pentsatu eta xehetasun txiki guztiak kontuan hartu beharra.
Erabiltzaile gehienek aukeratzen dute lehen aukera eta gero leunki pasatzen dira bigarren aukerara. Eta gero iraunkorrenak 3. aukerara iristen dira.
Baina bada sistema banatua dei daitekeen aukera bat: gailu bakoitza zerbitzaria eta bezeroa izango da. Funtsean, hau 1. aukera eta 2. aukera hartu eta konbinatzeko saiakera bat da. Hartu pros guztiak eta kontrakoak kendu, urrezko bitartekoa harrapatzeko.
Beharbada norbaitek esango du jadanik aukera hori garatu dela. Baina halako erabakiak estu-estu bideratzen dira; programazioan adituak diren pertsonentzat. Gure helburua da horrelako sistema banatuetan sartzeko oztopoa jaistea, bai amaierako gailuen moduan, bai lehendik dauden gailuak gure sisteman integratzeko moduan. Termostato baten kasuan, erabiltzaileak termostato zaharra kendu, adimendun bat instalatu eta lehendik dituen sentsoreak konektatzen ditu. Pauso gehigarririk gabe.
Ikus dezagun gure sisteman integrazioa adibide bat erabiliz.
Imajina dezagun 8 Sonoff modulu ditugula gure sarean. Erabiltzaile batzuentzat, Sonoff hodeiaren bidez kontrolatzea nahikoa izango da (1. kategoria). Batzuk hirugarrenen firmwarea erabiltzen hasiko dira eta leunki 2. kategoriara pasatuko dira. Hirugarrenen firmwarearen zatirik handiena printzipio berdinarekin funtzionatzen du: datuak MQTT zerbitzari batera transferitzea. OpenHub-ek, Majordomo-k edo beste edozeinek helburu bat dute: hainbat gailu batzea Interneten edo sare lokal batean kokatutako informazio-espazio bakar batean. Beraz, zerbitzari baten presentzia derrigorrezkoa da. Hor sortzen da arazo nagusia: zerbitzariak huts egiten badu, sistema osoak modu autonomoan funtzionatzeari uzten dio. Hori ekiditeko, sistemak konplexuagoak bihurtzen dira, zerbitzariaren hutsegite bat gertatuz gero automatizazioa bikoizten duten eskuzko kontrol-metodoak gehitzen dira.
Bide ezberdin bat hartu genuen, non gailu bakoitza autosufizientea den. Horrela, Zerbitzariak ez du paper erabakigarririk jokatzen, funtzionaltasuna zabaltzen du soilik.
Itzuli gaitezen pentsamendu-esperimentura. Har ditzagun berriro 8 Sonoff modulu berdinak eta instala ditzagun Lytko firmwarea horietan. Lytko firmware guztiek dute funtzioa . SSDP sareko protokolo bat da, sareko zerbitzuak iragartzeko eta aurkitzeko Interneteko protokolo multzoan oinarrituta. Eskaera baten erantzuna estandarra edo hedatua izan daiteke. Funtzio estandarrez gain, erantzun honetan sareko gailuen zerrenda bat sortzea sartu dugu. Horrela, gailuek eurek elkar aurkitzen dute, eta horietako bakoitzak izango du zerrenda hori. SSDP fitxa adibidea:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Adibidean ikus dezakezun bezala, zerrendan gailuen IDak, sareko IP helbidea, unitate mota (gure kasuan, Sonoff-en oinarritutako termostatoa) daude. Zerrenda hau bi minuturo eguneratzen da (epe hori nahikoa da sareko gailu kopuruaren aldaketa dinamikoei erantzuteko). Horrela, gehitutako, aldatutako eta desgaitutako gailuen jarraipena egiten dugu, erabiltzaileen ekintzarik gabe. Zerrenda hori arakatzailera edo mugikorrerako aplikaziora bidaltzen da, eta scriptak berak orrialde bat sortzen du bloke kopuru jakin batekin. Bloke bakoitza gailu/sentsore/kontrolagailu bati dagokio. Ikusmenezko zerrendak honela dauka:
Baina zer gertatzen da beste irrati-sentsore batzuk esp8266/esp32-ra cc2530 (ZigBee) edo nrf24 (MySensors) bidez konektatzen badira?
Proiektuei buruz
Hainbat sistema banatuta daude merkatuan. Gure sistemak ezagunenekin integratzeko aukera ematen dizu.
Jarraian, modu batera edo bestera fabrikatzaile ezberdinek elkarren artean bateraezintasunarekin egoera aldatzen saiatzen diren proiektuak daude. Hau da, adibidez, , edo . MQTT zerbitzari bati lotuta dago, beraz, ez da egokia adibiderako.
MySensors ezartzeko aukera bat ESP8266-n oinarritutako atebidea da. Gainerako adibideak ESP32n daude. Eta horietan gailuen zerrenda bat detektatzeko eta sortzeko gure funtzionamendu-printzipioa ezarri dezakezu.
Egin dezagun beste pentsamendu-esperimentu bat. ZESP32 gateway edo SLS Gateway, edo MySensors dugu. Nola konbina daitezke informazio-espazio bakar batean? Pasabide hauen funtzio estandarrei SSDP protokolo liburutegia gehituko diegu. Kontrolagailu honetara SSDP bidez sartzean, hari konektatuta dauden gailuen zerrenda gehituko dio erantzun estandarrari. Informazio horretan oinarrituta, nabigatzaileak orri bat sortuko du. Oro har, honela izango da:
Web interfazea
PWA aplikazioa
"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"
}
Adibideak erakusten du gailuak elkarrengandik independentean gehitzen direla. IP helbide propioak dituzten 3 termostato eta ID bakarra duten 5 sentsore ezberdin konektatuta daude. Sentsorea Wi-Fi sare batera konektatuta badago, bere IP propioa izango du; atebide batera konektatuta badago, gailuaren IP helbidea atebidearen IP helbidea izango da.
WebSocket erabiltzen dugu gailuekin komunikatzeko. Horri esker, baliabideen kostuak minimiza ditzakezu eskaerak lortzeko eta informazioa modu dinamikoan lortzeko konektatzean edo aldatzean.
Datuak blokea dagokion gailutik zuzenean hartzen dira, zerbitzaria saihestuz. Horrela, gailuren batek huts egiten badu, sistemak funtzionatzen jarraitzen du. Web interfazeak ez du zerrendan falta den gailua bistaratzen. Baina galerari buruzko seinalea, beharrezkoa bada, erabiltzailearen aplikazioan jakinarazpen moduan etorriko da.
Ikuspegi hau ezartzeko lehen saiakera PWA aplikazio bat izan zen. Horri esker, bloke-oinarri bat erabiltzailearen gailuan gorde dezakezu eta beharrezkoak diren datuak soilik eska ditzakezu. Baina egituraren berezitasunak direla eta, aukera hau osatugabea da. Eta irteera bakarra dago: Android eta IOS-erako jatorrizko aplikazioa, gaur egun garapen aktiboan dagoena. Lehenespenez, aplikazioak barne sarean bakarrik funtzionatuko du. Beharrezkoa izanez gero, dena kanpoko kontrolera transferi dezakezu. Beraz, erabiltzailea sare lokaletik irteten denean, aplikazioa automatikoki hodeira aldatzen da.
Kanpoko kontrola - orrialdearen bikoizketa osoa. Orria aktibatuta dagoenean, erabiltzaileak zerbitzarian saioa hasi eta gailuak kudeatu ditzake bere kontu pertsonalaren bidez. Horrela, Zerbitzariak bere funtzionalitateak zabaltzen ditu, etxetik kanpo gailuak kudeatzeko aukera emanez, eta ez dago portuen birbidaltzearekin edo IP dedikatuarekin lotuta egon.
Horrela, goiko aukerak ez du zerbitzariaren ikuspegiaren desabantailarik, eta gailu berriak konektatzeko malgutasunari dagokionez ere abantaila ugari ditu.
Termostatoari buruz
Ikus dezagun kontrol-sistema gure termostatoa adibide gisa erabiliz.
Emanda:
- Termostato bakoitzaren tenperatura kontrola (bloke bereizi gisa bistaratzen da);
- Termostatoaren funtzionamendu-ordutegia ezartzea (goizez, arratsaldez, arratsaldez, gauez);
- Wi-Fi sare bat hautatzea eta hari gailu bat konektatzea;
- Gailua "airean" eguneratzea;
- MQTT konfiguratzea;
- Konfiguratu gailua konektatuta dagoen sarea.
Web interfazearen bidez kontrolatzeaz gain, klasikoa eman dugu, pantailan klik eginez. Nextion NX3224T024 2.4 hazbeteko monitorea dago taula gainean. Gailuarekin lan egiteko erraztasunagatik erori zitzaion aukeraketa. Baina gure monitore propioa garatzen ari gara STM32n oinarrituta. Bere funtzionaltasuna ez da Nextion-ena baino okerragoa, baina kostu txikiagoa izango du, eta horrek eragin positiboa izango du gailuaren azken prezioan.
Norbere burua errespetatzen duen termostatoaren pantaila bezala, gure Nextion-ek honako hauek egin ditzake:
- erabiltzaileak behar duen tenperatura ezarri (eskuineko botoiak erabiliz);
- programatutako funtzionamendu modua piztu eta itzali (H botoia);
- bistaratzeko errelearen funtzionamendua (ezkerreko gezia);
- haurren babesa du (klik fisikoak blokeatzen dira blokeoa kendu arte);
- WiFi seinalearen indarra erakusten du.
Horrez gain, monitorea erabiliz, egin dezakezu:
- hautatu erabiltzaileak instalatutako sentsore mota;
- kudeatu haurren blokeo funtzioa;
- eguneratu firmwarea.
WiFi barran klik eginez, erabiltzaileak konektatutako sareari buruzko informazioa aurkituko du. QR kodea HomeKit firmwarean gailua parekatzeko erabiltzen da.
Pantailarekin lan egiteko demoa:
garatu dugu konektatutako hiru termostatoekin.
Galdetuko duzu: "Zer da berezia zure termostatoak?" Orain merkatuan Wi-Fi funtzioa, programatutako funtzionamendua eta ukipen-kontrola duten termostato asko daude. Eta zaleek moduluak idatzi dituzte etxeko sistema adimendun ezagunenekin elkarreragiteko (Majordomo, HomeAssistant, etab.).
Gure termostatoa horrelako sistemekin bateragarria da eta aurreko guztia dauka. Baina ezaugarri bereizgarria termostatoa etengabe hobetzen ari dela da, sistemaren malgutasunari esker. Eguneratze bakoitzean funtzionaltasuna zabalduko da. Sistema kudeatzeko metodo estandarrari (egutegi baten arabera), moldakorra gehituko diogu. Aplikazioak erabiltzailearen geokokapena lortzeko aukera ematen du. Horri esker, sistemak dinamikoki aldatuko ditu funtzionamendu moduak bere kokapenaren arabera. Eta eguraldiaren moduluak eguraldi baldintzetara egokitzeko aukera emango dizu.
Eta hedagarritasuna. Edonork ordezkatu dezake bere ohiko termostatoa gurearekin. Gutxieneko ahaleginarekin. Merkatuan dauden sentsore ezagunenetako 5 hautatu ditugu eta haientzako laguntza gehitu dugu. Baina sentsoreak ezaugarri esklusiboak baditu ere, erabiltzaileak gure termostatoarekin konektatu ahal izango du. Horretarako, termostatoa kalibratu beharko duzu sentsore zehatz batekin funtziona dezan. Argibideak emango ditugu.
Termostato bat edo beste edozein gailu konektatzean, aldi berean edonon agertzen da: bai web interfazean, bai PWA aplikazioan. Gailu bat gehitzea automatikoki gertatzen da: Wi-Fi sarera konektatu besterik ez duzu behar.
Gure sistemak ez du zerbitzaririk behar, eta huts egiten badu, ez da kalabaza bihurtzen. Osagairen batek huts egiten badu ere, sistema ez da larrialdi egoera batean funtzionatzen hasten. Kontrolagailuak, sentsoreak, gailuak - elementu bakoitza zerbitzaria eta bezeroa da, beraz, guztiz autonomoa.
Interesa dutenentzat, gure sare sozialak: , , , , .
E-mail: [posta elektroniko bidez babestua]
PS Ez zaitugu zerbitzaria alde batera utztzera animatzen. MQTT zerbitzari bat ere onartzen dugu eta gure hodeia dugu. Gure helburua sistemaren egonkortasuna eta fidagarritasuna maila berri batera eramatea da. Beraz, Zerbitzaria ez da puntu ahul bat, baina funtzionaltasuna osatzen du eta sistema erosoagoa egiten du.
Iturria: www.habr.com