Informační systém pro domácnost

Transkript

1 Bankovní institut vysoká škola Praha Katedra informatiky a kvantitativních metod Informační systém pro domácnost Bakalářská práce Autor: Studijní obor: Jakub Prikner Informační technologie a management Vedoucí práce: Ing. Vladimír Beneš, Ph.D. Praha 2017

2 Prohlášení Prohlašuji, že jsem závěrečnou práci zpracoval samostatně a v seznamu uvedl veškerou použitou literaturu. Svým podpisem stvrzuji, že odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, že se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací. V Praze, dne 4. května 2017 Jakub Prikner

3 Poděkování Rád bych poděkoval vedoucímu mé bakalářské práce Ing. Vladimíru Benešovi, Ph.D. za jeho cenné rady, připomínky a názory při tvorbě mé bakalářské práce, které mi velmi pomohly při formování její struktury a obsahu. Osobní poděkování patří mým nejbližším za jejich podporu při tvorbě mé bakalářské práce.

4 Anotace Bakalářská práce se zabývá tvorbou vestavěného informačního systému v komplexní podobě, tedy pokrývá většinu fází vývoje projektu, od návrhu a analýzy požadavků, až po samotnou implementaci. Výstupem bude prototyp plně funkčního produktu. Součástí bakalářské práce je i bodová a kvantitativní analýza rizik projektu. Klíčová slova Arduino, Raspberry Pi, NRF24L01+, GPIO, IoT, vestavný systém, chytrá domácnost. Annotation The bachelor thesis is focused on the construction of an integrated information system in its complex form, so it covers the main phases of the project development from the design and requirements analysis to the implementation itself. There will be a fully functional prototype at the end of this work. The thesis also contains the point and quantitative risk analysis of the project. Key words Arduino, Raspberry Pi, NRF24L01+, GPIO, IoT, embedded system, smart home.

5 Obsah 1 Úvod Motivace Internet věcí a chytrá domácnost Chytrá domácnost IoT řešení a služby IoT technologie a protokoly Vestavné systémy obecně Uživatelské rozhraní Analýza Účel a parametry projektu Klady a zápory projektu Analýza funkčních požadavků Analýza nefunkčních požadavků Diagram případů užití Diagram aktivit Sekvenční diagram Koncepce a návrh systému Technická specifikace Komunikace Sběrnice a rozhraní NRF24L ESP Arduino Nano, ESP8266 řídicí aplikace a spotřeba Arduino Nano

6 3.3.2 ESP Raspberry Pi Seznam komponent a materiálu Seznam pomůcek Doménový model Předběžná kalkulace nákladů Implementace Fyzické zapojení Rozložení pinů Arduino Rozložení pinů NRF24L Schéma zapojení Napájení z baterií Spotřeba energie Typická spotřeba mikrokontroleru Prvky s největším odběrem proudu Režimy spánku Redukce spotřeby Výsledek Faktory ovlivňující průměrnou spotřebu a výdrž Programová část O jazyce Wiring Arduino IDE Použité knihovny Ovládání servomotoru Čtení hodnot ze senzoru osvětlení Posílání zpráv mezi klientem a serverem

7 4.4.7 Popis použitých globálních proměnných Integrace do systému chytré domácnosti Vestavba do horní lišty žaluzií Zhodnocení Analýza rizik Kvantitativní analýza rizik spojených s provozem systému Bodová analýza rizik projektu Závěry analýzy Závěr Seznam použité literatury Seznam obrázků Seznam tabulek Seznam grafů Seznam příloh

8 1 Úvod Cílem práce bylo za použití dostupných komponent vytvořit vestavný systém určený k ovládání interiérových žaluzií a schopný samočinného provozu bez nutnosti řízení přímo uživatelem. Při zpracování práce byly využity vědomosti nabyté v průběhu studia na Bankovním institutu vysoká škola Praha, poznatky získané z odborné literatury na téma vestavných systémů, mikrokontrolerů a automatizace, ale také praktické zkušenosti v oblasti HW architektur, programování, jakož i modelářství a 3D tisku. Práce je rozdělena do čtyř kapitol, ve kterých jsou podrobně popsány jednotlivé fáze vývoje projektu. V úvodu jsou obsaženy obecné informace o této bakalářské práci a o technologiích a principech, úzce souvisejících s projektem, který je obsahem práce. Druhá kapitola se zabývá analýzou projektu. Podrobněji popisuje požadavky na funkce, které by měl systém obsahovat. V rámci této kapitoly je také provedena analýza funkčních a nefunkčních požadavků na systém a jsou zde rozebrány výhody a nevýhody projektu. Třetí kapitola patří návrhu systému dle předešlé analýzy. Jsou zde popsány specifikace jak hardwaru, využitého při fyzické implementaci, tak i použitého programového vybavení. Čtvrtá kapitola popisuje postup konstrukce a implementace systému od prostého zapojení jednotlivých komponent přes řešení různých problémů a úskalí, až po testování a uvedení prototypu do provozu. V páté kapitole je provedena analýza rizik projektu kvantitativní a bodová. V přílohách této práce jsou obsaženy ukázky z vytvořeného programového kódu. 1.1 Motivace Na úvod několik vět o tom, co předcházelo rozhodnutí začít se zabývat vlastním řešením automatizace žaluzií a následně i chytré domácnosti. Na úplném počátku stála potřeba nějakým způsobem vyřešit ovládání žaluzií v okně nad schodištěm v rodinném domku, umístěným v takové výšce, že na ovládací tyč nelze dosáhnout. Žaluzie jsou zde proto trvale nastaveny na částečné zatemnění, jedná se tak o jakýsi kompromis. Následovalo zjištění, že na trhu existuje řešení v podobě motorického ovládání od firmy Somfy. To však (alespoň v té době) umožňovalo pouze ruční spínání dálkovým ovladačem, plně automatický chod zde chyběl. Navíc tento systém jen pro jedno okno stál přibližně 3500 Kč. Alternativa k tomuto produktu na trhu nebyla, všechny ostatní 8

9 konkurenční produkty byly nabízeny jen pro venkovní předokenní žaluzie. Proto vznikla myšlenka, jak zkonstruovat vlastní systém fungující na baterie, jehož výroba by byla podstatně levnější, než zmíněný komerční produkt. A zároveň, aby takový systém umožňoval bezproblémový a téměř bezúdržbový automatický provoz, ovšem i s možností ručního ovládání v případě potřeby. S desítkami kompatibilních typů různých vstupně / výstupních senzorů, řídicích prvků, ale i bezdrátových komunikačních modulů a již popsaných hotových řešení projektů, provozovaných na energii z baterií, se jako velice zajímavá pro tento účel zdála být platforma Arduino. Na základě hlubšího zkoumání této platformy a jejích možností přicházely další nápady na využití v domácnosti, chytrou meteostanicí počínaje a automatickým zavlažováním, ovládáním bazénové technologie nebo třeba otevíráním dveří a řízením přístupu skrze biometrickou čtečku otisků prstů konče. Tak se zrodila myšlenka všechny tyto drobné dílčí projekty propojit v jeden celek a vytvořit tak vlastní komplexní chytrou domácnost. Tato práce se však z časových důvodů, ale i kvůli vysoké technologické a finanční náročnosti řešení chytré domácnosti jako celku, zaměřuje pouze na onen původní projekt automatických interiérových žaluzií. 1.2 Internet věcí a chytrá domácnost Internet umožňuje vývojářům vytvářet řešení produkující data, která mohou být zobrazena kýmkoliv, kdekoliv na světě. Přizpůsobit prototyp nebo menší verzi řešení tak, aby bylo využito možností internetu, může být výzvou. Nelze jen vzít zařízení, fungující v lokální síti nebo na obdobném komunikačním mechanismu, a jednoduše přidat internetovou konektivitu. Například, rozšíření stávající sítě senzorů z několika málo kusů monitorujících data a zobrazovaných pouze několika uživatelům na senzorovou síť zahrnující stovky senzorů s daty dostupnými potenciálně komukoliv, může vyžadovat zcela nový návrh použitých komunikačních metod, sběru dat a jejich uchovávání. Základem pro internet věcí (IoT, Internet of Things) jsou jednoduše propojená zařízení, která generují a vyměňují si data z různých měření, pozorování a dalších zdrojů a poskytují je tak, aby byla dostupná komukoliv. Přestože na trhu existují snahy přeměnit prakticky cokoliv připojeného do internetu v IoT zařízení, IoT řešení jsou navrhována tak, aby nám poskytovala přesnější a více relevantní informace o světě kolem, tím, že umožňují získávat data 9

10 o čemkoliv, odkudkoliv a kdykoliv. Nehledě na to, je zřejmé, že IoT zařízení mají potenciál svým počtem brzy převýšit lidskou populaci na planetě. (Bell, 2016) Chytrá domácnost Téma domácí automatizace (též známé jako smart home chytrá domácnost) se v poslední době stává čím dál více populární, zejména ve spojení s IoT řešením. Přestože automatizace domácnosti sama o sobě není ničím novým, ve spojení s přístupem do, resp. z internetu nebo propojením s cloudovými službami jsou tato řešení pro koncové uživatele mnohem atraktivnější. Řešení pro chytrou domácnost je typicky složeno z řady senzorů a ovládacích prvků, které umožňují uživateli řídit běžné vybavení domácnosti, a to i vzdáleně. Příkladem mohou být senzory pro detekci pohybu, hlídání otevřených, resp. zavřených oken a dveří, čidla teploty, vlhkosti, atmosférického tlaku, bezpečnostní požární hlásiče a další. Je možné do systému zapojit i elektromagnetické zámky, které může uživatel ovládat také vzdáleně, případně integrovat relé, spínající osvětlení vně i uvnitř objektu. (Bell, 2016) Aktuálním trendem v IoT pro domácnosti se stávají technologie s velmi nízkým odběrem proudu. Tyto technologie jsou natolik úsporné, že nevyžadují žádné externí napájení. Většinou jsou schopny fungovat i bez potřeby napájení z baterie - příkladem mohou být různé spínače a ovladače, založené na principu piezoelektrické indukce. Pokud však mají zabudovaný akumulátor, pak jsou schopny jej samy dobíjet s využitím zdroje energie z okolí. Toto umí například chytré termostatické hlavice, které se během topné sezony dobíjí díky energii získané z tepla radiátoru a jsou tak schopny bezdrátově komunikovat s centrální řídicí jednotkou systému. V období mimo sezonu pak hlavice přejdou do úsporného režimu podobného hibernaci a díky tomu vydrží s energií baterie opět až do začátku další topné sezony. Další technologickou novinkou je bezdrátové napájení prostřednictvím radiových vln, vysílaných bezdrátovými sítěmi Wi-Fi. Tato technologie je aktuálně ve fázi testování a je vyvíjena vědeckým týmem na University of Washington, který ji jako koncept poprvé představil v roce

11 1.2.2 IoT řešení a služby IoT řešením se rozumí sada zařízení, navržených generovat, zpracovávat, poskytovat nebo jinak využívat data o nějakém typu události nebo pozorování. Tato zařízení by současně měla být připojena do internetu. Cloudová řešení Většina velkých světových IT společností se postupem času stále více orientuje na cloudová řešení a snaží se nabízet služby zaměřené na internet věcí. Například Amazon poskytuje tento druh služeb prostřednictvím svého AWS 1 Cloud, společnost IBM pak v rámci své cloudové platformy IBM Bluemix nabízí službu Watson IoT, umožňující připojit vlastní chytrá zařízení a nastavit komunikaci například prostřednictvím protokolu MQTT 2 (protokol typu publish subscribe). Lokální řešení Další velice zajímavou možností je využití lokálního serveru jako náhrady připojení IoT řešení ke cloudovým službám. Server, umístěný většinou uvnitř objektu s implementovaným IoT systémem, sám komunikuje se všemi připojenými senzory, relé a dalšími ovládacími nebo kontrolními prvky a plně tak nahrazuje připojení ke službě třetí strany. Dvě hlavní nevýhody cloudových řešení jsou nutnost zajištění trvalé konektivity do internetu pro správnou funkci systému a rizika spojená s bezpečností. V případě výpadku internetového připojení přestávají veškeré závislé domácí systémy fungovat. Pokud však dojde k napadení cloudu nebo komunikačního kanálu útočníky a k jejich převzetí kontroly nad systémem, je situace ještě horší. V tu chvíli může útočník z jakéhokoliv místa na Zemi ovládat naše osvětlení, aktivovat či deaktivovat alarm, prohlížet si obraz z bezpečnostních kamer, manipulovat se stínící technikou a podobně. Implementací IoT koncepce s lokálním serverem lze zcela eliminovat problém výpadku internetové konektivity, protože v takovém případě sice nemůžeme systém ovládat vzdáleně, nicméně lokální ovládání bude stále fungovat. Riziko napadení útočníkem nikdy nelze úplně vyloučit, je ale možné jej do značné míry minimalizovat dostatečným zabezpečením domácí 1 Amazon Web Services Cloud computingová platforma firmy Amazon 2 Protokol MQTT je blíže představen na str

12 sítě a realizací vzdáleného přístupu prostřednictvím VPN (Virtual Private Network) s vhodně zvoleným bezpečnostním protokolem. Výborným příkladem pro koncepci IoT s využitím lokálního serveru je EasyIoT: jedná se o projekt spolufinancovaný ze zdrojů Evropské Unie a poskytující možnost volby mezi připojením do cloudu (EasyIoT Framework II Architecture EasyIoT Cloud) a lokální konfigurací (EasyIoT Framework I Architecture). Možnosti takové konfigurace ukazuje následující schéma: Obrázek 1 1: Architektura EasyIoT Zdroj: 12

