Mõni aeg tagasi tutvustasime teile . Käesolev artikkel oli algselt mõeldud kui selle tarkvara ja juhtimisse süsteemi demonstreerimine. Kuid termostaadi töölogika ja meie teostuste selgitamiseks on vajalik kogu kontseptsiooni üldiselt üle vaadata.
Automatiseerimisest
Üldiselt saab kogu automatiseerimise jagada kolme kategooriasse:
Kategooria 1 — üksikud “nutikad” seadmed. Te ostate erinevatelt tootjatelt lampe, veekeetjaid jne. Plussid: iga seade laiendab võimalusi ja suurendab mugavust. Miinused: iga uue tootja jaoks on vajalik oma rakendus. Erinevate tootjate seadmete protokollid on sageli omavahel ühildumatud.
Kategooria 2 — üheplaadi arvuti või x86 ühilduva seadme paigaldamine. See garanteerib arvutusvõimsuse piirangute eemaldamise ja sellele masinale on paigaldatud MajorDoMo või mõni muu serveri distributsioon nutikate kodude haldamiseks. Nii saavad enamiku tootjate seadmed ühisesse inforuumi. St. tekib oma Nutika Kodu Server. Plussid: ühtsuse all olev koosolek, mis annab laiemad juhtimisvõimalused. Miinused: serveri rikkumise korral naaseb kogu süsteem etappi 1, st. muutub killustatuks või muutub kasutuks.
Kategooria 3 — kõige hardcore variant. Remondi etapis on mõlemad kommunikatsioonid paigaldatud ja kõik süsteemid on dubleeritud. Plussid: kõik on viidud ideaali ja siis muutub kodu tõeliselt nutikaks. Miinused: äärmuslik kallidus võrreldes kategooriatega 1 ja 2, vajadus kõik eelnevalt läbi mõelda ja iga pisiasja arvesse võtta.
Enamik kasutajaid valib variandi üks ja seejärel liigub sujuvalt variandi kaks. Ja tulevikus jõuavad kõige vastupidavamad ka variandi 3 juurde.
Aga on olemas variant, mida saab nimetada jaotatud süsteemiks: iga eraldi seade on nii server kui ka klient. Sisuliselt on see katse kombineerida variant 1 ja variant 2. Võtab kõik nende plussid ja välistab miinused, püüdes saavutada kuldset kesktee.
Võib-olla ütleb keegi, et selline lahendus on juba välja töötatud. Kuid need lahendused on kitsas suunas; need on mõeldud programmeerimisega kursis olevatele inimestele. Meie eesmärk on alandada sisenemispiiri sellistesse hajutatud süsteemidesse, nii lõppseadmetena kui ka olemasolevate seadmete integreerimisena meie süsteemi. Termostaadi puhul eemaldab kasutaja lihtsalt oma vana termostaadi, paigaldab nutika ja ühendab olemasolevad andurid sellele. Ilma täiendavate toiminguteta.
Vaatleme meie süsteemi integreerimist ühe näite kaudu.
Kujutame ette, et meie võrgus on 8 Sonoff moodulit. Mõnele kasutajale piisab Sonoffi pilveteenuse kaudu juhtimisest (kategooria 1). Teised hakkavad kasutama kolmandate osapoolte püsivara ja sujuvalt liiguvad kategooriasse 2. Enamik kolmandate osapoolte püsivara töötab sama põhimõtte põhjal: andmete edastamine MQTT-serverisse. OpenHub, Majordomo või mõni muu teenus teenib ühte eesmärki – ühendada erinevad seadmed ühte teabekeskkonda, mis asub kas Internetis või kohaliku võrgu sees. Seega on serveri olemasolu kohustuslik. Siit tuleneb peamine probleem – serveri rikke korral lakkab kogu süsteem autonoomselt töötamast. Selle vältimiseks keerukust suurendatakse, lisatakse käsitsi juhtimise meetodeid, mis dubleerivad automaatikat serveri rikke puhul.
Oleme läinud teist teed, kus iga seade on isemajandav. Nii ei mängi server määravat rolli, vaid ainult laiendab funktsionaalsust.
Naaseme mõttelist eksperimenti. Võtame taas need samad 8 Sonoff moodulit ja installime neisse Lytko püsivara. Kõikides Lytko püsivara versioonides on rakendatud funktsioon . SSDP on võrguprotokoll, mis põhineb Interneti protokollide kogumil ja mis teenib võrgu teenuste kuulutamiseks ja avastamiseks. Vastus päringule võib olla nii tavaline kui ka laiendatud. Oleme selle vastuse sisse lülitanud, luues võrgu seadmete nimekirja. Nii leiavad seadmed üksteist ise ja igal neist on selline nimekiri. Näide SSDP loendist:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Nagu näha, sisaldab loetelu seadmete id-sid, IP-aadresse võrgus, ploki tüüpi (meie juhul Sonoffi põhine termostaat). See loetelu uuendatakse iga kahe minuti järel (see aeg on piisav, et reageerida võrgus olevate seadmete arvu dünaamilistele muutustele). Seega jälgime seadmete lisamist, muutmist ja väljalülitamist ilma kasutaja sekkumiseta. See loetelu saadetakse brauserisse või mobiilirakendusse, ja skript genereerib ise lehe soovitud plokkide arvuga. Iga plokk vastab ühele seadmele/sensorile/kontrollerile. Visuaalselt näeb loetelu välja nii:
Aga mis siis, kui esp8266/esp32 külge on ühendatud teised raadio sensorid cc2530 (ZigBee) või nrf24 (MySensors) kaudu?
Projektid
Turul on erinevaid jaotatud süsteeme. Meie süsteem võimaldab integreeruda kõige populaarsematega.
Allpool on projekid, mis püüavad muuta erinevate tootjate üksteisega mitteütlemise olukorda. Näiteks , või . on seotud MQTT-serveriga, seega ei sobi see näitena.
Üks MySensors'i rakendamise võimalusi on ESP8266 põhine seadmevahetus. Ülejäänud näited põhinevad ESP32-l. Nendes on võimalik rakendada meie seadmete avastamise ja loendamise põhimõtet.
Teeme veel ühe mõttelise eksperimendi. Oletame, et meil on ZESP32 või SLS Gateway või MySensors. Kuidas neid ühendada ühte infosüsteemi? Standardfunktsioonidele lisame SSDP protokolli raamatukogu. Kui pöördume selle kontrolleri poole SSDP kaudu, lisab see standardvastusele nimekirja seadmetest, mis on temaga ühendatud. Selle teabe põhjal genereerib brauser lehe. Üldiselt näeb see välja nii:
Veebiliides
PWA-rakendus
"ssdpList":
{
"id": 94967291, \/\/ seadme unikaalne identifikaator
"ip": "192.168.x.x", \/\/ IP aadress võrgus
"type": "thermostat" \/\/ seadme tüüp
},
{
"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"
}
Näide näitab, et seadmed lisatakse üksteisest sõltumatult. On ühendatud 3 termostaati oma IP-aadressidega ja 5 erinevat sensorit unikaalsete ID-dega. Kui sensor on ühendatud Wi-Fi võrguga, siis on tal oma IP, kui see on ühendatud väravaga, siis seadme IP-aadress on värava IP-aadress.
Seadmetega suhtlemiseks kasutame WebSocketit. See võimaldab ressursikasutust vähendada võrreldes GET-päringutega ja saada teavet dünaamiliselt ühendamise või muudatuste korral.
Andmed saadakse otse seadmest, millele plokk kuulub, möödudes serverist. Nii jätkab süsteem tööle kõigi seadmete rikke korral. Veebiliideses ei kuvata vaid puuduvat seadet. Kuid hädaolukorras saab kasutusele tuleva signaali teatisena ühe kasutaja rakendusse.
Selle lähenemise esimene katse oli PWA-rakendus. See võimaldab salvestada plokkide andmebaasi kasutaja seadmesse ja küsida vaid vajalikke andmeid. Kuid selle struktuuri eripära tõttu on see variant puudulik. Ja väljapääs on ainus - natiivrakendused Androidile ja IOS-ile, mis on praegu aktiivse arenduse all. Vaikimisi töötab rakendus ainult sisevõrgus. Vajadusel saab kõik viia välise juhtimise juurde. Nii et, kui kasutaja lahkub lokaalsest võrgust, lülitub rakendus automaatselt pilve.
Väline juhtimine - lehe täielik dubleerimine. Lehe aktiveerimisel saab kasutaja sisse logida serverisse ja hallata seadmeid isiklikust kontost. Nii laieneb serveri funktsionaalsus, võimaldades hallata seadmeid väljaspool kodu ja mitte olla sõltuv sadamate edastamisest või dedikeeritud IP-st.
Seega on ülaltoodud variant vabastatud serveri lähenemise puudustest ja tal on mitmeid eeliseid uute seadmete paindliku ühenduse näol.
Termostaadi kohta
Vaatame juhtimissüsteemi meie termostaadi näitel.
Eeldatud:
- Iga termostaadi temperatuuri reguleerimine (kuvatakse eraldi plokina);
- Termostaadi tööaja ajakava seadistamine (hommik, päev, õhtu, öö);
- Wi-Fi võrgu valimine ja seadme sellele ühendamine;
- Seadme värskendamine "õhu kaudu";
- MQTT seadistamine;
- Seadme ühendatud võrgu seadistamine.
Lisaks veebiliidese kaudu haldamisele on olemas ka klassikaline — ekraanil vajutamisega juhtimine. Seadmest leiab 2,4-tollise Nextion NX3224T024 monitori. Valik langes sellele tänu seadme lihtsale kasutusele. Kuid arenduses on ka meie enda STM32 põhine monitor. Selle funktsionaalsus pole halvem kui Nextionil, kuid hind on madalam, mis mõjutab positiivselt seadme lõpphinda.
Nagu iga enesest lugupidav termostaadi ekraan, oskab meie Nextion:
- seada soovitud kasutaja temperatuuri (vajutustega paremal);
- lülitada sisse ja välja töörežiimi vastavalt ajakavale (nupp N);
- näidata relee tööd (nooleke vasakul);
- omada laste kaitset (füüsilised vajutused on lukustatud, kuni lukustus on avatud);
- näitab WiFi signaali taset.
Lisaks on monitori kaudu võimalik:
- valida kasutaja seadmele paigaldatud anduri tüüpi;
- hallata laste kaitse funktsiooni;
- värskendada püsivara.
WiFi ribale klikkides saab kasutaja teavet ühendatud võrgu kohta. QR-koodi kasutatakse seadme sidumiseks HomeKiti püsivaraga.
Demonstreerimine ekraaniga:
Olemegi välja töötanud kolme ühendatud termostaadiga.
Küsite: “Mis on teie termostaadi eripära?” Praegu on turul palju WiFi funktsiooniga termostaate, ajakava alusel töötavaid ja puutejuhtimisega. Ja entusiastid on kirjutanud mooduleid, et suhelda enamiku tuntud nutikodu süsteemidega (Majordomo, HomeAssistant jne).
Meie termostaat on nende süsteemidega ühilduv ja omab kogu eelnevalt mainitut. Kuid eripära seisneb selles, et termostaati arendatakse pidevalt, tänu süsteemi paindlikkusele. Iga uuendusega laieneb funktsionaalsus. Tavaarvestuse meetodi (ajakava alusel) lisame adaptiivse. Rakendus võimaldab saada kasutaja geolokatsiooni. Tänu sellele suudab süsteem dünaamiliselt muuta töörežiime sõltuvalt tema asukohast. Ja ilmaprogramm võimaldab kohanduda ilmaoludega.
Ja laienemisvõime. Igaüks, kes soovib, saab oma tavalise termostaadi meie omaga vahetada. Selleks on vajalik minimaalne vaev. Oleme valinud 5 kõige populaarsemat andurit, mis turul saadaval, ja lisanud nende toe. Kuid isegi sensorite eksklusiivsete omaduste korral saab kasutaja selle meie termostaadiga ühendada. Selleks tuleb termostaat kalibreerida konkreetse anduri jaoks. Anname juhised.
Termostaati või mõnda muud seadet ühendades ilmub see automaatselt igal pool: nii veebiliideses kui ka PWA-rakenduses. Seadmese lisamine toimub automaatselt: piisab, kui ühendada see Wi-Fi võrku.
Meie süsteem ei vaja serverit ja serveri rikke korral ei muutu see kõrvitsaks. Isegi kui üks komponentidest ebaõnnestub, ei hakka süsteem tööle hädaolukorra stsenaariumi järgi. Kontrollerid, andurid, seadmed — iga element on nii server kui klient, seega täiesti autonoomne.
Kellele huvi pakub — meie sotsiaalmeedia: , , , , .
E-post: shop@lytko.com
P. S. me ei kutsu üles serverist loobuma. Meil on ka MQTT-serveri tugi ja oma pilv. Meie eesmärk on tõsta süsteemi stabiilsus ja usaldusväärsus uuele kvaliteedinivelle. Et server ei oleks nõrk koht, vaid täiendaks funktsionaalsust ja muudaks süsteemi mugavamaks.
Allikas: habr.com
