Bachelor Informatica

Automation engine voordomotica platform

Tom Zoon

12 augustus 2015

Supervisor(s): Toto van Inge (UvA)

Signed:

Informatica—

Universiteit

vanAmst

erdam

2

Samenvatting

De focus van deze scriptie is het ontwikkelen van een automation engine voor een nieuw domoticaplatform. Voor het automatiseren van een huis zijn een aantal domotica systemen beschikbaar.Aan deze domotica systemen kunnen nodes worden aangesloten, waarna deze geautomatiseerdkunnen worden. Onderzoek concludeert dat de huidige domotica systemen tekortkomen. Dezetekortkomingen zijn te groeperen in drie groepen, namelijk in de interactie met de gebruiker,flexibiliteit in het instellen en mogelijkheden qua uitbreiding. Dat heeft ruimte geboden voor eennieuw domotica platform.

Voor deze scriptie wordt een nieuwe automation engine geprogrammeerd voor een nieuw domoticaplatform. Deze scriptie heeft een antwoord gezocht op de vraag Is het mogelijk om, gebruik-makend van hedendaagse kennis uit het Internet of Things en real-time scheduling,een stabiel en flexibel domotica platform te bouwen? Deze hoofdvraag is op te delenin drie deelvragen. Is er een implementatie die openheid kan combineren met stabiliteit? Hoekan de flexibiliteit van het platform worden gewaarborgd? en is er een balans te vinden tussenintuıtiviteit en controle voor het grafische interface?

De mogelijkheden qua uitbreiding zijn gewaarborgd door gebruikers in staat te stellen driversvoor nog niet ondersteunde nodes toe te voegen. Deze drivers zijn modulair geımplementeerdwat zorgt voor stabiliteit. De flexibiliteit en de controle van het platform zijn gewaarborgddoor het combineren van condities met acties. Als aan de condities worden voldaan zullen deacties plaatsvinden. Op basis van het platform als resultaat is gebleken dat de onderzoeksvraagmogelijk is.

Inhoudsopgave

1 Inleiding 31.1 Probleemstelling: Tekortkoming huidige domotica platformen . . . . . . . . . . . 41.2 Origine scriptie: Voordelen van een domotica platform . . . . . . . . . . . . . . . 41.3 Onderzoek: Weg naar nieuwe automation engine . . . . . . . . . . . . . . . . . . 5

2 Analyse en onderzoek deelgebieden 62.1 Huidige platformen: Opdeling hardware en software . . . . . . . . . . . . . . . . 62.2 Interfaces: If this then that en Scratch . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Polling tegenover event driven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4 Gesloten of een open architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Architectuur keuzes en design 83.1 Programmeertaal keuze front-end en back-end . . . . . . . . . . . . . . . . . . . . 83.2 Flexibiliteit door condities en acties . . . . . . . . . . . . . . . . . . . . . . . . . 83.3 De regels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.4 Event-based implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 De automation engine 104.1 Regel in de automation engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.2 Stappen in het volgen van een regel . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.2.1 Event binnengekomen tijdens het checken van een event . . . . . . . . . . 114.3 Opslag en het inladen regels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.4 Aantal gemaakte algoritmes voor de automation engine . . . . . . . . . . . . . . 13

4.4.1 Check functie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.4.2 Checken van een tijds conditie . . . . . . . . . . . . . . . . . . . . . . . . 13

4.5 Uitvoeren van acties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5 Elementair grafisch gebruikers interface 155.1 Functionaliteit in de regel maker . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.2 Samenwerking interface en automation engine bij het maken van een regel . . . . 16

6 Openheid en stabiliteit door middel van modulaire drivers 186.1 Inladen en modulariteit drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

7 Resultaten van het open domotica platform 207.1 Openheid en stabiliteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207.2 Flexibiliteit in de controle van het platform . . . . . . . . . . . . . . . . . . . . . 217.3 Controle en intuıviteit van het grafische interface . . . . . . . . . . . . . . . . . . 21

8 Conclusie 22

2

HOOFDSTUK 1

Inleiding

De focus van deze scriptie is het ontwikkelen van een automation engine voor een nieuw domoticaplatform. Het idee van een slim huis is niet nieuw, maar het heeft nog niet het grote publiek be-reikt. Een slim huis is een huis dat op een autonome manier de huiselijke objecten kan aansturen.Door apparaten autonoom te schakelen kan de directe controle over genomen worden door hethuis, terwijl de gebruiker de controle vooraf behoud. De gebruiker delegeert de aansturende taak

Figuur 1.1: Opdeling domotica platform

aan het huis, waarbij de gebruiker alle re-gels bepaald. Wat een huis een slim huis kanmaken is een domotica platform. Het woord”domoticaıs een samentrekking van het La-tijnse woord domus (huis) en tica wat afkom-stig is van informatica, telematica en robotica.De officiele definitie van domotica is: De in-tegratie van technologie en diensten, ten be-hoeve van een betere kwaliteit van wonen enleven [9]. Op een domotica platform kunnennodes aangesloten worden waarna ze kunnensamenwerken. Met nodes worden apparatenof voorwerpen bedoelt die over sensoren en/ofcommunicatie mogelijkheden beschikken. Denodes zijn opgedeeld in twee groepen, name-lijk closed loop nodes(CLN’s) en open loop no-des(OLN’s). CLN’s zijn in staat te reagerenop signalen van buitenaf en ook feedback tegeven op deze signalen. Bij automatisatie vande CLN’s is deze feedback onmisbaar, omdatmet deze feedback niet aangekomen signalen waargenomen en opgelost kunnen worden. BijOLN’s is deze feedback er niet. In de rest van de scriptie zal gesproken worden over nodes, waar-mee een combinatie van CLN’s en OLN’s bedoelt wordt. Met het domotica platform wordt hetgehele platform bedoelt, namelijk de nodes zelf, de software die de nodes regelt en de hardwarewaar deze software op draait. Dit is te zien in figuur 1.1. Voor deze scriptie wordt ingezoomdop de software hiervan, namelijk de automation engine. Met behulp van deze software kan degebruiker zijn voorkeuren instellen voor het platform. Bij sommige domotica platformen behoudde gebruiker de mogelijkheid om het platform te overrulen, waarbij de gebruiker de directe con-trole kan overnemen. De nodes zijn in staat met ingebouwde sensoren de omgeving in te schattenen autonoom op deze informatie te reageren. Door middel van de communicatie mogelijkhedenkan data worden gedeeld met andere nodes.