13 1.2.3 IoT technologie a protokoly EnOcean Bezdrátové senzory a spínače, které se díky využití technologie EnOcean dokáží samy napájet, jsou ideální pro trvalé aplikace uvnitř budov. Napájeny jsou díky pohybu, světlu nebo teplu. Pro funkci spínání nebo shromažďování informací ze senzorů (teplota vzduchu, vody, detekce pohybu ) tak nepotřebují žádné baterie ani kabely. Senzory a pohony založené na technologii EnOcean mohou komunikovat přímo mezi sebou nebo mohou být ovládány prostřednictvím ovládacího panelu, případně mobilní aplikací nebo programem v počítači. ( LoRa a LoRaWAN LoRa Technology je jednou ze zajímavých technologií pro internet věcí a také zařízení pro vzdálenou signalizaci a řízení (LRSC Long Range Signaling and Control), které budou instalované na velké rozloze (WAN Wide Area Network) a zároveň si vystačí s malým datovým tokem, případně se od nich ještě očekává velmi nízká spotřeba (Low Power). Obecně se pak takové sítě označují jako LP-WAN (Low Power Wide Area Network). LoRa (Long Range) je modulace patentovaná firmou Semtech, která mimo jiné využívá kódování 4/5, dopřednou korekci chyb a modulaci Chirp. Protokol LoRaWAN zajišťuje transparentní zabezpečený přenos dat mezi koncovým zařízením (internet věcí) a aplikací běžící na serveru a zpět. O standardizaci a rozvoj protokolu LoRaWAN se stará nezisková organizace LoRa Alliance, mezi jejíž členy patří desítky firem. LoRa byla navržena jak pro evropské pásmo 868 MHz, tak pro to americké 913 MHz. Obě pásma mají výhodu a zároveň nevýhodu, že jsou volná a zdarma. Legislativa se pro obě pásma liší, přesto zmíněná technologie dosahuje skvělých výsledků. Citlivost je -136 db a odolnost vůči rušení -16 db (pod úrovní šumu), dosah na přímou viditelnost 40 km, v městské zástavbě okolo 2 km. Aby nedošlo k mýlce, hardware a software se pro oba kmitočty liší, nicméně aplikační rozhraní je identické. Modulace LoRa Jedná se o patentově chráněný přístup, založený na modulaci Chirp. Chirp je modulace poměrně nová a signál rozprostírá po celém vysílacím kanálu (125 khz, 250 khz, 500 khz), podobně jako DSSS, FHSS atd. Rozdíl však spočívá v tom, že ostatní provádějí změny skokovou změnou kmitočtu, kdežto Chirp lineární, což zvyšuje odolnost vůči Dopplerovskému 13

14 jevu a snižuje nároky na zdroj kmitočtu a jeden kanál může využívat současně několik vysílačů. Modulace má několik volitelných možností pro rozprostření (Spreading Factor) a šířku pásma, pevně stanovených pro každou datovou rychlost (DR Data Rate), což je jediný parametr, který by měl uživatel nastavovat. Pro stacionární aplikace se doporučuje zapnout ADR (Automatic Data Rate), která volí automaticky nejvyšší možnou přenosovou rychlost na základě naměřeného signálu bránou. LoRaWAN Protokol LoRaWAN zajišťuje zabezpečený přenos dat mezi koncovými zařízeními a aplikací běžící na internetu. Každý koncový bod má přidělený jedinečný 64bitový identifikátor a dva 128bitové klíče, kterými jsou data pomocí AES zašifrována. Jeden klíč se používá v rámci sítě, to aby mohlo stejné území pokrývat více sítí, druhý k zabezpečení dat mezi sítí a uživatelskou aplikací. Obrázek 1 2: IoT technologie LoRaWAN schéma komunikace Zdroj: LoRaWAN Master přijímá data ze všech bran, vyhodnocuje jejich rádiové vlastnosti a přeposílá je k patřičnému aplikačnímu serveru. Dalším úkolem bude odesílat přes vhodnou bránu data pro koncový bod. V budoucnu při dostatečném pokrytí lze určit pozici (místo) vysílače. Koncové body V současné době jsou definovány celkem tři třídy koncových bodů, které se liší dobou naslouchání a tudíž vlastní spotřebou. Třída A naslouchá jen chvíli po odvysílání dat, proto 14

15 má spotřebu nejnižší. Třída B naslouchá po odvysílání dat jako třída A a v plánových časech. Poslední třída C naslouchá trvale, kromě doby vysílání, a proudový odběr má tudíž největší. (Mácha, 2016) SigFox Technologie SigFox umožňuje IoT zařízením komunikovat levně, bezpečně a na velké vzdálenosti při zcela minimální spotřebě energie. V České republice síť SigFox vybudovala a provozuje společnost SimpleCell Networks ve spolupráci s operátorem T-Mobile, který poskytuje své prostory pro výstavbu základnových stanic SigFoxu. Aktuální pokrytí činí více než 90 % území a obyvatelstva ČR a v těchto dnech (na jaře roku 2017) by mělo být dosaženo úplného pokrytí. Síť SigFox využívá bezdrátového spojení v bezlicenčním pásmu na rádiové frekvenci 868 MHz. Tato síť není určena pro velké objemy dat a kontinuální přenos. Je vhodná tam, kde je potřeba jednou za čas poslat krátkou zprávu, například o tom, kde se zařízení nachází nebo v jakém je stavu. Výhodou této sítě je, že zařízení, která ji využívají, mohou být navržena tak, aby měla co nejnižší spotřebu. Taková zařízení mohou fungovat na jednu baterii i několik let. V této chvíli už na trhu působí několik společností, které nabízejí či uvádějí na trh zařízení, jež využívají právě připojení přes síť SigFox. Implementace tohoto připojení je totiž snadná, díky nabídce předpřipravených elektronických modulů za příznivé ceny. Stejně tak jsou příznivé i ceny za samotné používání sítě - provoz jednoho zařízení stojí ročně jednotky až desítky eur, což je v porovnání s jinými způsoby připojení řádově nižší cena. Síť SigFox se používá už dnes například ke zmiňovanému sledování nákladů, ale i v dalších oblastech. Zajímavým využitím je například sledování obsazenosti parkovacích míst. Ve Francii jsou touto technologií vybavovány například požární hydranty, které pravidelně hlásí tlak vody a upozorní, kdyby někde poklesl pod požadovanou hranici. Baterie v takovém hydrantu vystačí až na deset let provozu. Další oblast využití mohou být hlídané objekty, kdy je pravidelně posílána informace o tom, zda je vše v pořádku. Velkou oblastí pro síť SigFox je také telemetrie - odečty vodoměrů, plynoměrů a dalších měřidel, která jednou za čas sama odešlou informaci o svém stavu. ( BigClown BigClown je modulární systém hardware a software, vyvinutý společností BigClown Labs, dceřinou společností českého Jablotronu. S tímto systémem je možné prototypovat i stavět 15

16 reálné aplikace pro telemetrii, automatizaci a další použití, včetně IoT. Na BigClown lze pohlížet jako na celý systém, ale také jako na stavebnici sadu komponent s jednotným rozhraním, které je možné k sobě spojovat tak, jak je potřeba pro danou aplikaci. Obrázek 1 3: IoT technologie BigClown koncept Zdroj: Srdcem každého podobného systému je samotné zařízení, tedy node. Základem nodu BigClown je takzvaný Core Module. Ten je poháněn jednočipem s jádrem Cortex-M0+, konkrétně jde o STM32L083CZ. Tento čip byl vybrán hned z několika důvodů: jde o obvod z ověřené a používané řady ARM procesorů STM32, má velmi nízký odběr (což je důležité pro napájení nodů z baterií), má integrované USB s ROM bootloaderem, dostatečný počet rozhraní, dostatečnou velikost pamětí (Flash, RAM i EEPROM) a především má dvě komponenty, důležité pro kryptografii: TRNG (True Random Number Generator) a akcelerátor pro výpočet AES-128. Obrázek 1 4: IoT technologie BigClown Core modul Zdroj: S tímto čipem úzce spolupracuje čip ATSHA204A. Jde o paměť EEPROM, navrženou pro ukládání klíčů, která zároveň implementuje několik kryptografických operací s pomocí algoritmu SHA-256. Výrobce garantuje, že klíče v této paměti uložené nelze přečíst ani 16

17 pomocí metod přímého útoku na hardware či postranními kanály (power analysis, power glitching, dekapsulace odstranění pouzdra, a podobně). BigClown jej používá pro kryptografickou autentizaci nodu (uzlu) vůči gateway a gateway vůči node, a pro kryptografickou aktualizaci AES klíče, používaného pro šifrování a zajištění integrity spojení Node Gateway. Na Core modulu je zároveň integrován tříosý akcelerometr (LIS2DH12), teploměr (TMP112) a bezdrátový komunikační modul (SPSGRF). Samotný Core Module tak může sloužit jako snímač pohybu a teploty (akcelerometr lze využít i pro detekci fyzického útoku, např. že se někdo dobývá do zařízení) a může předávat data buď přes rádio, přes USB CDC nebo i jinými způsoby (I2C, UART, SPI, GPIO). Core modul má vyvedené sběrnice, díky kterým je možné k němu připojit další senzory, aktuátory či celé systémy. Podporuje rozšířená rozhraní typu I2C, SPI, 1-Wire a UART. Core modul může fungovat i samostatně, ale lze k němu připojit další moduly například modul pro napájení z baterií nebo takzvaný Tag Module, což je deska, která umožňuje připojení až šesti různých I2C zařízení ve formě tzv. tagů. Tagy jsou malé desky se snímači, namátkou snímač intenzity osvětlení, teploměr, vlhkoměr nebo NFC tag. K dispozici je i CO2 senzor a ve vývoji je i modul displeje a ovladače (otočný enkodér s tlačítkem). Samotný Core Module (či s rozšiřujícími tagy a moduly) může fungovat jako autonomní jednotka, připojená přes USB například k Raspberry Pi či k Turris Omnia. Zajímavější možná bude ale jejich zapojení do bezdrátové sítě (využívá frekvenci 868 MHz, popř. 915 MHz). Více Core modulů pak komunikuje s jedním centrálním modulem (koncentrátorem), který je připojen k počítači. V tuto chvíli se počítá s využitím linuxových strojů Raspberry Pi nebo Turris Omnia. Zde běží MQTT broker, který se stará o předávání a směřování zpráv, hub (napsaný v Pythonu), který řeší příjem zpráv od modulů, a k tomu volitelně např. webserver (takže je možné Raspberry Pi připojit k monitoru či televizi a mít přehled o naměřených datech, popřípadě rovnou ovládat potřebné periferie) nebo různé automatizační moduly pro lokální zpracování dat (technicky jde o libovolné spustitelné aplikace, napsané v Pythonu, Node.js, C++ či v jiných jazycích, které komunikují s MQTT brokerem). Samozřejmě je možné vše připojit na internet a integrovat s existujícími službami (Azure IoT, Amazon IoT, Thingspeak či s vlastním řešením) pomocí MQTT over TLS, MQTT over WebSocket, nebo pomocí HTTPS REST API. (Malý, 2016) 17

18 MQTT protokol V IoT systémech by snímače neměly určovat, co kdo má udělat. Ony snímají a jen posílají zprávy do centrálního místa. O víc se nestarají. Ti, co mají zájem o jejich zprávy, se přihlásí k jejich odběru, a nějak na ně reagují. V ideální podobě se přidává i další vrstva abstrakce, kde žárovka reaguje na pokyn vypnout / zapnout, vypínač informuje o tom, že byl stisknut, a někdo třetí, nějaký softwarový agent, čte zprávy od vypínače a nějak na ně reaguje. Pak je mnohem snazší doplnit různé funkce, jako například zhasnutí se zpožděním nebo přemapování fyzických zařízení tak, aby logicky fungovala lépe. Komunikace nodů se světem po internetových protokolech vypadala zpočátku jako poměrně jednoduchá, a vypadalo to, alespoň v hlavách nepříliš zkušených, jako hotová věc: použijeme HTTP, všichni ho znají, všichni ho používají, je to celkem jednoduchý protokol, a bude. Na druhé straně může být REST API, jaký tedy problém? Postupem času se ukázalo, že HTTP má pro využití v internetu věcí mnoho nevýhod. Je hodně upovídaný. Jeho implementace není triviální (ale lze z něj používat nějaký minimální subset). Je založen na principu klient táhne, takže pro komunikaci typu server tlačí je potřeba řešit různé hacky typu long polling, heartbeat, použít HTTP/2 apod. Nemá vyřešené různé úrovně QoS (Quality of Service) a pro dvě zařízení s protokolem HTTP je vždy nutné mít nějakou serverovou aplikaci, která jim umožní vzájemnou komunikaci, protože samotný HTTP server nedokáže sám data předávat mezi klienty. Z HTTP vznikla jeho binární podoba CoAP ta měla v první řadě zjednodušit implementaci v MCU (Microcontroller Unit), snížit množství dat, protože textové hlavičky nahradila binárními příznaky, místo TCP používat UDP a řešit QoS. Jeho výhodou je snadné předávání zpráv mezi CoAP a HTTP. Pro komunikaci se serverem využívá observer pattern a princip odpověď po dlouhé době. S volitelnými doplňky ale CoAP opět nabobtnal, čímž hlavní výhoda zmizela. MQTT (dříve Message Queuing Telemetry Transport, dnes MQ Telemetry Transport) je jednoduchý a nenáročný protokol pro předávání zpráv mezi klienty prostřednictvím centrálního bodu brokeru. Díky této nenáročnosti a jednoduchosti je snadno implementovatelný i do zařízení s malými procesory a poměrně rychle se rozšířil. Navržen byl v IBM, dnes za ním stojí Eclipse Foundation a před nedávnem proběhla standardizace OASIS. 18

19 U protokolu MQTT probíhá přenos pomocí TCP a používá návrhový vzor publisher subscriber. Tedy existuje jeden centrální bod (MQTT broker), který se stará o výměnu zpráv. Zprávy jsou tříděny do tzv. témat (topic) a zařízení buď publikuje v daném tématu (publish), to znamená, že posílá data brokeru, který je ukládá a distribuuje dalším zařízením, nebo je přihlášeno k odběru tématu či témat (subscribe), a broker pak všechny zprávy s daným tématem posílá do zařízení. Jedno zařízení samozřejmě může najednou být v některých tématech publisher, v jiných subscriber. Samotný obsah zpráv není nijak daný ani vyžadovaný, MQTT je payload agnostic. Obsah zprávy jsou prostě nějaká binární data, která jsou přenesena. Nejčastěji se používá JSON, BSON, textové zprávy, ale může to být opravdu cokoli. Velikost zprávy je v aktuální verzi protokolu omezena, je to necelých 256 MB, ale naprostá většina zpráv je mnohem menší. MQTT minimalizuje množství balastních dat, takže přidává jen minimum servisních dat. Zavádí tři úrovně QoS tedy potvrzování zpráv, kde ta nejnižší znamená, že zpráva je odeslána bez potvrzení a není zaručeno její doručení (at-most-once), prostřední úroveň říká, že zpráva je doručena alespoň jednou (at-least-once), a nejvyšší úroveň QoS znamená, že každá zpráva je doručena právě jednou. Klient však nemusí podporovat všechny tři úrovně QoS. Zprávy v MQTT patří do určitých témat. Každá zpráva patří právě do jednoho tématu. Témata jsou hierarchická, oddělená lomítky, například hypotetické světlo číslo 26 na stropě v místnosti 103, první patro, budova 1 může mít topic building-1/floor-1/room- 103/ceiling/light-26. Nebo třeba dům/ložnice/světlo témata jsou v MQTT řetězce v UTF - 8, takže pojmenování s diakritikou není problém. Hierarchie není pevně dána, záleží na aplikaci a na vlastním návrhu. Jak správně navrhnout hierarchii může být netriviální úloha, ne vždy je nejsprávnější struktura ta přirozená. Důležité je už v rámci těchto úvah rozmyslet datový model a rozhraní tedy vhodné uspořádání tak, aby bylo možné přihlásit takové topics, které logicky patří k sobě. Publisher, tedy ten, kdo zprávu produkuje, zvolí topic a pošle ho spolu se zprávou. Nemusí topic nijak zakládat ani kontrolovat, broker funguje tak, že jakmile přijme zprávu pro topic, který ještě nemá, tak jej založí. Je ale zásadní věc, aby si publisher s odběratelem předem dohodli téma, jaké budou používat. Většinou to bude dáno právě datovým modelem. Zařízení se přihlašují k odběru zpráv úplně stejně tedy pošlou brokeru speciální zprávu subscribe s názvem topicu, který chtějí odebírat. (Malý, 2016) 19

20 1.3 Vestavné systémy obecně Vestavěný systém (zabudovaný systém embedded system) je jednoúčelový systém, ve kterém je řídicí počítač zcela zabudován do zařízení, které ovládá. Na rozdíl od univerzálních počítačů, jako jsou osobní počítače, jsou zabudované počítače většinou jednoúčelové, určené pro předem definované činnosti. Vzhledem k tomu, že systém je určen pro konkrétní účel, mohou tvůrci systém při návrhu optimalizovat pro konkrétní aplikaci a tak snížit cenu výrobku. Vestavěné systémy jsou často vyráběny sériově ve velkém množství, takže úspora bývá znásobena velkým počtem vyrobených kusů. Na rozdíl od všeobecně použitelného počítače (například osobního) jsou vestavěné systémy navrženy pro konkrétní činnosti. Některé také pracují v reálném čase, protože zpoždění činnosti nebo akce ovládané řídícím procesorem může mít fatální následky nebo poruchu činnosti včetně nebezpečných stavů (např. zastavení motoru letadla nebo naopak nezastavení motoru ve vlaku či automobilu). U systémů vyráběných ve velkých sériích, jako například MP3 přehrávačů nebo mobilních telefonů, je většinou jedním z primárních cílů ve fázi návrhu nízká cena. Tvůrci těchto zařízení často používají hardware, který je přesně dostačující pro implementaci požadovaných funkcí. Například digitální přijímač DVB-S pro příjem satelitní televize zpracovává každou sekundu obrovská množství dat, ale zpracování je provedeno v zákaznickém integrovaném obvodu, který provádí pouze tuto jedinou činnost. Hlavní procesor pouze nastaví a spustí tento proces, případně zobrazuje menu, animace a podobně, k čemuž mu stačí jeho menší výpočetní výkon. Při malých sériích nebo prototypech vestavěných systémů lze použít hardware osobního počítače a použít pouze konkrétní programy nebo nahradit původní operační systém operačním systémem pracujícím v reálném čase (RTOS). Software určený pro vestavěné systémy je často označován jako firmware a je uložen v čipech ROM nebo Flash na rozdíl od programů v osobním počítači, které jsou uloženy na pevném disku. Tento software často počítá s omezenými prostředky zařízení malá nebo žádná klávesnice, omezený nebo žádný displej, malé množství paměti RWM-RAM a podobně. Řídicí systémy jsou vestavěny do zařízení, od nichž se očekává, že budou schopna pracovat léta bez chyb a v některých případech schopna zotavit se z poruchy. Proto bývají programy většinou vyvíjeny a testovány pečlivěji než programy pro osobní počítače a v návrhu se nepoužívají nespolehlivé mechanické součástky jako disky, přepínače, tlačítka. Zotavení 20

21 z poruchy může využít například techniky watchdog timeru, který resetuje počítač, pokud program po jistou dobu neupozornil watchdog, že je v pořádku. ( 1.4 Uživatelské rozhraní Uživatelská rozhraní u vestavěných systémů se liší od nulového uživatelského rozhraní až po plné rozhraní podobné systému stolního PC, jako je tomu například u PDA, MDA nebo smartphonů. Někde uprostřed bývají zařízení s malými displeji, které jsou schopny zobrazovat pouze některé znaky, a pouze několika tlačítky (např. kalkulačka). Jeden z přístupů často používaných u vestavěných systémů bez sofistikovaných displejů používá pouze několik tlačítek pro ovládání menu, kdy některá tlačítka slouží pro pohyb v menu a další pro nastavování hodnot. U těchto zařízení jsou používána jednoduchá a levná řešení, jako například LED pro indikaci stavu. Při použití větších displejů bývají použity dotykové displeje nebo displeje s ovládacími klávesami vedle displeje (soft button), které poskytují dostatečnou flexibilitu při minimalizaci použitého prostoru. Výhodou tohoto řešení je, že funkce tlačítek se změní nápisem na displeji, a také přirozené ovládání. Systémy do ruky (PDA, MDA, mobilní telefony) často mají displej a joystickové tlačítko ovládající kurzor, i zde je však významný přesun k dotykovým displejům. Rozvoj webu dává tvůrcům vestavěných zařízení další, zcela novou možnost ovládání pomocí webové stránky dostupné prostřednictvím síťového připojení. Toto řešení eliminuje potřebu složitého displeje, a přesto poskytuje možnost složitého nastavení a zobrazení v případě potřeby (na vzdáleném počítači). Toto řešení je úspěšně používáno pro ovládání vzdálených, pevně instalovaných zařízení. Některá moderní vestavěná zařízení také používají k zobrazení uživatelského rozhraní standardní VGA monitor a PS/2 klávesnici. ( 21

22 2 Analýza V této kapitole podrobněji rozebereme, co obnáší tvorba vestavného systému pro automatické ovládání interiérových žaluzií, jaké jsou výhody a nevýhody takového řešení a definujeme hlavní funkční i nefunkční požadavky na systém. 2.1 Účel a parametry projektu Prototyp vestavného systému vyvíjený v rámci této práce vznikl s cílem zjednodušit člověku každodenní život, případně ulehčit život tělesně handicapovaným. Konkrétně se jedná o systém pro polohování interiérových žaluzií v závislosti na intenzitě venkovního osvětlení. Celý systém ovládání by mělo být možno plně integrovat do stávajících žaluzií zabudováním do konzolové lišty tak, aby prvky systému byly prakticky neviditelné a aby byla minimalizována nebo pokud možno zcela eliminována nutnost zásahů do interiéru (instalace nové napájecí, resp. datové kabeláže). S ohledem na tyto požadavky je vhodné systém navrhnout jako bezdrátový, s napájením z baterií. Systém by měl být schopen plně autonomního provozu, s možností ručního ovládání uživatelem prostřednictvím webového rozhraní nebo mobilní aplikace. Aby mohl systém fungovat autonomně, musí znát úroveň venkovního světla. Její měření by měl zajišťovat senzor intenzity osvětlení, integrovaný do systému. Uživatelské rozhraní by mělo umožňovat uživateli definovat vlastní profily, případně zvolit z profilů již předkonfigurovaných. Profily by měly upravovat chování systému, například aktivní profil Stinný dům by měl mít za efekt, že systém propustí do interiéru méně světla, než profil Slunný dům, který by měl množství propuštěného světla maximalizovat. 2.2 Klady a zápory projektu Nespornou výhodou implementace vestavného systému do prostředí domácnosti je její automatizace v oblasti, kterou daný vestavný systém pokrývá. Také je velmi vhodné, pokud systém svou konstrukcí počítá s možným rozšířením o další funkcionality, například integrace s elektronickým zabezpečovacím systémem (EZS) a možnost definování akcí při poplachu, případně rozšíření o systémy fungující na jiných komunikačních protokolech. Příkladem může být implementace technologie EnOcean pro IoT aplikace s velmi nízkým odběrem energie a další protokoly, koncepty a systémy. 22

23 Mezi hlavní nevýhody projektu lze zařadit složitost řešení problémů bateriového napájení prvků systému a bezdrátové komunikace mezi prvky. Dále v případě automatizace chodu žaluzií je prakticky eliminována možnost jejich mechanického ovládání uživatelem. Toto je třeba nějakým způsobem zachovat, proto spolu se samotným systémem je nutno implementovat také uživatelské prostředí, které uživateli poskytne možnost ruční kontroly nad žaluziemi. Řešením může být tvorba webového uživatelského rozhraní, nasazeného na lokálním serveru, mobilní aplikace pro ovládání systému, případně kombinace těchto prvků. 2.3 Analýza funkčních požadavků Polohování žaluzií automatický chod s možností ručního řízení uživatelem; včasná indikace nízkého stavu baterie upozornění uživatele LED indikací a upozorněním v ovládací aplikaci; možnost vytvořit půdorysný plán objektu vč. jednotlivých pater, zakreslení a pojmenování místností, zakreslení a pojmenování jednotlivých oken; možnost volit mezi přednastavenými profily, upravujícími chování systému, na výběr dva režimy: jeden profil pro celou domácnost nebo jiný profil pro každou místnost zvlášť; možnost definovat uživatelské profily; možnost napojení systému na EZS a definování chování během případného poplachu (plně zatemnit plně roztemnit). 2.4 Analýza nefunkčních požadavků Zajištění kompatibility pro případnou budoucí integraci do komplexního systému inteligentní domácnosti; tichý chod systému, zejména servomotoru, během polohování žaluzií - systém nesmí rušit svou činností obyvatele domácnosti; snadná obsluha systému uživatelem, důraz na co nejjednodušší ovládání; efektivita systému měla by být minimalizována potřeba údržby systému; baterie nesmí uživatele zatěžovat potřebou příliš častého dobíjení; spolehlivost systému to znamená, že nesmí docházet k situacím, kdy například server i klient čekají na odpověď od druhé strany a tento stav by trval až do restartování jednoho z nich; bezpečnost systému: 23

24 o Ve smyslu předcházení možným úrazům uživatelů jako zdroj používat pouze bezpečné napětí, aby nemohlo dojít k úrazu elektrickým proudem. Dále zabezpečit, aby jakákoliv pohyblivá součást nemohla způsobit zranění při vlastním samočinném provozu. Proto je velmi vhodné po samotné výrobě funkčního prototypu zaměřit pozornost na vývoj šasi a zlepšení celkového provedení vestavby do horní konzolové lišty žaluzií. o Ve smyslu zabezpečení systému před neautorizovanou manipulací ovládání systému by nemělo být přístupné z internetu, maximálně skrze zabezpečené VPN připojení. Doporučenou variantou je pouze lokální ovládání v rámci místní domácí sítě a skrze internet pouze monitorování chodu a stavu systému. doba odezvy mikrokontrolerů v oknech na příkazy musí být přiměřená. Je třeba hledat určitý kompromis mezi mírou úspory energie (hluboký spánek mikrokontroleru, bude vysvětleno později v kapitole Implementace Spotřeba energie) a potřebou mít systém, rychle reagující na příkazy ze strany uživatele. 24

25 2.5 Diagram případů užití Obrázek 2 1: Diagram případů užití Zdroj: vlastní úprava (autor) 25

26 2.6 Diagram aktivit Obrázek 2 2: Diagram aktivit: reakce systému na změnu den / noc Zdroj: vlastní úprava (autor) Tento diagram aktivit popisuje chování a reakci systému na změnu dne na noc a naopak. Rozhodování, zda je právě den či noc, se zde děje na základě textového souboru, ve kterém jsou uloženy časy východu a západu Slunce pro každý den v roce. Druhou možností, poněkud jednodušší, je zapojení senzoru reagujícího na světlo a nastavení systému tak, aby ve spolupráci s tímto senzorem reagoval na změnu intenzity denního světla. 26

27 2.7 Sekvenční diagram Obrázek 2 3: Sekvenční diagram: nastavení profilu a rotace servomotoru Zdroj: vlastní úprava (autor) 27

28 3 Koncepce a návrh systému V této kapitole je řešena celková koncepce systému automatického ovládání žaluzií. Mimo vlastní řešení problematiky autorem byly využity také poznatky nabyté z níže uvedené literatury: Podniková informatika (GÁLA, L., POUR, J., ŠEDIVÁ, Z., 2009) a Practical Aspects of Embedded System Design using Microcontrollers (PARAB, J. a kol., 2008). 3.1 Technická specifikace Systém se bude skládat z uzlů umístěných v jednotlivých oknech a z jednoho serveru, který bude všechny uzly řídit. Jedná se o tzv. konfiguraci master slave, přičemž v roli master se nachází server a v roli slave jsou všechny ovládané uzly. Jeden uzel bude obsahovat senzor intenzity osvětlení a bude umístěn mimo okno, nejlépe vně objektu (budovy, bytu) tak, aby byla zajištěna jeho spolehlivá funkčnost. To znamená, aby správně reagoval na změny v intenzitě venkovního osvětlení, a zároveň, aby nemohlo docházet k jeho ovlivnění a tím ke zkreslení měření, například interferencí způsobenou lampou veřejného osvětlení. V rámci této práce byly pro okenní uzly zvoleny mikropočítače Arduino Nano, založené na architektuře Atmel AVR (čip Atmel ATmega 328p). Jako bezdrátový modul pro komunikaci mezi uzly byl vybrán NRF24L01+ od společnosti Nordic Semiconductor. Modul operuje ve frekvenčním pásmu 2,4 GHz a v tomto pásmu umožňuje využít až 127 kanálů, přičemž šířka pásma může být 1 nebo 2 MHz. Komunikace dosahuje maximální rychlosti 2 Mbps, ale lze nastavit také 1 Mbps nebo 250 Kbps. Využitím nejnižší zmíněné přenosové rychlosti lze dosáhnout nejvyššího zisku signálu modulu ( 94 dbm), a tím i podstatně zvýšit dosah modulu, zejména uvnitř budovy. 3.2 Komunikace Sběrnice a rozhraní Mikrokontrolery Arduino, minipočítače Raspberry Pi i jejich klony nebo konkurenční zařízení jiných výrobců založené na jiné architektuře (např. STM32) ty všechny bývají zpravidla vybaveny komunikačním rozhraním. To může sloužit k interakci s různými rozšiřujícími moduly, vstupně / výstupními senzory, ovládacími prvky a podobně. 28

29 GPIO GPIO je zkratka z anglického General Purpose Input / Output, v překladu jde o univerzální vstupně / výstupní rozhraní. Petr Horáček GPIO definuje jako piny, tedy jakési vývody, které lze programovat pomocí softwaru. Do těchto pinů lze posílat elektrický signál nebo jej z nich naopak přijímat, tím lze ve finále pracovat s připojeným hardware na té nejnižší úrovni. (Horáček, 2012) SPI Sběrnice SPI (Serial Peripheral Interface) představuje jednu z forem sériových externích sběrnic sloužících pro vzájemné propojení dvou či více komunikujících uzlů, přičemž jeden uzel obvykle vystupuje v roli takzvaného řadiče sběrnice (master), ostatní uzly pracují v režimu slave. Uzel, který pracuje jako master, obsahuje generátor hodinového signálu, který je rozveden do všech ostatních uzlů, čímž je umožněn zcela synchronní (navíc ještě obousměrný) přenos dat. Hodinový signál je rozváděn vodičem označovaným symbolem SCK. Kromě vodiče s hodinovým signálem jsou uzly propojeny dvojicí vodičů označovaných většinou symboly MISO (Master In, Slave Out) a MOSI (Master Out, Slave In), pomocí nichž se obousměrně (full duplex) přenáší data. Posledním signálem, který se u této sběrnice používá, je signál SSEL (Slave Select), jenž slouží jak již jeho název napovídá k výběru některého uzlu pracujícího v režimu slave. V následujících kapitolách si ukážeme, jak a kdy se tento signál používá. Všechny čtyři signály SCK, MISO, MOSI i SSEL, pro svoji funkci vyžadují pouze jednosměrné porty, což přispívá k jednoduché a především levné implementaci této sběrnice. Mezi největší přednost sběrnice SPI patří její značná jednoduchost a tím i snadnost implementace. Jednoduché je jak elektrické rozhraní sběrnice (jednosměrné piny kompatibilní s technologií TTL, čemuž dnes odpovídají i integrované obvody využívající technologii CMOS), tak i přenosový protokol. Ve své podstatě totiž není SPI nic jiného než několik externě propojených posuvných registrů, přičemž posun je řízen jednotným hodinovým signálem. Jednoduchost přenosového protokolu vyplývá i z toho, že data jsou přenášena obousměrně po samostatných vodičích, takže není nutné řešit přepínání mezi vysíláním a příjmem, jako tomu bylo u některých sběrnic používajících poloduplexní přenos dat, i u dále popsané sběrnice I 2 C. I přenosová rychlost je pro mnoho účelů dostatečně vysoká. Hodinová frekvence, z níž se odvozuje bitová rychlost (bitrate), se v běžných případech pohybuje 29

30 v rozsahu 1 MHz až 10 MHz, při dodržení dostatečně malé kapacity spoje je však možné použít i poměrně vysokou frekvenci až 70 MHz, což odpovídá obousměrně přeneseným bitům za sekundu. Mezi nevýhody sběrnice SPI patří především existence pouze jednoho zařízení, které může pracovat v režimu master. Existuje sice možnost použít zapojení označované multiple master, ale to již vyžaduje použití složitějšího přenosového protokolu, takže se vytrácí jednoduchost celého řešení. Pomocí SPI je také možné přenášet data pouze na kratší vzdálenosti, což je dáno jednak nutností synchronizace hodinového signálu s přenášenými daty (shodné zpoždění), tak i neexistencí signálu typu ACK (acknowledge), kterým by se potvrzoval příjem dat a dovoloval tak řídit rychlost přenosu dat v případě, že některé zařízení nedokáže data rychle zpracovat. Další nevýhodou je fakt, že u SPI je možné použít několik způsobů synchronizace dat hodinovým signálem lze použít obě polarity hodin, synchronizovat na náběžnou či sestupnou hranu atd. Proto například mnoho mikrořadičů obsahuje konfigurační registry, pomocí nichž je možné zvolit, jakým způsobem se má hodinový signál generovat (master) či naopak interpretovat (slave). Poslední nevýhodou, která však kvůli komunikaci na menší vzdálenosti není tak patrná, je nutnost použít minimálně čtyři vodiče pro obousměrnou komunikaci SCK, MISO, MOSI a GND (signálová zem). Alternativní způsob zapojení (MISO a MOSI spojené do jednoho vodiče SISO) se příliš často nepoužívá. (Tišnovský, 2008) I 2 C Další sběrnice je označovaná poněkud neobvykle symbolem I 2 C, což je zkratka z celého názvu Inter-Integrated Circuit. V určitých ohledech se jedná o sběrnici podobnou SPI (existence hodinového signálu, jediný uzel typu master), ovšem některé vlastnosti těchto sběrnic jsou odlišné. Zatímco u sběrnice SPI byl umožněn obousměrný přenos dat díky použití dvojice vodičů MISO a MOSI, je sběrnice I 2 C vybavena pouze jedním datovým vodičem SDA, z čehož vyplývá, že se data přenáší poloduplexně. Také to znamená poněkud složitější interní strukturu všech připojených zařízení, protože příslušné piny musí být možné přepínat ze vstupního režimu na režim výstupní. Také zde není použit výběr zařízení typu slave pomocí zvláštních signálů, protože každému uzlu je přiřazena jednoznačná adresa kromě elektrických charakteristik je totiž přesně stanoven i komunikační protokol, což je další rozdíl oproti výše popsané sběrnici SPI. Obecně je možné říci, že I 2 C je sice poněkud složitější, ale zato flexibilnější sběrnice, která se velmi často používá i pro komunikaci na delší vzdálenosti (řádově metry - například DDC u monitorů), než tomu je u sběrnice SPI. (Tišnovský, 2008) 30

31 1-Wire 1-Wire je patentní systém komunikace s čidly a obecně zdroji krátkých informací (teploměry, vlhkoměry, identifikační čipy, hodiny, malé paměti, atd.) od Dallas Semiconductors (nyní Maxim). Jedno z obchodních jmen této technologie je ibutton a rutinně se používá v docházkových systémech. Jednoúčelové obvody firmy Dallas komunikující po 1-Wire sběrnici se v současné době vývoje mikroprocesorové techniky rozšířily i v naší zemi. Mezi nejznámější patří teplotní čidla rodiny DS18x20. Komunikace na sběrnici je asynchronní a poloduplexní, striktně dodržuje master/slave schéma. Zařízení typu slave může být připojeno více (řádově až stovky). Sběrnice je neaktivní v logické 1, což je zabezpečeno pull-up rezistorem. Všechna zařízení mají budič s otevřeným kolektorem, pomocí kterého mohou sběrnici stáhnout na logickou 0. Mohou být připojena prostřednictvím pouhých dvou vodičů - datového a zemnícího. V takovém případě se zařízení napájejí parazitně ze signálového vodiče. Pro vyšší spolehlivost lze použít zapojení třívodičové zem, napájení a signál. Komunikace je rozdělena do tzv. časových slotů, trvajících typicky 60 s. Jeden bit je přenesen během jednoho časového slotu. Master zahajuje veškerou komunikaci generováním sestupné hrany, kterou se synchronizují všechna slave zařízení. Na sběrnici jsou definovány čtyři základní operace: zápis 1, zápis 0, čtení a reset. ( 2005) ( 2004) NRF24L01+ Bezdrátový modul NRF24L01+ pracuje v nelicencovaném 2,4 GHz pásmu. Nejedná se ale o WiFi modul, jak by se na první pohled mohlo zdát, nýbrž o generický RF modul. Jak je patrné na následujících obrázcích, modul je možné sehnat ve dvou variantách, a to buď s anténou integrovanou na PCB, anebo s reverzním SMA konektorem pro připojení antény externí. Tím je možno dosáhnout vyššího zisku signálu a podstatným způsobem tak zvýšit dosah zařízení. 31

32 Obrázek 3 1: Bezdrátový modul NRF24L01+ Zdroj: ESP8266 ESP8266 je další z dostupných bezdrátových modulů, použitelných s mikrokontrolery Arduino. Tento je však oproti svému předchůdci již skutečně postaven na technologii WiFi. Frekvence modulu je opět 2,4 GHz. Vizuálně je modul velmi podobný NRF24L01+ a lze jej taktéž sehnat v provedení s integrovanou anténou, ale i v provedení s konektorem pro externí anténu. Obrázek 3 2: Bezdrátový modul ESP8266 Zdroj: Za velkou nevýhodu ESP8266 lze považovat právě technologii WiFi, kterou používá ke komunikaci. A to hlavně kvůli vysokému odběru proudu během aktivní komunikace, který dle specifikace činí asi 80 ma. 32

33 Naopak výhodou tohoto modulu je podpora zabezpečení přenosu dat prostřednictvím WPA a WPA2 protokolu. Během bližšího zkoumání funkcí tohoto modulu bylo dále zjištěno, že ESP8266 je vybaven 32bitovým čipem Tensilica Xtensa L106 a dokáže pracovat jako samostatná jednotka. Proto si tuto problematiku ještě více rozebereme v kapitole Arduino Nano, ESP8266 řídicí aplikace a spotřeba Arduino Nano Arduino Nano je mikrokontroler založený na čipu ATmega 328 (architektura AVR). Na desce chybí DC napájecí konektor, namísto toho je zde mini USB konektor. Provozní napětí je 5 V, rozsah vstupního napětí je 5 12 V. Nano disponuje programovou pamětí typu flash o velikosti 32 KB. Čip je v základu taktován na 16 MHz, ale tento takt je v rámci úspory energie možné snížit až na 1 MHz. Typická spotřeba během provozu činí dle specifikace 19 ma. Rozměry kontroleru jsou 18 x 45 mm. Obrázek 3 3: Mikrokontroler Arduino Nano Zdroj: Kvůli snížení spotřeby na minimum se počítá s uspáváním Arduina. Čip ATmega 328p podporuje pět režimů spánku, které budou podrobněji rozepsány v kapitole Implementace. Tato kapitola se bude detailně věnovat spotřebě celé soustavy. Podstatné je, že v nejúspornějším možném režimu spánku, tj. SLEEP_MODE_PWR_DOWN, lze mikrokontroler uspat nejdéle na osm sekund (proč tomu tak je, bude rozebráno rovněž v kapitole Implementace, v části zabývající se redukcí spotřeby). Po tuto dobu se zařízení tváří jako vypnuté, takže s ním nelze jakkoli komunikovat, avšak spotřeba energie klesne řádově až stokrát. Toto je velice důležitým faktem při stanovování celkové spotřeby systému a odhadu času, po který bude možné systém provozovat v rámci jednoho nabíjecího cyklu akumulátorů. 33

34 Osm sekund je naopak poměrně dlouhá doba, pokud se na věc díváme pohledem uživatele, který chce se systémem manipulovat. V nejhorším případě zmáčkne tlačítko těsně po uspání mikrokontroleru, takže server musí osm sekund čekat, než může klientu doručit zprávu příkaz. Teprve potom klient začne na příkaz reagovat, například pootočením žaluzií. Tato doba je dlouhá natolik, že v neinformovaném uživateli může vyvolat dojem, že systém nefunguje, jak by měl. V tomto projektu se však předpokládá jistá míra edukace uživatelů, alespoň pokud jde o podobné informace, spojené s chováním a ovládáním systému. Díky tomu, že je systém po probuzení aktivní jen několik desítek, maximálně stovek milisekund, a po tuto dobu jeho spotřeba nepřekročí 15 ma, tak lze uvažovat o zkrácení doby spánku z 8 sekund na 4 - případně i 2 sekundy by ještě měly být akceptovatelné. Po této úpravě by se reakční doba neboli odezva systému na příkazy uživatele podstatným způsobem zlepšila a systém by tak mohl budit dojem schopnosti téměř real-time operace. Uvedené odhady zatím nejsou podloženy praktickými zkušenostmi. Je proto nezbytné nejprve otestovat vliv délky intervalu spánku na celkovou výdrž akumulátorů. V ideálním případě se může stát, že se testováním zjistí přijatelnost i jednosekundového uspávání. Detailněji se celé problematice budeme věnovat v kapitole Implementace, kde bude mimo jiné provedeno měření spotřeby a na jeho základě také kalkulace odhadu doby provozu na jeden nabíjecí cyklus akumulátoru ESP8266 Jak již bylo řečeno dříve, ESP8266 může nabídnout mnohem více, než jen zprostředkování komunikace přes WiFi. Díky integrovanému 32bitovému procesoru, taktovanému v základu na 80 MHz, s možností přetaktování až na 160 MHz, a přítomnosti 16 GPIO pinů, lze toto zařízení používat i samostatně a plně tak nahradit například Arduino Nano. Ovšem pouze za předpokladu, že si vystačíme se 16 piny a 3,3 V provozním napětím modulu. Na první pohled se ESP8266 oproti NRF24L01+ jeví jako lepší varianta, stačí jednoduše nastavit WiFi připojení a pak už jen komunikovat. U druhého zmíněného modulu je komunikace mnohem složitější, řeší se pomocí různých knihovních funkcí a vyžaduje poměrně hodně vlastního programování. Ale o tom více až v kapitole Implementace. ESP8266 je bezpochyby lepší, ovšem jen do chvíle, než se vezme do úvahy také samotná spotřeba obou modulů. Díky integrovanému CPU je možné s ESP8266 zacházet podobným způsobem, jako s Arduinem, a to včetně využití jednoho ze čtyř režimů spánku. V tom nejhlubším možném 34

35 (zde se jedná o režim Power Off) tak lze dosáhnout snížení spotřeby dle specifikace až na 10 µa. Při použití akumulátoru o kapacitě 2000 mah by to teoreticky znamenalo výdrž neuvěřitelných 22 let. Tato spotřeba se však týká čistě jen fáze spánku, není v ní zohledněna aktivita modulu během doby, kdy je ze spánku probuzen. Po vzetí do úvahy spotřeby během aktivity se teoretická výdrž podstatným způsobem změní. Vezmeme opět modelový příklad spánku po dobu 8 sekund, po kterém se modul probudí a zkontroluje, zda pro něj má server nějaká užitečná data (příkazy, požadavky). U NRF24L01+ tato procedura může trvat desítky až maximálně pár set milisekund, během kterých odebírá kolem 15 ma proudu. ESP8266 je oproti tomu v mnohem horší situaci, a to především kvůli technologii WiFi: když modul spí, odpojí se od WiFi sítě. Po probuzení se k ní musí nejprve znovu připojit, než může zahájit komunikaci se serverem. Samotné znovupřipojení může trvat různě dlouho, v závislosti na tom, jestli na síti používáme DHCP protokol pro automatické přidělování adres nebo jsme na routeru IP adresu modulu nastavili ručně. Pro variantu s DHCP se čas potřebný pro připojení pohybuje v rozmezí 0,5 ~ 5 sekund. Staticky přidělená adresa znamená připojení k síti za 100 ~ 500 milisekund. Když zanedbáme samotnou komunikaci se serverem, která může trvat i jen několik málo milisekund, a také spotřebu 10 µa během spánku, která je oproti spotřebě během operace naprosto zanedbatelná, můžeme přibližný výsledek spočítat přibližně takto: ý ž á ů ě á ř, kde (1) Konkrétní výpočet: ř ř č í (2) ř, 4,6, (3) ý ž, 428,6 17,8. (4) Při výpočtu byly použity poměrně optimistické odhady - pouhých 500 milisekund trvající aktivita modulu mezi uspáními a počet uspání jen 7 za minutu. I přesto však maximální výdrž na jedno nabití akumulátoru dosahuje teoreticky jen necelých 18 dní. Závěr: modul ESP8266 nelze pro nízkoenergetické projekty s požadavkem na aktivní interakci doporučit. Pro projekt automatizace žaluzií je zcela nevhodný i přesto, že může plně zastoupit Arduino a kromě bezdrátové komunikace také řídit servo. Jeho energetická 35

36 náročnost je i přes dostupné režimy spánku příliš vysoká. Použití by se vyplatilo v situaci, kdy by stačilo modul probouzet ze spánku jen jednou za několik minut, kdy by například odeslal údaj o naměřené teplotě a poté opět přešel do spánku. Pak se může výdrž baterie pohybovat mezi půl rokem a rokem. To ale není případ tohoto projektu, kdy nelze nechat uživatele čekat dlouhé minuty od zadání pokynu na sklopení lamel žaluzií. 3.4 Raspberry Pi 3 Jedná se o minipočítač typu SoC (System on Chip), nepatrně větší, než kreditní karta. Srdcem systému je 64bitový čtyřjádrový procesor ARM Cortex-A53 od společnosti Broadcom, založený na architektuře ARMv8. Procesor má základní takt 1,2 GHz a je doplněný o 1 GB paměti RAM. Na desce je integrována WLAN, Bluetooth ve verzi 4.1, kombinovaný audio jack 3,5 mm, HDMI 1.3 konektor s podporou HDMI-CEC, 100 MBit LAN konektor, 4x USB 2.0 a 40 GPIO pinů. Dále je zde slot pro microsd kartu, ze které se spouští nainstalovaný operační systém. Nachází se zde také speciální konektory CSI (Camera Serial Interface) a DSI (Display Serial Interface) pro připojení originální Raspberry Pi kamery a různých druhů displejů, od černobílých 3,2 až po 7 oficiální kapacitně-dotykový. Obrázek 3 4: Raspberry Pi 3 Zdroj: 36

37 Pro Raspberry Pi 3 existuje několik základních druhů operačních systémů: Raspbian nejznámější a nejvíce používaná distribuce Linuxu pro ARM procesory, vychází z Debianu; Pidora vychází z desktopové linuxové distribuce Fedora; Arch Linux ARM distribuce Linuxu s vysokou mírou customizace, ovšem nepříliš vhodný pro začátečníky vše se instaluje ručně, včetně grafického rozhraní; OpenELEC / XBMC / KODI multimediální centrum postavené opět na Linuxu; Windows 10 IoT Core jádro Windows 10 určené pro IoT, nemá desktop rozhraní, pouze terminál. 3.5 Seznam komponent a materiálu Následující seznam obsahuje všechny důležité součásti, ze kterých se prototyp chytrého ovládání žaluzií skládá: 1) Arduino Nano (2 ks), 2) Nordic Semiconductor NRF24L01+ (2 ks), 3) AA NiMH akumulátor 2000 mah (4 ks), 4) držák AA baterií, 5) mikro servomotor (modelářský), 6) NPN tranzistor, 7) mini USB konektor, 8) propojovací kabely mezi GPIO piny Arduina a periferie, 9) Adafruit TSL2591 High Dynamic Range Light Sensor, 10) držák servomotoru do konzole, 11) plastová hmoždinka o průměru 6 mm, 12) modelářské sekundové lepidlo, 13) smršťovací bužírka a další drobné příslušenství. 3.6 Seznam pomůcek Seznam nástrojů a nářadí, potřebných v průběhu realizace prototypu systému: 1) multimetr, 2) pájecí stanice, 3) horkovzdušná pistole, 37

