Kanina pa kami nagpakilala sayo . Ang artikulong ito ay orihinal na inilaan bilang isang pagpapakita ng firmware at control system nito. Ngunit upang maipaliwanag ang lohika ng termostat at kung ano ang ipinatupad namin, kinakailangan na balangkasin ang buong konsepto sa kabuuan.
Tungkol sa automation
Karaniwan, ang lahat ng automation ay maaaring nahahati sa tatlong kategorya:
Kategorya 1 β hiwalay na "smart" na mga aparato. Bumili ka ng mga bumbilya, teapot, atbp. mula sa iba't ibang mga tagagawa. Mga Kalamangan: Ang bawat device ay nagpapalawak ng mga kakayahan at nagpapataas ng ginhawa. Kahinaan: Ang bawat bagong tagagawa ay nangangailangan ng sarili nitong aplikasyon. Ang mga protocol ng mga device mula sa iba't ibang mga tagagawa ay kadalasang hindi tugma sa isa't isa.
Kategorya 2 β pag-install ng isang single-board PC o x86 compatible. Inaalis nito ang mga paghihigpit sa kapangyarihan sa pag-compute, at ang MajorDoMo o anumang iba pang pamamahagi ng server para sa pamamahala ng isang matalinong tahanan ay naka-install sa makinang ito. Kaya, ang mga device mula sa karamihan ng mga tagagawa ay konektado sa isang espasyo ng impormasyon. Yung. lalabas ang sarili mong Server para sa isang smart home. Mga kalamangan: pagiging tugma sa ilalim ng isang solong sentro, na nagbibigay ng mga pinahusay na kakayahan sa pamamahala. Cons: kung nabigo ang server, babalik ang buong system sa stage 1, i.e. nagiging pira-piraso o nagiging inutil.
Kategorya 3 - ang pinaka-hardcore na opsyon. Sa yugto ng pag-aayos, lahat ng mga komunikasyon ay inilatag at lahat ng mga sistema ay nadoble. Mga kalamangan: lahat ay dinadala sa pagiging perpekto at pagkatapos ang bahay ay nagiging tunay na matalino. Mga disadvantages: sobrang mahal kumpara sa mga kategorya 1 at 2, ang pangangailangan na pag-isipan ang lahat nang maaga at isaalang-alang ang bawat maliit na detalye.
Karamihan sa mga user ay pipili ng opsyon isa at pagkatapos ay maayos na lumipat sa opsyon na dalawa. At pagkatapos ay ang mga pinaka-persistent ay umabot sa opsyon 3.
Ngunit mayroong isang opsyon na maaaring tawaging isang distributed system: ang bawat indibidwal na device ay magiging parehong server at client. Sa esensya, ito ay isang pagtatangka na kunin at pagsamahin ang opsyon 1 at opsyon 2. Kunin ang lahat ng kanilang mga kalamangan at alisin ang mga kahinaan, upang mahuli ang ginintuang ibig sabihin.
Marahil ay may magsasabi na ang ganitong opsyon ay binuo na. Ngunit ang gayong mga desisyon ay makitid na nakatuon; para sa mga taong savvy sa programming. Ang aming layunin ay babaan ang hadlang sa pagpasok sa mga naturang distributed system, parehong sa anyo ng mga end device at sa anyo ng pagsasama ng mga kasalukuyang device sa aming system. Sa kaso ng isang termostat, inaalis lang ng user ang kanyang lumang thermostat, nag-i-install ng smart, at ikinokonekta ang kanyang mga kasalukuyang sensor dito. Nang walang anumang karagdagang mga hakbang.
Tingnan natin ang pagsasama sa aming system gamit ang isang halimbawa.
Isipin natin na mayroon tayong 8 Sonoff modules sa ating network. Para sa ilang mga gumagamit, ang kontrol sa pamamagitan ng Sonoff cloud (kategorya 1) ay magiging sapat. Ang ilan ay magsisimulang gumamit ng third-party na firmware at maayos na lilipat sa kategorya 2. Ang karamihan ng third-party na firmware ay gumagana sa parehong prinsipyo: paglilipat ng data sa isang MQTT server. Ang OpenHub, Majordomo o anupamang iba ay nagsisilbi sa isang layunin - upang pag-isahin ang magkakaibang mga aparato sa isang espasyo ng impormasyon na matatagpuan alinman sa Internet o sa isang lokal na network. Samakatuwid, ang pagkakaroon ng isang Server ay sapilitan. Ito ay kung saan ang pangunahing problema arises - kung ang Server ay nabigo, ang buong sistema ay hihinto sa paggana ng autonomously. Upang maiwasan ito, ang mga system ay nagiging mas kumplikado, ang mga manu-manong pamamaraan ng kontrol ay idinagdag na duplicate na automation sa kaganapan ng isang pagkabigo ng Server.
Iba't ibang landas ang tinahak namin, kung saan ang bawat device ay may sariling kakayahan. Kaya, ang Server ay hindi gumaganap ng isang mapagpasyang papel, ngunit pinapalawak lamang ang pag-andar.
Bumalik tayo sa eksperimento sa pag-iisip. Kunin muli ang parehong 8 Sonoff module at i-install ang Lytko firmware sa kanila. Ang lahat ng mga firmware ng Lytko ay may function . Ang SSDP ay isang network protocol batay sa Internet protocol suite para sa advertising at pagtuklas ng mga serbisyo sa network. Ang tugon sa isang kahilingan ay maaaring maging karaniwan o pinalawig. Bilang karagdagan sa mga karaniwang pag-andar, isinama namin sa sagot na ito ang paglikha ng isang listahan ng mga device sa network. Kaya, ang mga device mismo ay nahahanap ang isa't isa, at ang bawat isa sa kanila ay magkakaroon ng ganoong listahan. Halimbawa ng SSDP sheet:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Tulad ng nakikita mo mula sa halimbawa, kasama sa listahan ang mga id ng device, IP address sa network, uri ng unit (sa aming kaso, isang termostat na nakabatay sa Sonoff). Ang listahang ito ay ina-update isang beses bawat dalawang minuto (ang panahong ito ay sapat na upang tumugon sa mga dynamic na pagbabago sa bilang ng mga device sa network). Sa ganitong paraan, sinusubaybayan namin ang mga device na idinagdag, binago, at hindi pinagana nang walang anumang pagkilos ng user. Ang listahang ito ay ipinadala sa browser o mobile application, at ang script mismo ay bumubuo ng isang pahina na may ibinigay na bilang ng mga bloke. Ang bawat bloke ay tumutugma sa isang device/sensor/controller. Biswal na ganito ang hitsura ng listahan:
Ngunit paano kung ang ibang mga sensor ng radyo ay konektado sa esp8266/esp32 sa pamamagitan ng cc2530 (ZigBee) o nrf24 (MySensors)?
Tungkol sa mga proyekto
Mayroong iba't ibang mga ipinamamahaging sistema sa merkado. Pinapayagan ka ng aming system na isama ang mga pinakasikat.
Nasa ibaba ang mga proyekto na isang paraan o iba pang sinusubukang baguhin ang sitwasyon sa hindi pagkakatugma ng iba't ibang mga tagagawa sa isa't isa. Ito ay, halimbawa, , o . ay nakatali sa isang MQTT server, kaya hindi ito angkop para sa halimbawa.
Ang isang opsyon para sa pagpapatupad ng MySensors ay isang gateway batay sa ESP8266. Ang natitirang mga halimbawa ay nasa ESP32. At sa kanila maaari mong ipatupad ang aming prinsipyo sa pagpapatakbo ng pag-detect at paglikha ng isang listahan ng mga device.
Gumawa tayo ng isa pang eksperimento sa pag-iisip. Mayroon kaming ZESP32 gateway o SLS Gateway, o MySensors. Paano sila pagsasamahin sa isang espasyo ng impormasyon? Idaragdag namin ang SSDP protocol library sa mga karaniwang function ng mga gateway na ito. Kapag ina-access ang controller na ito sa pamamagitan ng SSDP, magdaragdag ito ng listahan ng mga device na nakakonekta dito sa karaniwang tugon. Batay sa impormasyong ito, bubuo ang browser ng isang pahina. Sa pangkalahatan ito ay magiging ganito:
Web interface
Aplikasyon ng 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"
}
Ipinapakita ng halimbawa na ang mga device ay idinagdag nang hiwalay sa bawat isa. Nakakonekta ang 3 thermostat na may sariling mga IP address at 5 magkakaibang sensor na may natatanging ID. Kung nakakonekta ang sensor sa isang Wi-Fi network, magkakaroon ito ng sarili nitong IP; kung nakakonekta ito sa isang gateway, ang IP address ng device ay magiging IP address ng gateway.
Ginagamit namin ang WebSocket para makipag-ugnayan sa mga device. Binibigyang-daan ka nitong bawasan ang mga gastos sa mapagkukunan kumpara sa pagkuha ng mga kahilingan at pagkuha ng impormasyon nang dynamic kapag kumokonekta o nagbabago.
Ang data ay direktang kinuha mula sa device kung saan nabibilang ang block, na lumalampas sa server. Kaya, kung nabigo ang alinman sa mga device, patuloy na gagana ang system. Hindi lang ipinapakita ng web interface ang nawawalang device mula sa listahan. Ngunit ang isang senyas tungkol sa pagkawala, kung kinakailangan, ay darating sa anyo ng isang abiso sa application ng user.
Ang unang pagtatangka na ipatupad ang pamamaraang ito ay isang aplikasyon ng PWA. Binibigyang-daan ka nitong mag-imbak ng block base sa device ng user at humiling lamang ng kinakailangang data. Ngunit dahil sa mga kakaiba ng istraktura, ang pagpipiliang ito ay hindi kumpleto. At mayroon lamang isang paraan out - isang katutubong application para sa Android at IOS, na kasalukuyang nasa ilalim ng aktibong pag-unlad. Bilang default, gagana lamang ang application sa panloob na network. Kung kinakailangan, maaari mong ilipat ang lahat sa panlabas na kontrol. Kaya, kapag umalis ang user sa lokal na network, awtomatikong lilipat ang application sa cloud.
Panlabas na kontrol - kumpletong pagdoble ng pahina. Kapag na-activate ang page, maaaring mag-log in ang user sa server at mamahala ng mga device sa pamamagitan ng kanilang personal na account. Kaya, pinalawak ng Server ang functionality nito, na nagbibigay-daan sa iyong pamahalaan ang mga device habang nasa labas ng bahay, at hindi nakatali sa port forwarding o isang dedikadong IP.
Kaya, ang pagpipilian sa itaas ay walang mga disadvantages ng diskarte sa server, at mayroon ding ilang mga pakinabang sa anyo ng kakayahang umangkop sa pagkonekta ng mga bagong device.
Tungkol sa termostat
Tingnan natin ang control system gamit ang ating thermostat bilang isang halimbawa.
Ibinigay:
- Kontrol sa temperatura para sa bawat termostat (ipinapakita bilang isang hiwalay na bloke);
- Pagtatakda ng iskedyul ng pagpapatakbo ng termostat (umaga, hapon, gabi, gabi);
- Pagpili ng Wi-Fi network at pagkonekta ng device dito;
- Pag-update ng device "over the air";
- Pagse-set up ng MQTT;
- I-configure ang network kung saan nakakonekta ang device.
Bilang karagdagan sa kontrol sa pamamagitan ng web interface, ibinigay namin ang classic - sa pamamagitan ng pag-click sa display. May nakasakay na Nextion NX3224T024 2.4-inch monitor. Ang pagpili ay nahulog sa kanya dahil sa kadalian ng pagtatrabaho sa device. Ngunit gumagawa kami ng sarili naming monitor batay sa STM32. Ang pag-andar nito ay hindi mas masahol kaysa sa Nextion, ngunit mas mababa ang halaga nito, na magkakaroon ng positibong epekto sa panghuling presyo ng device.
Tulad ng anumang screen ng thermostat na may paggalang sa sarili, ang aming Nextion ay maaaring:
- itakda ang temperatura na kinakailangan ng gumagamit (gamit ang mga pindutan sa kanan);
- i-on at i-off ang naka-iskedyul na mode ng operasyon (button H);
- display relay operation (arrow sa kaliwa);
- may proteksyon sa bata (pinipigilan ang mga pisikal na pag-click hanggang maalis ang lock);
- nagpapakita ng lakas ng signal ng WiFi.
Bilang karagdagan, gamit ang monitor maaari mong:
- piliin ang uri ng sensor na naka-install ng user;
- pamahalaan ang tampok na child lock;
- i-update ang firmware.
Sa pamamagitan ng pag-click sa WiFi bar, malalaman ng user ang impormasyon tungkol sa konektadong network. Ginagamit ang QR code para ipares ang device sa firmware ng HomeKit.
Demo ng pagtatrabaho sa display:
Nadevelop na kami na may tatlong konektadong thermostat.
Maaari mong itanong, "Ano ang espesyal sa iyong thermostat?" Ngayon sa merkado ay maraming mga thermostat na may Wi-Fi function, naka-iskedyul na operasyon, at touch control. At ang mga mahilig ay may nakasulat na mga module para makipag-ugnayan sa pinakasikat na mga smart home system (Majordomo, HomeAssistant, atbp.).
Ang aming thermostat ay tugma sa mga naturang system at mayroon ang lahat ng nasa itaas. Ngunit ang natatanging tampok ay ang thermostat ay patuloy na pinapabuti, salamat sa flexibility ng system. Sa bawat pag-update, lalawak ang functionality. Sa karaniwang paraan ng pamamahala ng system (ayon sa isang iskedyul), magdaragdag kami ng isang adaptive. Binibigyang-daan ka ng application na makuha ang geolocation ng user. Salamat dito, pabago-bagong babaguhin ng system ang mga operating mode depende sa lokasyon nito. At ang module ng panahon ay magbibigay-daan sa iyo na umangkop sa mga kondisyon ng panahon.
At pagpapalawak. Kahit sino ay maaaring palitan ang kanilang kasalukuyang kumbensyonal na thermostat ng sa amin. Sa kaunting pagsisikap. Pumili kami ng 5 sa mga pinakasikat na sensor sa merkado at nagdagdag ng suporta para sa kanila. Ngunit kahit na ang sensor ay may mga eksklusibong katangian, maikokonekta ito ng user sa aming thermostat. Upang gawin ito, kakailanganin mong i-calibrate ang termostat upang gumana sa isang partikular na sensor. Magbibigay kami ng mga tagubilin.
Kapag nagkokonekta ng thermostat o anumang iba pang device, sabay-sabay itong lumalabas sa lahat ng dako: sa web interface at sa PWA application. Awtomatikong nagaganap ang pagdaragdag ng device: kailangan mo lang itong ikonekta sa Wi-Fi network.
Hindi kailangan ng aming system ng Server, at kung mabigo ito, hindi ito magiging kalabasa. Kahit na nabigo ang isa sa mga bahagi, hindi magsisimulang gumana ang system sa isang sitwasyong pang-emergency. Mga controller, sensor, device - bawat elemento ay parehong Server at client, samakatuwid ay ganap na nagsasarili.
Para sa mga interesado, ang aming mga social network: , , , , .
E-mail: [protektado ng email]
PS Hindi ka namin hinihikayat na talikuran ang Server. Sinusuportahan din namin ang isang MQTT server at mayroon kaming sariling cloud. Ang aming layunin ay dalhin ang katatagan at pagiging maaasahan ng system sa isang bagong antas. Upang ang Server ay hindi isang mahinang punto, ngunit pinupunan ang pag-andar at ginagawang mas maginhawa ang system.
Pinagmulan: www.habr.com