3

1.1 Probleemstelling: Tekortkoming huidige domotica platformen

Onderzoek [3] naar huidige domotica platformen concludeert dat deze platformen nog tekort-komen. Deze tekortkomingen doen zich voor in de manier waarop de objecten worden aange-stuurd [4] door het domotica platform. De mogelijkheden van de nodes worden niet optimaalingezet [7]. Deze problemen zijn onder te verdelen in een drie groepen [3].

InteractieEen veelvoorkomend probleem zit in de manier waarop de interactie plaatsvind tussende automation engine en de gebruiker [2]. Ingewikkelde interfaces verhinderen optimaalgebruik van de mogelijkheden, omdat vaak gekozen wordt om alle mogelijkheden in 1menu weer te geven. Dit zorgt voor overvolle menu’s waardoor sommige functionaliteitonvindbaar wordt [8].

Gesloten architectuurVaak wordt gebruik gemaakt van een gesloten architectuur. Dit maakt het aansluiten vannieuwe nodes lastig [13]. Dit is vaak alleen mogelijk met een beperkt aantal ondersteundenodes.

FlexibiliteitIn de huidige domotica platformen mist flexibiliteit [3]. Het platform is maar tot op zekerehoogte in te stellen waardoor de functionaliteit beperkt wordt. Dit beperkt de controle diede gebruiker heeft op het systeem.

1.2 Origine scriptie: Voordelen van een domotica platform

De origine van deze scriptie komt voort uit de constatering dat domotica platformen nog niet hetgrote publiek hebben bereikt. Deze constatering gepaard met een interesse voor automatisatie enelektronische objecten komt samen in een idee van een nieuw domotica platform. Een domoticaplatform dat de tekortkomingen van de huidige platformen te verbetert. Een domotica platformbrengt namelijk een aantal voordelen met zich mee, zoals gebruikersgemak, energiebesparing enveiligheid.

EnergiebesparingHet automatisch schakelen van nodes voorkomt onnodig energieverbruik, omdat gereageerdwordt op de omgeving. Door te reageren op de omgeving wordt rekening gehouden metbijvoorbeeld het weer, opkomen van de zon, het thuis zijn van bewoners en het open staanvan deuren en ramen. Deze energiebesparing wordt gerealiseerd door een combinatie vanfactoren, namelijk in het regelen van de thermostaat, het schakelen van energie gebruikendenodes en het reageren op de opbrengst van bijvoorbeeld zonnepanelen.

VeiligheidHet domotica platform analyseert de omgeving waardoor gevaren worden gedetecteerd,waarna gepast wordt gehandeld. De detectie van gevaren is afhankelijk van een groot aan-tal variabelen. Zo wordt bijvoorbeeld de luchtkwaliteit geanalyseerd waardoor gevaren zoalsrook en koolmonoxide aan de gebruiker kunnen worden gemeld. Indringers zouden gede-tecteerd kunnen worden door middel van bewegingsdetectie en opengaande deuren/ramen.

GebruikersgemakDe bovenstaande voordelen bereiken een niveau in complexiteit die niet meer handmatigis te behalen. Het platform kan door de omgevings data van de nodes feedback hierovergeven aan de gebruiker. Het platform neemt deze complexiteit van de gebruiker over doorde directe controle over te nemen, zoals te zien is in figuur 1.2. De gebruiker behoud deindirecte controle, vanwege de controle op het domotica platform zelf. De gebruiker kanten alle tijden (tijdelijk) de directe controle weer over nemen door het domotica platformte overrulen.

4

Figuur 1.2: Directe of Indirecte controle

1.3 Onderzoek: Weg naar nieuwe automation engine

Het domein Domotica heeft een aantal gemeenschappelijke vlakken met het Internet of Things.Het Internet of Things refereert aan de situatie dat de meerderheid van de aansluitingen aanhet internet zullen zijn ingenomen door nodes in plaats van menselijke gebruikers [7]. Objectenuit het Internet of Things zijn geschikt voor domotica, omdat de essentie van domotica [12]bestaat uit de communicatie tussen objecten. Het Internet of Things zal om deze reden meegenomen worden in het onderzoek. Dit zal terug komen in het volgende hoofdstuk. Onderzoeknaar real-time scheduling is gebruikt om een gepaste manier te vinden voor het afhandelenvan data afkomstig van de nodes. Het onderzoek van deze scriptie richt zich op een domoticaplatform voor het automatiseren van nodes. De vraag die bij dit onderzoek centraal staat: Ishet mogelijk om, gebruikmakend van hedendaagse kennis uit het Internet of Thingsen real-time scheduling, een stabiel en flexibel domotica platform te bouwen? Omdeze vraag te beantwoorden is eerst onderzoek gedaan naar de huidige staat van de domotica ende deelgebieden hiervan. Dit onderzoek heeft een aantal problemen zichtbaar gemaakt waar nogverbetering mogelijk is. Verder onderzoek naar deze probleemgebieden en andere deelgebiedenvan domotica komen samen in een aantal architectuurkeuzes voor het nieuwe domotica platform.Het programmeren van het platform en het testen van het resultaat zal antwoord geven op deonderzoeksvraag. De onderzoeksvraag is op te delen in drie deelvragen, namelijk:

Is er een implementatie die openheid kan combineren met stabiliteit?Openheid in het mogelijk maken dat nieuwe niet ondersteunde nodes kunnen worden toe-gevoegd. Dit brengt een aantal nieuwe uitdagingen mee qua stabiliteit, omdat deze nodesniet zijn getest.

Hoe kan de flexibiliteit van het platform worden gewaarborgd?Controle maximaliseren is een belangrijk doel van het platform. Een veelvoorkomendprobleem [3] is dat platformen de controle van de gebruiker beperken. Het doel is niet decontrole wegnemen, maar dat de gebruiker de directe controle delegeert aan het platform.Terwijl de gebruiker de indirecte controle behoud, zoals te zien is in figuur 1.2. Dit vereistdat het platform overweg kan met een groot scala aan mogelijkheden, omdat het beperkenvan de mogelijkheden het beperken van de controle impliceert.