38 4) modelářský skalpel, 5) 3D tiskárna, 6) počítač. 3.7 Doménový model Obrázek 3 5: Doménový model Zdroj: vlastní úprava (autor) 3.8 Předběžná kalkulace nákladů V následující tabulce jsou uvedeny odhadované pořizovací náklady na systém. Jedná se jen o cenu materiálu a použitých komponent práce, energie ani jiné faktory nejsou započítány. Kalkulace je vyhotovena ve dvou variantách: cena za jedno okno a celková cena za systém. Pro výpočet celkové ceny byl zvolen scénář použití v typickém třípokojovém bytě s celkem devíti okny. 38

39 Tabulka 3-1: Předběžná kalkulace nákladů na systém Položka cena za kus počet kusů cena celkem poznámka Arduino Nano 180 Kč Kč NRF24L Kč Kč Servomotor 200 Kč Kč AA NiMH aku 120 Kč Kč cena za kus = cena za balení 4ks Držák 4 AA baterií 30 Kč Kč TSL2591 světelný senzor 240 Kč Kč NPN tranzistor 2N Kč 9 18 Kč Mini USB konektor 15 Kč Kč Raspberry Pi Kč Kč MicroSD karta 16 GB 300 Kč Kč 7" dotykový displej 2090 Kč Kč Displej k Raspberry Pi oficiální Rámeček displeje 390 Kč Kč Zdroj 5V, 3A 290 Kč Kč Cena za okno 847 Kč bez Raspberry Pi 3 a příslušenství Cena za kompletní systém Kalkulace - byt 3+1 s devíti okny Kč Zdroj: vlastní úprava (autor) Výše uvedené ceny jsou reálné za tyto ceny byly jednotlivé komponenty skutečně nakoupeny. Poznámka: v kalkulaci je již zahrnut minipočítač Raspberry Pi 3 s displejem a základním příslušenstvím. Pro nasazení do skutečného uživatelského prostředí (domácnosti) je nezbytný k zajištění komfortu obsluhy systému. Nahrazuje tak druhé Arduino Nano, použité při testování prototypu okenního klientského prvku, které sloužilo jako zjednodušená serverová strana. 39

