Nemrég bemutattuk önnek . Ez a cikk eredetileg a firmware és a vezérlőrendszer bemutatója volt. De ahhoz, hogy elmagyarázzuk a termosztát logikáját és azt, amit megvalósítottunk, fel kell vázolni a koncepció egészét.
Az automatizálásról
Hagyományosan az összes automatizálás három kategóriába sorolható:
1. kategória — külön „okos” eszközök. Különböző gyártóktól vásárol izzókat, teáskannákat stb. Előnyök: Minden eszköz bővíti a képességeket és növeli a kényelmet. Hátrányok: Minden új gyártónak saját alkalmazásra van szüksége. A különböző gyártóktól származó eszközök protokolljai gyakran nem kompatibilisek egymással.
2. kategória — egykártyás PC vagy x86-kompatibilis PC telepítése. Ez megszünteti a számítási teljesítményre vonatkozó korlátozásokat, és a MajorDoMo vagy bármely más, az intelligens otthonok kezelésére szolgáló szerver elosztás telepítve lesz erre a gépre. Így a legtöbb gyártó eszközei egyetlen információs térben kapcsolódnak össze. Azok. megjelenik a saját szervere egy intelligens otthonhoz. Előnyök: kompatibilitás egyetlen központ alatt, amely továbbfejlesztett felügyeleti képességeket biztosít. Hátrányok: ha a szerver meghibásodik, az egész rendszer visszatér az 1. szakaszba, azaz. töredezetté válik vagy használhatatlanná válik.
3. kategória - a legkeményebb lehetőség. A javítási szakaszban minden kommunikáció megtörténik, és minden rendszer megkettőződik. Előnyök: mindent tökéletesre hoznak, és akkor válik igazán okossá a ház. Hátrányok: rendkívül drága az 1-es és 2-es kategóriához képest, mindent előre át kell gondolni és minden apró részletet figyelembe kell venni.
A legtöbb felhasználó az első lehetőséget választja, majd simán áttér a második lehetőségre. És akkor a legkitartóbbak elérik a 3-as opciót.
De van egy lehetőség, amit elosztott rendszernek nevezhetünk: minden egyes eszköz egyben szerver és kliens is lesz. Lényegében ez egy kísérlet az 1. és a 2. lehetőség kombinálására. Vegye ki az összes előnyét, és szüntesse meg a hátrányokat, hogy elkapja az arany középutat.
Talán valaki azt mondja, hogy egy ilyen lehetőséget már kidolgoztak. De az ilyen döntések szűk fókuszúak; a programozásban jártas emberek számára. Célunk, hogy csökkentsük az ilyen elosztott rendszerekbe való belépés akadályát, mind végberendezések formájában, mind a meglévő eszközök rendszerünkbe való integrálása formájában. Termosztát esetén a felhasználó egyszerűen kiveszi a régi termosztátját, beszerel egy okost, és ráköti a meglévő érzékelőit. Minden további lépés nélkül.
Nézzük meg a rendszerünkbe való integrációt egy példa segítségével.
Képzeljük el, hogy 8 Sonoff modul van a hálózatunkon. Egyes felhasználók számára elegendő a Sonoff felhőn keresztüli vezérlés (1. kategória). Egyesek harmadik féltől származó firmware-t kezdenek használni, és simán átkerülnek a 2. kategóriába. A harmadik féltől származó firmware nagy része ugyanazon az elven működik: adatok átvitele egy MQTT szerverre. Az OpenHub, a Majordomo vagy bármely más egyetlen célt szolgál: a különböző eszközöket egyetlen információs térbe egyesíteni, amely akár az interneten, akár a helyi hálózaton található. Ezért a szerver jelenléte kötelező. Itt adódik a fő probléma – ha a szerver meghibásodik, az egész rendszer önállóan leáll. Ennek megelőzése érdekében a rendszerek bonyolultabbá válnak, kézi vezérlési módszereket adnak hozzá, amelyek megkettőzik az automatizálást szerverhiba esetén.
Más utat választottunk, ahol minden eszköz önellátó. Így a Szerver nem játszik meghatározó szerepet, csak bővíti a funkcionalitást.
Térjünk vissza a gondolatkísérlethez. Vegyük újra ugyanazt a 8 Sonoff modult, és telepítsük bele a Lytko firmware-t. Minden Lytko firmware rendelkezik ezzel a funkcióval . Az SSDP egy internetes protokollcsomagon alapuló hálózati protokoll a hálózati szolgáltatások hirdetésére és felfedezésére. A kérésre adott válasz lehet szabványos vagy kiterjesztett. Ebben a válaszban a szabványos funkciók mellett a hálózaton lévő eszközök listájának elkészítését is beépítettük. Így maguk az eszközök egymásra találnak, és mindegyiknek lesz ilyen listája. Példa SSDP lapra:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Amint a példából is látható, a listán megtalálhatók az eszközazonosítók, a hálózaton lévő IP-cím, az egység típusa (esetünkben egy Sonoff-alapú termosztát). Ez a lista kétpercenként frissül (ez az időtartam elegendő a hálózaton lévő eszközök számának dinamikus változásaira). Így követjük nyomon a hozzáadott, módosított és letiltott eszközöket felhasználói beavatkozás nélkül. Ez a lista elküldésre kerül a böngészőnek vagy mobilalkalmazásnak, és maga a szkript generál egy adott számú blokkot tartalmazó oldalt. Minden blokk egy eszköznek/érzékelőnek/vezérlőnek felel meg. Vizuálisan a lista így néz ki:
De mi van akkor, ha más rádiós érzékelők cc8266-on (ZigBee) vagy nrf32-en (MySensors) keresztül csatlakoznak az esp2530/esp24-hez?
A projektekről
Különféle elosztott rendszerek vannak a piacon. Rendszerünk lehetővé teszi, hogy integrálódjon a legnépszerűbbekkel.
Az alábbiakban olyan projekteket mutatunk be, amelyek így vagy úgy próbálnak változtatni a helyzeten a különböző gyártók egymással való összeférhetetlenségével. Ez pl. , vagy . MQTT szerverhez van kötve, így nem alkalmas a példához.
A MySensors megvalósításának egyik lehetősége az ESP8266-on alapuló átjáró. A többi példa az ESP32-n található. És bennük megvalósíthatja működési elvünket az eszközök észlelésére és listájának létrehozására.
Végezzünk még egy gondolatkísérletet. Van ZESP32 átjárónk vagy SLS átjárónk, vagy MySensorunk. Hogyan kombinálhatók egyetlen információs térben? Az SSDP protokollkönyvtárat hozzáadjuk ezen átjárók szabványos funkcióihoz. Ha SSDP-n keresztül éri el ezt a vezérlőt, a szabványos válaszhoz hozzáadja a hozzá csatlakoztatott eszközök listáját. Ezen információk alapján a böngésző létrehoz egy oldalt. Általában így fog kinézni:
Webes felület
PWA alkalmazás
"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"
}
A példa azt mutatja, hogy az eszközöket egymástól függetlenül adják hozzá. 3 saját IP-című termosztát és 5 különböző egyedi azonosítóval rendelkező érzékelő van csatlakoztatva. Ha az érzékelő Wi-Fi hálózathoz csatlakozik, akkor saját IP-címe lesz, ha pedig átjáróhoz csatlakozik, akkor az eszköz IP-címe lesz az átjáró IP-címe.
Az eszközökkel való kommunikációhoz a WebSocketet használjuk. Ez lehetővé teszi az erőforrásköltségek minimalizálását a kérések lekéréséhez és a dinamikus információszerzéshez képest a csatlakozás vagy a módosítás során.
Az adatokat közvetlenül arról az eszközről veszik, amelyhez a blokk tartozik, a szerver megkerülésével. Így ha valamelyik eszköz meghibásodik, a rendszer tovább működik. A webes felület egyszerűen nem jeleníti meg a hiányzó eszközt a listából. De ha szükséges, a veszteségről szóló jelzés értesítés formájában érkezik a felhasználó alkalmazásában.
Az első kísérlet ennek a megközelítésnek a megvalósítására egy PWA alkalmazás volt. Ez lehetővé teszi, hogy blokkbázist tároljon a felhasználó eszközén, és csak a szükséges adatokat kérje le. De a szerkezet sajátosságai miatt ez a lehetőség hiányos. És csak egy kiút van - egy natív alkalmazás Androidra és IOS-re, amely jelenleg aktív fejlesztés alatt áll. Alapértelmezés szerint az alkalmazás csak a belső hálózaton működik. Ha szükséges, mindent átvihet külső vezérlésre. Tehát amikor a felhasználó elhagyja a helyi hálózatot, az alkalmazás automatikusan átvált a felhőre.
Külső vezérlés - az oldal teljes másolása. Az oldal aktiválásakor a felhasználó személyes fiókján keresztül bejelentkezhet a szerverre és kezelheti az eszközöket. Így a Szerver kibővíti funkcionalitását, lehetővé téve, hogy otthonon kívül kezelje az eszközöket, és ne legyen port-továbbításhoz vagy dedikált IP-címhez kötve.
Így a fenti lehetőség nem rendelkezik a szerveres megközelítés hátrányaival, és számos előnnyel jár az új eszközök csatlakoztatásának rugalmassága formájában.
A termosztátról
Nézzük meg a vezérlőrendszert a termosztátunk példájával.
Biztosítani:
- Hőmérsékletszabályozás minden egyes termosztáthoz (külön blokkként jelenik meg);
- A termosztát működési ütemezésének beállítása (reggel, délután, este, éjszaka);
- Wi-Fi hálózat kiválasztása és eszköz csatlakoztatása hozzá;
- Az eszköz frissítése „éteren keresztül”;
- MQTT beállítása;
- Konfigurálja azt a hálózatot, amelyhez az eszköz csatlakozik.
A webes felületen keresztüli vezérlés mellett a klasszikust biztosítottuk - a kijelzőre kattintva. A fedélzeten egy Nextion NX3224T024 2.4 hüvelykes monitor található. A választás az eszközzel való könnyű munkavégzés miatt esett rá. De mi fejlesztjük saját monitorunkat STM32-re. Funkcionalitása nem rosszabb, mint a Nextioné, de olcsóbb lesz, ami pozitívan befolyásolja a készülék végső árát.
Mint minden önbecsülő termosztát képernyő, a Nextionunk is:
- állítsa be a felhasználó által igényelt hőmérsékletet (a jobb oldali gombok segítségével);
- az ütemezett üzemmód be- és kikapcsolása (H gomb);
- kijelző relé működése (nyíl a bal oldalon);
- gyermekvédelemmel rendelkezik (a fizikai kattanások a zár eltávolításáig blokkolva vannak);
- megjeleníti a WiFi jelerősséget.
Ezenkívül a monitor használatával:
- válassza ki a felhasználó által telepített érzékelő típusát;
- kezelje a gyermekzár funkciót;
- frissítse a firmware-t.
A WiFi sávra kattintva a felhasználó információkat kap a csatlakoztatott hálózatról. A QR-kód az eszköz párosítására szolgál a HomeKit firmware-ben.
Demo a kijelzővel való munkavégzésről:
Mi fejlődtünk három csatlakoztatott termosztáttal.
Felteheti a kérdést: „Mi a különleges a termosztátjában?” Most a piacon számos termosztát található Wi-Fi funkcióval, ütemezett működéssel és érintésvezérléssel. A rajongók pedig modulokat írtak a legnépszerűbb intelligens otthoni rendszerekkel való interakcióhoz (Majordomo, HomeAssistant stb.).
Termosztátunk kompatibilis az ilyen rendszerekkel, és a fentiek mindegyikével rendelkezik. A megkülönböztető jellemző azonban az, hogy a termosztátot a rendszer rugalmasságának köszönhetően folyamatosan fejlesztik. A funkciók minden frissítéssel bővülnek. A szokásos rendszerkezelési módszerhez (ütemezés szerint) egy adaptív módszert adunk. Az alkalmazás lehetővé teszi a felhasználó földrajzi helyének megszerzését. Ennek köszönhetően a rendszer dinamikusan változtatja az üzemmódot a helyétől függően. Az időjárási modul pedig lehetővé teszi az időjárási viszonyokhoz való alkalmazkodást.
És bővíthetőség. Bárki lecserélheti meglévő hagyományos termosztátját a miénkre. Minimális erőfeszítéssel. Kiválasztottunk az 5 legnépszerűbb érzékelőt a piacon, és hozzáadtuk a támogatásukat. De még ha az érzékelő exkluzív tulajdonságokkal is rendelkezik, a felhasználó csatlakoztathatja a termosztátunkhoz. Ehhez kalibrálnia kell a termosztátot, hogy egy adott érzékelővel működjön. Útmutatást adunk.
A termosztát vagy bármely más eszköz csatlakoztatásakor mindenhol egyszerre jelenik meg: a webes felületen és a PWA alkalmazásban egyaránt. Az eszköz hozzáadása automatikusan megtörténik: csak csatlakoznia kell a Wi-Fi hálózathoz.
A rendszerünknek nem kell Szerver, és ha meghibásodik, nem válik tökké. Még ha valamelyik összetevő meghibásodik, a rendszer nem kezd el működni vészhelyzet esetén. Vezérlők, érzékelők, eszközök – minden elem egyben szerver és kliens is, ezért teljesen autonóm.
Az érdeklődőknek közösségi oldalaink: , , , , .
Posta: [e-mail védett]
PS Nem javasoljuk, hogy elhagyja a szervert. Támogatjuk az MQTT szervert is, és saját felhőnk is van. Célunk, hogy a rendszer stabilitását és megbízhatóságát teljesen új szintre emeljük. Hogy a Szerver ne legyen gyenge pont, hanem kiegészítse a funkcionalitást és kényelmesebbé tegye a rendszert.
Forrás: will.com