Is er een balans te vinden tussen intuıtiviteit en controle voor het grafische interface?Een beperking in opties betekent ook een beperking in controle. Bij het maximaliseren vancontrole brengt dit ook een maximalisatie van opties met zich mee. Om deze reden zijn con-trole en gebruikersvriendelijkheid vaak lastig te combineren een interface. In deze scriptieworden tools gemaakt om grafisch interface bouwers de mogelijkheid te bieden een gebrui-kersvriendelijk interface te bouwen. Met deze tools is een elementair grafisch interfacegemaakt voor het kunnen testen van het platform.

5

HOOFDSTUK 2

Analyse en onderzoek deelgebieden

Dit is niet de eerste keer dat een domotica platform wordt geprogrammeerd en daarom zijner conclusies te trekken uit de huidige domotica markt. Ook zijn er een aantal technieken dieraakvlakken hebben met domotica geanalyseerd.

2.1 Huidige platformen: Opdeling hardware en software

Figuur 1.1 uit de inleiding laat zien uit welke delen een domotica platform is opgebouwd. Name-lijk de automation engine, de hardware waar deze engine op draait en de nodes. Op dit momentzijn er 3 verschillende typen aanwezig op de domotica markt te vinden.

Alles in 1De eerste type is een alles in 1, namelijk de engine en de hardware, samen met de nodes.Deze platformen zijn meestal slecht uitbreidbaar, omdat het platform alleen geschikt is vooreen vaste set hardware. Meestal hebben deze platformen een onoverzichtelijk interface [3].Voordeel is dat de compatibiliteit van de nodes meestal uitvoerig is getest, omdat er eenvaste set van nodes wordt meegeleverd.

Applicatie afhankelijke nodesHet volgende type zijn de applicatie afhankelijke nodes [5]. Dit type heeft geen automa-tion engine, maar wel is extra hardware beschikbaar waarmee de nodes via een applicatieaangestuurd kunnen worden. Het voordeel van deze besturing is dat het sneller is danhet lopen naar een fysieke schakelaar. Het nadeel hiervan is dat indien er meerdere nodesaanwezig zijn die afhankelijk zijn van verschillende applicaties de snelheidswinst vervalt,omdat gewisseld moet worden tussen verschillende applicaties. Dit type kan ook vallenonder het Internet of things.

Onafhankelijke automation engineHet laatste type is dat van de losse automation engine. Op deze engine kan de gebruikerzijn nodes aansluiten en ze hierna automatiseren. Deze implementatie is erg afhankelijkvan de nodes van de andere types, omdat zonder compatibele nodes de automation enginenutteloos is. Voordeel van dit type is dat alle aandacht is gegaan naar de engine. Deze focusop de engine komt naar voren in een goed en begrijpelijk interface voor de engine. Plat-formen gemaakt met een losse automation engine zijn goed uitbreidbaar, omdat de enginerekening houdt met verschillende soorten nodes. Voor deze scriptie wordt een automationengine gemaakt met dit type.

2.2 Interfaces: If this then that en Scratch

De interfaces van de huidige domotica platformen zijn vaak onoverzichtelijk en ingewikkeld [3].Het internet platform If this then that, met afkorting IFTTT [6], geeft gebruikers de mogelijkheid

6

om regels te maken voor social media en andere met internet verbonden applicaties. Met eenregel wordt een conditie bedoelt die gekoppeld is aan een actie. In het nederlands als dit dan dat.Zodra aan de conditie wordt voldaan zal de actie plaatsvinden. Een voorbeeld hiervan is dat nahet maken van een foto, deze direct ook in dropbox wordt geplaatst. Het platform Scratch [11]leert kinderen met behulp van grafische blokken programmeren. De blokken zijn maar op eenbepaalde manier aan te sluiten wat intuıtief duidelijk maakt wat wel en niet mogelijk is. Debeide interfaces geven mensen zonder programmeerkennis de mogelijkheid om met behulp vaneen grafisch interface op een begrijpelijke manier te programmeren.

2.3 Polling tegenover event driven

In de automation engine zal gereageerd moeten worden op data afkomstig van de nodes. Dit ver-eist dat er een keuze gemaakt moet worden hoe dit wordt afgehandeld. Twee geschikte methoden

Figuur 2.1: Polling tegenover event-based

zijn polling en event-based. Pol-ling houdt in dat met een vast in-terval data van de nodes wordt op-gevraagd. De frequentie waarin ditplaatsvind heet de pollfrequentie.De pollfrequentie moet hoger zijndan de snelheid waarmee de dataverandert, omdat anders veranderin-gen gemist kunnen worden. Event-driven reageert met een event op ver-anderingen [1], zoals te zien is infiguur 2.1. Dit betekend dat eenevent-based platform sneller kan re-ageren dan een polling based plat-form. Omdat een event-based plat-form reageert als de data veranderten polling based pas als data wordtopgevraagd. In de polling imple-mentatie kan de wachttijd wordenverkleind door de pollfrequentie teverhogen, waardoor vaker wordt ge-polt. Bij polling zal het voorkomen dat nodes onnodig worden benadert, omdat de omgeving nogniet is verandert. Zeker bij een hoge pollfrequentie zal dit veelvuldig voorkomen. Dit verhoogthet energiegebruik van de nodes en dat is niet praktisch omdat sommige nodes batterij gevoedzijn.

2.4 Gesloten of een open architectuur

Domotica platformen kunnen met twee verschillende architecturen zijn opgebouwd, namelijk eenopen en een gesloten architectuur. Bij een geloten architectuur zijn de communicatie protocollenniet bekend. Dit maakt het voor andere partijen lastig tot onmogelijk om niet ondersteundenodes toe te voegen op het platform. Bij een open architectuur zijn deze protocollen wel bekend,bijvoorbeeld door middel van een gedocumenteerde API. Het voordeel van een gesloten archi-tectuur is dat alles uitvoerig kan worden getest door de makers van het platform. Een nadeelvoor de gebruiker is dat het niet mogelijk is om niet ondersteunde nodes aan te sluiten op hetplatform. Bij een open architectuur kan dit wel, maar hiervoor is wel programmeerkennis nodig.