40 4 Implementace 4.1 Fyzické zapojení V této podkapitole je uvedeno rozložení pinů Arduina a bezdrátového modulu NRF24L01+. Je zde také vyobrazeno schéma zapojení celého systému, které bylo navrženo za použití opensource programu Fritzing Rozložení pinů Arduino Obrázek 4 1: Arduino Nano, schéma rozložení pinů Zdroj: 40

41 4.1.2 Rozložení pinů NRF24L01+ Obrázek 4 2: NRF24L01+, schéma rozložení pinů Zdroj: Popis a využití jednotlivých pinů je následující: GND zem. Tento pin se propojí s GND pinem Arduina; VCC kladný napájecí pin. NRF24L01+ toleruje napětí v rozmezí 1,9 3,6 V. Toto vstupní napětí se nesmí překročit, jinak se modul nenávratně poškodí. To v praxi znamená, že modul nelze napájet z 5V pinu Arduina, ale pouze z pinu označeného 3V3 ; CE Chip Enable. CSN Chip Select. SCK Serial Clock MOSI Master Output Slave Input. MISO Master Input Slave Output. IRQ Interrupt Request Schéma zapojení Obrázek 4 3: Náčrt systému Zdroj: vlastní úprava (autor) 41

42 Obrázek 4 4: Schéma zapojení Zdroj: vlastní úprava (autor) 4.2 Napájení z baterií V této podkapitole se zaměříme na to, jakým způsobem je možné mikrokontroler typu Arduino provozovat bez potřeby vedení napájecích kabelů od zdroje (zásuvka s 230 V 5 V transformátorem s USB konektorem) až k samotnému plánovanému umístění kontroleru. To může být značně nepraktické a většinou i z estetických důvodů nerealizovatelné, zejména kvůli nutnosti zasekat napájecí kabel pod omítku a následně vše uvést do původního stavu: drážku s kabelem znovu vyplnit hmotou, omítnout, vymalovat. V případě jednoho instalovaného kusu to ještě může být únosné, ale při větším počtu zařízení, umístěných různě po bytě nebo domě, je realizace obtížnější a navyšuje pořizovací náklady. Z toho důvodu je pro úspěch projektu zcela zásadní vyřešit daný problém jiným způsobem, a to napájením pomocí baterií nebo dobíjecích akumulátorů. 42

