Nekoč smo vam predstavili . Ta članek je bil prvotno zamišljen kot predstavitev njegovega programske opreme in sistema upravljanja. Vendar pa je za razumevanje logike delovanja termostata in tega, kar smo uresničili, potrebno orisati celotno konceptualno zasnovo.
O avtomatizaciji
Pogojno lahko vso avtomatizacijo razdelimo na tri kategorije:
Kategorija 1 — posamezni "pametni" naprave. Kupujete različne proizvode, kot so žarnice, električni kotli itd. Prednosti: vsaka naprava povečuje zmogljivost in udobje. Slabosti: za vsakega novega proizvajalca potrebujete svojo aplikacijo. Protokoli naprav različnih proizvajalcev pogosto niso združljivi med seboj.
Kategorija 2 — namestitev enoplatnega računalnika ali x86 združljivega sistema. To odpravlja omejitve procesorske moči, na tej napravi je mogoče namestiti MajorDoMo ali kateri koli drug strežniški distribucijski paket za upravljanje pametne hiše. Tako se lahko naprave večine proizvajalcev povežejo v enotnem informacijskem prostoru. T.j. imate svoj strežnik za pametno hišo. Prednosti: združljivost pod eno središče, kar omogoča razširjene možnosti upravljanja. Slabosti: ob okvari strežnika se celoten sistem vrne v stanje 1, t.j. postane razdrobljen ali pa se spremeni v neuporabnega.
Kategorija 3 — najbolj zahtevna izbira. Med obnovitvenimi deli so vsa omrežja položena in vsi sistemi so podvojeni. Prednosti: vse je dovršeno do popolnosti in hiša postane resnično pametna. Slabosti: izjemno visoki stroški v primerjavi s kategorijama 1 in 2, potreba po vnaprejšnjem razmišljanju o vsem in upoštevanju vsake podrobnosti.
Večina uporabnikov izbere možnost ena, nato pa počasi prehajajo na možnost dva. V nadaljevanju pa najtrdnejši dosežejo možnost 3.
Obstaja pa tudi možnost, ki jo lahko imenujemo distribuiran sistem: vsaka posamezna naprava bo tako strežnik kot tudi odjemalec. V bistvu je to poskus združiti možnost 1 in možnost 2. Zgrabi njihove prednosti in odpravi slabosti, ujame zlat srednji pot.
Morda bo nekdo rekel, da je taka možnost že razvita. Vendar so takšna rešitev usmerjene; za ljudi, ki se spoznajo na programiranje. Naš cilj je znižati vstopno oviro v tovrstne distribuirane sisteme, tako v obliki končnih naprav, kot tudi pri integraciji obstoječih naprav v naš sistem. Kar zadeva termostat, uporabnik preprosto odstrani svoj stari termostat, namesti pametnega in poveže obstoječe senzorje na njega. Brez kakršnih koli dodatnih dejanj.
Oglejmo si integracijo v naš sistem na primeru.
Predstavljajmo si, da imamo v omrežju 8 modulov Sonoff. Nekaterim uporabnikom bo zadostovalo upravljanje preko oblaka Sonoff (kategorija 1). Nekateri se bodo odločili za uporabo tretje programske opreme in gladko prešli v kategorijo 2. Večina zunanjih programski oprem deluje na enakem principu: prenos podatkov na MQTT strežnik. OpenHub, Majordomo ali katerikoli drug služijo enemu namenu – združiti razpršene naprave v enotno informacijsko okolje, bodisi v internetu, bodisi v lokalnem omrežju. Zato je prisotnost strežnika obvezna. Od tod izhaja glavni problem – ob odpovedi strežnika celoten sistem preneha delovati avtonomno. Da bi to preprečili, se sistemi zapletajo, dodajajo se ročni načini upravljanja, ki podvajajo avtomatiko v primeru odpovedi strežnika.
Mi pa smo šli po drugi poti, kjer je vsaka naprava samostojna. Tako strežnik ne igra odločilne vloge, ampak le razširja funkcionalnost.
Vrnimo se k miselnemu eksperimentu. Spet vzemimo iste 8 modulov Sonoff in namestimo zanjo programsko opremo Lytko. V vseh različicah programske opreme Lytko je implementirana funkcija . SSDP je omrežni protokol, temelječ na naboru internetnih protokolov, ki se uporablja za objavo in iskanje omrežnih storitev. Odgovor na zahtevo je lahko tako standarden kot tudi razširjen. V ta odgovor smo vključili poleg standardnih funkcij tudi ustvarjanje seznama naprav v omrežju. Tako naprave same najdejo druga drugo, in vsaka od njih bo imela tak seznam. Primer seznama SSDP:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "termostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "termostat"
}Kot vidite iz primera, seznam vključuje id naprav, ip-naslov v omrežju, tip enote (v našem primeru — termostat na osnovi Sonoff). Ta seznam se posodablja enkrat na dve minuti (ta interval je dovolj za odzivanje na dinamične spremembe števila naprav v omrežju). Tako spremljamo dodajanje, spremembo in izklop naprav brez kakršnih koli dejanj s strani uporabnika. Ta seznam se pošilja v brskalnik ali mobilno aplikacijo, skript pa sam oblikuje stran z določenim številom enot. Vsaka enota ustreza eni napravi/senzorju/kontrolerju. Vizualno seznam izgleda tako:
Toda kaj, če so na esp8266/esp32 povezani drugi brezžični senzorji preko cc2530 (ZigBee) ali nrf24 (MySensors)?
O projektih
Na trgu so prisotne različne porazdeljene sisteme. Naš sistem omogoča integracijo z najpopularnejšimi.
Spodaj so projekti, ki si na tak ali drugačen način prizadevajo spremeniti situacijo s kompatibilnostjo različnih proizvajalcev. To so na primer: , ili . je povezan na MQTT strežniku, zato ni primeren za ta primer.
Ena od možnosti izvedbe MySensors je prehod, ki temelji na ESP8266. Ostali primeri so na ESP32. V njih lahko vgradimo naš princip delovanja pri zaznavanju in ustvarjanju seznama naprav.
Izvedimo še en miselni eksperiment. Imamo prehod ZESP32 ali SLS Gateway ali MySensors. Kako jih lahko združimo v enotnem informacijskem prostoru? K standardnim funkcijam teh prehodov dodajamo knjižnico protokola SSDP. Ko se obrnemo na ta kontroler po SSDP, bo k standardnemu odgovoru dodal seznam naprav, ki so priključene nanj. Na podlagi teh informacij bo brskalnik oblikoval stran. Na splošno bo to izgledalo tako:
Spletni vmesnik
PWA-aplikacija
"ssdpList":
{
"id": 94967291, // unikatna identifikacijska številka naprave
"ip": "192.168.x.x", // ip naslov v omrežju
"type": "thermostat" // tip naprave
},
{
"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"
}
Iz primera je razvidno, da se naprave dodajajo neodvisno ena od druge. Povezani so 3 termostati z lastnimi IP-naslovi in 5 različnih senzorjev z uničnimi ID-ji. Če je senzor povezan z Wi-Fi omrežjem, bo imel svoj IP, če je povezan z prehodom, bo IP-naslov naprave enak IP-naslovu prehoda.
Za komunikacijo z napravami uporabljamo WebSocket. To omogoča minimalizacijo porabe virov v primerjavi z GET zahtevki in dinamično pridobivanje informacij ob povezavi ali spremembi.
Podatki se pridobivajo neposredno z naprave, ki ji blok pripada, brez posredovanja strežnika. Tako sistem nadaljuje z delovanjem tudi ob odpovedi katere koli naprave. Na spletnem vmesniku le ne bo prikazano izgubljeno napravo. Vendar bo signal o izgubi, če bo potrebno, poslan kot obvestilo v uporabniško aplikacijo.
Prvi poskus realizacije takšnega pristopa je bila PWA-aplikacija. To omogoča shranjevanje baze blokov na uporabniški napravi in pridobivanje samo potrebnih podatkov. Vendar pa zaradi posebnosti strukture ta različica ni popolna. Edina rešitev je nativna aplikacija za Android in IOS, ki je trenutno v aktivnem razvoju. Privzeto bo aplikacija delovala samo v notranjem omrežju. Po potrebi lahko vse prenesemo na zunanjo upravljanje. Tako ko uporabnik zapusti lokalno omrežje, se aplikacija samodejno preklopi na oblak.
Zunanje upravljanje — popolno podvajanje strani. Ko je stran aktivirana, se lahko uporabnik prijavi na strežnik in upravlja naprave preko svojega računa. Tako strežnik razširja funkcionalnost, kar omogoča upravljanje naprav izven doma in ne povezuje uporabnika z usmerjanjem vrat ali dodeljenim IP.
Tako ta opisani pristop nima pomanjkljivosti strežniškega pristopa ter ima vrsto prednosti v smislu fleksibilnosti pri povezovanju novih naprav.
O termostatu
Poglejmo sistem upravljanja na primeru našega termostata.
Predvideno je:
- Urejanje temperature vsakega termostata (prikazano v obliki ločenega bloka);
- Nastavitev urnika delovanja termostata (jutro, dan, večer, noč);
- Izbor Wi-Fi omrežja in povezava naprave nanj;
- Posodobitev naprave “po zraku”;
- Nastavitev MQTT;
- Nastavitev omrežja, h kateremu je povez naprava.
Poleg upravljanja preko spletnega vmesnika smo predvideli tudi klasično upravljanje — s pritiski na zaslon. Na voljo imamo monitor Nextion NX3224T024 2.4 palca. Izbira je padla nanj zaradi enostavne uporabe naprave. V razvoju pa je tudi naš lasten monitor na osnovi STM32. Njegova funkcionalnost ni nič manjša od funkcionalnosti Nextion, a bo cenejši, kar bo pozitivno vplivalo na končno ceno naprave.
Kot vsak pravi zaslon termostata, naš Nextion zna:
- nastaviti želeno temperaturo za uporabnika (s gumbi na desni);
- vklopiti in izklopiti način delovanja po urniku (gumb N);
- prikazovati delovanje releja (puščica na levi);
- ima zaščito pred otroki (fizični pritiski so blokirani, dokler ni zaklep odstranjen);
- prikazuje raven WiFi signala.
Poleg tega lahko preko monitorja:
- izbere vrsto senzorja, ki ga ima uporabnik;
- upravljate funkcijo zaščite pred otroki;
- posodobite programsko opremo.
Ob klikovanju na WiFi vrstico uporabnik izve informacije o povezanem omrežju. QR koda se uporablja za povezovanje naprave s programsko opremo HomeKit.
Demo dela z zaslonom:
Razvili smo s tremi povezanimi termostati.
Vprašali boste: "Kakšna je posebnost vašega termostata?" Na trgu je že veliko termostatov z Wi-Fi funkcijo, delovanjem po urniku in upravljanjem na dotik. Enthuzijasti so napisali module za interakcijo s številnimi priljubljenimi sistemi pametnega doma (Majordomo, HomeAssistant itd.).
Naš termostat je združljiv s takšnimi sistemi in ima vse našteto. Ampak posebnost je, da se termostat neprestano izboljšuje, zahvaljujoč fleksibilnosti sistema. Z vsakim posodobitvijo se bo funkcionalnost širila. K standardnemu načinu upravljanja sistema (po urniku) bomo dodali prilagodljivega. Aplikacija omogoča pridobitev geolokacije uporabnika. Zaradi tega bo sistem dinamično spreminjal načine delovanja glede na njegovo lokacijo. In modul za vreme bo omogočal prilagoditev vremenskim razmeram.
In addition to expandability. Anyone can easily replace the installed standard thermostat with ours. We selected five of the most popular sensors available on the market and added their support. Even if there are exclusive characteristics of the sensor, the user will be able to connect it to our thermostat. Calibration of the thermostat for specific sensors will be required. We will provide instructions.
When connecting the thermostat or any other device, it appears everywhere: both in the web interface and in the PWA application. The addition of the device occurs automatically: just connect it to the Wi-Fi network.
Our system does not require a Server, and in case of its failure, it does not turn into a pumpkin. Even if one of the components fails, the system does not revert to emergency mode. Controllers, sensors, devices — each element acts as both a Server and a client, making it completely autonomous.
For those interested — our social networks: , , , , .
Email: shop@lytko.com
P. S. We do not advocate abandoning the Server. We also support an MQTT server and have our own cloud. Our goal is to bring the stability and reliability of the system to a qualitatively new level. So that the Server does not become a weak point, but complements functionality and makes the system more convenient.
Izvor: habr.com
