ESP 80162 jsme zdokonalili tak, až jsme na něj dostali certifikaci (EASYCON)

1

Easycon je úspěšný startup z Brna. Působí v Jihomoravském inovačním centru. Jeho zakladatelé Pavel Vejnar a Radek Sysel vyvinuli řešení na dálkové odečítání energií, které v současné době testuje RWE a od rolku 2017 je plánovaný pilotní provoz s  Pražskou energetikou.

Vyvinuli jste řešení na měření teploty a klimatu. Přidali jste k němu odečítání eneregií. Jak jste při vývoji postupovali? Kde jste sháněli komponenty? Jaké byly první zkušenosti s IOT? 

Na začátku jsme zkoušeli kupovat komponenty na eBay. Ten nám však přišel naprosto nepoužitelný. Má hrozně dlouhý dodací lhůty. Na každou součástku jsme čekali měsíc, což je v případě testování neuvěřitelně dlouho. Později jsme přešli na farnell.com.

Určitě jste v průběhu vývoje řešili nějaké problémy. Bylo něco co vás překvapilo?

První překvapení pro nás bylo, když jsme začali shánět čipy a senzory. Vycházeli jsme z předpokladu, že všechny součástky budou levné. Když jsme to ale celýposkládali, zjistili jsme, že cena vůbec nízká nebyla.

Jak jste si komponenty vybírali? Byly nějaké komplikace?

Objednávali jsme vždycky víc čidel od více výrobců a zkoušeli jsme je. Spálili jsme se na Ethernetu. Ze začátku jsme do řešení zařadili Ethernet, ale zjistili jsme, že ethernet zásuvky nejsou všude, zatímco klienti chtějí umístit řešení na nejrůznějších místech. Po nějakém čase jsme zvolili Wi-fi. Například na operačním sálu, kde jedno z našich řešení je, si napojení na ethernet nedovedeme představit.

Co jste použili?

Začínali jsme s ESP8266, mikroporcesorem, který má v sobě i wi-fi. Tento procesor si můžu sám naprogramovat aby buď jen odesílal data ze snímačů, nebo je přímo zpraocvával. Ze začátku byl hrozně nespolehlivej a neodladěnej.  Ale podařilo se nám ho postupně odladit.

ESP 8266 je považovej spíš za software pro hobby ne? Vaše řešení jsou ale pro business.

To jo. Nám se ale podařilo tento čip odladit tak, že jsme na něho dostali dokonce certifikaci. Takže jsme snad jediní v Čechách, kdo má na  naESPéčko certifikaci o shodě a typický označení CE.

V čem jste hardware programovali?

Programovali jsme ho v Arduinu. To prostředí má výhodu, že si můžeme stáhnout spoustu hotových knihoven a nemusíme programovat každej detail zvlášť. Tyk bylo možný rychle měnit myšlenky a přizpůsobovat celý hardware. Funguje to jako takový sofistikovanější LEGO. Setkali jsme se s několika odpůrci Arduina, kteří se divili, jak to v něm můžeme dělat. Naše zkušenost je, že nám zařízení běží vice jak rok, bez toho aby se cokoliv zaseklo nebo zkreslilo. Neregistrujeme ani, že by se nám někdy ztratily data a to i při výpadku internetu.

O Arduinu se říká, že je náročnější na spotřebu energie.

Je to možný. Naše řešení je ale permanentně zapojený do sítě. Nemusíme zakopávat senzory do země, nebo je instalovat někde daleko v terénu, takže tento problém neřešíme.

Co přenos dat?

Ze začátku jsme využívali čistě Wi-Fi . Postupně jsme začali zkoušet LORu a Sigfox. Ve finálevyužívámeSigfox.

Byl nějakej zvláštní důvod?

Pokrytí. Sigfox v té době, kdy jsme celé řešení dodávali, měl pokrytí podstatně lepší.

Co software?

SQL, Open Source platformy, PHP a další. Využili jsme jádro našeho  CRM, které se používalo pro správu www stránek. Pak jsme na něj nabalovali moduly a funkce podle toho, co jsme chtěli zobrazovat. Požadavek byl na modularitu a škálovatelnost, taky na rychlost, aby nebylo dlouhé načítání.

Tady to šlo všechno hladce?

Několikrát se měnila struktura tabulek. Po té co nám narůstal počet měřených veličiin jsme převedli tyto veličiny ze sloupců na řádky, tím byla lepší škálovatelnost. Ve finále jsme vytvořili speciální tabulky s dlouhodobě uchovanými daty a menší tabulky pro zobrazování, kvůli rychlosti. K tomu jsme došli při zkoumání toho, jak se chováaplikace při využívánívelkého množství dat. Samozřejmě jsme dělali hodně simulačních (zátěžových) testů Jinak využívámerelace,kontroluklíčů a tzv. transakce. Když například spadne server, tak se softwarevrátí do poslední verze a tím se vyloučí chybovost. Historická data, která nebyla přijmutá, se nám pak nahrají hned po startu serveru.

Jaký byly požadavky firem? 

Když  jsme software vyvíjeli, půl roku jsme ladili pěknou grafiku. Při komunikaci s firmama jsme ale zjistili, že je grafika vůbec nezajímala. Firmy sledovaly jasnej zájem. Jednoduchost a s ní spojenou přehlednost. Např. RWE vyložene ocenilo přehlednost řešení.

Nějaké další ořísky?

Měli jsme problémy s volbama grafů a knihoven k nim. Bylo důležité, abychom cokoliv mohli měnit a modifikovat. Hotová řešení se nám nehodily. Taky jsme řešili bezpečnost, kvůli které jsme museli změnit způsob přihlašování. Při kontaktu s RWE vznikl požadavek na zobrazení celkové spotřeby na měřidle, nikol za čas. Věcí bylo poměrně hodně, ale to je život.

Co se týče softweru, je to opravdu na každém, v čem svou aplikaci naprogramují. Někteří navrhují Python a PHP naopak zatracují, jiní zase mluví o jiném backandovém jazyku. Je to o volbě každého programátora.

Kde vaše řešení testujete?

Máme piloty s RWE a Pražskou energetikou. Náš produkt běží v Dětské nemocnici v Brně. Spolupracujeme s VUT Brno, výzkumným oddělením AdMaS, které je zapojeno do konceptu Smart City.

Co velcí vendoři.

Byli jsme osloveníSAPem abychom použili SAP HANA. Jsme už ale moc daleko, abychom něco měnili.

 

Díky za rozhovor

leave a reply

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *

related posts

instagram imagesfollow us @ instagram