43 Teoretických možností, který druh baterií zvolit, se nabízí hned několik, avšak jen jedna je vzhledem ke specifikům projektu vhodná. Možnost 1: Lithium-polymerové akumulátory. Jejich nominální napětí je 3,7 V na článek. Plně nabitý článek má přibližně 4,2 V. Nedoporučuje se vybíjet pod 3,3 V na článek, vybití na méně než 3 V může způsobit nenávratné poškození článku. Provozní rozsah mikro servomotoru je 4,8 V 6,0 V, proto jednočlánkový akumulátor pro tyto účely nestačí. Akumulátor složený ze dvou článků má však již provozní napětí v rozsahu 7,4 V 8,4 V. Tyto hodnoty jsou také nevyhovující, jsou příliš vysoké, a to kvůli fyzicky odstraněnému regulátoru napětí (vysvětleno v podkapitole Spotřeba energie). Maximální hodnota vstupního napájecího napětí nesmí překročit 5,5 V, jinak právě kvůli vyřazenému regulátoru reálně hrozí zničení celého mikrokontroleru. Kapacita Lithium-polymerových akumulátorů může být i několik Ah, je ale přímo úměrná jejich velikosti a hmotnosti. Například, pokud tříčlánkový akumulátor s kapacitou 4000 mah má rozměry 120 x 40 x 30 mm a váží kolem 340 gramů, potom tříčlánkový akumulátor o kapacitě 8000 mah může mít rozměry 180 x 65 x 40 mm a hmotnost přes 650 gramů. Výhody: Lithium-polymerové akumulátory vynikají svou schopností konstantně dodávat velmi vysoké proudy a zároveň absencí paměťového efektu. Nevýhody: Nutnost akumulátory chránit před hlubokým vybitím, jinak hrozí jejich zničení. Také jsou poměrně drahé. Shrnutí: Tento typ akumulátoru je pro podobné účely nevhodný a nelze jej tedy doporučit. Pro tento konkrétní projekt je pak naprosto nepoužitelný. Možnost 2: Lithium-iontové akumulátory. Mají velice podobné parametry, jako Lithiumpolymerové. Výhody: Lithium-iontové akumulátory nemají paměťový efekt a mají poměrně vysokou životnost, až přes tisíc nabíjecích cyklů. Nevýhody: Podobně jako Lithium-polymerové, i Lithium-iontové akumulátory se mohou poškodit, pokud jejich napětí klesne pod 3 Volty na článek. Jsou drahé. 43

44 Shrnutí: Ani tento typ akumulátoru není pro projekt vhodný, a to především kvůli nevyhovujícím hodnotám napětí, které nabízí. Možnost 3: Jednorázové alkalické baterie. Poskytují napětí kolem 1,5 V na článek, jejich formát je standardizován, typické jsou velikosti AA nebo AAA. Kapacita se může lišit v závislosti na výrobci a typu baterie. Výhody: Tyto baterie jsou poměrně levné, výhodou jsou tedy nízké pořizovací náklady. Nevýhody: Nemožnost opakovaného použití baterií. Ale především jejich napětí 1,5 V na článek, kdy při použití tří článků lze dosáhnout napětí pouze 4,5 V to není dost pro provoz servomotoru. Při použití čtyř článků se napětí pohybuje nad hranicí 6 Voltů hodnota, která je pro servomotor v pořádku, ale pro samotný mikrokontroler bez funkčního regulátoru napětí je likvidační. Shrnutí: Příznivá cena těchto baterií by měla být motivací k jejich použití, avšak kvůli nevyhovujícím hodnotám napětí je stejně jako předešlé Lithiové akumulátory nelze použít. Možnost 4: Akumulátory typu NiCd a NiMH. Poskytují nominální napětí 1,2 V, plně nabité mají kolem 1,35 V na článek. Formát může být různý, ale nejobvyklejší provedení je stejně jako u jednorázových baterií typ AA, a také menší verze AAA. Kapacita článků může být různá, v AAA variantě lze běžně zakoupit akumulátory o kapacitě 700 mah, ve velikosti AA jsou pak k dostání kapacity od 2000 do 2800 mah. Výhody: Možnost opakovaného použití, poměrně příznivá cena, velikost akumulátorů a dostupné příslušenství (držáky a podobně). Největší výhodou je, že při použití čtyř kusů akumulátoru lze dosáhnout napětí v plně nabitém stavu asi 5,35 V, tedy pod kritickou hranicí. To je zároveň příznivá hodnota pro provoz servomotoru. Ve vybitém stavu pak napětí klesne pod 1,1 V na článek, a tedy pod 4,4 V na soustavu. Paměťový efekt, který je obecnou nevýhodou těchto typů akumulátorů, je zde naopak užitečnou vlastností, protože článkům nejen že hluboké vybíjení neškodí, ale naopak jim prospívá. Paměťový efekt se díky tomu nemůže projevit a jejich životnost ani kapacita tím netrpí. 44

45 Pro použití v projektech s nízkým odběrem proudu a potřebou dlouhé životnosti baterie jsou tak naprosto ideální. Nevýhody: Paměťový efekt, který však mají NiMH akumulátory méně výrazný než NiCd varianta. Shrnutí: Tyto typy akumulátorů, zejména pak typ NiMH, byly shledány velice vhodnými, ba téměř ideálními pro daný účel použití. Doporučují se proto k využití i v jiných podobných projektech s požadavky na dlouhodobý, energeticky nenáročný chod systému, kde je časté dobíjení a péče o akumulátory nežádoucí. Tímto je vyřešen hlavní problém týkající se napájení volba vhodného druhu baterií. Nyní zbývá vybrat požadovanou velikost NiMH článků, tomu odpovídající obal a následně celý takto vytvořený akumulátor připojit k Arduinu. Co se týče velikosti, jsou na výběr dvě základní varianty. Těmi jsou všeobecně známé formáty AA, resp. menší AAA. Druhá zmíněná velikost by byla rozměrově vhodnější, snáze by se integrovala do horní lišty žaluzií. Jenže neopomenutelným faktem zůstává přibližně třetinová kapacita AAA akumulátorů oproti typu AA. Proto byla pro tvorbu a testování prototypu zvolena velikost AA i přes její nevýhodné rozměry. Držáky AA baterií jsou k dostání v několika možných rozloženích: 1) čtyři baterie v řadě za sebou, držák tak tvoří tvar dlouhého úzkého válce, 2) dva krát dva dvě baterie vedle sebe a nad sebou, 3) dva krát dva dvě baterie vedle sebe a za sebou. Po delší úvaze byla zvolena druhá možnost, přičemž vhodné by mohlo být i válcové rozložení typu čtyři krát jedna. Poslední záležitostí je připojení k Arduinu. Na straně akumulátorů je připojení dáno držákem. Ten nabízí konektor stejný, jaký používají devítivoltové baterie. Na straně Arduina je situace složitější. Za normálních okolností by bylo možné jednoduše přivést kladný vodič na VIN pin Arduina a záporný pak na GND pin. Toto zapojení však nemůže fungovat kvůli vyřazenému regulátoru napětí (bude vysvětleno později). Proto jediným způsobem, jak mikrokontroler v tomto stavu externě napájet, je využít jeho USB připojení. 45