7

HOOFDSTUK 3

Architectuur keuzes en design

De designdoelen uit het eerste hoofdstuk moeten worden omgezet in een functioneel design. Inhet vorige hoofdstuk zijn een aantal technieken besproken en in het komende hoofdstuk wordendeze meegenomen in het design voor de automation engine. Voor het interface is ook gekekennaar interfaces van software uit andere gebieden dan domotica.

3.1 Programmeertaal keuze front-end en back-end

De front-end van het platform is een web interface geworden. Op deze manier hoeft geen losscherm aangesloten te worden aan de hardware waar de engine op wordt gedraaid. Dit webinterface wordt gehost door de automation engine zelf. Apparaten die beschikken over eeninternet browser en zich in hetzelfde netwerk bevinden als de automation engine kunnen hetweb interface benaderen. Bij het maken van het web interface is geen aandacht besteed aan devormgeving en design, omdat design en vormgeving buiten het domein van deze scriptie vallen.Het web interface is geprobeerd zo simpel mogelijk te houden. De taalkeuze voor de back-end isJava. Bij het op Zigbee gebaseerd domotica systeem [3] wordt beargumenteerd waarom Java isgebruikt voor het platform. De belangrijkste reden hiervoor is dat Java gedraaid kan worden opalle grote besturingssystemen. Een ander voordeel van Java is het grote aanbod aan packagesdat verschillende communicatie methoden ondersteunt. Een bijkomend voordeel is dat Java alkan draaien op een apparaat van 25 euro [10], wat betekent dat er geen dure hardware nodig isom het platform te draaien.

3.2 Flexibiliteit door condities en acties

In het vorige hoofdstuk is naar voren gekomen dat IFTTT een implementatie gebruikt dat 1conditie verbind met 1 actie. Aan de populariteit van IFTTT [6] is te zien dat gebruikers ditgegeven snappen. Voor domotica doeleinden is de oplossing van IFTTT alleen niet toereikend.Bij domotica is het wenselijk dat ook gereageerd kan worden op een complex aan condities. Omdeze reden is gekozen voor de IFTTT oplossing, maar dan uitgebreid met de mogelijkheid ommeerdere condities te koppelen aan meerdere acties. De gebruiker kan zelf regels verzinnen enmaken voor zijn gekoppelde nodes. De automation engine zal deze regels bijhouden en de nodesregelen.

8

3.3 De regels

Een regel is opgebouwd uit condities en acties. Als aan de condities wordt voldaan zullen deacties plaatsvinden. Programmeurs kennen dit gegeven al langer als de ’if’-statement, waarvan

Figuur 3.1: Voorbeeld regel

een voorbeeld te zien is in algorithm 1. Mini-male eisen van een regel zijn 1 of meer condi-ties geschakeld met ’en’ en ’of’, samen met 1of meer acties. Hoe de regels in de engine zijnopgebouwd is te lezen in het volgende hoofd-stuk. Een voorbeeld van een regel is te zien infiguur 3.1. De voorbeeld regel is opgebouwduit 2 condities geschakeld met een ’en’. Devoorbeeld regel bevat 2 acties. Acties zijn al-tijd geschakeld met ’en’. Gekozen is om geen’else’ of ’else if’ statement toe te voegen. Eenpragmatische benadering van het ’else’ en ’elseif’ probleem gaf aan dat deze statements maarin een heel klein aantal regels nuttig is. Een’else’ of ’else if’ regel is ook te maken is metmeerdere regels, waardoor met het weglatenvan deze statements geen functionaliteit ver-loren gaat. Een bijkomende reden hiervoor isdat het interface simpel en begrijpelijk moestblijven en de ’else’ of ’else if’ optie zorgt voor extra complexiteit.

Algorithm 1 Regel voorbeeld

1: if Condition1 and Condition2 or Condition3 then2: for every action[] do3: action[i].activate()

3.4 Event-based implementatie

Real-time scheduling is niet nodig voor het gemaakte domotica platform, omdat intern niet aanstricte deadlines hoeft te voldoen. Wel is de tijd waarin de events worden afgehandeld van belang,daarom wordt gesproken van in-time processing. Wat inhoud dat gestreefd wordt de data vande nodes zo snel mogelijk te behandelen. Een belangrijk dilemma voor een platform dat moetreageren op data van buitenaf is de keuze tussen polling of event-based. Een uitleg van deze beideimplementaties is te lezen in sectie 2.3. In figuur 3.2 is te zien dat het platform wacht tot eenevent plaatsvind. De nodes worden geınstrueerd een event te sturen aan de engine als aan eenconditie wordt voldaan. Deze implementatie wordt nader toegelicht in het volgende hoofdstuk.

Figuur 3.2: Event-based implementatie

9

HOOFDSTUK 4

De automation engine

De gemaakte engine is op te delen in drie delen, namelijk de engine zelf, het grafische interface ende modulaire drivers. De modulaire drivers stellen het platform open voor nog niet ondersteundenodes. Deze modulaire drivers voegen de mogelijkheid toe om drivers voor nieuwe nodes aande automation engine toe te voegen. Dit komt naar voren in hoofdstuk 6. Om de engine in tekunnen stellen is een grafisch gebruikers interface gemaakt. Het grafische interface komt naarvoren in hoofdstuk 5. Het grafische interface wordt gehost door de automation engine zelf. Indit hoofdstuk wordt de automation engine globaal beschreven. Eerst wordt de structuur van eenregel in de engine uitgelegd. Daarna zal naar voren komen uit welke stappen het volgen van eenregel bestaat. Vervolgens komt de opslag en het inladen van de gemaakte regels aan bod.

4.1 Regel in de automation engine

