Bachelor Informatica
Automation engine voor
domotica platform
Tom Zoon
12 augustus 2015
Supervisor(s): Toto van Inge (UvA)
Inf
orma
tica
—
Universiteit
v
an
Ams
terd
am
Samenvatting
De focus van deze scriptie is het ontwikkelen van een automation engine voor een nieuw domotica platform. Voor het automatiseren van een huis zijn een aantal domotica systemen beschikbaar. Aan deze domotica systemen kunnen nodes worden aangesloten, waarna deze geautomatiseerd kunnen worden. Onderzoek concludeert dat de huidige domotica systemen tekortkomen. Deze tekortkomingen 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 een nieuw domotica platform.
Voor deze scriptie wordt een nieuwe automation engine geprogrammeerd voor een nieuw domotica platform. 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 delen in drie deelvragen. Is er een implementatie die openheid kan combineren met stabiliteit? Hoe kan de flexibiliteit van het platform worden gewaarborgd? en is er een balans te vinden tussen intu¨ıtiviteit en controle voor het grafische interface?
De mogelijkheden qua uitbreiding zijn gewaarborgd door gebruikers in staat te stellen drivers voor nog niet ondersteunde nodes toe te voegen. Deze drivers zijn modulair ge¨ımplementeerd wat zorgt voor stabiliteit. De flexibiliteit en de controle van het platform zijn gewaarborgd door het combineren van condities met acties. Als aan de condities worden voldaan zullen de acties plaatsvinden. Op basis van het platform als resultaat is gebleken dat de onderzoeksvraag mogelijk is.
Inhoudsopgave
1 Inleiding 3
1.1 Probleemstelling: Tekortkoming huidige domotica platformen . . . 4
1.2 Origine scriptie: Voordelen van een domotica platform . . . 4
1.3 Onderzoek: Weg naar nieuwe automation engine . . . 5
2 Analyse en onderzoek deelgebieden 6 2.1 Huidige platformen: Opdeling hardware en software . . . 6
2.2 Interfaces: If this then that en Scratch . . . 6
2.3 Polling tegenover event driven . . . 7
2.4 Gesloten of een open architectuur . . . 7
3 Architectuur keuzes en design 8 3.1 Programmeertaal keuze front-end en back-end . . . 8
3.2 Flexibiliteit door condities en acties . . . 8
3.3 De regels . . . 9
3.4 Event-based implementatie . . . 9
4 De automation engine 10 4.1 Regel in de automation engine . . . 10
4.2 Stappen in het volgen van een regel . . . 11
4.2.1 Event binnengekomen tijdens het checken van een event . . . 11
4.3 Opslag en het inladen regels . . . 12
4.4 Aantal gemaakte algoritmes voor de automation engine . . . 13
4.4.1 Check functie . . . 13
4.4.2 Checken van een tijds conditie . . . 13
4.5 Uitvoeren van acties . . . 13
5 Elementair grafisch gebruikers interface 15 5.1 Functionaliteit in de regel maker . . . 15
5.2 Samenwerking interface en automation engine bij het maken van een regel . . . . 16
6 Openheid en stabiliteit door middel van modulaire drivers 18 6.1 Inladen en modulariteit drivers . . . 19
7 Resultaten van het open domotica platform 20 7.1 Openheid en stabiliteit . . . 20
7.2 Flexibiliteit in de controle van het platform . . . 21
7.3 Controle en intu¨ıviteit van het grafische interface . . . 21
HOOFDSTUK 1
Inleiding
De focus van deze scriptie is het ontwikkelen van een automation engine voor een nieuw domotica platform. 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 het huis, 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 kan maken 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 offici¨ele definitie van domotica is: De in-tegratie van technologie en diensten, ten be-hoeve van een betere kwaliteit van wonen en leven [9]. Op een domotica platform kunnen nodes aangesloten worden waarna ze kunnen samenwerken. Met nodes worden apparaten of voorwerpen bedoelt die over sensoren en/of communicatie mogelijkheden beschikken. De nodes 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 reageren op signalen van buitenaf en ook feedback te geven op deze signalen. Bij automatisatie van de CLN’s is deze feedback onmisbaar, omdat
met deze feedback niet aangekomen signalen waargenomen en opgelost kunnen worden. Bij OLN’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 het gehele platform bedoelt, namelijk de nodes zelf, de software die de nodes regelt en de hardware waar deze software op draait. Dit is te zien in figuur 1.1. Voor deze scriptie wordt ingezoomd op de software hiervan, namelijk de automation engine. Met behulp van deze software kan de gebruiker zijn voorkeuren instellen voor het platform. Bij sommige domotica platformen behoud de 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 schatten en autonoom op deze informatie te reageren. Door middel van de communicatie mogelijkheden kan data worden gedeeld met andere nodes.
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 optimaal ingezet [7]. Deze problemen zijn onder te verdelen in een drie groepen [3].
Interactie
Een veelvoorkomend probleem zit in de manier waarop de interactie plaatsvind tussen de automation engine en de gebruiker [2]. Ingewikkelde interfaces verhinderen optimaal gebruik van de mogelijkheden, omdat vaak gekozen wordt om alle mogelijkheden in 1 menu weer te geven. Dit zorgt voor overvolle menu’s waardoor sommige functionaliteit onvindbaar wordt [8].
Gesloten architectuur
Vaak wordt gebruik gemaakt van een gesloten architectuur. Dit maakt het aansluiten van nieuwe nodes lastig [13]. Dit is vaak alleen mogelijk met een beperkt aantal ondersteunde nodes.
Flexibiliteit
In de huidige domotica platformen mist flexibiliteit [3]. Het platform is maar tot op zekere hoogte in te stellen waardoor de functionaliteit beperkt wordt. Dit beperkt de controle die de 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 het grote publiek hebben bereikt. Deze constatering gepaard met een interesse voor automatisatie en elektronische objecten komt samen in een idee van een nieuw domotica platform. Een domotica platform dat de tekortkomingen van de huidige platformen te verbetert. Een domotica platform brengt namelijk een aantal voordelen met zich mee, zoals gebruikersgemak, energiebesparing en veiligheid.
Energiebesparing
Het automatisch schakelen van nodes voorkomt onnodig energieverbruik, omdat gereageerd wordt op de omgeving. Door te reageren op de omgeving wordt rekening gehouden met bijvoorbeeld het weer, opkomen van de zon, het thuis zijn van bewoners en het open staan van deuren en ramen. Deze energiebesparing wordt gerealiseerd door een combinatie van factoren, namelijk in het regelen van de thermostaat, het schakelen van energie gebruikende nodes en het reageren op de opbrengst van bijvoorbeeld zonnepanelen.
Veiligheid
Het 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 zoals rook en koolmonoxide aan de gebruiker kunnen worden gemeld. Indringers zouden gede-tecteerd kunnen worden door middel van bewegingsdetectie en opengaande deuren/ramen. Gebruikersgemak
De bovenstaande voordelen bereiken een niveau in complexiteit die niet meer handmatig is te behalen. Het platform kan door de omgevings data van de nodes feedback hierover geven aan de gebruiker. Het platform neemt deze complexiteit van de gebruiker over door de directe controle over te nemen, zoals te zien is in figuur 1.2. De gebruiker behoud de indirecte controle, vanwege de controle op het domotica platform zelf. De gebruiker kan ten alle tijden (tijdelijk) de directe controle weer over nemen door het domotica platform te overrulen.
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 aan het internet zullen zijn ingenomen door nodes in plaats van menselijke gebruikers [7]. Objecten uit 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 mee genomen worden in het onderzoek. Dit zal terug komen in het volgende hoofdstuk. Onderzoek naar real-time scheduling is gebruikt om een gepaste manier te vinden voor het afhandelen van data afkomstig van de nodes. Het onderzoek van deze scriptie richt zich op een domotica platform voor het automatiseren van nodes. De vraag die bij dit onderzoek centraal staat: Is het mogelijk om, gebruikmakend van hedendaagse kennis uit het Internet of Things en real-time scheduling, een stabiel en flexibel domotica platform te bouwen? Om deze vraag te beantwoorden is eerst onderzoek gedaan naar de huidige staat van de domotica en de deelgebieden hiervan. Dit onderzoek heeft een aantal problemen zichtbaar gemaakt waar nog verbetering mogelijk is. Verder onderzoek naar deze probleemgebieden en andere deelgebieden van 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 de onderzoeksvraag. 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 nodes niet zijn getest.
Hoe kan de flexibiliteit van het platform worden gewaarborgd?
Controle maximaliseren is een belangrijk doel van het platform. Een veelvoorkomend probleem [3] is dat platformen de controle van de gebruiker beperken. Het doel is niet de controle 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 vereist dat het platform overweg kan met een groot scala aan mogelijkheden, omdat het beperken van 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 van controle 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 scriptie worden tools gemaakt om grafisch interface bouwers de mogelijkheid te bieden een gebrui-kersvriendelijk interface te bouwen. Met deze tools is een elementair grafisch interface gemaakt voor het kunnen testen van het platform.
HOOFDSTUK 2
Analyse en onderzoek deelgebieden
Dit is niet de eerste keer dat een domotica platform wordt geprogrammeerd en daarom zijn er conclusies te trekken uit de huidige domotica markt. Ook zijn er een aantal technieken die raakvlakken 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 moment zijn er 3 verschillende typen aanwezig op de domotica markt te vinden.
Alles in 1
De 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 voor een 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 een vaste set van nodes wordt meegeleverd.
Applicatie afhankelijke nodes
Het 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 applicatie aangestuurd kunnen worden. Het voordeel van deze besturing is dat het sneller is dan het lopen naar een fysieke schakelaar. Het nadeel hiervan is dat indien er meerdere nodes aanwezig zijn die afhankelijk zijn van verschillende applicaties de snelheidswinst vervalt, omdat gewisseld moet worden tussen verschillende applicaties. Dit type kan ook vallen onder het Internet of things.
Onafhankelijke automation engine
Het laatste type is dat van de losse automation engine. Op deze engine kan de gebruiker zijn nodes aansluiten en ze hierna automatiseren. Deze implementatie is erg afhankelijk van de nodes van de andere types, omdat zonder compatibele nodes de automation engine nutteloos is. Voordeel van dit type is dat alle aandacht is gegaan naar de engine. Deze focus op 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 engine rekening houdt met verschillende soorten nodes. Voor deze scriptie wordt een automation engine 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
om regels te maken voor social media en andere met internet verbonden applicaties. Met een regel 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 na het 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 een bepaalde manier aan te sluiten wat intu¨ıtief duidelijk maakt wat wel en niet mogelijk is. De beide interfaces geven mensen zonder programmeerkennis de mogelijkheid om met behulp van een 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 dit plaatsvind heet de pollfrequentie. De pollfrequentie moet hoger zijn dan de snelheid waarmee de data verandert, omdat anders veranderin-gen gemist kunnen worden. Event-driven reageert met een event op ver-anderingen [1], zoals te zien is in figuur 2.1. Dit betekend dat een event-based platform sneller kan re-ageren dan een polling based form. Omdat een event-based plat-form reageert als de data verandert en polling based pas als data wordt opgevraagd. In de polling imple-mentatie kan de wachttijd worden verkleind door de pollfrequentie te verhogen, waardoor vaker wordt
ge-polt. Bij polling zal het voorkomen dat nodes onnodig worden benadert, omdat de omgeving nog niet is verandert. Zeker bij een hoge pollfrequentie zal dit veelvuldig voorkomen. Dit verhoogt het energiegebruik van de nodes en dat is niet praktisch omdat sommige nodes batterij gevoed zijn.
2.4
Gesloten of een open architectuur
Domotica platformen kunnen met twee verschillende architecturen zijn opgebouwd, namelijk een open en een gesloten architectuur. Bij een geloten architectuur zijn de communicatie protocollen niet bekend. Dit maakt het voor andere partijen lastig tot onmogelijk om niet ondersteunde nodes 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 nadeel voor de gebruiker is dat het niet mogelijk is om niet ondersteunde nodes aan te sluiten op het platform. Bij een open architectuur kan dit wel, maar hiervoor is wel programmeerkennis nodig.
HOOFDSTUK 3
Architectuur keuzes en design
De designdoelen uit het eerste hoofdstuk moeten worden omgezet in een functioneel design. In het vorige hoofdstuk zijn een aantal technieken besproken en in het komende hoofdstuk worden deze meegenomen in het design voor de automation engine. Voor het interface is ook gekeken naar 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 los scherm aangesloten te worden aan de hardware waar de engine op wordt gedraaid. Dit web interface wordt gehost door de automation engine zelf. Apparaten die beschikken over een internet browser en zich in hetzelfde netwerk bevinden als de automation engine kunnen het web interface benaderen. Bij het maken van het web interface is geen aandacht besteed aan de vormgeving 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 is Java. Bij het op Zigbee gebaseerd domotica systeem [3] wordt beargumenteerd waarom Java is gebruikt voor het platform. De belangrijkste reden hiervoor is dat Java gedraaid kan worden op alle grote besturingssystemen. Een ander voordeel van Java is het grote aanbod aan packages dat verschillende communicatie methoden ondersteunt. Een bijkomend voordeel is dat Java al kan draaien op een apparaat van 25 euro [10], wat betekent dat er geen dure hardware nodig is om 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 1 conditie verbind met 1 actie. Aan de populariteit van IFTTT [6] is te zien dat gebruikers dit gegeven 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. Om deze reden is gekozen voor de IFTTT oplossing, maar dan uitgebreid met de mogelijkheid om meerdere condities te koppelen aan meerdere acties. De gebruiker kan zelf regels verzinnen en maken voor zijn gekoppelde nodes. De automation engine zal deze regels bijhouden en de nodes regelen.
3.3
De regels
Een regel is opgebouwd uit condities en acties. Als aan de condities wordt voldaan zullen de acties 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 1 of meer acties. Hoe de regels in de engine zijn opgebouwd is te lezen in het volgende hoofd-stuk. Een voorbeeld van een regel is te zien in figuur 3.1. De voorbeeld regel is opgebouwd uit 2 condities geschakeld met een ’en’. De voorbeeld regel bevat 2 acties. Acties zijn al-tijd geschakeld met ’en’. Gekozen is om geen ’else’ of ’else if’ statement toe te voegen. Een pragmatische benadering van het ’else’ en ’else if’ probleem gaf aan dat deze statements maar in een heel klein aantal regels nuttig is. Een ’else’ of ’else if’ regel is ook te maken is met meerdere regels, waardoor met het weglaten van deze statements geen functionaliteit ver-loren gaat. Een bijkomende reden hiervoor is dat het interface simpel en begrijpelijk moest
blijven en de ’else’ of ’else if’ optie zorgt voor extra complexiteit. Algorithm 1 Regel voorbeeld
1: if Condition1 and Condition2 or Condition3 then
2: for every action[] do
3: action[i].activate()
3.4
Event-based implementatie
Real-time scheduling is niet nodig voor het gemaakte domotica platform, omdat intern niet aan stricte 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 van de nodes zo snel mogelijk te behandelen. Een belangrijk dilemma voor een platform dat moet reageren op data van buitenaf is de keuze tussen polling of event-based. Een uitleg van deze beide implementaties is te lezen in sectie 2.3. In figuur 3.2 is te zien dat het platform wacht tot een event plaatsvind. De nodes worden ge¨ınstrueerd een event te sturen aan de engine als aan een conditie wordt voldaan. Deze implementatie wordt nader toegelicht in het volgende hoofdstuk.
HOOFDSTUK 4
De automation engine
De gemaakte engine is op te delen in drie delen, namelijk de engine zelf, het grafische interface en de modulaire drivers. De modulaire drivers stellen het platform open voor nog niet ondersteunde nodes. Deze modulaire drivers voegen de mogelijkheid toe om drivers voor nieuwe nodes aan de automation engine toe te voegen. Dit komt naar voren in hoofdstuk 6. Om de engine in te kunnen stellen is een grafisch gebruikers interface gemaakt. Het grafische interface komt naar voren in hoofdstuk 5. Het grafische interface wordt gehost door de automation engine zelf. In dit hoofdstuk wordt de automation engine globaal beschreven. Eerst wordt de structuur van een regel in de engine uitgelegd. Daarna zal naar voren komen uit welke stappen het volgen van een regel 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 events en 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’ kan gebruikt worden om te checken of de bewoner thuis is en is dus een conditie zonder event. Deze opsplitsing wordt gemaakt zodra een regel wordt opgeslagen. Bij het opslaan van een regel wordt nagekeken welke condities als events behandelt kunnen worden en welke niet. In figuur 4.1 is weergegeven hoe een toegevoegde regel is omgezet in een regel voor de engine. Hierbij is alleen conditie 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
verwijst naar een conditie of naar een actie. Zoals ook te zien is in figuur 4.1. Als een conditie of een event verwijst naar meerdere condities is er sprake van een ’of’-schakeling. Als naar een actie wordt verwezen zal het toetsen van andere condities worden gestopt. In figuur 4.1 is dat te zien 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 gaan bijhouden. Een overzicht hiervan is te zien in figuur 4.2. Een event kan plaatsvinden door een signaal van een node of een gebeurtenis binnenin de engine. Deze gebeurtenis kan bijvoorbeeld bestaan 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 worden meegegeven aan een functie die ze 1 voor 1 toetst. Indien aan een conditie wordt voldaan wordt gekeken naar wat deze conditie verwijst. Als het verwijst naar nog een conditie (of meerdere condities) wordt deze getoetst. Als de conditie verwijst naar een actie wordt het toetsen van overige condities gestopt, want dit is niet meer nodig. Zodra bij een actie is aangekomen wordt deze uitgevoerd. Als dit is gelukt wordt gekeken of de actie linkt naar nog een actie. Indien bij het uitvoeren van een actie een error plaatsvind door bijvoorbeeld het niet kunnen bereiken van een node zal de regel op non-actief worden gezet en de gebruiker worden gesignaleerd. Als alle acties 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 engine nog 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 het event ook bij dezelfde regel hoort. Indien dit zo is wordt het event verwijdert. Indien het event
van een andere node afkomstig is of gekoppeld is aan een andere regel wordt deze in de queue geplaatst. Als de engine klaar is met het afhandelen van de vorige regel zal de engine kijken of er 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 zijn op te delen in condities en acties. De opslag van deze regels is gedaan in een XML file. Voor XML is gekozen omdat dit gemakkelijk te parsen is voor het Javascript interface en voor de in Java geprogrammeerde automation engine. Deze structuur is versimpeld weergegeven in figuur 4.3. De init.class include stap en de initialize stap komen naar voren in hoofdstuk 6, want deze hebben te maken met de node drivers. De XML file wordt alleen tijdens het opstarten van de engine aangeroepen of als de engine een herstart signaal krijgt. Dit herstart signaal wordt door het interface aangeroepen als de XML is aangepast. De structuur van de XML file is opgedeeld in regels, zoals te zien is in figuur 4.3. Per regel zullen de events, condities en acties staan met de 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 het figuur. De tijds conditie verwijst naar de sms actie. Zodra de XML is ingeladen worden de regels verdeelt over regel klassen die weer bestaan uit conditie en actie klassen. Iedere conditie en actie bestaan uit een node, de functie die gebruikt wordt van de node, de data die daarbij hoort en een link naar een volgende conditie of actie. Als het om de laatste actie gaat is deze link leeg.
4.4
Aantal gemaakte algoritmes voor de automation engine
De automation engine is opgebouwd uit een aantal algoritmes. Een aantal van deze algoritmes zal onderstaand worden besproken met behulp van pseudocode. De meeste van deze algoritmes zijn redelijk klein en overzichtelijk. De complexiteit van het platform zit hem in de keten waarin deze worden aangesproken, zoals te zien was in figuur 4.2. Onderstaand is de event handler die na 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 do
3: if rule[i].event.id == sender then
4: rule[i].startCheck()
4.4.1
Check functie
De check functie wordt aangeroepen met een lijst van condities. Deze gaat in met behulp van de recursieve functie check() alle condities af tot een keten gevonden is die allemaal met true antwoord. Zodra dit gebeurd word de actie functie aangeroepen. Indien niet aan de condities wordt voldaan zal opnieuw gewacht worden op een event.
Algorithm 3 start check
1: procedure startCheck() 2: for every this.cond[] do
3: if this.cond[i].check then 4: this.executeAll() 5: break Algorithm 4 check 1: procedure check() 2: if device.check(data) then 3: if link == N U LL then 4: return true
5: for every link[] do
6: if link[i].check() then
7: return true
8: break
9: return f alse
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 het checken van een datum zijn ook intern. Voor dit voorbeeld is gekozen voor een tijdsperiode, maar ook een tijdsmoment is mogelijk. Iedere driver heeft een centrale check functie die doorschakelt naar de benodigde check functie. In dit geval is dat checkPeriod(). In de volgende pseudocode is 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 actie functie is aangeroepen. Deze functie doet niks anders dan 1 voor 1 de acties uitvoeren. Als de
Algorithm 5 check time - period
1: data[0] = 8 : 00
2: data[1] = 20 : 00
3: procedure checkPeriod() 4: if data[0] < data[1] then
5: if data[0] < this.time and this.time < data[1] then
6: return true
7: return f alse
8: if data[0] > this.time or this.time > data[1] then
9: return true
10: return f alse
actie is geslaagd wordt gereageerd met true. Indien dit niet lukt is een object niet bereikbaar en zal de regel worden uitgeschakeld en de gebruiker op de hoogte worden gesteld.
Algorithm 6 start check
1: procedure executeAll() 2: for every this.act[] do
3: if not this.act[i].execute() then
4: Control.f lag(this)
HOOFDSTUK 5
Elementair grafisch gebruikers interface
Om het platform te kunnen testen is een elementair grafisch gebruikers interface gebouwd. De tools die hiervoor gemaakt zijn komen naar voren in dit hoofdstuk. Het grafische interface is te benaderen vanuit het netwerk waaraan de engine is aangesloten. Hier worden de tools die het interface bezit kort besproken. Het grafische interface bestaat uit 2 delen, namelijk het overzicht en de regel maker. In het overzicht is een lijst met de gemaakte regels te zien. Vanuit hier kan iedere regel aangepast, verwijdert, uit/aangezet en getest worden. De tools die hiervoor beschikbaar zijn gesteld is een API waar een lijst met regels kan worden opgevraagd en waar de genoemde functies kunnen worden aangeroepen. Het tweede deel van het interface is de regel maker.
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 regel te 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 worvel-den ge-sleept. Iedere aangesloten node krijgt een te-gel in de rete-gel maker. Dit vormt een lijst met tegels voor de nodes van de gebruiker. De re-den voor een lijst is dat het rekening houdt met het toevoegen van meerdere nodes, want een lijst kan mee schalen met verschillende hoeveelheden nodes. Bij het openen van de regel maker wordt eerst een request naar de automation engine gedaan voor een lijst met de gekoppelde nodes. Voor iedere gekoppelde node wordt een tegel, een pop-up en een aan-tal controle functies aangemaakt. Dit is te zien in figuur 5.2. De tegel met een plaatje van 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 een veld is gesleept. In deze 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 tijds node 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 door de automation engine meegeleverd bij het laden van het grafische interface. De controle functies worden aangeroepen zodra de gebruiker de regel wil opslaan. Deze functies gaan na of alles correct is ingevuld door de gebruiker. Deze worden apart per node meegeleverd zodat rekening kan worden gehouden met nieuwe nodes, die misschien anders moeten worden gecontroleerd.
Figuur 5.2: Opdeling per node in regel maker
5.2
Samenwerking interface en automation engine bij het maken van
een regel
Voor het aanmaken van een nieuwe regel werken het grafische interface en de engine samen. Het aanmaken van een nieuwe regel is onder te verdelen in de volgende stappen. Zoals te zien is in figuur 4.5. Alles in het interface wordt lokaal door Javascript gedaan. In de automation engine is dit Java.
Figuur 5.3: Samenwerking bij aanmaken van een regel
Gebruiker opent regel maker
De gebruiker opent vanaf het overzichtsscherm de regel maker. Eerst wordt een signaal gestuurd naar de automation engine voor het ophalen van de aangesloten nodes. Deze nodes worden hierna teruggestuurd naar het interface, waarmee de drie delen uit figuur 5.2 gemaakt kunnen worden.
Regel maker wordt zichtbaar
De regel maker wordt zichtbaar voor de gebruiker nadat de lijst met nodes is ontvangen en de tegels zijn aangemaakt. Met deze tegels kan gesleept worden om een nieuwe regel
te vormen. Zodra de gebruiker een regel heeft gevormd en de save functie activeert volgen een aantal controle functies.
Controle functies
Invoer van gebruiker wordt gecheckt op fouten. Eerst wordt gekeken of er geen lege velden aanwezig 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 activatie
De regel wordt in XML omgezet en naar de automation engine toe gestuurd. De automation engine plaatst deze dan tussen de andere regels, waarna de engine wordt herstart.
HOOFDSTUK 6
Openheid en stabiliteit door middel van
modulaire drivers
Het gemaakte platform bezit een open architectuur in een zodanige vorm dat er al rekening is gehouden met niet ondersteunde nodes. De nodes zijn verwisselbaar en maken geen verschil voor de architectuur van de engine zelf, maar wel voor de drivers die de engine gebruikt. Voor iedere ondersteunde node zijn de componenten aanwezig uit figuur 6.1. Voor niet ondersteunde nodes is dit niet het geval. Niet indersteunde nodes kunnen worden aangesloten op het platform door de componenten uit figuur 6.1 toe te voegen. Dit vergt alleen wel programmeerkennis bij de gebruiker.
6.1
Inladen en modulariteit drivers
De gebruiker de mogelijkheid geven om drivers toe te voegen cre¨eert een aantal uitdagingen qua stabiliteit. 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 te
zien is in figuur 6.2. De volgende reden voor het modulair implementeren van drivers is het kunnen testen en toevoegen van nieuwe drivers zonder dat de engine hoeft worden aangepast. De laatste reden is dat de engine niet geleverd hoeft te worden met een overmaat aan drivers. De gebruiker hoeft alleen de drivers binnen te halen voor de nodes die de gebruiker bezit. Bij het 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 zonder de bijbehorende node. De regels die gebruik maken van deze driver zullen worden gedeacti-veerd. Bij het opstarten van de engine laad het de init.class file, die op zijn beurt alle gedefi-nieerde driver files include. Dit mechanisme is te zien in figuur 6.3. Hierna zal initialize() de test functies van de drivers aanroepen. Deze functies doen een poging tot contact met de
bijbehorende node door middel van de test() functie, indien dit niet lukt wordt de driver en de bijbehorende node op non-actief gezet en wordt dit gemeld aan de gebruiker. Als er een driver of node weg valt tijdens het draaien van de engine zal hetzelfde gebeuren als tijdens het niet kunnen laden van een driver.
HOOFDSTUK 7
Resultaten van het open domotica
platform
Het platform is werkend en stabiel. Het afhandelen van errors in drivers verloopt goed, waardoor nog geen vastlopers zijn voorgekomen. Het platform is op te delen in drie delen, namelijk de engine, het interface en de modulaire node drivers. Deze drie delen worden kort behandelt waarna het platform naast de deelvragen wordt gelegd.
Automation engine
De 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 te stellen samen met een event-based implementatie om de regels te volgen. Door middel van de event-based implementatie worden nodes niet onnodig benadert en worden condities pas getoetst zodra het event heeft plaatsgevonden. Indien er een event plaatsvind tijdens het toetsen van een andere regel wordt deze in de queue geplaatst, waardoor geen events worden gemist.
Grafisch gebruikers interface
Het grafische interface geeft gebruikers de mogelijkheid om regels toe te voegen aan het platform. Eerst wordt de lijst met aangesloten nodes uit de automation engine gehaald waarmee het grafische interface de regel maker opstelt. Met deze regel maker kan de gebruiker condities met acties verbinden. Het grafische interface zal ook controleren of de invoer van de gebruiker klopt, voordat dit wordt doorgestuurd aan de automation engine. Modulaire driver implementatie
De gebruiker kan nieuwe drivers schrijven voor nog niet ondersteunde nodes. Deze nodes zijn na het toevoegen van deze drivers beschikbaar voor het maken van nieuwe regels. Deze drivers zijn modulair ge¨ımplementeerd om te voorkomen dat het platform vast loopt als een driver dat doet. Als een driver weg valt wordt deze op non-actief gezet samen met de bijbehorende 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 van onbekende nodes niet kan worden getest. Wel kan het platform zo zijn opgebouwd dat het niet gelijk vast loopt als een driver van een node dat doet. In de automation engine is dit gedaan door alle drivers modulair naast elkaar te draaien. Indien een driver vast loopt wordt dit gemeld 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 het totale platform vast laat lopen. Om een niet ondersteunde node toe te voegen is wel nog steeds
programmeerkennis nodig bij de gebruiker. De gemiddelde gebruiker zal geen programmeerkennis hebben en voor deze gebruiker zal het dan ook niet mogelijk zijn om niet ondersteunde nodes toe te voegen. Dit kan in de toekomst worden verholpen door het delen van drivers.
Delen van drivers
Stel een gebruiker heeft een nog niet ondersteunde node werkend gekregen door een nieuwe driver te schrijven. Deze zou kunnen worden gedeeld met andere gebruikers. Indien genoeg gebruikers deze node met driver hebben getest en aangegeven hebben dat deze werkt kan deze 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 gecre¨eerd dat stabiel draait. Op dit moment is deze openheid alleen voor de gebruiker met programmeerkennis. De toekomst zal uitwijzen of de bovenstaande toevoeging van het delen van drivers het mogelijk maakt dat de 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 te stellen. Dit komt meestal neer op een enkel instellingenscherm. In de gemaakte automation engine 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 aan acties. Dit geeft de gebruiker een grote mate van vrijheid, omdat niks voor de gebruiker wordt beslist. Een nadeel van deze implementatie is dat voor bepaalde functionaliteit meerdere regels nodig zijn. Een voorbeeld hiervan is de thermostaat aanzetten als er iemand thuis is, want dit vereist 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 dit naar voren gekomen door middel van het slepen van tegels. Voor iedere aangesloten CLO is een tegel te vinden in het grafische interface. Zodra deze tegel wordt gebruikt in een nieuwe regel wordt door middel van een pop-up duidelijk welke opties er mogelijk zijn. Deze implementatie geeft de gebruiker totale controle door de gebruiker de tools te geven om zijn eigen regels te programmeren.
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. De controle is gewaarborgd door het model te gebruiken dat condities koppelt aan acties. Wel kan vergeleken worden met platformen zoals IFTTT en scratch, die vergelijkbare implementaties ge-bruiken. Deze platformen zijn erg populair en daaruit kan worden afgeleid dat gebruikers grafisch programmeren snappen.
HOOFDSTUK 8
Conclusie
De gemaakte automation engine werkt en draait met behulp van hardware en nodes die al voor handen waren. Door het gebruik van Java als programmeertaal kan de engine op verschillende typen van hardware draaien. Op de gebruikte hardware draait het stabiel, maar dit is niet getest voor andere typen hardware. De engine reageert op de nodes door middel van een event-based implementatie. Deze oplossing maakt polling overbodig en reageert direct op veranderingen uit de 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 auau-tomation engine zelf, maar de instellingen op te bouwen uit regels. Deze regels bestaan uit condities gekoppeld aan acties. Dit geeft de gebruiker een grote mate van vrijheid, omdat niks voor de gebruiker wordt beslist. Is er een implementatie die openheid kan combineren met stabiliteit? Dit is te combineren door de gebruiker de mogelijkheid geven om zijn eigen drivers toe te voegen. Door deze drivers modulair te draaien zal het platform niet vast lopen als een driver dat doet, waarmee de stabiliteit wordt gewaarborgd. Nadeel hiervan is dat er wel programmeerkennis nodig is om drivers toe te voegen. Door de mogelijkheid toe te voegen van het delen van drivers wordt dit nadeel 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 dit naar voren gekomen door middel van het slepen van tegels. Voor iedere aangesloten CLO is een tegel te vinden in het interface. Zodra deze tegel wordt gebruikt in een nieuwe regel wordt door middel van een pop-up duidelijk welke opties er mogelijk zijn. Dit zorgt voor een begrijpelijke besturing van het platform.
Is het mogelijk om, gebruikmakend van hedendaagse kennis uit het Internet of Things 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 al bestaande hardware en nodes een stabiel en flexibel domotica platform is te bouwen. Door middel van 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 volledig in te stellen door de gebruiker met behulp van het condities met acties model.
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, and
future 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 blocks for the internet of things. ”Internet Computing, IEEE”, 2010.
[8] Rajeev Piyare. Internet of things: Ubiquitous home control and monitoring system using android based smart phone. Department of Information Electronics Engineering, Mokpo National 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.