46 Bylo tedy nutné zakoupit samostatný pětipinový mini USB konektor a kabel se dvěma vodiči a konektorem kompatibilním s devítivoltovou baterií. Samotné zapojení pak probíhalo jednoduše, stačilo připájet kladný a záporný vodič na odpovídající piny mini USB konektoru a zbývající dva datové piny nechat bez povšimnutí. Samozřejmé je použití smršťovací bužírky pro izolaci v místech, kde je to třeba. Takto sestavený akumulátor s konektorem již jen stačilo pro ověření funkčnosti řešení připojit k mini USB portu Arduina a zkontrolovat jeho činnost pomocí indikačních LED diod, integrovaných na mikrokontroleru. 4.3 Spotřeba energie Typická spotřeba mikrokontroleru Arduino samotné, pokud k němu nejsou připojeny žádné další prvky a pokud není v jednom z režimů spánku, má spotřebu přibližně 19 ma (dle vlastního měření multimetrem). To potvrzuje spotřebu uvedenou v oficiální specifikaci. Změna spotřeby v závislosti na použitém režimu spánku bude rozebrána níže. Autor této práce se také zabýval vztahem spotřeby energie a kódu, běžícího uvnitř mikrokontroleru. K tomu využil svůj vlastní programový kód napsaný v jazyce C. Ten by měl čip zatížit dostatečně na to, aby bylo možné učinit závěry o vlivu složitosti kódu programu na spotřebu. Referenční spotřeba 19 ma byla naměřena při spuštěné prázdné loop smyčce, nevykonával se tedy žádný kód. Po nahrání programu a zopakování měření nebyl zjištěn rozdíl ve spotřebě. Lze tedy prohlásit, že složitost spouštěného programového kódu nemá žádný, anebo téměř žádný vliv na aktuální spotřebu Arduina. Když však k Arudinu připojíme další prvek, spotřeba se může dramaticky změnit, v závislosti na charakteru onoho prvku. Například servomotor, zapojený na piny Arduina způsobí, že se spotřeba v klidu, tj. při neaktivitě servomotoru, zvýší asi o 7 ma. V zátěži, během operace servomotoru pak spotřeba činí několik stovek ma Prvky s největším odběrem proudu Servomotor Jedná se o součástku používanou převážně v RC modelářství. Servo má integrované převody a hřídel, kterou lze otáčet a nastavovat na přesně danou pozici úhel. Obvyklý rozsah otáčení servomotorů je od 0 do 180, existují však i serva s rozsahem 360 a více. Servomotor má 46

47 tři vodiče: napájecí kladný (obvykle červený), záporný (obvykle černý) a signální (většinou žlutý nebo bílý). Běžný provozní rozsah napájení serva je 4,8 V 6,0 V. Obrázek 4 5: Servomotor EMAX Zdroj: Během operace servomotor spotřebovává až několik stovek ma. I při nečinnosti ale odebírá trvale kolem 7 ma. Čip ATmega V běžném provozu má Arduino jako celek spotřebu kolem 19 ma. Po odečtení dílčí spotřeby regulátoru napětí a indikační LED diody se dostáváme na hodnotu 13,5 ma pro samotný čip a jeho přidružené součásti. Regulátor napětí Trvale odebírá proud v rozmezí 2 až 5 ma, v závislosti na připojeném zdroji. Regulátor má za úkol stabilizovat vstupní napětí, které může být v rozsahu 5 12 V, na napětí 5 V, což je provozní napětí čipu ATmega 328p a ostatních komponent na desce. Čím vyšší je vstupní napětí, tím více je regulátor zatěžován, zahřívá se a spotřebovává více proudu jen pro svůj vlastní provoz. Konkrétní typ regulátoru LM1117, použitý na deskách Arduino Nano, má vcelku nevýhodnou vlastnost. I když je hodnota vstupního napětí 5 V, a regulátor tak nemusí napětí usměrňovat, stále sám spotřebovává přibližně 2 ma. 47

48 Indikační LED dioda Tato zelená dioda je napojena přímo na napájecí obvod. To znamená, že pokud je Arduino napájeno, tak trvale svítí. Nelze ji nijak softwarově vypnout. Diodou odebíraný proud se pohybuje kolem 3,5 ma. Shrnutí graf podílu spotřeby prvků Graf 4-1: Poměr spotřeby jednotlivých prvků vůči celku 13% 8% 27% servomotor Atmega 328p regulátor LM1117 LED dioda 52% Zdroj: vlastní úprava (autor) Režimy spánku Arduino Nano nabízí pět různých režimů spánku, které lze využít k úspoře energie. Zde jsou uvedeny a seřazeny podle míry úspory od nejmenší po největší: Režim 1: SLEEP_MODE_IDLE Režim 2: SLEEP_MODE_ADC Režim 3: SLEEP_MODE_PWR_SAVE Režim 4: SLEEP_MODE_STANDBY Režim 5: SLEEP_MODE_PWR_DOWN 48

49 4.3.4 Redukce spotřeby Servomotor Tato komponenta systému se poměrně velkou měrou podílí na celkové spotřebě energie. Se spotřebou během otáčení servomotoru nelze příliš mnoho dělat, maximálně zakoupit jiný, méně výkonný typ. V každém případě, při otočení serva dvakrát za den (ráno a večer) se z akumulátoru za rok provozu spotřebuje méně, než 500 mah kapacity. To je poměrně málo a rozhodně jde o přijatelnou hodnotu. Pojďme se tedy nyní zaměřit na druhý parametr, který je z hlediska dlouhodobého provozu mnohem významnější tím je spotřeba energie v klidovém stavu. Servo samotné, v čase, kdy nepracuje a jen je zapojeno do soustavy, kontinuálně odebírá asi 7 ma. To je způsobeno samotným principem funkce tohoto typu pohonu, servo totiž nepracuje jen zdánlivě. Ve skutečnosti však nepřetržitě drží pozici, nastavenou signálovým vodičem. Toto je možné jednoduše ověřit pokud bychom se pokusili táhlem či límcem nasazeném na hřídeli serva pootočit, motor nám bude klást odpovídající odpor a to ve směru proti námi působené síle. I kdyby se nám podařilo hřídelí více pohnout, servo ji okamžitě vrátí zpět do původní pozice. Po úvaze, jak tento problém řešit, bylo jako nejlepší možnost zvoleno použití tranzistoru typu NPN, konkrétně typ 2N4401. Obrázek 4 6: NPN tranzistor, typ 2N4401 (TO-92) Zdroj: Tento tranzistor pracuje tak, že je ve výchozím stavu zavřený. Pokud je však na hradlo přiveden signál, tranzistor se otevře. Řešení tak bylo poměrně jednoduché. Spočívalo 49

50 v propojení kladného 5V pinu Arduina (nebo kladného pólu přímo z akumulátoru) na kolektor tranzistoru a kladného vodiče servomotoru na emitor. Pin Arduina, kterým chceme tranzistor otevírat, se pak připojil na bázi. Důsledkem tohoto řešení je, že pokud chceme nyní se servomotorem pracovat, musíme nejprve přivést logickou 1 na pin Arduina, který jsme propojili s bází tranzistoru. Tím je servomotor připojen k napájení a lze jím otáčet. Po dokončení činnosti servomotor opět odpojíme. Arduino a čip ATmega Jak již bylo zmíněno, Arduino nabízí celkem pět možných úrovní spánku, díky kterým lze spořit energii. Úrovně se mezi sebou liší měrou úspory i způsobem, jakým jí Arduino dosahuje. Obecně lze říci, že v závislosti na použitém režimu mikrokontroler vypíná různé prvky svého systému. Které prvky to jsou a v jakém stavu se nacházejí při daném režimu spánku, lze vidět v následující tabulce: Tabulka 4-1: Režimy spánku Arduina s vyznačením aktivních prvků systému Zdroj: Z tabulky je i bez hlubšího zkoumání patrné, že největší úsporu energie poskytuje režim SLEEP_MODE_PWR_DOWN. Hlavní čip ATmega je v tomto režimu úplně vypnutý, stejně tak oscilátory timer a zdroj hodinového signálu. To má mimochodem za důsledek, že pokud v našem programu používáme nějakou funkci operující s časem, pak během trvání spánku 50

51 je počítání času pozastaveno. Toto lze kompenzovat po probuzení například úpravou časové proměnné přičtením času, po který systém spal. Takové řešení však není příliš přesné vzhledem k nepatrným odchylkám v kmitočtu krystalového 128 khz oscilátoru u jednotlivých kusů mikrokontroleru. Oscilátorem se řídí WDT časovač, který má na starosti probouzení kontroleru po nastavené době spánku. Díky drobné odchylce v kmitočtu oscilátoru ale tato doba nikdy není přesná, například pokud nastavíme nejdelší možný interval 8 sekund, ve skutečnosti se může čip uspávat na 8,02 sekundy a podobně. WDT neboli Watchdog Timer je při použití SLEEP_MODE_PWR_DOWN velice důležitý, kromě možnosti využití externího přerušení (Interrupt) přivedeného na pin INT0 nebo INT1 se totiž jedná o jediný způsob, jak kontroler probudit ze spánku. WDT pracuje tak, že po odpočítání určitého počtu cyklů krystalu odešle požadavek na přerušení (IRQ, Interrupt Request). Kromě WDT je v tomto režimu spánku aktivní ještě funkce hlídající případné podpětí (BOD, Brown-Out Detection). Podpětí může být například způsobené přílišným vybitím akumulátoru během provozu mikrokontroleru a stejně jako napětí přesahující provozní limit čipu, může být i toto poměrně nebezpečné. BOD má za úkol takový stav včas detekovat a zareagovat okamžitým vypnutím Arduina. Přestože existuje způsob, jak BOD ochranu vyřadit z provozu, vzhledem k velice malé úspoře energie, kterou toto opatření přináší, je lepší ponechat tuto ochranu zapnutou. Případná úspora by totiž činila jen ~20 µa. Regulátor napětí Toto je z hlediska spotřeby energie další velice zajímavá komponenta. Na obrázku je jeho umístění zvýrazněno červeně. Obrázek 4 7: Arduino Nano v3.0, spodní strana Zdroj: Regulátor napětí, použitý výrobcem u mikrokontrolerů Arduino Nano, tedy typ LM1117, nepatří k příliš efektivním. I když není v zátěži, napětí přivedené na vstup je v rozsahu 51

52 provozního napětí a regulátor tak nevykonává téměř žádnou práci, trvale spotřebovává minimálně 2 ma proudu. Jednou z cest, jak spotřebu této komponenty snížit, by jistě byla výměna regulátoru za některý z efektivnějších typů. V kontextu zjištění, že napájení Lithium-polymerovými akumulátory není kvůli hrozbě jejich hlubokého vybití (a tedy poškození) vhodné, byla zvolena cesta napájení akumulátory typu NiMH. Při použití čtyř článků na jeden akumulátor nepřesáhne napětí akumulátoru 5,5 Voltu ani při plném nabití. Díky tomu, že se napětí pohybuje pod horním limitem provozního napětí mikrokontroleru, je možné Arduino napájet přímo z akumulátoru, regulátor napětí není potřeba. Toto byl jednoznačně snazší způsob, jak vyřešit problém odběru proudu regulátorem, než jej složitě nahrazovat jiným typem, který, ač by byl úspornější, tak by stále odebíral energii navíc. K přímému napájení Arduina z akumulátoru stačilo s pomocí pájecí stanice fyzicky vyřadit regulátor z provozu. V ten moment však bylo zjištěno, že již nelze připojit akumulátor přímo na vstupní GND a VIN piny, jako doposud. Signál z těchto pinů vede přímo přes regulátor a jeho odpojením došlo k přerušení obvodu, proto bylo nezbytné hledat jinou cestu, jak Arduinu zajistit napájení. V této fázi, kdy byl již regulátor nenávratně vyřazen z činnosti, nezbývalo než ověřit, zda stále funguje připojení k počítači skrze mini USB konektor. Zřejmě díky faktu, že je USB standardizováno na nominální výstupní napětí 5 Voltů, je Arduino navrženo k napájení přes USB napřímo. Proto tento způsob připojení fungoval. To vedlo ke zjištění, že toto je jediná cesta, jak nyní mikrokontroler připojit ke zdroji energie. Následoval průzkum možností, na jehož konci bylo zakoupení několika kusů samostatných 5pinových mini USB konektorů. Obrázek 4 9: Mini USB konektor Obrázek 4 8: Zapojení mini USB konektoru Zdroje:

53 Na obrázku vpravo je vidět rozložení pinů mini USB konektoru. Na jeho základě byl připojen kladný vodič z akumulátoru na levý krajní pin a záporný vodič na pravý krajní pin (GND, Ground). Prostřední datové piny mohou zůstat nevyužity, pro účely čistě jen napájení Arduina je nepotřebujeme. Indikační LED dioda Tato zelená dioda je jedna z celkem čtyř diod, přítomných na vrchní straně Arduina. Účel těchto diod je následující: TX červená dioda, je aktivní při odesílání dat přes sériovou linku (USB); RX červená dioda, je aktivní při přijímání dat přes sériovou linku (USB); PWR / ON zelená dioda (ona zmíněná indikační), při přítomnosti napájení svítí nepřetržitě; L červená dioda, kterou lze ovládat skrze pin 13, resp. softwarově skrze přivedení logické 1 na tento pin. Zde je v programovém kódu klientského mikrokontroleru nastavena tak, aby se při každém probuzení Arduina krátce rozsvítila (na 100 ms) a signalizovala tak, v který moment je Arduino aktivní. Toto se může hodit zejména při vývoji a ve fázi testování. Zelenou PWR diodu bylo nutné kvůli jejímu konstantnímu odběru proudu přibližně 3,5 ma fyzicky odstranit. K odstranění postačovalo použití pájecí stanice a pinzety. Jeden z kontaktů diody se hrotem mikropáječky nejprve nahřál na teplotu přes 300 C a následně se dioda na této straně pinzetou zvedla z desky směrem vzhůru. Tento zákrok, i přes šetrné provedení a použití pinzety však vedl k nenávratnému poškození diody, a to kvůli její miniaturní velikosti. To pro účely tohoto projektu není na škodu, dioda zde neplní žádný praktický účel. Důležité je úspěšné snížení spotřeby celku o další 3,5 ma Výsledek Po všech předchozích dílčích krocích následovalo ověření funkce takto upraveného mikrokontroleru spolu s akumulátorem a kontrolní měření odebíraného proudu. Arduino se po připojení mini USB konektoru od akumulátoru ihned uvedlo do provozu. Tato část se tedy podařila. Následuje měření odběru proudu. Během spánku Arduina byla naměřena hodnota jen 190 µa. Pouze při aktivitě kontroleru byla spotřeba vyšší. Díky tomu, že je tato aktivní fáze mezi 53