Om de regels event-based te kunnen volgen moeten de condities worden opgesplitst in eventsen condities zonder events. Een voorbeeld hiervan is het verschil tussen ’bewoner komt thuis’en ’bewoner is thuis’. ’Bewoner komt thuis’ kan een event afgeven. En ’bewoner is thuis’ kangebruikt worden om te checken of de bewoner thuis is en is dus een conditie zonder event. Dezeopsplitsing wordt gemaakt zodra een regel wordt opgeslagen. Bij het opslaan van een regel wordtnagekeken welke condities als events behandelt kunnen worden en welke niet. In figuur 4.1 isweergegeven hoe een toegevoegde regel is omgezet in een regel voor de engine. Hierbij is alleenconditie 1 een event. De condities worden pas getoetst zodra het event heeft plaatsgevonden.Het pas toetsen van condities na een event zorgt ervoor dat niet onnodig data wordt opgevraagd.De regels worden opgeslagen in de vorm van een multiple linked list. Ieder event of conditie

Figuur 4.1: Regel in de engine

10

verwijst naar een conditie of naar een actie. Zoals ook te zien is in figuur 4.1. Als een conditieof een event verwijst naar meerdere condities is er sprake van een ’of’-schakeling. Als naar eenactie wordt verwezen zal het toetsen van andere condities worden gestopt. In figuur 4.1 is dat tezien als conditie 2 waar is, zal conditie 3 niet meer worden nagegaan.

4.2 Stappen in het volgen van een regel

Zodra de automation engine is opgestart en de regels zijn ingeladen zal de engine de regels gaanbijhouden. Een overzicht hiervan is te zien in figuur 4.2. Een event kan plaatsvinden door eensignaal van een node of een gebeurtenis binnenin de engine. Deze gebeurtenis kan bijvoorbeeldbestaan uit een 11:00 moment, wat op 11:00 een event afgeeft. Zodra een event plaatsvind zullen

Figuur 4.2: Overzicht van het volgen van een regel

de gelinkte conditie(s) waarnaar dit event verwijst worden getoetst. Deze condities wordenmeegegeven aan een functie die ze 1 voor 1 toetst. Indien aan een conditie wordt voldaan wordtgekeken naar wat deze conditie verwijst. Als het verwijst naar nog een conditie (of meerderecondities) wordt deze getoetst. Als de conditie verwijst naar een actie wordt het toetsen vanoverige condities gestopt, want dit is niet meer nodig. Zodra bij een actie is aangekomen wordtdeze uitgevoerd. Als dit is gelukt wordt gekeken of de actie linkt naar nog een actie. Indien bijhet uitvoeren van een actie een error plaatsvind door bijvoorbeeld het niet kunnen bereiken vaneen node zal de regel op non-actief worden gezet en de gebruiker worden gesignaleerd. Als alleacties zijn uitgevoerd zal de engine weer gaan wachten op nieuwe events.

4.2.1 Event binnengekomen tijdens het checken van een event

Het is mogelijk dat er meerdere events in een korte tijdspanne plaatsvinden. Indien de enginenog niet klaar is met een andere regel en er vind een event plaats wordt dit als volgt afgehandeld.Eerst wordt gekeken of het event van dezelfde node afkomstig is. Zo ja, dan wordt gekeken of hetevent ook bij dezelfde regel hoort. Indien dit zo is wordt het event verwijdert. Indien het event

11

van een andere node afkomstig is of gekoppeld is aan een andere regel wordt deze in de queuegeplaatst. Als de engine klaar is met het afhandelen van de vorige regel zal de engine kijken ofer nog events in de queue staan, waarna deze 1 voor 1 worden afgehandeld.

4.3 Opslag en het inladen regels

Figuur 4.3: Opstarten engine: Laden van regels

De gebruiker stuurt het domotica platform aan door het maken van regels. Deze regels zijnop te delen in condities en acties. De opslag van deze regels is gedaan in een XML file. VoorXML is gekozen omdat dit gemakkelijk te parsen is voor het Javascript interface en voor de inJava geprogrammeerde automation engine. Deze structuur is versimpeld weergegeven in figuur4.3. De init.class include stap en de initialize stap komen naar voren in hoofdstuk 6, want dezehebben te maken met de node drivers. De XML file wordt alleen tijdens het opstarten van deengine aangeroepen of als de engine een herstart signaal krijgt. Dit herstart signaal wordt doorhet interface aangeroepen als de XML is aangepast. De structuur van de XML file is opgedeeldin regels, zoals te zien is in figuur 4.3. Per regel zullen de events, condities en acties staan metde bijbehorende node en data. Conditie 0 is bijvoorbeeld een tijdsperiode van 10:00 tot 20:00.Intern zijn deze tijden in ms weergegeven, maar voor de leesbaarheid is dit aangepast voor hetfiguur. De tijds conditie verwijst naar de sms actie. Zodra de XML is ingeladen worden de regelsverdeelt over regel klassen die weer bestaan uit conditie en actie klassen. Iedere conditie en actiebestaan uit een node, de functie die gebruikt wordt van de node, de data die daarbij hoort eneen link naar een volgende conditie of actie. Als het om de laatste actie gaat is deze link leeg.

12

4.4 Aantal gemaakte algoritmes voor de automation engine

De automation engine is opgebouwd uit een aantal algoritmes. Een aantal van deze algoritmeszal onderstaand worden besproken met behulp van pseudocode. De meeste van deze algoritmeszijn redelijk klein en overzichtelijk. De complexiteit van het platform zit hem in de keten waarindeze worden aangesproken, zoals te zien was in figuur 4.2. Onderstaand is de event handler diena het binnenkomen van een event de check functie start voor de gekoppelde regel.

Algorithm 2 event handler

1: procedure HandleEvent(sender)2: for every active rule do3: if rule[i].event.id == sender then4: rule[i].startCheck()

4.4.1 Check functie

De check functie wordt aangeroepen met een lijst van condities. Deze gaat in met behulp vande recursieve functie check() alle condities af tot een keten gevonden is die allemaal met trueantwoord. Zodra dit gebeurd word de actie functie aangeroepen. Indien niet aan de conditieswordt voldaan zal opnieuw gewacht worden op een event.

Algorithm 3 start check

1: procedure startCheck()2: for every this.cond[] do3: if this.cond[i].check then4: this.executeAll()5: break

Algorithm 4 check

1: procedure check()2: if device.check(data) then3: if link == NULL then4: return true5: for every link[] do6: if link[i].check() then7: return true8: break9: return false

4.4.2 Checken van een tijds conditie

