Nějakou dobu zpátky jsme vám představili . Tento článek byl původně navržen jako ukázka jeho firmwaru a systému řízení. Ale abychom vysvětlili logiku fungování termostatu a to, co jsme implementovali, je nutné nastínit celou koncepci jako celek.
O automatizaci
Automatizaci lze podmíněně rozdělit do tří kategorií:
Kategorie 1 — jednotlivá "inteligentní" zařízení. Kupujete od různých výrobců žárovky, varné konvice atd. Plusy: každé zařízení rozšiřuje možnosti a zvyšuje pohodlí. Minusy: pro každého nového výrobce je nutná vlastní aplikace. Protokoly zařízení různých výrobců nejsou často vzájemně kompatibilní.
Kategorie 2 — instalace jednodeskového PC nebo x86 kompatibilního zařízení. To odstraňuje omezení výpočetního výkonu, a na tomto stroji je nainstalován MajorDoMo nebo jakýkoli jiný serverový distribuce pro řízení chytré domácnosti. Takto jsou zařízení většiny výrobců spojena v jednom informačním prostoru. Tedy vzniká vlastní server pro chytrou domácnost. Plusy: kompatibilita pod jednotným centrem, která nabízí rozšířené možnosti pro řízení. Minusy: při poruše serveru se celý systém vrací do stádia 1, tj. stává se nesourodým nebo zbytečným.
Kategorie 3 — nejextrémnější varianta. V rámci opravy se zakládají všechny komunikace a duplikují se všechny systémy. Plusy: vše je dotáhnuto k dokonalosti a poté se dům stává skutečně inteligentním. Minusy: extrémní cena ve srovnání s kategoriemi 1 a 2, nutnost promýšlení všeho dopředu a zohlednění každého detailu.
Většina uživatelů si vybírá variantu jedna a poté postupně přechází na variantu dvě. A nakonec se ti nejodolnější dostanou až k variantě 3.
Existuje však varianta, kterou lze nazvat distribuovaným systémem: každé jednotlivé zařízení bude jak serverem, tak klientem. V podstatě je to pokus vzít a spojit variantu 1 a variantu 2. Vzít všechny jejich výhody a vyloučit nevýhody, najít zlatou střední cestu.
Možná někdo řekne, že takové řešení už bylo vyvinuto. Ale tato řešení jsou úzce specializovaná; pro lidi znalé programování. Naším cílem je snížit vstupní bariéru do podobných distribuovaných systémů, a to jak ve formě koncových zařízení, tak ve formě integrace stávajících zařízení do našeho systému. Pokud jde o termostat, uživatel jednoduše odstraní svůj starý termostat, nainstalují chytrý a připojí k němu dostupné senzory. Bez jakýchkoli dalších akcí.
Zvažme integraci do našeho systému na příkladu.
Představme si, že máme v síti 8 modulů Sonoff. Některým uživatelům bude stačit ovládání přes cloud Sonoff (kategorie 1). Někteří začnou používat alternativní firmware a plynule přešli do kategorie 2. Většina alternativních firmware funguje na stejném principu: přenos dat na MQTT server. OpenHub, Majordomo nebo jakýkoli jiný slouží jednomu cíli – sjednotit roztříštěná zařízení do jedného informačního prostoru, umístěného buď na internetu, nebo v místní síti. Tudíž je přítomnost serveru nezbytná. Odtud vyvstává hlavní problém – pokud server selže, celý systém přestává fungovat autonomně. Aby se tomu předešlo, systémy se složitější, přidávají se manuální ovládací prvky, které duplikují automatizaci v případě selhání serveru.
My jsme se ale vydali jinou cestou, kde každé zařízení je soběstačné. Tím pádem server nehraje rozhodující roli, ale pouze rozšiřuje funkčnost.
Vraťme se k myšlenkovému experimentu. Znovu vezmeme stejných 8 modulů Sonoff a nainstalujeme do nich firmware Lytko. Ve všech firmware Lytko je implementována funkce . SSDP je síťový protokol založený na sadě internetových protokolů, který slouží k oznamování a objevování síťových služeb. Odpověď na dotaz může být jak standardní, tak rozšířená. Do této odpovědi jsme kromě standardních funkcí zahrnuli i vytvoření seznamu zařízení v síti. Tím pádem zařízení se samy navzájem nacházejí a každé z nich bude mít takový seznam. Příklad SSDP seznamu:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Jak je patrné z příkladu, seznam zahrnuje id zařízení, ip adresu v síti a typ bloku (v našem případě – termostat na bázi Sonoff). Tento seznam se aktualizuje jednou za dvě minuty (tento interval je dostatečný pro reakci na dynamickou změnu počtu zařízení v síti). Takto sledujeme přidávání, změny a odpojení zařízení bez jakýchkoliv akcí ze strany uživatele. Tento seznam je odesílán do prohlížeče nebo mobilní aplikace, a skript automaticky vytváří stránku s daným počtem bloků. Každý blok odpovídá jednomu zařízení/senzoru/ovladači. Vizuálně seznam vypadá takto:
Ale co když jsou k esp8266/esp32 připojeny další rádiové senzory přes cc2530 (ZigBee) nebo nrf24 (MySensors)?
O projektech
Na trhu existují různé distribuované systémy. Náš systém umožňuje integraci s nejpopulárnějšími.
Níže uvedené projekty se tím či oním způsobem snaží změnit situaci s nekompatibilitou různých výrobců mezi sebou. To jsou například: , nebo . je vázán na MQTT serveru, takže se nehodí pro příklad.
Jednou z variant realizace MySensors je brána založená na ESP8266. Ostatní příklady jsou na ESP32. A do nich lze implementovat náš princip práce na objevování a vytváření seznamu zařízení.
Provedeme ještě jeden myšlenkový experiment. Máme bránu ZESP32 nebo SLS Gateway, nebo MySensors. Jak je můžeme spojit v jednom informačním prostoru? Ke standardním funkcím těchto bran přidáme knihovnu protokolu SSDP. Při dotazování na tento kontroler přes SSDP přidá k standardní odpovědi seznam zařízení, která k němu jsou připojena. Na základě těchto informací prohlížeč vytvoří stránku. V obecné podobě by to vypadalo takto:
Webové rozhraní
PWA aplikace
"ssdpList":
{
"id": 94967291, // unikátní identifikátor zařízení
"ip": "192.168.x.x", // ip adresa v síti
"type": "thermostat" // typ zařízení
},
{
"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"
}
Z příkladu je zřejmé, že zařízení se přidávají nezávisle na sobě. Jsou připojeny 3 termostaty s vlastními IP adresami a 5 různých senzorů s unikátními ID. Pokud je senzor připojen k Wi-Fi síti, bude mít svou IP, pokud je připojen k bráně, bude IP adresa zařízení IP adresou brány.
Pro komunikaci s zařízeními používáme WebSocket. To umožňuje minimalizovat využití zdrojů ve srovnání s GET dotazy a získávat informace dynamicky při připojení nebo změně.
Data se získávají přímo z toho zařízení, kterému blok náleží, bez obcházení serveru. Takto systém pokračuje v práci při selhání jakéhokoli ze zařízení. Na webovém rozhraní se pouze nezobrazí chybějící zařízení ze seznamu. Avšak signál o ztrátě, pokud je to nutné, přijde jako oznámení v aplikaci uživatele.
Prvním pokusem o implementaci tohoto přístupu byla PWA aplikace. To umožňuje ukládat databázi bloků na zařízení uživatele a požadovat pouze potřebná data. Vzhledem k vlastnostem struktury však nemá tato varianta plnou funkcionalitu. A jediné východisko je nativní aplikace pro Android a iOS, která je nyní v aktivním vývoji. Aplikace bude standardně fungovat pouze v místní síti. Pokud bude potřeba, lze vše převést na externí ovládání. Takže když uživatel opustí místní síť, aplikace se automaticky přepne na cloud.
Externí ovládání — plné duplikování stránky. Po aktivaci stránky se může uživatel přihlásit na server a spravovat zařízení prostřednictvím osobního účtu. Tak server rozšiřuje funkčnost, umožňuje spravovat zařízení, i když je uživatel mimo domov, a být nezávislý na výpustech portů nebo dedikované IP.
Takže výše popsaná varianta postrádá nevýhody serverového přístupu a má řadu výhod v podobě flexibility připojení nových zařízení.
O termostatu
Podívejme se na systém řízení na příkladu našeho termostatu.
Předpokládá se:
- Regulace teploty každého termostatu (zobrazuje se jako samostatný blok);
- Nastavení pracovního rozvrhu termostatu (ráno, den, večer, noc);
- Výběr Wi-Fi sítě a připojení zařízení k ní;
- Aktualizace zařízení „vzduchem“;
- Nastavení MQTT;
- Nastavení sítě, k níž je zařízení připojeno.
Kromě ovládání prostřednictvím webového rozhraní jsme zahrnuli i klasickou metodu — stiskem na displeji. Na palubě je monitor Nextion NX3224T024 o velikosti 2,4 palce. Volba padla na něj kvůli jednoduchosti práce se zařízením. Ve vývoji je však také náš vlastní monitor založený na STM32. Jeho funkce není o nic horší než u Nextion, ale bude stát méně, což se pozitivně odrazí na konečné ceně zařízení.
Stejně jako každý důstojný termostat má náš Nextion:
- nastavit požadovanou teplotu pro uživatele (tlačítky vpravo);
- zapínat a vypínat režim podle plánu (tlačítko N);
- zobrazovat činnost relé (šipka vlevo);
- má ochranu proti dětem (fyzická stisknutí jsou blokována, dokud není zámek odemčen);
- zobrazuje úroveň signálu WiFi.
Kromě toho pomocí monitoru lze:
- vybrat typ nainstalovaného senzoru;
- ovládat funkci ochrany proti dětem;
- aktualizovat firmware.
Kliknutím na ikonu WiFi se uživatel dozví informace o připojené síti. QR kód se používá pro párování zařízení ve firmwaru HomeKit.
Demo práce s displejem:
Vyvinuli jsme se třemi připojenými termostaty.
Ptáte se: “Jaká je zvláštnost vašeho termostatu?” Na trhu dnes existuje mnoho termostatů s funkcí Wi-Fi, plánováním, dotykovým ovládáním. A nadšenci napsali moduly pro interakci s většinou populárních systémů chytré domácnosti (Majordomo, HomeAssistant atd.).
Náš termostat je kompatibilní s těmito systémy a disponuje všemi výše uvedenými funkcemi. Ale jedinečnost spočívá v tom, že termostat je neustále zdokonalován, díky flexibilitě systému. S každou aktualizací se funkčnost rozšíří. K standardnímu způsobu ovládání systému (podle plánu) přidáme adaptivní. Aplikace umožňuje získávat geolokaci uživatele. Díky tomu se systém dynamicky přizpůsobí režimům provozu na základě jeho umístění. A modul počasí umožní přizpůsobit se povětrnostním podmínkám.
A rozšiřitelnost. Každý si může snadno vyměnit svůj standardní termostat za náš. S minimálním úsilím. Vybrali jsme 5 nejpopulárnějších senzorů dostupných na trhu a přidali jejich podporu. I v případě exkluzivních vlastností senzoru bude moci uživatel jej připojit k našemu termostatu. K tomu bude nutné provést kalibraci termostatu pro práci s konkrétním senzorem. Poskytneme instrukce.
Při připojení termostatu nebo jiného zařízení se automaticky zobrazuje všude: jak v webovém rozhraní, tak v PWA aplikaci. Přidání zařízení probíhá automaticky: stačí ho připojit k Wi-Fi síti.
Náš systém nepotřebuje server a v případě jeho výpadku se nepřevádí na dýni. I při selhání jedné z komponent systém nepřejde na havarijní scénář. Řídicí jednotky, senzory, zařízení – každý prvek je současně serverem i klientem, a tedy zcela autonomní.
Pro zájemce – naše sociální sítě: , , , , .
E-mail: shop@lytko.com
P. S. nevyzýváme k opuštění serveru. Máme také podporu MQTT serveru a vlastní cloud. Naším cílem je posunout stabilitu a spolehlivost systému na kvalitativně novou úroveň. Aby server nebyl slabým místem, ale doplňoval funkčnost a činil systém pohodlnější.
Zdroj: habr.com
