Nemrég bemutattuk Önnek . A jelen cikk eredetileg a firmware és a vezérlőrendszer bemutatásának szántuk. Azonban ahhoz, hogy megértsük a termosztát működésének logikáját és azt, amit megvalósítottunk, szükséges, hogy az egész koncepciót átfogóan vázoljuk fel.
Az automatizálásról
Feltételesen az automatizálást három kategóriára lehet bontani:
1. kategória — különálló „okos” eszközök. Különböző gyártóktól vásárol lámpákat, vízforralókat stb. Előnyök: minden eszköz bővíti a lehetőségeket és növeli a kényelmet. Hátrányok: minden új gyártóhoz saját alkalmazás szükséges. A különböző gyártók eszközeinek protokolljai gyakran nem kompatibilisek egymással.
2. kategória — egy egylapkás PC vagy x86 kompatibilis telepítése. Ez megszünteti a számítási kapacitás korlátait, és erre a gépre telepítik a MajorDoMo-t vagy bármely más szerver disztribúciót az okos otthon irányítására. Így a legtöbb gyártó eszköze egyesül egy közös információs térben. Tehát létrejön egy saját server az okos otthonhoz. Előnyök: a kompatibilitás egy központ alatt, amely kibővített irányítási lehetőségeket biztosít. Hátrányok: ha a szerver meghibásodik, az egész rendszer visszatér az 1. szakaszba, vagyis szétszórttá válik, vagy haszontalanná válik.
3. kategória — a legextrémebb lehetőség. A felújítás során minden kommunikációt lefektetnek, és minden rendszert megdupláznak. Előnyök: minden tökéletesre van hangolva, és a ház valóban okossá válik. Hátrányok: rendkívül magas költségek az 1. és 2. kategóriához képest, szükségessé teszi minden előre átgondolását és minden apróság figyelembevételét.
A legtöbb felhasználó az első lehetőséget választja, majd fokozatosan átmegy a második lehetőségbe. A legkitartóbbak pedig eljutnak a harmadik lehetőséghez.
De létezik egy lehetőség, amelyet elosztott rendszernek nevezhetünk: minden különálló eszköz egyszerre lesz szerver és kliens. Lényegében ez a próbálkozás az 1. és 2. lehetőség összevonására. Meg lehet szerezni az összes előnyüket és kizárni a hátrányokat, megtalálni az arany középutat.
Lehet, hogy valaki azt mondja, hogy egy ilyen megoldás már létezik. De az ilyen megoldások — szűk célúak; programozásban jártas embereknek. Célunk, hogy csökkentsük a belépési küszöböt az ilyen elosztott rendszerekbe, mind a végberendezések, mind a meglévő eszközök integrálásával a rendszerünkbe. A termosztát esetében a felhasználónak egyszerűen el kell távolítania a régi termosztátját, telepítenie kell az okos termosztátot, és csatlakoztatnia kell hozzá a meglévő érzékelőit. Mindenféle kiegészítő művelet nélkül.
Nézzük meg az integrációt a rendszerünkbe egy példa segítségével.
Tegyük fel, hogy van 8 Sonoff modulunk a hálózatban. Néhány felhasználónak elegendő a Sonoff felhőn keresztüli vezérlés (1. kategória). Néhányan külső firmware-t fognak használni, és fokozatosan átkerülnek a 2. kategóriába. A legtöbb külső firmware azonos elven működik: adatokat küld egy MQTT-szerverre. Az OpenHub, Majordomo vagy bármely más célja az, hogy egyesítse a szétszórt eszközöket egy egységes információs térbe, amely az Interneten vagy a helyi hálózaton található. Ezért a szerver megléte kötelező. Ebből ered a fő probléma — ha a szerver leáll, az egész rendszer nem működik autonóm módon. Ennek megakadályozására a rendszerek bonyolultabbá válnak, kézi vezérlési lehetőségeket adnak hozzá, amelyek megduplázzák az automatikát a szerver leállásának esetére.
Mi más utat választottunk, ahol minden eszköz önállóan működik. Így a szerver nem játszik döntő szerepet, csupán a funkcionalitást bővíti.
Térjünk vissza a gondolatkísérlethez. Ismét vegyük a fent említett 8 Sonoff modult, és telepítsünk rájuk Lytko firmware-t. A Lytko firmware-ek mindegyikében megvalósult a funkció . Az SSDP egy hálózati protokoll, amely az Internet protokolljaira épül, és a hálózati szolgáltatások bejelentésére és felfedezésére szolgál. A lekérdezésre adott válasz lehet standard vagy kiterjesztett. Ebbe a válaszba a standard funkciók mellett beépítettük a hálózatban lévő eszközök listájának létrehozását is. Így az eszközök maguk találják meg egymást, és mindegyiküknek lesz egy ilyen listája. Például az SSDP lista:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Ahogyan a példából látható, a lista tartalmazza az eszközök azonosítóit, a hálózati IP-címet, a blokk típusát (jelen esetben Sonoff alapú termosztát). Ez a lista két percenként frissül (ez az időintervallum elegendő a hálózaton lévő eszközök dinamikus változásaira való reagáláshoz). Így nyomon követjük az eszközök hozzáadását, módosítását és lekapcsolását felhasználói beavatkozás nélkül. Ez a lista a böngészőbe vagy mobilalkalmazásba kerül, és a szkript automatikusan létrehozza az oldalt a megadott számú blokk alapján. Minden blokk egy-egy eszközhöz/szenzorhoz/kontrollerhez tartozik. Vizualizálva a lista így néz ki:
De mi van, ha az esp8266/esp32-hez más rádiószenzorok csatlakoznak cc2530 (ZigBee) vagy nrf24 (MySensors) révén?
A projektekről
A piacon különböző elosztott rendszerek találhatók. A rendszerünk lehetőséget nyújt a legnépszerűbbekkel való integrációra.
Az alábbiakban bemutatott projektek próbálnak változtatni a különböző gyártók közötti inkompatibilitás helyzetén. Például: , vagy . MQTT-szerverre van kötve, így nem megfelelő példa.
A MySensors megvalósításának egyik lehetősége az ESP8266 alapú átjáró. A többi példa az ESP32-re épül. Ezekben a példákban alkalmazni lehet a mi működési elvünket az eszközök felfedezésére és listájának létrehozására.
Végezzünk el még egy gondolatkísérletet. Van egy ZESP32 vagy SLS Gateway, illetve MySensors átjárónk. Hogyan lehet őket egy közös információs térbe integrálni? Az ilyen átjárókhoz standard funkciókhoz hozzáadjuk az SSDP protokoll könyvtárát. Amikor erre a vezérlőre SSDP-n keresztül hivatkozunk, a standard válaszhoz hozzáadja az eszközök listáját, amelyek csatlakoznak hozzá. Ezen információk alapján a böngésző létrehozza az oldalt. Általánosan ez így néz ki:
Webes felület
PWA-alkalmazás
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"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 alapján látható, hogy az eszközök egymástól függetlenül kerülnek hozzáadásra. 3 termosztát van csatlakoztatva saját ip-címmel, és 5 különböző érzékelő egyedi id-vel. Ha az érzékelő Wi-Fi hálózatra csatlakozik, akkor lesz egy ip-címe, ha pedig átjáróra csatlakozik, akkor az eszköz ip-címe az átjáró ip-címe lesz.
Az eszközökkel való kommunikációhoz WebSocketet alkalmazunk. Ez lehetővé teszi az erőforrások minimalizálását a GET kérésekhez képest, és dinamikusan kapunk információt a csatlakozás vagy változás során.
Az adatok közvetlenül az eszköztől származnak, amelyhez a blokk tartozik, megkerülve a szervert. Így bármelyik eszköz meghibásodása esetén a rendszer továbbra is működik. A webes interfészen csak a eltűnt eszköz nem jelenik meg a listában. De a kiesésről, ha szükséges, értesítés érkezik a felhasználó alkalmazásába.
A megközelítés első kísérlete a PWA alkalmazás volt. Ez lehetővé teszi a blokkok adatainak tárolását a felhasználó eszközén, és csak a szükséges adatok lekérdezését. De a struktúra sajátosságai miatt ez a változat hiányos. Az egyetlen megoldás a natív alkalmazások fejlesztése Android és iOS rendszerre, amely jelenleg aktív fejlesztés alatt áll. Alapértelmezés szerint az alkalmazás csak a belső hálózaton fog működni. Szükség esetén minden átvihető külső irányításra. Így, amikor a felhasználó elhagyja a helyi hálózatot, az alkalmazás automatikusan átáll a felhőre.
A külső irányítás — a teljes oldal másolása. Az oldal aktiválásakor a felhasználó bejelentkezhet a szerverre és kezelheti az eszközöket a személyes fiókján keresztül. Így a szerver kibővíti a funkcionalitást, lehetővé téve az eszközök irányítását a házon kívül, és nem teszi lehetővé a portforwarding vagy dedikált ip használatát.
Így a fent leírt megoldás mentes a szerveres megközelítés hátrányaitól, és számos előnnyel jár, mint az új eszközök csatlakoztatásának rugalmassága.
A termosztátról
Vizsgáljuk meg a vezérlőrendszert a termosztátunk példáján.
Elő van írva:
- Minden termosztát hőmérsékletének szabályozása (külön blokk formájában jelenik meg);
- A termosztát munkarendjének beállítása (reggel, dél, este, éjszaka);
- A Wi-Fi hálózat kiválasztása és az eszköz csatlakoztatása;
- A készülék frissítése "légi úton";
- MQTT beállítása;
- A hálózat beállítása, amelyhez az eszköz csatlakozik.
A webes felületen való irányításon kívül hagyományos vezérlést is biztosítottunk, érintéssel a kijelzőn. A fedélzeten egy Nextion NX3224T024 2,4 hüvelykes monitor található. Ezt a választást a készülék egyszerű használata miatt tettük. De fejlesztés alatt áll egy saját monitor STM32 alapokon. Funkcionalitása nem rosszabb, mint a Nextioné, de olcsóbb lesz, ami kedvezően hat az eszköz végső árára.
Mint minden önmagát tisztelő termosztát képernyő, a mi Nextionunk is tudja:
- beállítani a szükséges felhasználói hőmérsékletet (jobb oldali gombokkal);
- bekapcsolni és kikapcsolni a program szerint működő módot (N gomb);
- megmutatni a relé működését (bal oldali nyíl);
- gyermeki védelemmel rendelkezik (a fizikai nyomásokat blokkolják, amíg a zár le nem van téve);
- megjeleníti a WiFi jelerősségét.
Ezenkívül a monitor segítségével lehet:
- választhatja a felhasználónál telepített érzékelőtípust;
- kezelni a gyermekvédelmi funkciót;
- frissíteni a firmware-t.
A WiFi sávjára kattintva a felhasználó tájékoztatást kap a csatlakoztatott hálózatról. A QR kódot a HomeKit firmware-jében az eszköz párosításához használják.
Demó a kijelzővel való munkához:
Kifejlesztettük három csatlakoztatott termosztáttal.
Megkérdezheti: „Mi az Ön termosztátjának különlegessége?” Jelenleg sok termosztát érhető el a piacon Wi-Fi funkcióval, program szerinti működéssel, érintéses vezérléssel. Emellett a lelkes fejlesztők moduleseket írtak a legnépszerűbb okosotthon rendszerekkel való interakcióra (Majordomo, HomeAssistant stb.).
A mi termosztátunk kompatibilis ezekkel a rendszerekkel, és minden fent említettel rendelkezik. De a megkülönböztető jellemzője az, hogy a termosztát folyamatosan fejlődik a rendszer rugalmasságának köszönhetően. Minden frissítéssel a funkcionalitás bővülni fog. A rendszer hagyományos vezérléséhez (program szerint) hozzáadunk egy adaptív vezérlést. Az alkalmazás lehetővé teszi a felhasználó helymeghatározását. Ennek köszönhetően a rendszer dinamikusan változtatja majd a működési módjait a felhasználó tartózkodási helye alapján. Az időjárás modul lehetővé teszi, hogy alkalmazkodjon az időjárási körülményekhez.
És a skálázhatóság. Bárki, aki akarja, egyszerű erőfeszítéssel kicserélheti a telepített hagyományos termosztátját a miénkre. Kiválasztottuk a piacon elérhető legnépszerűbb 5 érzékelőt, és hozzáadtuk a támogatásukat. De még az érzékelő exkluzív jellemzői esetén is a felhasználó csatlakoztathatja azt a termosztátunkhoz. Ehhez kalibrálnia kell a termosztátot, hogy az a konkrét érzékelővel működjön. Az utasításokat mi biztosítjuk.
A termosztát vagy bármely más eszköz csatlakoztatásakor az automatikusan megjelenik mindenhol: a webes felületen és a PWA-alkalmazásban is. Az eszköz hozzáadása automatikusan történik: csak annyit kell tennie, hogy csatlakoztatja a Wi-Fi hálózathoz.
Rendszerünknek nincs szüksége szerverre, és a szerver meghibásodásakor nem alakul át tök-kké. Még ha az egyik komponens meghibásodik, a rendszer nem kezd el vészüzemmódban működni. A vezérlők, érzékelők, eszközök — minden elem egyszerre szerver és kliens, ezért teljesen önálló.
Az érdeklődőknek — közösségi médiáink: , , , , .
Email: shop@lytko.com
P. S. nem kérjük, hogy mondjon le a szerverről. MQTT-szerver támogatással és saját felhőszolgáltatásunkkal is rendelkezünk. Célunk a rendszer stabilitásának és megbízhatóságának új szintre emelése. Ezért a szerver nem jelent gyenge pontot, hanem kiegészíti a funkcionalitást és könnyebbé teszi a rendszert.
Forrás: habr.com
