Antaŭ iom da tempo ni prezentis vin . Ĉi tiu artikolo estis origine celita kiel pruvo de sia firmvaro kaj kontrolsistemo. Sed por klarigi la logikon de la termostato kaj kion ni efektivigis, necesas skizi la tutan koncepton kiel tuton.
Pri aŭtomatigo
Konvencie, ĉiu aŭtomatigo povas esti dividita en tri kategoriojn:
Kategorio 1 — apartaj “inteligentaj” aparatoj. Vi aĉetas ampolojn, tekruĉojn ktp de malsamaj fabrikantoj. Avantaĝoj: Ĉiu aparato pligrandigas kapablojn kaj pliigas komforton. Malavantaĝoj: Ĉiu nova fabrikanto postulas sian propran aplikon. Protokoloj de aparatoj de malsamaj fabrikantoj ofte ne kongruas unu kun la alia.
Kategorio 2 — instalado de unu-estrara komputilo aŭ x86 kongrua. Ĉi tio forigas limigojn pri komputika potenco, kaj MajorDoMo aŭ ajna alia servila distribuo por administri inteligentan hejmon estas instalita sur ĉi tiu maŝino. Tiel, aparatoj de plej multaj fabrikantoj estas konektitaj en ununura informspaco. Tiuj. via propra Servilo por inteligenta hejmo aperas. Avantaĝoj: kongruo sub ununura centro, kiu provizas plibonigitajn administradkapablojn. Kontraŭoj: se la servilo malsukcesas, la tuta sistemo revenas al etapo 1, t.e. iĝas fragmenta aŭ iĝas senutila.
Kategorio 3 - la plej malmola opcio. En la ripara stadio, ĉiuj komunikadoj estas metitaj kaj ĉiuj sistemoj estas duobligitaj. Avantaĝoj: ĉio estas perfektigita kaj tiam la domo fariĝas vere inteligenta. Malavantaĝoj: ege multekosta kompare kun kategorioj 1 kaj 2, neceso pripensi ĉion anticipe kaj konsideri ĉiun detalon.
Plej multaj uzantoj elektas opcion unu kaj tiam glate transiras al opcio du. Kaj tiam la plej persistaj atingas la opcion 3.
Sed ekzistas opcio, kiu povas esti nomata distribuita sistemo: ĉiu individua aparato estos kaj servilo kaj kliento. Esence, ĉi tio estas provo preni kaj kombini opcion 1 kaj opcion 2. Prenu ĉiujn iliajn avantaĝojn kaj elimini la malavantaĝojn, por kapti la oran mezumon.
Eble iu diros, ke tia opcio jam estis evoluigita. Sed tiaj decidoj estas mallarĝe fokusitaj; por homoj lertaj pri programado. Nia celo estas malaltigi la baron al eniro en tiaj distribuitaj sistemoj, kaj en la formo de finaj aparatoj kaj en la formo de integri ekzistantajn aparatojn en nian sistemon. En la kazo de termostato, la uzanto simple forigas sian malnovan termostaton, instalas inteligentan kaj ligas al ĝi siajn ekzistantajn sensilojn. Sen aldonaj paŝoj.
Ni rigardu integriĝon en nia sistemo uzante ekzemplon.
Ni imagu, ke ni havas 8 Sonoff-modulojn en nia reto. Por iuj uzantoj, kontrolo per la Sonoff-nubo (kategorio 1) estos sufiĉa. Iuj komencos uzi triapartan firmvaron kaj glate translokiĝos al kategorio 2. La plej granda parto de triaparta firmvaro funkcias laŭ la sama principo: transdoni datumojn al MQTT-servilo. OpenHub, Majordomo aŭ iu ajn alia servas unu celon - kunigi disajn aparatojn en ununuran informspacon situantan aŭ en la Interreto aŭ en loka reto. Tial, la ĉeesto de Servilo estas deviga. Ĉi tie aperas la ĉefa problemo - se la Servilo malsukcesas, la tuta sistemo ĉesas funkcii aŭtonome. Por malhelpi tion, sistemoj iĝas pli kompleksaj, manaj kontrolmetodoj estas aldonitaj kiuj duobligas aŭtomatigon en la okazaĵo de Servila fiasko.
Ni prenis malsaman vojon, kie ĉiu aparato estas memsufiĉa. Tiel, la Servilo ne ludas decidan rolon, sed nur vastigas la funkciojn.
Ni revenu al la pensa eksperimento. Ni prenu denove la samajn 8 Sonoff-modulojn kaj instalu Lytko-firmware en ili. Ĉiuj Lytko-firmvaro havas la funkcion . SSDP estas retprotokolo bazita sur la Interreta protokolo-serio por reklamado kaj malkovro de retservoj. La respondo al peto povas esti aŭ norma aŭ etendita. Krom normaj funkcioj, ni inkluzivis en ĉi tiu respondo la kreadon de listo de aparatoj en la reto. Tiel, la aparatoj mem trovas unu la alian, kaj ĉiu el ili havos tian liston. Ekzempla SSDP-folio:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Kiel vi povas vidi de la ekzemplo, la listo inkluzivas aparatajn identigilojn, IP-adreson en la reto, unuospecon (en nia kazo, Sonoff-bazita termostato). Ĉi tiu listo estas ĝisdatigita unufoje ĉiujn du minutojn (ĉi tiu periodo sufiĉas por respondi al dinamikaj ŝanĝoj en la nombro da aparatoj en la reto). Tiel ni spuras aparatojn aldonitajn, ŝanĝitajn kaj malŝaltitajn sen iu ajn ago de uzanto. Ĉi tiu listo estas sendita al la retumilo aŭ poŝtelefona aplikaĵo, kaj la skripto mem generas paĝon kun difinita nombro da blokoj. Ĉiu bloko respondas al unu aparato/sensilo/regilo. Vide la listo aspektas jene:
Sed kio se aliaj radiosensiloj estas konektitaj al la esp8266/esp32 per cc2530 (ZigBee) aŭ nrf24 (MySensors)?
Pri projektoj
Estas diversaj distribuitaj sistemoj sur la merkato. Nia sistemo permesas vin integriĝi kun la plej popularaj.
Malsupre estas projektoj, kiuj unu maniero aŭ alia provas ŝanĝi la situacion kun la nekongrueco de malsamaj fabrikantoj inter si. Ĉi tio estas, ekzemple, , aŭ . estas ligita al MQTT-servilo, do ĝi ne taŭgas por la ekzemplo.
Unu opcio por efektivigi MySensors estas enirejo bazita sur la ESP8266. La ceteraj ekzemploj estas sur ESP32. Kaj en ili vi povas efektivigi nian funkcian principon de detektado kaj kreado de listo de aparatoj.
Ni faru alian pensan eksperimenton. Ni havas ZESP32-enirejon aŭ SLS-enirejon, aŭ MySensors. Kiel ili povas esti kombinitaj en ununura informspaco? Ni aldonos la protokolbibliotekon SSDP al la normaj funkcioj de ĉi tiuj enirejoj. Alirante ĉi tiun regilon per SSDP, ĝi aldonos liston de aparatoj konektitaj al ĝi al la norma respondo. Surbaze de ĉi tiu informo, la retumilo generos paĝon. Ĝenerale ĝi aspektos jene:
Reta interfaco
PWA-apliko
"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"
}
La ekzemplo montras, ke aparatoj estas aldonitaj sendepende unu de la alia. 3 termostatoj kun siaj propraj IP-adresoj kaj 5 malsamaj sensiloj kun unikaj identigiloj estas konektitaj. Se la sensilo estas konektita al reto Wi-Fi, ĝi havos sian propran IP; se ĝi estas konektita al enirejo, tiam la IP-adreso de la aparato estos la IP-adreso de la enirejo.
Ni uzas WebSocket por komuniki kun aparatoj. Ĉi tio ebligas al vi minimumigi rimedkostojn kompare kun ricevi petojn kaj akiri informojn dinamike dum konekto aŭ ŝanĝado.
La datumoj estas prenitaj rekte de la aparato al kiu la bloko apartenas, preterirante la servilon. Tiel, se iu el la aparatoj malsukcesas, la sistemo daŭre funkcias. La retinterfaco simple ne montras la mankantan aparaton el la listo. Sed signalo pri la perdo, se necese, venos en formo de sciigo en la aplikaĵo de la uzanto.
La unua provo efektivigi ĉi tiun aliron estis PWA-aplikaĵo. Ĉi tio permesas vin konservi blokan bazon sur la aparato de la uzanto kaj peti nur la necesajn datumojn. Sed pro la proprecoj de la strukturo, ĉi tiu opcio estas nekompleta. Kaj ekzistas nur unu elirejo - denaska aplikaĵo por Android kaj IOS, kiu nuntempe estas aktiva disvolviĝo. Defaŭlte, la aplikaĵo funkcios nur en la interna reto. Se necese, vi povas transdoni ĉion al ekstera kontrolo. Do, kiam la uzanto forlasas la lokan reton, la aplikaĵo aŭtomate ŝanĝas al la nubo.
Ekstera kontrolo - kompleta duobligo de la paĝo. Kiam la paĝo estas aktivigita, la uzanto povas ensaluti al la servilo kaj administri aparatojn per sia persona konto. Tiel, la Servilo pligrandigas sian funkciecon, ebligante al vi administri aparatojn ekster la hejmo, kaj ne esti ligita al haveno plusendado aŭ dediĉita IP.
Tiel, la supra opcio ne havas la malavantaĝojn de la servila aliro, kaj ankaŭ havas kelkajn avantaĝojn en formo de fleksebleco en konekti novajn aparatojn.
Pri la termostato
Ni rigardu la kontrolsistemon uzante nian termostaton kiel ekzemplon.
Provizite:
- Kontrolo de temperaturo por ĉiu termostato (montrita kiel aparta bloko);
- Agordi la horaron de funkciado de termostato (matene, posttagmeze, vespere, nokte);
- Elektante Wi-Fi-reton kaj konekti aparaton al ĝi;
- Ĝisdatigi la aparaton "super la aero";
- Agordi MQTT;
- Agordu la reton al kiu la aparato estas konektita.
Krom kontrolo per la retinterfaco, ni disponigis la klasikan - per klako sur la ekrano. Estas Nextion NX3224T024 2.4-cola monitoro surŝipe. La elekto falis sur lin pro la facileco labori kun la aparato. Sed ni disvolvas nian propran monitoron bazitan sur STM32. Ĝia funkcieco ne estas pli malbona ol tiu de Nextion, sed ĝi kostos malpli, kio havos pozitivan efikon sur la fina prezo de la aparato.
Kiel iu ajn memrespekta termostata ekrano, nia Nextion povas:
- agordu la temperaturon postulitan de la uzanto (uzante la butonojn dekstre);
- ŝalti kaj malŝalti la planitan operacian reĝimon (butono H);
- montra relajso operacio (sago maldekstre);
- havas infanan protekton (fizikaj klakoj estas blokitaj ĝis la seruro estas forigita);
- montras WiFi-signalforton.
Krome, uzante la monitoron vi povas:
- elektu la tipon de sensilo instalita de la uzanto;
- administri la infanŝlosilon;
- ĝisdatigi la firmware.
Alklakante la WiFi-stangon, la uzanto trovos informojn pri la konektita reto. La QR-kodo estas uzata por parigi la aparaton en la HomeKit-firmvaro.
Demo pri laborado kun la ekrano:
Ni evoluis kun tri konektitaj termostatoj.
Vi povas demandi: "Kio estas speciala pri via termostato?" Nun sur la merkato estas multaj termostatoj kun Wi-Fi-funkcio, planita funkciado kaj tuŝa kontrolo. Kaj entuziasmuloj skribis modulojn por interagi kun plej popularaj inteligentaj hejmaj sistemoj (Majordomo, HomeAssistant, ktp.).
Nia termostato kongruas kun tiaj sistemoj kaj havas ĉion supre. Sed la karakterizaĵo estas, ke la termostato konstante plibonigas, danke al la fleksebleco de la sistemo. Kun ĉiu ĝisdatigo la funkcio pligrandiĝos. Al la norma metodo de sistema administrado (laŭ horaro), ni aldonos adaptan. La aplikaĵo permesas vin akiri la geolokigon de la uzanto. Danke al ĉi tio, la sistemo dinamike ŝanĝos operaciumojn depende de sia loko. Kaj la vetermodulo permesos al vi adaptiĝi al veterkondiĉoj.
Kaj vastebleco. Ĉiu povas anstataŭigi sian ekzistantan konvencian termostaton per la nia. Kun minimuma peno. Ni elektis 5 el la plej popularaj sensiloj sur la merkato kaj aldonis subtenon por ili. Sed eĉ se la sensilo havas ekskluzivajn trajtojn, la uzanto povos konekti ĝin al nia termostato. Por fari tion, vi devos kalibri la termostaton por labori kun specifa sensilo. Ni provizos instrukciojn.
Konektante termostaton aŭ ajnan alian aparaton, ĝi samtempe aperas ĉie: kaj en la retinterfaco kaj en la aplikaĵo PWA. Aldono de aparato okazas aŭtomate: vi nur bezonas konekti ĝin al la reto Wi-Fi.
Nia sistemo ne bezonas Servilon, kaj se ĝi malsukcesas, ĝi ne fariĝas kukurbo. Eĉ se unu el la komponantoj malsukcesas, la sistemo ne komencas funkcii en kriz-scenaro. Regiloj, sensiloj, aparatoj - ĉiu elemento estas kaj Servilo kaj kliento, do tute aŭtonoma.
Por interesatoj, niaj sociaj retoj: , , , , .
Poŝtoficejo: [retpoŝte protektita]
PS Ni ne instigas vin forlasi la Servilon. Ni ankaŭ subtenas MQTT-servilon kaj havas nian propran nubon. Nia celo estas alporti la stabilecon kaj fidindecon de la sistemo al tute nova nivelo. Por ke la Servilo ne estas malforta punkto, sed kompletigas la funkciecon kaj igas la sistemon pli oportuna.
fonto: www.habr.com