De tijd driver zit intern in de automation engine. Drivers voor het versturen van een sms of hetchecken van een datum zijn ook intern. Voor dit voorbeeld is gekozen voor een tijdsperiode, maarook een tijdsmoment is mogelijk. Iedere driver heeft een centrale check functie die doorschakeltnaar de benodigde check functie. In dit geval is dat checkPeriod(). In de volgende pseudocodeis de tijd weergegeven in een leesbaar format. Intern is dit in system milliseconde van de dag.

4.5 Uitvoeren van acties

Een event heeft plaatsgevonden en de bijbehorende condities zijn gecheckt, waarna de actiefunctie is aangeroepen. Deze functie doet niks anders dan 1 voor 1 de acties uitvoeren. Als de

13

Algorithm 5 check time - period

1: data[0] = 8 : 002: data[1] = 20 : 003: procedure checkPeriod()4: if data[0] < data[1] then5: if data[0] < this.time and this.time < data[1] then6: return true7: return false

8: if data[0] > this.time or this.time > data[1] then9: return true

10: return false

actie is geslaagd wordt gereageerd met true. Indien dit niet lukt is een object niet bereikbaar enzal de regel worden uitgeschakeld en de gebruiker op de hoogte worden gesteld.

Algorithm 6 start check

1: procedure executeAll()2: for every this.act[] do3: if not this.act[i].execute() then4: Control.f lag(this)5: break

14

HOOFDSTUK 5

Elementair grafisch gebruikers interface

Om het platform te kunnen testen is een elementair grafisch gebruikers interface gebouwd. Detools die hiervoor gemaakt zijn komen naar voren in dit hoofdstuk. Het grafische interface is tebenaderen vanuit het netwerk waaraan de engine is aangesloten. Hier worden de tools die hetinterface bezit kort besproken. Het grafische interface bestaat uit 2 delen, namelijk het overzichten de regel maker. In het overzicht is een lijst met de gemaakte regels te zien. Vanuit hierkan iedere regel aangepast, verwijdert, uit/aangezet en getest worden. De tools die hiervoorbeschikbaar zijn gesteld is een API waar een lijst met regels kan worden opgevraagd en waar degenoemde functies kunnen worden aangeroepen. Het tweede deel van het interface is de regelmaker.

5.1 Functionaliteit in de regel maker

De regel maker is de naam van het scherm waar de gebruiker in staat wordt gesteld om een regelte ontwerpen. De regel maker is op te delen in twee gedeelten. Als eerst een lijst met tegels voor

Figuur 5.1: Regel maker

de condities en de acties en daarnaast de vel-den waar deze naartoe kunnen worden ge-sleept. Iedere aangesloten node krijgt een te-gel in de regel maker. Dit vormt een lijst mettegels voor de nodes van de gebruiker. De re-den voor een lijst is dat het rekening houdtmet het toevoegen van meerdere nodes, wanteen lijst kan mee schalen met verschillendehoeveelheden nodes. Bij het openen van deregel maker wordt eerst een request naar deautomation engine gedaan voor een lijst metde gekoppelde nodes. Voor iedere gekoppeldenode wordt een tegel, een pop-up en een aan-tal controle functies aangemaakt. Dit is tezien in figuur 5.2. De tegel met een plaatjevan de node geeft de gebruiker de mogelijk-heid om deze te slepen naar de nieuwe regel. De pop-up wordt zichtbaar wanneer de tegel in eenveld is gesleept. In deze pop-up kan de gebruiker de conditie of actie verder instellen. Deze pop-up wordt aangemaakt aan de hand van de specificaties van de node. Als het gaat om een tijdsnode zal in de pop-up eerst gekozen moeten worden of het gaat om een periode of een moment,waarna de bijbehorende tijd kan worden ingevuld. De specificaties voor de pop-ups worden doorde automation engine meegeleverd bij het laden van het grafische interface. De controle functiesworden aangeroepen zodra de gebruiker de regel wil opslaan. Deze functies gaan na of allescorrect is ingevuld door de gebruiker. Deze worden apart per node meegeleverd zodat rekeningkan worden gehouden met nieuwe nodes, die misschien anders moeten worden gecontroleerd.

15

Figuur 5.2: Opdeling per node in regel maker

5.2 Samenwerking interface en automation engine bij het maken vaneen regel

Voor het aanmaken van een nieuwe regel werken het grafische interface en de engine samen. Hetaanmaken van een nieuwe regel is onder te verdelen in de volgende stappen. Zoals te zien is infiguur 4.5. Alles in het interface wordt lokaal door Javascript gedaan. In de automation engineis dit Java.

Figuur 5.3: Samenwerking bij aanmaken van een regel

Gebruiker opent regel makerDe gebruiker opent vanaf het overzichtsscherm de regel maker. Eerst wordt een signaalgestuurd naar de automation engine voor het ophalen van de aangesloten nodes. Dezenodes worden hierna teruggestuurd naar het interface, waarmee de drie delen uit figuur 5.2gemaakt kunnen worden.

Regel maker wordt zichtbaarDe regel maker wordt zichtbaar voor de gebruiker nadat de lijst met nodes is ontvangenen de tegels zijn aangemaakt. Met deze tegels kan gesleept worden om een nieuwe regel

16

te vormen. Zodra de gebruiker een regel heeft gevormd en de save functie activeert volgeneen aantal controle functies.

Controle functiesInvoer van gebruiker wordt gecheckt op fouten. Eerst wordt gekeken of er geen lege veldenaanwezig zijn. Hierna wordt de invoer van de gebruiker gecontroleerd of het wel klopt.Bijvoorbeeld of een tijd goed is ingevuld (25:00 is bijvoorbeeld niet mogelijk).

Opslag en activatieDe regel wordt in XML omgezet en naar de automation engine toe gestuurd. De automationengine plaatst deze dan tussen de andere regels, waarna de engine wordt herstart.

17

HOOFDSTUK 6

Openheid en stabiliteit door middel vanmodulaire drivers

