Před časem jsme vám představili Tento článek byl původně zamýšlen jako demonstrace firmwaru a řídicího systému. Abychom však vysvětlili logiku fungování termostatu a to, co jsme implementovali, je nutné nastínit celý koncept.
O automatizaci
Veškerou automatizaci lze obvykle rozdělit do tří kategorií:
Kategorie 1 — jednotlivá chytrá zařízení. Žárovky, konvice atd. kupujete od různých výrobců. Výhody: každé zařízení rozšiřuje možnosti a zlepšuje pohodlí. Nevýhody: každý nový výrobce vyžaduje vlastní aplikaci. Protokoly zařízení od různých výrobců jsou často nekompatibilní.
Kategorie 2 — Instalace jednodeskového počítače nebo systému kompatibilního s x86. Tím se odstraní omezení výpočetního výkonu a na tento počítač lze nainstalovat MajorDoMo nebo jakoukoli jinou serverovou distribuci pro správu inteligentní domácnosti. Tímto způsobem jsou zařízení od většiny výrobců propojena v jednom informačním prostoru a vytvářejí tak dedikovaný server inteligentní domácnosti. Výhody: kompatibilita pod jedním řídicím centrem, což poskytuje rozšířené možnosti správy. Nevýhody: pokud server selže nebo selže, celý systém se vrátí do fáze 1, stane se nesouvislým nebo nepoužitelným.
Kategorie 3 — nejnáročnější varianta. Během fáze rekonstrukce se instalují všechny inženýrské sítě a zálohují všechny systémy. Klady: vše je dovedeno k dokonalosti a dům se pak stává skutečně chytrým. Zápory: extrémně drahé ve srovnání s kategoriemi 1 a 2, nutnost vše předem promyslet a zohlednit každý detail.
Většina uživatelů si vybere možnost jedna a poté postupně přejde k možnosti dvě. A ti nejvytrvalejší pak k možnosti tři.
Existuje však možnost, kterou by bylo možné nazvat distribuovaným systémem: každé jednotlivé zařízení by bylo zároveň serverem i klientem. V podstatě se jedná o pokus o zkombinování možností 1 a 2, využití všech jejich výhod a odstranění nevýhod, a nalezení zlaté střední cesty.
Někdo by mohl namítnout, že taková možnost již byla vyvinuta. Taková řešení jsou však vysoce specializovaná a určená pro lidi s programátorskými dovednostmi. Naším cílem je snížit bariéru vstupu do takových distribuovaných systémů, a to jak ve formě koncových bodů, tak integrací stávajících zařízení do našeho systému. V případě termostatu uživatel jednoduše odstraní svůj starý termostat, nainstaluje chytrý a připojí k němu stávající senzory. Nejsou vyžadovány žádné další kroky.
Podívejme se na integraci do našeho systému na příkladu.
Představme si, že v naší síti máme 8 modulů Sonoff. Některým uživatelům bude stačit ovládání přes cloud Sonoff (kategorie 1). Jiní budou používat firmware třetích stran a postupně přejdou do kategorie 2. Většina firmwaru třetích stran funguje na stejném principu: přenos dat na MQTT server. OpenHub, Majordomo nebo jakýkoli jiný server slouží stejnému účelu – sjednotit různorodá zařízení do jednoho informačního prostoru, umístěného buď na internetu, nebo v lokální síti. Proto je server nezbytný. To vede k hlavnímu problému: pokud server selže, celý systém přestane fungovat autonomně. Aby se tomu zabránilo, systémy se stávají složitějšími a přidávají se metody manuálního ovládání, které zálohují automatizovaný systém v případě selhání serveru.
Zvolili jsme jiný přístup, kde je každé zařízení soběstačné. Server tedy nehraje rozhodující roli, ale pouze rozšiřuje funkcionalitu.
Vraťme se k myšlenkovému experimentu. Vezměme si stejných osm modulů Sonoff a nainstalujme na ně firmware Lytko. Všechny verze firmwaru Lytko implementují funkci SSDP je síťový protokol založený na sadě internetových protokolů, který se používá k inzerování a vyhledávání síťových služeb. Odpověď na požadavek může být standardní nebo rozšířená. Kromě standardních funkcí jsme do této odpovědi zahrnuli i vytvoření seznamu zařízení v síti. Tímto způsobem se zařízení automaticky navzájem vyhledávají a každé z nich bude mít takový seznam. Příklad seznamu SSDP:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Jak je vidět z příkladu, seznam obsahuje ID zařízení, IP adresy sítě a typ jednotky (v našem případě termostat Sonoff). Tento seznam se aktualizuje každé dvě minuty (tento interval je dostatečný k reakci na dynamické změny počtu zařízení v síti). Tímto způsobem sledujeme přidávání, úpravy a mazání zařízení bez jakékoli interakce s uživatelem. Tento seznam se odešle do prohlížeče nebo mobilní aplikace a skript automaticky vygeneruje stránku se zadaným počtem jednotek. Každá jednotka 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 existuje řada distribuovaných systémů. Náš systém umožňuje integraci s těmi nejoblíbenějšími.
Níže jsou uvedeny projekty, které se tak či onak snaží zlepšit situaci s nekompatibilitou mezi různými výrobci. Například , nebo . Je vázán na MQTT server, takže pro tento příklad není vhodný.
Jednou z možností implementace MySensors je brána založená na ESP8266. Ostatní příklady jsou založeny na ESP32. Náš princip vyhledávání zařízení a generování seznamů lze v nich implementovat.
Proveďme další myšlenkový experiment. Řekněme, že máme bránu ZESP32, bránu SLS nebo bránu MySensors. Jak je můžeme integrovat do jednoho informačního prostoru? Přidejme ke standardním funkcím těchto bran knihovnu protokolu SSDP. Při přístupu k tomuto řídicímu systému přes SSDP se k standardní odpovědi připojí seznam zařízení, která jsou k němu připojena. Na základě těchto informací prohlížeč vygeneruje stránku. Obecně bude vypadat takto:
webové rozhraní
aplikace 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"
}
Příklad ukazuje, že zařízení jsou přidávána nezávisle. Jsou připojeny tři termostaty s vlastními IP adresami a pět různých senzorů s jedinečnými ID. Pokud je senzor připojen k síti Wi-Fi, bude mít svou vlastní IP adresu; pokud je připojen k bráně, bude IP adresa zařízení IP adresou brány.
Pro komunikaci se zařízeními používáme WebSockety. To minimalizuje využití zdrojů ve srovnání s požadavky GET a umožňuje nám dynamicky načítat informace při připojení nebo změně.
Data se načítají přímo ze zařízení, ke kterému blok patří, a obcházejí server. To znamená, že pokud jakékoli zařízení selže, systém pokračuje v provozu. Webové rozhraní jednoduše nezobrazuje chybějící zařízení. V případě potřeby však bude o chybějícím zařízení informováno oznámením v uživatelské aplikaci.
Prvním pokusem o implementaci tohoto přístupu byla PWA aplikace. Ta umožňuje ukládat databázi bloků na zařízení uživatele a vyžadovat pouze potřebná data. Vzhledem ke specifické struktuře aplikace je však tento přístup neúplný. Jediným řešením je nativní aplikace. Android a iOS, který je momentálně ve fázi aktivního vývoje. Ve výchozím nastavení bude aplikace běžet pouze v interní síti. V případě potřeby ji lze přepnout na externí správu. Takže když uživatel opustí lokální síť, aplikace se automaticky přepne do cloudu.
Externí správa je kompletní kopií stránky. Po aktivaci stránky se uživatel může přihlásit k serveru a spravovat zařízení prostřednictvím svého osobního účtu. Server tak rozšiřuje funkcionalitu a umožňuje spravovat zařízení i mimo domov, bez nutnosti přesměrování portů nebo vyhrazené IP adresy.
Výše popsaná možnost je tedy zbavena nevýhod serverového přístupu a má také řadu výhod v podobě flexibility při připojování nových zařízení.
O termostatu
Podívejme se na řídicí systém na příkladu našeho termostatu.
Pokud:
- Regulace teploty každého termostatu (zobrazena jako samostatný blok);
- Nastavení časového harmonogramu termostatu (ráno, den, večer, noc);
- Výběr sítě Wi-Fi a připojení zařízení k ní;
- Aktualizace zařízení bezdrátově;
- Nastavení MQTT;
- Nakonfigurujte síť, ke které je zařízení připojeno.
Kromě webového ovládání nabízí zařízení také tradiční dotykové rozhraní. Vestavěný monitor Nextion NX3224T024 má úhlopříčku 2.4 palce. Byl vybrán kvůli snadnému použití. V současné době se však vyvíjí vlastní monitor založený na STM32. Jeho funkčnost není o nic horší než u Nextionu, ale bude levnější, což pozitivně ovlivní konečnou cenu zařízení.
Stejně jako každá sebeúctyhodná termostatická obrazovka, i náš Nextion dokáže:
- nastavte teplotu požadovanou uživatelem (pomocí tlačítek vpravo);
- zapnutí a vypnutí plánovaného provozu (tlačítko H);
- zobrazit funkci relé (šipka vlevo);
- má dětskou pojistku (fyzické stisknutí je blokováno, dokud není zámek odstraněn);
- Zobrazuje sílu signálu WiFi.
Kromě toho můžete pomocí monitoru:
- vyberte typ senzoru instalovaného uživatelem;
- řídit funkci ochrany dětí;
- aktualizovat firmware.
Kliknutím na panel WiFi se zobrazí informace o připojené síti. QR kód se používá ke spárování zařízení s firmwarem HomeKit.
Zobrazit ukázku:
Vyvinuli jsme se třemi připojenými termostaty.
Možná se ptáte: „Co je na vašem termostatu tak zvláštního?“ Na trhu je nyní mnoho termostatů s Wi-Fi, možnostmi plánování a 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 nabízí všechny výše uvedené funkce. Jeho charakteristickým rysem však je, že se neustále vylepšuje díky flexibilitě systému. S každou aktualizací se funkcionalita rozšiřuje. Kromě standardního plánovaného ovládání systému přidáme adaptivní ovládání. Aplikace umožňuje sledovat geolokaci uživatele, což systému umožňuje dynamicky měnit provozní režimy na základě jeho polohy. A modul počasí vám umožní přizpůsobit se měnícím se povětrnostním podmínkám.
A rozšiřitelnost. Kdokoli může s minimálním úsilím vyměnit svůj stávající termostat za náš. Vybrali jsme pět nejoblíbenějších senzorů na trhu a přidali pro ně podporu. I když má senzor jedinečné funkce, uživatelé ho stále mohou připojit k našemu termostatu. K tomu budou muset termostat kalibrovat tak, aby s daným senzorem fungoval. Poskytneme vám pokyny.
Když připojíte termostat nebo jakékoli jiné zařízení, zobrazí se všude: ve webovém rozhraní i v aplikaci PWA. Přidání zařízení je automatické: stačí ho připojit k síti Wi-Fi.
Náš systém nevyžaduje server a pokud jeden selže, nezmění se v dýni. I když selže jedna komponenta, systém se nedostane do stavu havárie. Řídicí jednotky, senzory, zařízení – každý prvek je zároveň serverem i klientem, takže je zcela autonomní.
Pro zájemce, zde jsou naše účty na sociálních sítích: , , , , .
E-mail: shop@lytko.com
PS Neobhajňujeme opuštění Serveru. Podporujeme také MQTT server a máme vlastní cloud. Naším cílem je posunout stabilitu a spolehlivost systému na zcela novou úroveň. Chceme, aby Server byl doplňkovou funkcí a zlepšoval použitelnost systému, spíše než úzkým hrdlem.
Zdroj: www.habr.com