54 jednotlivými spánkovými cykly velmi krátká, nijak dramaticky dosaženou celkovou výdrž neovlivní. Doba výdrže byla počítána dle vzorce (1) z kapitoly 3: (5) (6) Pokud uvažujeme jen spotřebu během spánku a probouzení zanedbáme, stejně jako samovybíjení akumulátoru a další faktory, potom výdrž na jeden nabíjecí cyklus akumulátoru při uvažované kapacitě 2000 mah je nyní 438 dnů, to je 1,2 roku (t 1 ). Původní referenční výdrž bez úprav a zásahů byla přesně stonásobně nižší, tedy necelých 4,5 dne (t ref ). Graf 4-2: Graf spotřeby dle úprav [ma] referenční spotřeba (bez úprav) s tranzistorem tranzistor + spánek tranzistor + spánek + vyřazení regulátoru tranzistor + spánek + vyřazení regulátoru + odstranění diody Zdroj: vlastní úprava (autor) 54

55 Graf 4-3: Graf výdrže akumulátoru dle úprav [dny] referenční výdrž (bez úprav) s tranzistorem tranzistor + spánek tranzistor + spánek + vyřazení regulátoru tranzistor + spánek + vyřazení regulátoru + odstranění diody Zdroj: vlastní úprava (autor) Faktory ovlivňující průměrnou spotřebu a výdrž V předcházejících odstavcích jsme uvažovali jen spotřebu upraveného Arduina během spánku, probouzení jsme kvůli snazšímu porovnání nezohlednili. Nyní se však zaměříme na celkovou spotřebu včetně fáze aktivity, která má také jistý vliv na výsledek. Tři hlavní faktory, které v tomto hrají roli, jsou tyto: délka uspávání; délka trvání jednoho cyklu aktivity (50, 100, 200 ms apod.); kapacita akumulátoru. Dohromady by se dalo vztah těchto tří faktorů přirovnat k magickému trojúhelníku ve fotografii, kde jak doba osvitu snímače, tak i nastavená clona objektivu a citlivost na světlo, hrají svou roli a přímo ovlivňují výslednou expozici snímku. Délka uspávání čím delší je jeden spánkový cyklus Arduina, tím méně často se vykonává programový kód v loop části programu. Doba trvání aktivity tento parametr říká, kolik času je potřeba pro vykonání kódu, než je možné Arduino opět uspat. Tuto část ovlivňuje především princip komunikace mezi bezdrátovými moduly NRF24L01+, kde je nutné nejprve odeslat zprávu serveru a poté 55

56 počkat, než přijde odpověď. Toto trvá minimálně několik desítek milisekund. Celý časový úsek, po který je Arduino aktivní, lze vynásobit průměrnou spotřebou. Ta během aktivity dosahuje až 20 ma. Skládá se jednak ze spotřeby Arduina (ta má bez regulátoru, diody a s odpojeným servomotorem hodnotu přibližně 6,5 ma), jednak ze spotřeby bezdrátového modulu, který dle specifikace potřebuje přibližně 14 ma během vysílání či příjmu zprávy. Kapacita akumulátoru faktor, který také značnou měrou ovlivňuje celkový výsledek. V této práci počítáme ve všech příkladech s typickou kapacitou dobíjecích NiMH akumulátorů velikosti AA, která činí 2000 mah. Pokud bychom ale použili akumulátory jiného typu, například NiMH s atypickou velikostí, lze se dostat na kapacitu přesahující 3000, případně až 4000 mah. Tomuto je však již potřeba přizpůsobit celkový koncept zástavby do horní žaluziové konzoly, kam se širší články než AA již nevejdou. 4.4 Programová část O jazyce Wiring Programovací jazyk, v němž lze psát kód pro Arduino, se jmenuje Wiring. Podle autorů jde o jazyk podobný C++ ve skutečnosti je to jakýsi metajazyk či vylepšená sada maker nad C++. Wiring původně vznikl pro vývojový kit podobný Arduinu a vychází z dalšího open source projektu, který se jmenuje Processing. Návrh sledoval maximální jednoduchost a srozumitelnost pro programátora, co s jednočipy začíná: Syntakticky lze použít všechny návyky z C-like jazyků. To znamená složené závorky, středníky, definice funkcí a proměnných, poznámky, bloky i řídicí konstrukce to vše se zde používá stejným způsobem, jako při psaní kódu v C. (Malý, 2010) Programový kód pro Arduino musí obsahovat dvě povinné funkce, a sice setup a loop. Setup slouží k inicializaci a různému nastavení při spuštění mikrokontroleru. Jakmile se zde přítomný kód vykoná, automaticky se přejde do vnitřní části funkce loop. Ta představuje pouze smyčku, která se vykonává stále dokola po celou dobu běhu Arduina, takže se vlastně podobá konstrukci while (true), ovšem s rozdílem, že z loop smyčky nelze skočit ven použitím příkazu break. Do prostoru mimo tyto dvě funkce lze samozřejmě napsat funkce vlastní, které je možné libovolně volat, ať už jednorázově z funkce setup, nebo opakovaně z loop. 56

57 4.4.2 Arduino IDE Úspěch Arduina a jeho velké rozšíření není jenom díky zajímavému hardwaru, ale především jednoduchému vývojovému prostředí (zkráceně IDE, což doslova znamená Integrated Development Environment). Arduino IDE je aplikace, která nám umožní jednoduše s deskou Arduino pracovat. Obrázek 4 10: Arduino IDE Zdroj: vlastní úprava (autor) Arduino IDE obsahuje mimo jiné textový editor a několik tlačítek, které slouží k překladu (verify) a následnému nahrání kódu do Arduina (upload). Dále je součástí prostředí nástroj serial monitor, který umožňuje jednoduchou komunikaci s Arduino deskou na straně hardware k tomuto účelu pak slouží knihovna Serial. ( 57

58 4.4.3 Použité knihovny Knihovny jsou předpřipravené balíčky kódu, které základní program rozšiřují o nějakou funkcionalitu (například možnost ovládat specifický hardware, jako LCD displeje a podobné). Servo.h Tato knihovna umožňuje ovládat skrze Arduino malé servomotory, většinou určené pro RC modelářství. Na Arduino deskách podporuje až 12 připojených servomotorů. sleep.h Knihovna obsahující všechna důležitá volání a makra pro uvedení Arduina do režimu spánku. Podporuje všech pět režimů, do kterých lze mikrokontroler uspat. power.h a LowPower.h Tyto knihovny se týkají redukce spotřeby Arduina. Skrze vestavěné funkce a makra umožňují snáze přistupovat k zabudovaným součástem mikrokontroleru a dle potřeby je zapínat nebo vypínat. wdt.h Zde je definováno rozhraní pro inline makra, kterými lze ovládat Watchdog Timer Arduina a nastavovat různé parametry. RF24.h Tato knihovna poskytuje rozhraní pro komunikaci skrze bezdrátový modul NRF24L01+, včetně přepínání režimů naslouchání (RX) a vysílání (TX). String.h V této knihovně jsou obsaženy konstrukce potřebné pro zacházení s datovým typem String. Použití se velice podobná knihovně string.h a datovému typu string v jazyce C++. SPI.h Knihovna pro komunikaci skrze datový protokol sběrnice Serial Peripheral Interface (SPI). Wire.h Díky této knihovně lze využít také komunikaci se zařízeními prostřednictvím rozhraní I 2 C a TWI. 58

59 Adafruit_Sensor.h Knihovna pro interakci s různými druhy a typy senzorů, od akcelerometrů, gyroskopů, přes senzory teploty, vlhkosti a tlaku až po v tomto projektu použitý senzor hladiny osvětlení. Adafruit_TSL2591.h Tato knihovna je určena pro senzor osvětlení konkrétního typu TSL Ovládání servomotoru Po vytvoření objektu typu Servo je motor ovládán funkcí s názvem controlservo, vlastnoručně navrženou a implementovanou. Tato funkce umožňuje dle vstupního parametru otočit servem o plný rozsah 180 (jedním či druhým směrem) nebo pootočit o určitý úhel délka kroku může být 15, 30, případně Čtení hodnot ze senzoru osvětlení Komunikace se senzorem započne voláním tsl.begin( ). Funkce displaysensordetails má na starost detailní výpis údajů o senzoru. Ve funkci configuresensor je provedeno nastavení senzoru. Funkci advancedread pak v projektu používáme pro samotné čtení hodnot. Výsledek v Luxech je pak jako výstupní parametr funkce předán dál Posílání zpráv mezi klientem a serverem Toto je řešeno funkcemi sendmessage pro odeslání zprávy a getreply pro její příjem. Tyto funkce v základu používají volání knihovních funkcí z RF24.h, obsahují však úpravy a rozšíření nezbytné pro chod systému s ohledem na uspávání klientských prvků. Provedení je realizováno tak, že server naslouchá do té doby, než od klienta obdrží zprávu (100 ECHO), načež buď odpoví (101 REPLY) a klient se opět uspí, nebo pošle příkaz (300 OPEN, 301 CLOSE, 302 ANGLE, 303 SEND INFO). Vykonání příkazu je klientem následně potvrzeno (200 OK). Dokud neobdrží potvrzení, server posílá klientu stejný příkaz znovu. Návrh tvaru komunikačních kódů byl inspirován třícifernými číselnými status kódy protokolu HTTP. 59

60 4.4.7 Popis použitých globálních proměnných bool resendopen proměnná indikující, zda je třeba znovu odeslat požadavek na otevření serva (žaluzií); bool resendclose proměnná indikující, zda je třeba znovu odeslat požadavek na zavření serva; bool opened v této proměnné je uložený aktuální stav, ve kterém se žaluzie nacházejí. Pokud je false, žaluzie jsou zavřeny, při hodnotě true jsou otevřeny; uint32_t lux1, lux2, lux 3 zde jsou uložena poslední tři měření světla. Pokud se všechny současně nachází nad, resp. pod hranicí intenzity nastavené proměnnou luxset, a zároveň se žaluzie nachází ve stavu opačném, pak se odešle příkaz k otevření, resp. zavření žaluzií; uint32_t luxset touto proměnnou je možné nastavit hraniční hodnotu osvětlení v Luxech, při které má systém reagovat otevřením, resp. zavřením žaluzií. int cnt počítadlo provedených čtení ze senzoru. Hodnota se pohybuje mezi 0 a 2, poté se znovu vynuluje. Ve chvíli, kdy tato proměnná indikuje dostupnost všech tří měření, tyto se porovnají a na základě výsledku se případně klientu odešle příkaz. Tento mechanismus má za cíl eliminovat chyby, které senzor zřídka generuje a také zajistit, že změna intenzity má delší povahu, než například jen krátce vržený stín. 4.5 Integrace do systému chytré domácnosti Jak již bylo v úvodu této práce zmíněno, cílem projektu je vytvořit skutečně použitelný, funkční, plnohodnotný systém domácí automatizace neboli chytré domácnosti. Samočinné řízení žaluzií je jen součástí takového systému, dalším krokem proto bude zapojení minipočítače Raspberry Pi 3 s linuxovým operačním systémem. Pro účely testování může dobře posloužit nejrozšířenější z nabízených distribucí, a sice OS Raspbian, avšak je také možné vydat se cestou pokročilého ArchLinux OS. Ten by měl poskytovat vyšší stabilitu a robustnost, potřebnou pro nasazení do ostrého provozu. Raspberry Pi 3 by tedy později ve spojení s dotykovým displejem mělo tvořit centrální ovládací panel pro celý smart home systém. Po jeho plném uvedení do provozu by měl následovat návrh a vývoj mobilní aplikace, a to ideálně pro všechny tři hlavní platformy Android, ios i Windows Phone. Po úplném dokončení celého projektu by tak běžný uživatel měl mít možnost svou chytrou domácnost ovládat skrze webové rozhraní, dotykový panel nebo svým smartphonem či tabletem. 60

61 4.6 Vestavba do horní lišty žaluzií Zde hrály hlavní roli rozměry lišty, kterými bylo nutné se řídit. Zohledněny byly již při výběru typu mikrokontroleru. Se svojí šířkou 18 mm se Arduino Nano jako jediný dostupný mikrokontroler vešlo dovnitř lišty, která má rozměry 25 x 20 mm (šířka x výška). Bezdrátový modul se díky jeho miniaturním rozměrům taktéž podařilo vložit do lišty, servomotor mírně vystupuje přes její okraj. Akumulátor vystupuje více, to je dáno zvoleným typem článků (AA). Zde bylo možné použít menší typ AAA, ovšem s přibližně třetinovou kapacitou. Protože kapacita akumulátorů má přímý vliv na celkovou výdrž systému, byl tento faktor upřednostněn před estetickým dojmem. Byla tak vybrána větší varianta AA. Následně bylo nutné vyřešit uchycení serva v liště. Pro tvorbu držáku serva byla po úvaze vybrána metoda 3D tisku. Nejprve se tedy vymodeloval 3D objekt s rozměry odpovídajícími profilu konzoly. Modelování probíhalo v programu Autodesk Inventor. Hotový objekt se následně vyexportoval do formátu STL. Takto vytvořený soubor se poté otevřel v open-source programu Slic3r, kde proběhlo nastavení výšky vrstvy, síly stěny a hustoty výplně. Zadaly se zde také různé parametry tisku: teplota trysky a heatbedu, rychlost tisku v mm / s, míra retrakce materiálu a další. Pro tisk byl zvolen transparentní filament z PET plastu, nastavení proto byla tomuto materiálu uzpůsobena. Tryska byla nastavena na teplotu 220 C, heatbed pouze na 45 C. Výška vrstvy pak byla 0,2 mm, stěna o síle 4 vrstev a výplň 20 %, křížový vzor. Po této přípravě objektu se v programu Slic3r již jen vygeneroval soubor pro tisk ve formátu gcode. Ten pak stačilo poslat do tiskárny a počkat na výsledek. Pro lepší představu o tom, jak vypadá soubor typu gcode, je v příloze č. 3 obsažena ukázka z tohoto souboru. Obrázek 4 11: 3D model držáku servomotoru v programu Autodesk Inventor Zdroj: vlastní úprava (autor) 61

62 Obrázek 4 12: Rozměry držáku servomotoru (nárys) Zdroj: vlastní úprava (autor) Obrázek 4 13: Ukázka 3D tisku držáků Zdroj: vlastní úprava (autor) 62

63 Posledním úkolem v rámci vestavby bylo napojení servomotoru na ovládací tyč uvnitř konzoly. Toto bylo vyřešeno poněkud provizorně s využitím plastového adaptéru (hmoždinky), do kterého je možné tyč nasunout. Adaptér byl na jednom svém konci přilepen modelářským sekundovým lepidlem ke kruhovému límci, nasazenému na hřídeli serva. Toto uchycení poskytuje dostatečnou pevnost spojení mezi tyčí a adaptérem není téměř žádná vůle a tyč se otáčí přesně spolu se servem. Přesto se však do budoucna počítá s lepším řešením tohoto napojení. I zde se nabízí využití technologie 3D tisku pro tvorbu přesného adaptéru, který bude zároveň nasazen na hřídel servomotoru. Absence lepeného spoje tak eliminuje riziko rozlomení v tomto místě během provozu. Na následujícím obrázku lze spatřit finální podobu prototypu včetně osazení v modelu okna: 63

64 Obrázek 4 14: Funkční prototyp klientského prvku osazený v modelu okna Zdroj: vlastní úprava (autor) 64

65 4.7 Zhodnocení V této podkapitole je rozebráno, zda a jakým způsobem byl splněn cíl práce, tedy tvorba plně funkčního prototypu pro ovládání žaluzií na základě specifikace dle návrhu. Dále, do jaké míry byly splněny stanovené požadavky na systém. Jednalo se o tyto dílčí úkoly: 1) Vytvoření funkčního prototypu - splněno. 2) Bateriové napájení: - splněno. 3) Bezdrátový provoz: - splněno. 4) Esteticky přijatelná vestavba do lišty žaluzií: - splněno. 5) Plně autonomní provoz: - splněno. 6) Možnost ručního ovládání skrze webové rozhraní či aplikaci: - nesplněno. Komentář k úkolu 6: Tento bod nebyl splněn kvůli nedostatku času na další vývoj projektu během studia. Realizace této fáze projektu je časově velmi náročná (obnáší mimo jiné začlenění Raspberry Pi do systému, implementaci vlastního IS pro řízení chytré domácnosti anebo výběr z již existujících řešení a jeho správné nastavení). Takto rozšířená práce by navíc značně převýšila obvyklý rozsah bakalářské práce. Závěrem je nutné poznamenat, že celý projekt je koncipovaný pro dodatečnou montáž do již hotových interiérů. V případě montáže do novostaveb je vhodnější místo akumulátorů k napájení použít 5V centrální rozvod z transformátoru ke všem oknům. Tím se celková realizace nejen usnadní, ale také zlevní a dojde i ke zvýšení uživatelského komfortu. Uživatel se nebude muset zabývat sledováním stavu akumulátorů ani jejich nabíjením. 65