Het gemaakte platform bezit een open architectuur in een zodanige vorm dat er al rekening isgehouden met niet ondersteunde nodes. De nodes zijn verwisselbaar en maken geen verschil voorde architectuur van de engine zelf, maar wel voor de drivers die de engine gebruikt. Voor iedereondersteunde node zijn de componenten aanwezig uit figuur 6.1. Voor niet ondersteunde nodesis dit niet het geval. Niet indersteunde nodes kunnen worden aangesloten op het platform doorde componenten uit figuur 6.1 toe te voegen. Dit vergt alleen wel programmeerkennis bij degebruiker.

Figuur 6.1: Benodigtheden node in platform

18

6.1 Inladen en modulariteit drivers

De gebruiker de mogelijkheid geven om drivers toe te voegen creeert een aantal uitdagingen quastabiliteit. Als een driver vast loopt mag niet het platform mee vast lopen. Om deze reden zijn

Figuur 6.2: Modulariteit drivers

de drivers modulair geımplementeerd, zoals tezien is in figuur 6.2. De volgende reden voorhet modulair implementeren van drivers is hetkunnen testen en toevoegen van nieuwe driverszonder dat de engine hoeft worden aangepast.De laatste reden is dat de engine niet geleverdhoeft te worden met een overmaat aan drivers.De gebruiker hoeft alleen de drivers binnen tehalen voor de nodes die de gebruiker bezit. Bijhet opstarten wordt een poging gedaan de dri-vers te laden. Indien dit niet lukt zal dit wor-den gemeld aan de gebruiker, waarna de en-gine verder gaat zonder deze driver en zonderde bijbehorende node. De regels die gebruikmaken van deze driver zullen worden gedeacti-veerd. Bij het opstarten van de engine laad hetde init.class file, die op zijn beurt alle gedefi-nieerde driver files include. Dit mechanisme iste zien in figuur 6.3. Hierna zal initialize() detest functies van de drivers aanroepen. Dezefuncties doen een poging tot contact met debijbehorende node door middel van de test() functie, indien dit niet lukt wordt de driver en debijbehorende node op non-actief gezet en wordt dit gemeld aan de gebruiker. Als er een driverof node weg valt tijdens het draaien van de engine zal hetzelfde gebeuren als tijdens het nietkunnen laden van een driver.

Figuur 6.3: Opstarten engine: Laden van drivers

19

HOOFDSTUK 7

Resultaten van het open domoticaplatform

Het platform is werkend en stabiel. Het afhandelen van errors in drivers verloopt goed, waardoornog geen vastlopers zijn voorgekomen. Het platform is op te delen in drie delen, namelijk deengine, het interface en de modulaire node drivers. Deze drie delen worden kort behandelt waarnahet platform naast de deelvragen wordt gelegd.

Automation engineDe automation engine werkt door het toetsen van regels. Iedere regel bestaat uit events,condities en acties. Dit geeft de gebruiker een begrijpelijke manier om het platform in testellen samen met een event-based implementatie om de regels te volgen. Door middel vande event-based implementatie worden nodes niet onnodig benadert en worden conditiespas getoetst zodra het event heeft plaatsgevonden. Indien er een event plaatsvind tijdenshet toetsen van een andere regel wordt deze in de queue geplaatst, waardoor geen eventsworden gemist.

Grafisch gebruikers interfaceHet grafische interface geeft gebruikers de mogelijkheid om regels toe te voegen aan hetplatform. Eerst wordt de lijst met aangesloten nodes uit de automation engine gehaaldwaarmee het grafische interface de regel maker opstelt. Met deze regel maker kan degebruiker condities met acties verbinden. Het grafische interface zal ook controleren of deinvoer van de gebruiker klopt, voordat dit wordt doorgestuurd aan de automation engine.

Modulaire driver implementatieDe gebruiker kan nieuwe drivers schrijven voor nog niet ondersteunde nodes. Deze nodeszijn na het toevoegen van deze drivers beschikbaar voor het maken van nieuwe regels. Dezedrivers zijn modulair geımplementeerd om te voorkomen dat het platform vast loopt alseen driver dat doet. Als een driver weg valt wordt deze op non-actief gezet samen met debijbehorende regels.

De deelvragen die in de inleiding naar boven kwamen zijn naast het nieuwe platform gelegd.

7.1 Openheid en stabiliteit

Een open architectuur brengt uitdagingen met zich mee qua stabiliteit, omdat het gebruik vanonbekende nodes niet kan worden getest. Wel kan het platform zo zijn opgebouwd dat hetniet gelijk vast loopt als een driver van een node dat doet. In de automation engine is ditgedaan door alle drivers modulair naast elkaar te draaien. Indien een driver vast loopt wordt ditgemeld aan de gebruiker en de regels waar deze node in wordt gebruikt worden gedeactiveerd.Deze implementatie voorkomt dat een fout in de driver of in de connectie met een node hettotale platform vast laat lopen. Om een niet ondersteunde node toe te voegen is wel nog steeds

20

programmeerkennis nodig bij de gebruiker. De gemiddelde gebruiker zal geen programmeerkennishebben en voor deze gebruiker zal het dan ook niet mogelijk zijn om niet ondersteunde nodestoe te voegen. Dit kan in de toekomst worden verholpen door het delen van drivers.

Delen van driversStel een gebruiker heeft een nog niet ondersteunde node werkend gekregen door een nieuwedriver te schrijven. Deze zou kunnen worden gedeeld met andere gebruikers. Indien genoeggebruikers deze node met driver hebben getest en aangegeven hebben dat deze werkt kandeze worden toegevoegd aan de lijst met ondersteunde nodes.

Is er een implementatie die openheid kan combineren met stabiliteit?

Antwoord op deze deelvraag is ja, omdat een automation engine is gecreeerd dat stabiel draait.Op dit moment is deze openheid alleen voor de gebruiker met programmeerkennis. De toekomstzal uitwijzen of de bovenstaande toevoeging van het delen van drivers het mogelijk maakt datde gebruiker zonder programmeerkennis ook gaat profiteren van nieuwe drivers.

7.2 Flexibiliteit in de controle van het platform

