Pirms kāda laika mēs jums prezentējām . Šis raksts sākotnēji tika domāts kā tā programmatūras un vadības sistēmas demonstrācija. Taču, lai izskaidrotu termostata darbības loģiku un to, ko mēs esam īstenojuši, nepieciešams skaidri izklāstīt visu koncepciju kopumā.
Par automatizāciju
Nosacīti visu automatizāciju var iedalīt trīs kategorijās:
Kategorija 1 — atsevišķi “gudrie” ierīces. Jūs iegādājaties lampas, tējkannas utt. no dažādiem ražotājiem. Plusi: katra ierīce paplašina iespējas un palielina komfortu. Mīnusi: katram jaunam ražotājam nepieciešama sava lietotne. Atsevišķu ražotāju ierīču protokoli lielākoties nav savietojami.
Kategorija 2 — vienas plates datora vai x86 saderīgas ierīces uzstādīšana. Tas noņem ierobežojumus aprēķinu jaudā, un uz šīs ierīces tiek uzstādīts MajorDoMo vai jebkurš cits servera izplatījums gudrā nama vadībai. Tādējādi vairuma ražotāju ierīces apvienojas vienotā informācijas telpā. Proti, izveidojas sava gudrā mājas servera. Plusi: savietojamība zem viena centra, kas sniedz paplašinātas vadības iespējas. Mīnusi: ja serveris sabojājas, visa sistēma atgriežas pirmajā posmā, t.i., kļūst sadrumstalota vai kļūst par bezjēdzīgu.
Kategorija 3 — vissarežģītākais variants. Remonta posmā tiek ierīkotas visas komunikācijas un dublētas visas sistēmas. Plusi: viss tiek novests līdz ideālam, un māja patiesi kļūst gudra. Mīnusi: ārkārtējā dārdzība salīdzinājumā ar kategorijām 1 un 2, nepieciešamība iepriekš rūpīgi plānot visu un ņemt vērā katru sīkumu.
Lielākā daļa lietotāju izvēlas variantu vienu, bet tad pakāpeniski pāriet uz variantu divi. Un vēlāk tie, kas ir visizturīgākie, nonāk līdz variantam 3.
Bet pastāv variants, ko var saukt par izplatītu sistēmu: katra atsevišķā ierīce būs gan serveris, gan klients. Patiesībā tas ir mēģinājums apvienot variantu 1 un variantu 2. Ņemt visus viņu plusus un izslēgt mīnusus, atrast zelta vidusceļu.
Iespējams, kāds teiks, ka šāds variants jau ir izstrādāts. Bet šādi risinājumi ir šaura profila; tiem, kuri ir lietpratēji programmēšanā. Mūsu mērķis ir samazināt piekļuves slieksni līdzīgām sadalītām sistēmām gan kā gala ierīcēm, gan kā esošo ierīču integrācijai mūsu sistēmā. Attiecībā uz termostatu, lietotājs vienkārši noņem savu veco termostatu, uzstāda viedo un pievieno pie tā jau esošos sensorus. Bez jebkādām papildu darbībām.
Apskatīsim integrāciju mūsu sistēmā, izmantojot piemēru.
Iedomāsimies, ka mūsu tīklā ir 8 Sonoff moduļi. Dažiem lietotājiem pietiks ar vadību caur Sonoff mākoņa pakalpojumu (1. kategorija). Daži sāks izmantot trešo pušu programmaparatūru un pakāpeniski pāries uz 2. kategoriju. Lielākā daļa trešo pušu programmaparatūru darbojas pēc tāda paša principa: datu pārraide uz MQTT serveri. OpenHub, Majordomo vai jebkurš cits kalpo vienam mērķim – apvienot izkliedētās ierīces vienotā informācijas telpā, kas atrodas vai nu Internetā, vai lokālajā tīklā. Tādējādi servera klātbūtne ir obligāta. Nolūkā atrisināt galveno problēmu – ja serveris neizdodas, visa sistēma pārstāj darboties autonomi. Lai to novērstu, sistēmas kļūst sarežģītākas, tiek pievienoti manuālie vadības veidi, kas dublē automātiku servera neizdošanās gadījumā.
Mēs gājām pa citu ceļu, kur katra ierīce ir patstāvīga. Tādējādi serveris nespēlē izšķirošu lomu, bet vienkārši papildina funkcionalitāti.
Atgriezīsimies pie mentālā eksperimenta. Atkal ņemsim tos pašus 8 Sonoff moduļus un uzstādīsim tajos Lytko programmaparatūru. Visās Lytko programmaparatūrās ir realizēta funkcija . SSDP – tīkla protokols, kas balstīts uz Interneta protokolu kopumu, ko izmanto tīkla pakalpojumu paziņošanai un atklāšanai. Atbilde uz pieprasījumu var būt gan standarta, gan paplašināta. Mēs esam iekļāvuši šajā atbildē, papildus standarta funkcijām, ierīču saraksta izveidošanu tīklā. Tādējādi ierīces pats atrod viena otras, un katrai no tām būs šāds saraksts. SSDP saraksta piemērs:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Kā redzams piemērā, saraksts ietver ierīču id, IP adresi tīklā, bloka tipu (mūsu gadījumā - Sonoff bāzes termostats). Šis saraksts tiek atjaunināts reizi divās minūtēs (šis laika posms ir pietiekams, lai reaģētu uz dinamiskām izmaiņām ierīču skaitā tīklā). Tādējādi mēs uzraugām ierīču pievienošanu, izmaiņas un atslēgšanu bez lietotāja jebkādām darbībām. Šis saraksts tiek nosūtīts uz pārlūkprogrammu vai mobilu lietotni, un skripts pats veido lapu ar noteikto bloku skaitu. Katrs bloks atbilst vienai ierīcei/sensoram/kontrolierim. Vizuāli saraksts izskatās šādi:
Bet ko darīt, ja pie esp8266/esp32 ir pieslēgti citi radio sensori caur cc2530 (ZigBee) vai nrf24 (MySensors)?
Par projektiem
Tirgu pārstāv dažādas sadalītas sistēmas. Mūsu sistēma ļauj integrēties ar vispopulārākajām.
Zemāk ir projekti, kas kaut kā mēģina mainīt situāciju ar dažādu ražotāju savstarpējo nesavienojamību. Tie ir, piemēram, , vai . ir balstīts uz MQTT serveri, tāpēc nav piemērots šim piemēram.
Viens no MySensors ieviešanas variantiem ir uplink, kas balstīts uz ESP8266. Pārējie piemēri ir uz ESP32. Un tajos var ieviest mūsu darba principu ierīču atklāšanā un saraksta veidošanā.
Veiksim vēl vienu mentālu eksperimentu. Mums ir ZESP32 vai SLS Gateway, vai MySensors. Kā tos apvienot vienā informācijas telpā? Standarta šo uplink funkcijām pievienosim SSDP protokola bibliotēku. Piekļūstot šim kontrolierim caur SSDP, tas standartatbildē pievienos sarakstu ar ierīcēm, kas ir pievienotas tam. Pamatojoties uz šo informāciju, pārlūkprogramma izveidos lapu. Vispārējā izskatā tas izskatīsies šādi:
Web interfeiss
PWA lietotne
"ssdpList":
{
"id": 94967291, // unikālais ierīces identifikators
"ip": "192.168.x.x", // IP adrese tīklā
"type": "thermostat" // ierīces tips
},
{
"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"
}
Piemērā var redzēt, ka ierīces tiek pievienotas neatkarīgi viena no otras. Ir pievienoti 3 termostati ar saviem IP adresēm un 5 dažādi sensori ar unikālām ID. Ja sensors ir pievienots Wi-Fi tīklam, tam būs sava IP adrese, ja tas ir pievienots vārtiem, tad ierīces IP adrese būs vārtu IP adrese.
Sazināšanai ar ierīcēm mēs izmantojam WebSocket. Tas ļauj samazināt resursu patēriņu salīdzinājumā ar GET pieprasījumiem un dinamiski saņemt informāciju, kad tiek izveidota savienojums vai notiek izmaiņas.
Dati tiek ņemti tieši no tās ierīces, kurai pieder bloks, apejot serveri. Tādējādi, ja jebkura no ierīcēm neizdodas, sistēma turpina darboties. Web saskarnē vienkārši netiks parādīta no saraksta izslēgtā ierīce. Bet signāls par izslēgšanu, ja nepieciešams, tiks sūtīts kā paziņojums lietotāja lietotnē.
Pirmā šāda pieejas īstenošanas mēģinājums bija PWA lietotne. Tas ļauj uzglabāt bloku datubāzi lietotāja ierīcē un pieprasīt tikai nepieciešamos datus. Bet struktūras īpatnību dēļ šis variants nav pilnvērtīgs. Un risinājums ir viens - nativās lietotnes Android un IOS, kuru šobrīd aktīvi izstrādā. Noklusējuma iestatījumi nodrošina, ka lietotne darbosies tikai iekšējā tīklā. Ja nepieciešams, var visu pārcelt uz ārējo pārvaldību. Tādējādi, kad lietotājs pamet lokālo tīklu, lietotne automātiski pārslēdzas uz mākoni.
Ārējā pārvaldība — pilnīga lapas dublēšana. Aktivizējot lapu, lietotājs var pieslēgties serverim un pārvaldīt ierīces caur personīgo kabinetu. Tādējādi serveris paplašina funkcionalitāti, ļaujot pārvaldīt ierīces, atrodoties ārpus mājas, un nebūt piesaistītam pie portu pārlikšanas vai statiskās IP adreses.
Tādējādi iepriekš aprakstītais variants ir brīvs no serveru pieejas trūkumiem un ir vairākas priekšrocības, piemēram, jaunu ierīču savienojumu elastība.
Par termostatu
Apskatīsim vadības sistēmu, pamatojoties uz mūsu termostatu.
Paredzēts:
- Katrā termostatā regulēšana (tiek attēlots kā atsevišķs bloks);
- Termostata darbības grafika iestatīšana (rīts, diena, vakars, nakts);
- Wi-Fi tīkla izvēle un ierīces pieslēgšana;
- Ierīces atjaunināšana "pa gaisu";
- MQTT iestatīšana;
- Iestatījumi tīklam, pie kura ir pieslēgta ierīce.
Papildus vadībai, izmantojot web-interfeisu, ir paredzēta klasiskā opcija - piespiežot ekrānu. Uz dēļa ir uzstādīts Nextion NX3224T024 2.4 collu monitors. Izvēle krita uz to, ņemot vērā ērtību darbā ar ierīci. Tomēr tiek izstrādāts arī mūsu pašu monitors, balstīts uz STM32. Tā funkcionalitāte nebūt nav sliktāka par Nextion, bet tas būs lētāks, kas pozitīvi ietekmēs ierīces gala cenu.
Kā jebkuram cienījamam termostata ekrānam, mūsu Nextion spēj:
- iestatīt lietotājam nepieciešamo temperatūru (pogas labajā pusē);
- ieslēgt un izslēgt darba režīmu pēc grafika (N pogas);
- parādīt relē darbību (bultiņa pa kreisi);
- ir aizsardzība no bērniem (bloķē fiziskus pieskārienus, kamēr slēdzis nav noņemts);
- parāda WiFi signāla līmeni.
Turklāt, izmantojot monitoru, var:
- izvēlēties uzstādītā lietotāja sensora tipu;
- vadīt bērnu aizsardzības funkciju;
- atjaunot programmatūru.
Noklikšķinot uz WiFi joslas, lietotājs uzzinās informāciju par pieslēgto tīklu. QR kods tiek izmantots ierīces saistīšanai HomeKit programmatūrā.
Demonstrācija darbam ar displeju:
Mēs esam izstrādājuši ar trim pieslēgtiem termostātiem.
Jūs jautāsiet: “Kāda ir jūsu termostata īpatnība?” Šobrīd tirgū ir daudz termostatu ar Wi-Fi funkciju, darbiem pēc grafika, skārienvadības. Un entuziasti ir rakstījuši moduļus, lai mijiedarbotos ar lielāko daļu populāro inteligento māju sistēmām (Majordomo, HomeAssistant utt.).
Mūsu termostats ir savietojams ar šīm sistēmām un ietver visas iepriekš minētās funkcijas. Bet atšķirīga iezīme ir tā, ka termostats pastāvīgi tiek attīstīts, pateicoties sistēmas elastībai. Ar katru atjauninājumu funkcionālais apjoms tiks paplašināts. Standarta sistēmas vadības metodei (pēc grafika) mēs pievienosim adaptīvo. Lietotne ļaus saņemt lietotāja ģeolokāciju. Pateicoties tam, sistēma dinamiski mainīs darba režīmus atkarībā no tā atrašanās vietas. Un laika modulis ļaus pielāgoties laikapstākļiem.
Un paplašināmība. Ikviens varēs nomainīt pie viņa uzstādīto parasto termostatu uz mūsu. Ar minimālām pūlēm. Mēs esam izvēlējušies 5 populārākos sensorus, kas pieejami tirgū, un pievienojuši to atbalstu. Pat ja sensoram ir ekskluzīvas īpašības, lietotājs varēs to pieslēgt mūsu termostatam. Lai to izdarītu, būs nepieciešams kalibrēt termostatu darbam ar konkrēto sensoru. Norādījumus mēs sniegsim.
Pieslēdzot termostatu vai jebkuru citu ierīci, tā vienlaikus parādās visur: gan tīmekļa saskarnē, gan PWA lietotnē. Ierīces pievienošana notiek automātiski: pietiek tikai to pieslēgt Wi-Fi tīklam.
Mūsu sistēma neprasa serveri, un tā neveidojas par ķirbi servera atteikuma gadījumā. Pat ja viens no komponentiem atsakās, sistēma neiet iekritēšanas režīmā. Kontrolieri, sensori, ierīces — katrs elements ir gan serveris, gan klients, tādējādi pilnībā autonoms.
Interesentiem — mūsu sociālie tīkli: , , , , .
Epasts: shop@lytko.com
P. S. mēs nenovēršamies no Servera. Mums ir arī MQTT servera atbalsts un ir mūsu mākonis. Mūsu mērķis ir paaugstināt sistēmas stabilitāti un uzticamību uz kvalitatīvi jaunu līmeni. Lai serveris nebūtu vājā vieta, bet gan papildinātu funkcionalitāti un padarītu sistēmu ērtāku.
Avots: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish