Jasně, existuje spoustu hotových IoT frameworků pro ESP32 a ESP8266. Chytrých, v cloudu, nemusíte se o nic starat. Mohl jsem něco z nich použít. Ale řekl jsem si NE! A tady je výsledek.
Základní zadání je jednoduché: mám nějaké IoT čidlo a získaná data chci poslat na server. A tam dlouhodobě ukládat. A vizualizovat – vykreslit v grafech.
Mohu použít třeba Blynk, ten funguje moc hezky s mobilkami. Nebo tmep.cz. Iot Guru je taky dobrý. Možných řešení je spousta. Pokud si stavím něco na hraní na pár dní, cokoli z toho je dobré.
Jenže pokud vzniklá krabička poběží někde daleko, v cizí síti, bez možnosti přístupu, a plánuju její provoz s výhledem na roky, vnímám použití cloudové služby třetí strany jako problém. Jasně, pár dolarů ročně nemám problém zaplatit. Ale jak dlouho bude ta služba fungovat? Pamatujete třeba na Revolv / Nest Hub? Nepřijde provozovatel za pár měsíců s tím, že první verze API byla špatně a teď je vše potřeba předělat? Nebo že služby zahrnuté v základní ceně se stanou součástí Enterprise edice za cenu letu na nízkou oběžnou dráhu (na tebe se dívám, Oracle!)?
Data z různých senzorů ukládám už cca patnáct let let. Kolik dnešních poskytovatelů cloudových IoT služeb tu bude za pět či patnáct let?
Z jiného soudku je pak také to, že jsou informace, které nechcete publikovat volně do internetu:
Tím se nám požadavky na aplikaci postupně sumarizují:
- (1) Chci data ukládat do něčeho, co mám pod kontrolou. Nemusí to nutně běžet u mne na serveru; nemusím to ani provozovat já. Ale pokud to poběží v cloudu, musí tam být nástroj pro export všech dat a musí tam být možnost si danou serverovou aplikaci pustit u sebe, pokud by poskytovatel služby skončil. (To dříve šlo i u Blynk.io; jejich server byl volně k dispozici. Dnes stojí možnost odejít od Blynku $6000.)
- (2) Chci neomezenou retenci dat. Ne 10000 hodnot a 3 měsíce. Mám pár miliónů záznamů za 15 let.
- (3) Přístup k datům musí být řízený – některé grafy či jiné výstupy mohou být dostupné volně, u jiných chci jen autentizovaného uživatele.
Co dál ještě chci? No, spíš co nechci. Ukážu to na screenshotu z tutoriálu klientské aplikace pro IoT Guru cloud:
Jasně, tohle je standardní modus operandi. SSID a heslo k WiFi je zakompilované v aplikaci, stejně jako přístupové údaje k serverovému řešení. Takže když chci někde nasadit 10 krabiček, musím 10x aplikaci zkompilovat s jinými údaji. A až předělám WiFi, nebo krabičku přenesu jinam, musím aplikaci znovu překompilovat. Ne, to je kravina. Tedy:
- (4) Běhová konfigurace (SSID a heslo k WiFi, login a heslo k serverové platformě, případně další konfigurační parametry) se musí dát nastavit run-time, v poli, bez nutnosti rekompilace aplikace. A ideálně bez nutnosti ke krabičce připojovat nějaký kabel a počítač se speciální aplikací. Takže chci konfiguraci z telefonu, přes WiFi nebo Bluetooth – protože nic jiného v terénu nebude k dispozici.
- (5) Obecně je dobré, aby konfigurace šla následně změnit na dálku, ze serverové platformy. A to včetně adresy samotné serverové platformy, pokud budu chtít například přesunout krabičku na jiný server, k jinému poskytovateli.
Co dál? Co není zařazené do dohledového systému, to nemáte pod kontrolou. Takže?
- (6) Chci mít možnost být upozorněn, pokud z některé mé krabičky nechodí data tak, jak by měla. A také pokud má nějaký jiný běhový problém – například je potřeba vyměnit bezmála vybitou baterii.
Vlastně to nemohlo dopadnout jinak – znáte NIH syndrom? Z různých střípků a komponent, které jsem za uplynulé roky napsal, se mi tu postupně poskládalo vlastní řešení. Nakonec se ukázalo, že stačí napsat jen trochu kódu navíc a stane se z toho publikovatelná věc. Tak jsem to udělal.
K čemu to je a k čemu to není? Co to řeší a co ne?
K čemu je to vhodné a k čemu to vhodné není?
Pokud následující body neodpovídají vašemu use-case, pak vám to k ničemu nebude.
- Jde o řešení pro senzory, tedy pro případ, že z nějakého zařízení potřebujete posílat naměřené hodnoty na server. Jedno zařízení může mít více senzorů, z každého může posílat hodnoty nezávisle. V tento okamžik jsou podporovány senzory spojitých veličin (např. teplota), impulzní senzory (např. impulzní výstup plynoměru) a posílání souborů (fotky z kamery, CSV s daty s rychloběžného měřáku).
- Počítá se s přenosem „rozumného“ množství záznamů, v řádu jednotek až desítek záznamů za hodinu. Pokud potřebujete on-line měření stroje s tisícem měřených bodů za minutu, jděte hledat něco jiného.
- Nejde o řešení pro aktory, tj. není tam zpětný kanál, kterým by v reálném čase server mohl posílat pokyny koncové krabičce, že má něco zapnout/vypnout.
- Server může zpět posílat změny konfigurace, ale nejde o real-time kanál.
- Předpokládá se, že krabička je „samostatná“, někde vhozená do provozu. Komunikuje přes net přímo se serverem. Není k ní místní „gateway“ či „edge systém“. (Což nevylučuje situaci, že se server pustí ve stejné lokální síti. Z hlediska krabičky je jí to ale zcela jedno.)
- V rámci lokální sítě není způsob, jak se přímo zeptat mikrokontroléru na jeho stav či z něj načítat hodnoty. Není samozřejmě problém si dodělat třeba něco jako UDP broadcast odesílaných dat, ale řešení obecně nenabízí rozhraní pro přímé čtení z mikrokontroléru. Vždy je potřeba se ptát serveru.
- Podporovaná je komunikace přes WiFi. Mikrokontrolér je klient, připojuje se k WiFi AP.
- V tento okamžik je možné zadat do konfigurace jen jedny přístupové údaje k WiFi. Zařízení tedy nemůže roamovat mezi více WiFi sítěmi s odlišným SSID.
- Podpora pro snadný vývoj – OTA upgrade aplikace, automatické předávání logů na server.
Co to přináší programátorovi mikrokontroléru?
Základní kostra aplikace nabízí velmi rychlý vývoj s minimem kódu.
- Kompletně řeší připojení k WiFi včetně konfigurace.
- Můžete ho mít stále zapnuté; můžete si ho zapínat a vypínat z kódu; můžete nechat řízení na jádru aplikace (zapne se automaticky, když jsou data k odeslání, pak se vypne). Režim nastavíte v konfiguraci a dál neřešíte.
- Nastavení SSID a hesla pro WiFi se dělá v konfiguračním portálu, spolu s ostatními nastaveními aplikace. Konfigurační portál je přístupný přes WiFi (zařízení funguje jako AP) a spustí se automaticky při prvním startu aplikace (když nejsou informace vyplněny), nebo se spustí, pokud je při bootu zařízení sepnut některý vstupní pin.
- Uživatelská aplikace dostává callbacky o stavu připojení.
- Jednoduché odesílání dat.
- Pro každý senzor, který má zařízení k dispozici, jedním příkazem v aplikaci založíte komunikační kanál. Není potřeba nic konfigurovat na serveru – jen zařízení ví, jaké senzory má k dispozici. Takže například u teploměru není třeba předem nastavovat, kolik senzorů DS18B20 je k dispozici – zařízení si enumeruje čidla a pro každé z nich založí komunikační kanál. Při definici senzoru také zařízení nastaví, jakou veličinu senzor měří a v jakém intevalu by měl posílat data.
- A pak už můžete snadno odesílat naměřené hodnoty – jeden příkaz pro spojité veličiny, jeden příkaz pro impulzní senzory.
- Spolehlivé odesílání dat.
- Zapsané hodnoty se kešují v paměti a odesílají, jakmile je k dispozici WiFi. Pokud se nepodaří odeslání na server, opakuje se, dokud nejsou data spolehlivě předána. Na ESP32 může být keš v RTCMEM a uložené hodnoty tak přežijí i deep sleep.
- Zařízení proto může fungovat i několik dní bez spojení na server (nefunguje WiFi, výpadek serveru) bez ztráty dat. Data se odešlou, až bude spojení fungovat.
- U low power zařízení se dá udělat keš v RTCMEM o velikosti cca 3 kB. Do ní se vejde více než 200 naměřených hodnot, tj. pro jeden senzor hodinová data za devět dní.
- U stále zapnutých zařízení je možné udělat keš daleko větší – na ESP3266 se určitě dá pracovat s 10 kB, na ESP32 bez PSRAM se 100 kB a na ESP32 s PSRAM může být velikost keše v podstatě neomezená.
- Data je možné odesílat s různou prioritou – např. každou minutu s nejnižší, jednou za 10 minut s vyšší, jednou za hodinu s nejvyšší. Pokud výpadek spojení trvá tak dlouho, že se zaplní celá keš, jsou postupně přepisovány záznamy s nejnižší prioritou – v uvedeném případě pak nakonec přežijí jen „hodinové“ záznamy a alespoň základní průběh naměřené veličiny bude zaznamenán.
- Snadná obsluha konfigurace.
- Úvodní konfigurace (připojení k WiFi, připojení k serveru, další hodnoty potřebné pro zařízení) se nastaví přes konfigurační portál. Konfigurace se uloží jako soubor do flash paměti.
- Aplikace má k dispozici jednoduché API „dej mi konfigurační hodnotu X a pokud není vyplněna, vrať mi defaultní hodnotu Y“.
- Aplikace může zapisovat do konfigurace. O zápis do souboru se nemusí starat, proběhne automaticky.
- Ze serveru je možné poslat změny konfigurace.
- Určené konfigurační položky (typicky hesla) jsou ukládané šifrovaně (AES256, CBC).
- Podpora pro low-power režim.
- Aplikace může říct, že již připravila k odeslání všechna data, která měla. Jakmile dojde k jejich skutečnému odeslání na server, je zavolán callback, který může zařízení přepnout do deep sleep.
- Odesílání souborů.
- Z aplikace jde snadno odeslat soubor.
- Na rozdíl od běžných dat ze senzorů se souborová data nekešují (ehm, omezená paměť) a jde tedy o on-line funkci. Pokud není spojení nebo se nepodařilo soubor odeslat, vrátí chybu a je na aplikaci, jak se s tím vyrovná.
- OTA aktualizace aplikace (zatím jen pro ESP32)
- Log shipping – log z aplikace se může automaticky replikovat na server
Všechny díly:
- Úvod – co to dělá a co to nedělá
- Bezpečnost
- Aplikace na mikrokontroléru
- Serverová strana – funkce, instalace
pebrou 
Díky moc za sdílení projektu, vypadá to dobře! Seznam požadavků/důvodů koreluje s mými, mám dosti zbastlených projektů s provizorním stavem kódu a existence rozumně navržené kostry, ideálně i s nějakou komunitou okolo pro doladění chyb přímo na githubu atp. je určitě přínosem! Tohle je věc, kterou spousta lidí píše nebo slepuje sama, akorát se s tím pak nepodělí 🙂