De bestaande systemen leveren verschillende manieren voor de gebruiker om het platform in testellen. Dit komt meestal neer op een enkel instellingenscherm. In de gemaakte automationengine is deze flexibiliteit gewaarborgd door niks vast te liggen in de automation engine zelf,maar de instellingen op te bouwen uit regels. Deze regels bestaan uit condities gekoppeld aanacties. Dit geeft de gebruiker een grote mate van vrijheid, omdat niks voor de gebruiker wordtbeslist. Een nadeel van deze implementatie is dat voor bepaalde functionaliteit meerdere regelsnodig zijn. Een voorbeeld hiervan is de thermostaat aanzetten als er iemand thuis is, want ditvereist 2 regels. Een regel voor het thuis aan komen en een regel voor het thuis weg gaan.

Hoe kan de flexibiliteit van het platform worden gewaarborgd?

De flexibiliteit van het platform kan dus worden gewaarborgd door een andere back-end im-plementatie te kiezen die zo weinig mogelijk voor de gebruiker bepaald.

7.3 Controle en intuıviteit van het grafische interface

De controle is gewaarborgd door condities te koppelen aan acties. In het grafische interface is ditnaar voren gekomen door middel van het slepen van tegels. Voor iedere aangesloten CLO is eentegel te vinden in het grafische interface. Zodra deze tegel wordt gebruikt in een nieuwe regelwordt door middel van een pop-up duidelijk welke opties er mogelijk zijn. Deze implementatiegeeft de gebruiker totale controle door de gebruiker de tools te geven om zijn eigen regels teprogrammeren.

Is er een balans te vinden tussen intuıtiviteit en controle voor het grafische in-terface?

Op deze deelvraag is geen exact antwoord, omdat intuıtiviteit een subjectieve term is. Decontrole is gewaarborgd door het model te gebruiken dat condities koppelt aan acties. Wel kanvergeleken worden met platformen zoals IFTTT en scratch, die vergelijkbare implementaties ge-bruiken. Deze platformen zijn erg populair en daaruit kan worden afgeleid dat gebruikers grafischprogrammeren snappen.

21

HOOFDSTUK 8

Conclusie

De gemaakte automation engine werkt en draait met behulp van hardware en nodes die al voorhanden waren. Door het gebruik van Java als programmeertaal kan de engine op verschillendetypen van hardware draaien. Op de gebruikte hardware draait het stabiel, maar dit is niet getestvoor andere typen hardware. De engine reageert op de nodes door middel van een event-basedimplementatie. Deze oplossing maakt polling overbodig en reageert direct op veranderingen uitde omgeving. Hoe kan de flexibiliteit van het platform worden gewaarborgd? In de gemaakte au-tomation engine is deze flexibiliteit gewaarborgd door niks vast te liggen in de automation enginezelf, maar de instellingen op te bouwen uit regels. Deze regels bestaan uit condities gekoppeldaan acties. Dit geeft de gebruiker een grote mate van vrijheid, omdat niks voor de gebruikerwordt beslist. Is er een implementatie die openheid kan combineren met stabiliteit? Dit is tecombineren door de gebruiker de mogelijkheid geven om zijn eigen drivers toe te voegen. Doordeze drivers modulair te draaien zal het platform niet vast lopen als een driver dat doet, waarmeede stabiliteit wordt gewaarborgd. Nadeel hiervan is dat er wel programmeerkennis nodig is omdrivers toe te voegen. Door de mogelijkheid toe te voegen van het delen van drivers wordt ditnadeel verkleind. Is er een balans te vinden tussen intuıtiviteit en controle voor het grafische in-terface? De controle is gewaarborgd door condities te koppelen aan acties. In het interface is ditnaar voren gekomen door middel van het slepen van tegels. Voor iedere aangesloten CLO is eentegel te vinden in het interface. Zodra deze tegel wordt gebruikt in een nieuwe regel wordt doormiddel van een pop-up duidelijk welke opties er mogelijk zijn. Dit zorgt voor een begrijpelijkebesturing van het platform.

Is het mogelijk om, gebruikmakend van hedendaagse kennis uit het Internet ofThings en real-time scheduling, een stabiel en flexibel domotica platform te bou-wen?

Het is inderdaad mogelijk. De gemaakte automation engine bewijst dat met behulp van albestaande hardware en nodes een stabiel en flexibel domotica platform is te bouwen. Door middelvan event-based programming reageert het platform direct op veranderingen in de omgeving.Stabiliteit is gewaarborgd door het modulair opbouwen van de drivers. Het platform is volledigin te stellen door de gebruiker met behulp van het condities met acties model.

22

Bibliografie

[1] N. Audsley and A. Burns. Real-time system scheduling. ESPRIT BRA Project (3092),2006.

[2] J. Desbonnet and P.M. Corcoran. System architecture and implementation of a ce-bus/internet gateway. Dept. of Electronic Engineering, University College, Galway, Ireland,1997.

[3] K. Gill, Yang S.H., Yao F., and L. Xin. A zigbee-based home automation system, 2009.

[4] J. Gubbi, R. Buyya, S. Marusic, and M. Palaniswami. A vision, architectural elements, andfuture directions., 2013.

[5] S. Haller. The things in the internet of things. Elsevier, 2010.

[6] IFTTT. Ifttt, make the internet work for you. ”https://ifttt.com/”, 2015.

[7] G. Kortuem, F. Kawsar, D. Fitton, and V. Sundramoorthy. Smart objects as building blocksfor the internet of things. ”Internet Computing, IEEE”, 2010.

[8] Rajeev Piyare. Internet of things: Ubiquitous home control and monitoring system usingandroid based smart phone. Department of Information Electronics Engineering, MokpoNational University, Mokpo, 534-729, Korea South, 2013.

[9] Nationaal Kenniscentrum Domotica & Slim Wonen Stichting Smart Homes.”http://www.smart-homes.nl/”, 2015.

[10] Universiteit van Cambridge. Raspberry pi. ”http://tweakers.net/pricewatch/320116/raspberry-pi-model-b-(512mb).html”, 2012.

[11] Lifelong Kindergarten Group van het MIT Media Lab. ”https://scratch.mit.edu/”, 2015.

[12] Drs. Michiel D.J. van Well. Beter bouwen en bewonen: een praktijkgerichte toekomstver-kenning. ”Stichting Toekomstbeeld der Techniek”, 2007.

[13] C.L. Wu, C.F. Liao, and L.C. Fu. Service-oriented smart-home architecture. IEEE, 2007.

23