66 5 Analýza rizik 5.1 Kvantitativní analýza rizik spojených s provozem systému Rozdělení podle typů aspektů: 1) Peněžní hodnoty a) nákladnost opravy v případě poruchy, b) nákladnost výměny komponent či celého systému v případě nemožnosti opravy, 2) Technické aspekty c) porucha mikrokontroleru, d) porucha servomotoru, e) selhání baterií, f) závada na bezdrátovém modulu, g) selhání systému jako celku, h) oslnění senzoru, měřícího intenzitu světla, 3) Provozní aspekty i) doba od prvního výskytu závady po její odstranění, 4) Lidské aspekty j) nemožnost ručně ovládat průchod světla okny v případě selhání systému nebo jeho části. 66

67 Tabulka 5-1: Matice kvantitativní metody analýzy rizik Velmi vysoká (>75%) Vysoká (25-75%) Střední (10-25%) Nízká (1-10%) Velmi nízká (<1%) Pravděpodobnost chyby Kvantitativní metoda - matice: j) i) d), e) a) c), f), h) b), g) Dopady v případě výskytu chyby Velmi malé (méně než 1000 Kč) Malé ( Kč) Střední ( Kč) Velké ( Kč) Velmi velké (více než Kč) Zdroj: vlastní úprava (autor) Kvantitativní analýza rizik a dopadů uvedená výše je pouze orientační. Vychází z předpokladu 100 ks prodaných a u zákazníka namontovaných systémů, přičemž průměrná pořizovací cena 1 ks systému včetně montáže činí Kč. 5.2 Bodová analýza rizik projektu 1. Cíle auditovaného subjektu: prodej a montáž systému pro automatizaci žaluzií, záruční a pozáruční servis. 2. Identifikace rizik: vývoj HW a SW projektu, údržba a servis HW a SW. 3. Určení rizikových faktorů: doba trvání vývoje, vývojová platforma, velikost počáteční investice, průběžné kontroly - integrace SW a HW, bezchybné fungování systému, počet zaměstnanců vzhledem k objemu montážních a servisních prací. 67

68 4. Stanovení stupně významnosti rizika: Doba trvání vývoje: váha 4 Velmi krátká (< 2 týdny) 1 Krátká (2 týdny ~ 1 měsíc) 2 Střední (1 3 měsíce) 3 Dlouhá (3 měsíce 1 rok) 4 Velmi dlouhá (> 1 rok) 5 Vývojová platforma: váha 3 Open-source (Arduino + Raspberry Pi) 1 Open-source (ostatní typy mikrokontrolerů a SoC řešení) 3 Closed-source (proprietární řídicí deska vlastní výroby) 5 Velikost počáteční investice: váha 3 Nízká (< Kč) 1 Střední ( Kč) 3 Vysoká (> Kč) 5 Průběžné kontroly: váha 4 Pravidelné, dle stadia vývoje 1 Spíše nahodilé 3 Neprovádí se 5 Počet zaměstnanců vzhledem k objemu prací: váha 4 Dostatečný (pokryto s rezervou) 1 Vyhovující (bez rezervy) 3 Nízký (podstav, zpoždění prací) 5 Tabulka 5-2: Rizikové faktory bodové analýzy rizik I. Riziko - váha Bodovací faktory # Rizikové faktory Skore faktoru I. II. III. IV. V. 1. Doba trvání vývoje Vývojová platforma Velikost počáteční investice Průběžné kontroly Počet zaměstnanců MAX A 95 Zdroj: vlastní úprava (autor) 68

69 Tabulka 5-3: Rizikové faktory bodové analýzy rizik II. # Klíčové rizikové faktory Váha faktoru 1 (nízká) Míra rizikovosti faktoru 2 3 (střední) 4 5 (vysoká) CELKEM 1. Doba trvání vývoje Vývojová platforma Velikost počáteční investice Průběžné kontroly Počet zaměstnanců k zakázkám Stupeň významnosti rizika (body) Stupeň významnosti rizika (procenta) A = v 1. RF 1 + v 2. RF v k. RF k bodů B max % Peněžní hodnota objektu auditu (CZK) C pokud lze určit CZK Peněžní hodnota rizika (CZK) D = C x B CZK Zdroj: vlastní úprava (autor) Stupeň významnosti rizika výpočet: Doba trvání vývoje: 20 / 95 =21,0 % Vývojová platforma: 3 / 95 =3,2 % Velikost počáteční investice: 3 / 95 =3,2 % Průběžné kontroly: 4 / 95 =4,2 % Počet zaměstnanců k zakázkám: 20 / 95 =21,0 % Celkem: 50 / 95 =52,6 % 5.3 Závěry analýzy Při selhání jednotlivých komponent systému jsou průměrné náklady na opravu velice nízké, obdobně při méně pravděpodobném selhání celého systému se náklady spojené se znovuuvedením do provozu pohybují na přijatelné úrovni. Analýzu jsem vytvořil ve vztahu k 1 ks systému, a to z důvodu, že je vysoce nepravděpodobné selhání více systémů, na sobě navzájem nezávislých, naráz. Z bodové analýzy vyplývá, že největší riziko je spojené s dobou trvání vývoje a s podceněním počtu zaměstnanců vzhledem k objemu zakázek, tj. počtu požadavků na montáž a servis. Naopak při vhodně zvolené open-source platformě a s tím spojené nízké počáteční investici jsou tato rizika minimální a můžeme je zanedbat. 69

70 6 Závěr V úvodu této bakalářské práce bylo blíže vysvětleno její zadání a také motivace pro řešení. Byly zde také představeny principy a technologie, související s obsahem práce. Ve druhé části byly specifikovány parametry, které by měl budoucí systém splňovat. Zároveň byly podrobně rozepsány funkční i nefunkční požadavky kladené na systém, a to včetně diagramu případů užití. Třetí část se zabývala návrhem konkrétního řešení systému. V této kapitole je upřesněna specifikace systému, včetně volby platformy a jednotlivých komponent, které jsou zde také podrobně představeny. V závěru kapitoly je provedena předběžná kalkulace nákladů, potřebných pro realizaci a nasazení systému v běžném třípokojovém bytě. Ve čtvrté části byla popsána implementace systému. Ta se zakládá na návrhu řešení z předešlé části. Je zde podrobně řešena spotřeba energie, která úzce souvisí s problematikou napájení z akumulátorů. Proto byla v rámci implementace provedena také velmi výrazná optimalizace spotřeby. Dále je zde popsána programová část, a to včetně použitých knihoven a globálních proměnných. V programové části je taktéž vysvětlen mechanismus příjmu a odesílání zpráv přes bezdrátový modul NRF24L01+, způsob, jakým je ovládán servomotor a princip čtení hodnot ze senzoru osvětlení. Poslední odstavce v rámci této části jsou věnovány fyzické vestavbě do horní lišty žaluzií a budoucí možné integraci do systému chytré domácnosti. Použití v rámci širšího, komplexního celku je velmi žádoucí, pokud má být systém nasazen do běžného provozu v domácnosti. V poslední části práce byla provedena bodová a kvantitativní analýza rizik celého popsaného projektu za předpokladu jeho komerčního využití. Výstupem této práce je funkční prototyp bateriově napájeného prvku pro ovládání interiérových žaluzií (klientský, ovládaný prvek) a jeho serverová protistrana (řídicí prvek). Obě strany jsou založeny na platformě Arduino (architektura Atmel ATmega). Kromě samotného hardwaru je nedílnou součástí výstupu i software, tedy program pro klientský a serverový prvek, zajišťující řídicí logiku a komunikaci celého systému. Prozatím byl vytvořen pouze výše zmíněný prototyp, fungující samostatně. V budoucnu se ovšem počítá s napojením klientských modulů na Raspberry Pi, které převezme jejich řízení. Takové řešení zároveň poskytuje možnost využití webového rozhraní či mobilní aplikace pro ruční ovládání celého systému. Zároveň dojde k odstranění nedostatků popsaných 70

71 v závěru čtvrté části. Zejména bude upraveno napojení servomotoru na tyč uvnitř konzoly a celá sestava klientského prvku bude vložena do plastového šasi, vytištěného na 3D tiskárně pravděpodobně z ABS plastu. 71

72 7 Seznam použité literatury BELL, Charles, MySQL for the Internet of Things. 1. vyd. Berkeley, CA, USA: Apress, 335 s. ISBN GÁLA, Libor, POUR, Jan, ŠEDIVÁ, Zuzana, Podniková informatika. 2. vyd. Praha: Grada, 240 s. ISBN HORÁČEK, Petr. Raspberry Pi VIII. Úvod do GPIO [online]. c2012 [cit ]. Dostupné z: < MALÝ, Martin. BigClown se představuje: IoT otevřeně a hlavně bezpečně [online]. c2016 [cit ]. Dostupné z: < MALÝ, Martin. Protokol MQTT: komunikační standard pro IoT [online]. c2016 [cit ]. Dostupné z: < MALÝ, Martin. Arduino: jak pro něj začít programovat [online]. c2010 [cit ]. Dostupné z: < MÁCHA, Miroslav. LoRa Technology [online]. c2016 [cit ]. Dostupné z: < PARAB, Jivan a kol., Practical Aspects of Embedded System Design using Microcontrollers. 1. vyd., Springer Netherlands, 150 s. ISBN SCHWARTZ, Marco, Internet of Things with the Arduino Yún. 1. vyd., Packt Publishing, 112 s. ISBN TIŠNOVSKÝ, Pavel. Externí sériové sběrnice SPI a I 2 C [online]. c2008 [cit ]. Dostupné z: < < <docs.uart.cz/docs/arduino-ide> < < 72

73 8 Seznam obrázků Obrázek 1 1: Architektura EasyIoT...12 Obrázek 1 2: IoT technologie LoRaWAN schéma komunikace...14 Obrázek 1 3: IoT technologie BigClown koncept...16 Obrázek 1 4: IoT technologie BigClown Core modul...16 Obrázek 2 1: Diagram případů užití...25 Obrázek 2 2: Diagram aktivit: reakce systému na změnu den / noc...26 Obrázek 2 3: Sekvenční diagram: nastavení profilu a rotace servomotoru...27 Obrázek 3 1: Bezdrátový modul NRF24L Obrázek 3 2: Bezdrátový modul ESP Obrázek 3 3: Mikrokontroler Arduino Nano...33 Obrázek 3 4: Raspberry Pi Obrázek 3 5: Doménový model...38 Obrázek 4 1: Arduino Nano, schéma rozložení pinů...40 Obrázek 4 2: NRF24L01+, schéma rozložení pinů...41 Obrázek 4 3: Náčrt systému...41 Obrázek 4 4: Schéma zapojení...42 Obrázek 4 5: Servomotor EMAX...47 Obrázek 4 6: NPN tranzistor, typ 2N4401 (TO-92)...49 Obrázek 4 7: Arduino Nano v3.0, spodní strana...51 Obrázek 4 9: Zapojení mini USB konektoru...52 Obrázek 4 8: Mini USB konektor...52 Obrázek 4 10: Arduino IDE...57 Obrázek 4 11: 3D model držáku servomotoru v programu Autodesk Inventor...61 Obrázek 4 12: Rozměry držáku servomotoru (nárys)...62 Obrázek 4 13: Ukázka 3D tisku držáků...62 Obrázek 4 14: Funkční prototyp klientského prvku osazený v modelu okna

74 9 Seznam tabulek Tabulka 3-1: Předběžná kalkulace nákladů na systém...39 Tabulka 4-1: Režimy spánku Arduina s vyznačením aktivních prvků systému...50 Tabulka 5-1: Matice kvantitativní metody analýzy rizik...67 Tabulka 5-2: Rizikové faktory bodové analýzy rizik I...68 Tabulka 5-3: Rizikové faktory bodové analýzy rizik II Seznam grafů Graf 4-1: Poměr spotřeby jednotlivých prvků vůči celku...48 Graf 4-2: Graf spotřeby dle úprav...54 Graf 4-3: Graf výdrže akumulátoru dle úprav Seznam příloh Příloha 1: Ukázka - programový kód serveru Příloha 2: Ukázka - programový kód klienta Příloha 3: Kód 3D tiskárny (formát.gcode) 74

75 Ukázka - programový kód serveru PŘÍLOHA 1 1

76 2

77 Ukázka - programový kód klienta PŘÍLOHA 2 1

78 2

79 Kód 3D tiskárny (formát.gcode) PŘÍLOHA 3 1