Oscar Fredriksson
Mittuniversitetet
Avdelningen för informationssystem och teknologi (IST) Huvudområde: Datateknik
Högskolepoäng: 15hp Termin, år: VT, 2020
Handledare: Roger Olsson, roger.olsson@miun.se
Staffan Olsson, staffan.olsson@permobil.com Examinator: Patrik Österberg, patrik.osterberg@miun.se Program: Civilingenjör i Datateknik, 300hp
Sammanfattning
Smarta hem är en snabbt växande marknad idag som blir allt mer popu- lärt att använda för att underlätta vardagen. För människor som är rörel- sehindrade kan dessa system vara till extra stor hjälp.
Permobil är ett företag som tillverkar elektriska rullstolar och de arbe- tar ständigt med tekniklösningar som kan underlätta vardagen för deras kunder. Syftet med detta arbete var därför att undersöka hur Permobil kan hjälpa sina kunder genom att integrera sig mot smarta hem.
Användarnas behov kring en smart hem-integration har undersökts med enkätfrågor, där responsen pekar på ett tydligt intresse hos användarna.
Olika sätt att integrera dessa behov har undersökts där automationsram- verket IFTTT verkar lämpa sig bäst i dagsläget och har därför använts för att ta fram en prototyp. Den slutgiltiga prototypen är en fullt fungerande integration mot IFTTT som kan ansluta en användares rullstol till tjänsten med information från Permobils API.
Nyckelord:Smarta Hem, IFTTT, Automatisering, Permobil
Abstract
Smart homes is an ever growing market today and are being used to make everyday life a bit easier. For someone with a movement disability a smart home can be of extra great help.
Permobil is a company that make powered wheelchairs and they are con- stantly working with new technology that can assist their customers furt- her. The purpose of this project was to research how Permobil can help their customers by integrating their chairs towards smart homes.
Permobils customers interest in a smart-home integration has been ana- lyzed using survey questions, where the result points to a clear interest.
After this different integration methods were looked at where the auto- mation tool IFTTT seems to be the most suitable today and have been used to implement a prototype. The finished prototype is a fully working integration towards IFTTT that can connect a users chair to the service using information from Permobils API.
Keywords:Smart Homes, IFTTT, Automation, Permobil
Förord
Jag vill tacka min handledare Roger Olsson på Mittuniversitetet som har varit till bra hjälp i rapportskrivandet och har väglett mig genom hela arbetet.
Jag vill även tacka alla på Permobil som på något vis har hjälpt mig i mitt arbete. Det har varit både roligt och lärorikt att se hur er verksamhet fungerar och få möjlighet att göra detta arbete hos er.
Extra stort tack till Staffan och Björn som har stöttat och hjälpt mig genom hela detta projekt, samt även Christoffer som har hjälpt till med API och server-justeringar.
Stort tack!
1 Introduktion 2
1.1 Bakgrund och problemmotivering . . . 2
1.2 Övergripande syfte . . . 2
1.3 Avgränsningar . . . 2
1.4 Konkreta och Verifierbara mål . . . 3
1.5 Disposition . . . 3
1.6 Författarens bidrag . . . 3
2 Teori 4 2.1 Permobils system idag . . . 4
2.2 Ramverk och mjukvaror . . . 5
2.2.1 Node.js . . . 5
2.2.2 Express.js . . . 5
2.2.3 MongoDB . . . 5
2.2.4 Mongoose . . . 5
2.2.5 Cron . . . 5
2.2.6 Node Package Manager . . . 5
2.2.7 Typescript . . . 6
2.2.8 Angular . . . 6
2.2.9 Git . . . 6
2.2.10 Postman . . . 6
2.2.11 Trello . . . 6
2.3 Server-to-server kommunikation . . . 7
2.4 OAuth2 autentisering . . . 7
2.5 Smarta hem . . . 7
2.6 Integration mot ett smart hem-system . . . 7
2.6.1 Direkt integration . . . 7
2.6.2 IFTTT . . . 8
2.7 Raspberry Pi . . . 9
2.8 Relaterat arbete . . . 9
3 Metod 11 3.1 Arbetsgång . . . 11
3.1.1 Förstudie . . . 11
3.1.2 Behovsanalys . . . 11
3.1.3 Integrationsval . . . 12
3.1.4 Prestandatester . . . 12
3.1.5 Prototyp . . . 12
3.2 Planering . . . 13
3.3 Verktyg . . . 13
3.3.1 Programspråk . . . 14
3.3.2 Mjukvaror . . . 14
3.3.3 Test av endpoints . . . 14
4 Implementation 16 4.1 Integrationssätt . . . 16
4.1.1 Lokal-integration . . . 16
4.1.2 Moln-integration . . . 17
4.1.3 Kombinerad integration . . . 17
4.1.4 IFTTT-integration . . . 18
4.1.5 Tidsmätning av IFTTT . . . 19
4.1.6 Integrationsval för prototyp . . . 20
4.2 Prototyp . . . 20
4.2.1 Användarautentisering . . . 22
4.2.2 Trigger . . . 24
4.2.3 Kontroll av event . . . 26
4.2.4 Realtime API . . . 27
4.2.5 Trigger-fält . . . 28
4.2.6 Kodstruktur . . . 28
5 Resultat 30 5.1 Enkätresultat . . . 30
5.2 Implementationsval . . . 32
5.3 Prestandaanalys . . . 33
5.4 Prototyp . . . 34
6 Slutsatser 36 6.1 Utvärdering av behovsanalys . . . 36
6.2 Utvärdering av implementationsval . . . 37
6.3 Utvärdering av prototyp . . . 37
6.4 Vidareutveckling . . . 38
6.4.1 Systemarkitektur . . . 38
6.4.2 Bedömning av när ett event har inträffat . . . 38
6.5 Etiska och samhälleliga aspekter . . . 39
Bilaga A Enkät 1
Bilaga B Triggers 6
Bilaga C Projekt- och databasstruktur 9
Terminologi
API Application programming interface HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure IFTTT If This Then That
JSON JavaScript Object Notation REST Representational State Transfer SSH Secure Shell
GPS Global Positioning System
1 Introduktion
1.1 Bakgrund och problemmotivering
Personer som är i behov av en rullstol kan ha extra svårt med vardag- liga uppgifter som att tända/släcka belysning eller nå fjärrkontrollen till TVn. I och med att smart hemteknik börjar bli allt mer vanlig har personer med någon form av funktionsnedsättning möjlighet att kunna anpassa tekniken i sitt hem utefter deras behov. Dessa personer kan till exempel använda sig av smart belysning för att slippa behöva nå en lampknapp och istället kunna tända lyset med en app, eller istället för att behöva nå fjärrkontrollen kunna styra TVn med röstkommandon.
Permobil är ett företag som tillverkar elektriska rullstolar och de arbetar ständigt med tekniklösningar som kan underlätta vardagen för sina kun- der. Permobils stolar har idag uppkoppling mot molnet, men saknar stöd för hemautomatiseringssytem och företaget vill därför undersöka möjlig- heten av denna integration för att hjälpa sina kunder ytterligare.
1.2 Övergripande syfte
Syftet med detta examensarbete är att undersöka Permobilanvändares be- hov av att få sin elektriska rullstol ihopkopplad med sitt smarta hem. I en behovsanalys kommer både det generella behovet undersökas samt även vilken funktionalitet användarna är i behov av. Utifrån den funktionalitet som lyfts fram i behovsanalysen kommer en metod för att implementera detta att undersökas för att sedan kunna skapa en fungerande prototyp.
1.3 Avgränsningar
Permobil AB tillverkar både eldrivna och handdrivna rullstolar. På grund av att de personer som är i behov av en eldriven rullstol troligtvis är i större behov av stöd i vardagen än de som använder sig av en handdriven rullstol kommer detta arbete att fokusera på endast denna målgrupp.
Vidare har arbetet avgränsats till att endast undersöka automationsram- verket IFTTT, vad detta är förklaras i avsnitt 2.6.2. Permobil utryckte vid projektstart att om ett ramverk ska användas är det IFTTT de vill satsa på. De ytterligare avgränsningar som har gjorts under projektets gång be- skrivs i respektive delkapitel.
1.4 Konkreta och Verifierbara mål
För att uppfylla projektets syfte har det brutits ner i konkreta och verifier- bara mål. Arbetet har som mål att:
1. Ta reda på vilken funktionalitet användare av elektriska rullstolar har behov av att få integrerad med sitt smarta hem.
2. Utvärdera om automationsramverket IFTTT kan användas för att implementera noterad funktionalitet från mål 1.
3. Utföra tidsmätningar och tester av IFTTT för att utvärdera om tjäns- ten kan prestera så att funktionalitet inte blir begränsad av drift- stopp och/eller fördröjningar.
4. Ta fram en prototyp som implementerar noterad funktionalitet från mål 1 och därmed kan fungera som ett proof of concept.
1.5 Disposition
Denna rapport är uppdelad i sex huvudkapitel. I teoriavsnittet presente- ras den bakgrundsfakta läsaren behöver för att förstå rapportens övriga delar. Metodavsnittet beskriver det arbetssätt som har tillämpats under projektets gång och sedan presenteras arbetssättets praktiska utförande i implementationsavsnittet. I resultatavsnittet presenteras arbetets slutgil- tiga resultat och sedan kopplas dessa till frågeställningen i slutsatsavsnit- tet där de utvärderas och diskuteras.
1.6 Författarens bidrag
Arbetet har inte byggt vidare på någon tidigare studie, utan har byggt vidare på den grundidé Permobils systemutvecklare hade som inledande frågeställning. Arbetet har utförts på egen hand, men med nära samarbete och assistans av flera av de anställda på företaget.
2 Teori
I detta teoriavsnitt presenteras bakgrundsinformation för att underlätta läsandet av rapportens övriga delar.
2.1 Permobils system idag
Permobils elektriska rullstolar [1] drivs idag av en platform som kallas för Power platform. Denna har drivmotorer för att både kunna köra runt med stolen samt för att ändra vinkel på stolens ryggstöd, fotstöd och sits, samt att flytta sitsen upp eller ner.
Stolen har inbyggd GPS för att kunna logga sin egen position samt blue- tooth och en 4G uppkoppling för att kommunicera med Permobils appar;
MyPermobil och Virtual Seating Coach. 4G uppkopplingen används även för att kommunicera med Permobils molnbaserade REST API där da- tauppdateringar skickas med 10 minuters intervall. En GPS-uppdatering loggas och skickas till API:et varje 100 meter som stolen har kört. En över- siktsbild över hur stolens Power platform kommunicerar med appar och API kan ses i figur 1.
Figur 1: Översiktsbild av Permobils system idag
2.2 Ramverk och mjukvaror
Detta delavsnitt presenterar bakgrundsfakta om de olika ramverk och mjukvaror som arbetet har tillämpat.
2.2.1 Node.js
Node.js [2], eller endast Node, är ett open source ramverk för att exekvera programspråket Javascript på en server. Node är bland annat populärt för att skapa webbservrar.
2.2.2 Express.js
Express [3] är ett ramverk för att skapa webbservrar och API:er i No- de. Ramverket tillhandahåller metoder för att skapa rutter och funktioner som hanterar HTTP-förfrågningar som GET, POST och DELETE och har idag näst intill blivit standard för att göra detta i Node.
2.2.3 MongoDB
MongoDB [4] är en databas som använder sig av JSON-liknande doku- ment för att lagra data. MongoDB är vad som kallas för en NoSQL databas [5], vilket innebär att den lagrar data på ett annat vis än relationstabeller.
2.2.4 Mongoose
Mongoose [6] är ett ramverk för Node som hjälper användaren att ska- pa starkt-typade scheman som hanterar kopplingen mellan objekt i kod och objekt i databasen. Detta hjälper att validera ett databas-dokuments innehåll innan det sätts in i databasen, vilket ofta behövs då MongoDB i grunden är struktur- och typlös. ss
2.2.5 Cron
Cron [7] är ett Javascript-bibliotek för att schemalägga exekvering av pro- gramkod. Cron gör det möjligt att exempelvis varje halvtimme köra en specifik funktion i sitt Javascript projekt.
2.2.6 Node Package Manager
Node package manager [8], eller npm, är ett verktyg för att hantera och dela Node.js moduler. Npm gör det enkelt att hantera de bibliotek som ett projekt förlitar sig på. Npm används bland annat för att installera de Node.js ramverk som beskrivits tidigare i avsnitt 2.2.2, 2.2.4 och 2.2.5.
2.2.7 Typescript
Typescript [9] är en vidareutveckling av programspråket Javascript med syftet att skapa starkt typad kod. Typescript kompilerar den skrivna ko- den till ren Javascript. Genom att starkt typa sin annars typlösa Javascript kod med hjälp av Typescript fångas typfel och andra triviala skrivfel vid kompilering vilket gör koden enklare att skriva och underhålla.
2.2.8 Angular
Angular [10] är ett Typescript-baserat ramverk för att utveckla hemsidor.
Angular delar upp en hemsida i komponenter som sedan kan användas som HTML-element. Angular har många färdiga komponenter komplet- ta med stilmallar vilket gör det enkelt att snabbt komma igång med en dynamisk och snygg hemsida. Angular introducerar även stöd för dyna- misk data-bindning, där användarens inmatning i ett formulär kan vali- deras direkt när det anges. Detta gör Angular till ett kraftfullt ramverk för malldrivna formulär som kräver datavalidering.
2.2.9 Git
Git [11] är ett versionhanteringsverktyg utvecklat både för att underlätta samarbete mellan flera utvecklare samt för att skapa backuper och hante- ra olika versioner av sitt projekt.
2.2.10 Postman
Postman [12] är ett verktyg för att testa förfrågningar mot ett REST API.
Postman låter användaren på ett enkelt vis testa bland annat GET- och POST-förfrågningar utan att behöva skriva massa kod och kan därför an- vändas för att underlätta utvecklingsarbete.
2.2.11 Trello
Trello [13] är ett planeringsverktyg där enkla uppgifter kan sättas upp och grupperas med hjälp av listor och kort. Dessa kan sedan prioriteras, tag- gas och beskrivas med hjälp av färgkodning, förfallodatum, checklistor, mm, och de olika korten kan sedan flyttas mellan de olika listorna för att skapa en flexibel planeringstavla.
2.3 Server-to-server kommunikation
Server till server kommunikation, ibland kallat S2S eller inter-server på engelska, innebär att data byts direkt mellan två servrar utan inblandning från en klient.
2.4 OAuth2 autentisering
OAuth2 [14] är ett protokoll för att godkänna en ihopkoppling mellan olika tjänster. Oauth2 kan fungera på ett antal olika sätt, men den vanli- gaste modellen tillämpar en tvåstegsmetod där en kod först skapas som sedan byts mot en token. Denna används sedan av den ena tjänsten för att kommunicera med den andra. En kod skapas genom att användaren godkänner ihopkopplingen med hjälp av en inlogging eller liknande, se- dan skickas koden till den tjänst som ska godkännas. Denna frågar sedan den andra tjänstens server för en token med denna anslutningskod där en sådan fås som svar om koden är giltig. Tjänsten kan sedan använda sig av denna token för att skicka förfrågningar till den anslutna tjänsten. Ef- tersom en token aldrig skickas till en klient samt endast kan skapas utifrån en klient-godkänd kod är OAuth2 ett säkert protokoll för detta ändamål.
2.5 Smarta hem
Ett smart hem är en generell term för att enheter i hemmet är uppkopp- lade i syfte att underlätta för de som bor där. Detta kan till exempel vara lampor som kan styras med en mobilapp, termostater som automatiskt re- glerar temperaturen beroende på tid på dygnet eller röstassistenter som Google Home [15] och Alexa [16].
2.6 Integration mot ett smart hem-system
Flera smarta hem-system och sensorer integrerar sig mot varandra för att skapa ett större värde hos användaren. Ett exempel är att en lampa tänds om en termometer placerad i kylen detekterar att temperaturen är högre än vanligt. Dessa integrationer kan kommunicera med varandra på ett antal olika vis.
2.6.1 Direkt integration
Ett smart hem-system består ofta av att användaren har en hubb1 som sedan kommunicerar lokalt med resten av den hårdvara som användaren
1En hubb innebär i detta fall en central kontrollenhet som styr övriga enheter
har i hemmet. Detta sker ofta via protokollet Zigbee [17], Z-Wave [18] eller i vissa fall bluetooth [19]. Användaren kan sedan styra sin hårdvara via en applikation som kommunicerar med hubben över Wi-Fi. Hubb är ofta internetansluten för att låta användaren styra sina enheter när denna inte är hemma. Hubben kommunicerar då med en molntjänst som svarar på förfrågningar från användaren. Figur 2 visar ett blockdiagram på hur ett sådant system kan se ut.
Figur 2: Kommunikationsdiagram för ett typiskt smart hem- system. Orange pil visar koppling mellan ett smart hem-system och dess app.
Om en integration mot ett smart hem ska uppnås kan en integration där- för skapas direkt mot denna hubb via användarens lokala nätverk. Denna integration får då tillgång till alla enheter anslutna till denna hubb. Alter- nativt kan en integration skapas mot dess molntjänst för att även kunna styra enheter när användaren inte är hemma.
2.6.2 IFTTT
Ett annat alternativ är att använda sig av tjänsten IFTTT [20]. IFTTT, eller If This, Then That, är en molnbaserad tjänst för att sammankoppla flera smarta system med hjälp av vad de själva kallar för Applets. En Applet består av ett kriterium samt en eller flera händelser. Detta kan till exem- pel vara: när GPSen i användarens mobil är nära hemma; tänd lamporna
vid dörren. IFTTT kräver endast att ett företag ansluter sin produkt till tjänsten och sedan kan användaren koppla ihop produktens händelser och funktioner med samtliga andra produkter på IFTTT.
En ihopkoppling med IFTTT sker via server-to-server-kommunikation där IFTTT använder sig av en pollningsarkitektur2 för att söka efter ny data på tjänstens server. Företaget IFTTT förklarar själva att detta är för att in- te missa data utifall antingen IFTTT eller tjänstens server upplever drift- stopp. Pollningsfrekvensen kan variera och företaget förklarar därför att om man vill att IFTTT ska hämta data när den blir tillgänglig bör deras Realtime API [21] användas. [22] Realtime APIet skickar inte data direkt till IFTTT, utan fungerar endast som en notis till IFTTT om att det finns ny data att hämta.
Ytterliggare terminologi som används av IFTTT, och därför även kommer nämnas senare i denna rapport, presenteras i tabell 1.
Tabell 1: Terminologi som används av IFTTT.
Term Förklaring
Applet Kallades förut för ett recept. Den ihopkoppling IFTTT skapar mellan två tjänster.
Trigger This delen av en applet.
Action That delen av en applet.
TriggerField En parameter användaren kan specificera vid skapan- det av en applet.
Ingredient Varje trigger innehåller data, detta kallas för ingredien- ser.
2.7 Raspberry Pi
Raspberry Pi [23] är en liten enchipsdator som kör linux. En Raspberry Pi lämpar sig väl för projekt som kräver en enkel server på grund av dess formfaktor. Några vanliga användningsområden är enkla webbservrar, smarta hem-hubbar och media center.
2.8 Relaterat arbete
I artikeln An Empirical Characterization of IFTTT: Ecosystem, Usage and Per- formance [24] analyserar författarna bland annat IFTTTs prestanda. De sat- te upp en egen test-tjänst för att utvärdera IFTTTs prestanda och deras re- sultat pekar på att fördröjningen är lång (oftast 1 till 2 minuter) med hög
2Pollning innebär att ny data sökes efter med jämna intervall
varians (upp till 15 minuter). De utvärderar även IFTTTs realtime API och kommer fram till att det inte ger någon prestandaökning för deras service.
De föreslår därför att IFTTT ignorerar realtime API-notiser och endast an- vänder de för att anpassa pollningsfrekvensen. De förklarar att IFTTT be- höver anpassa sin egen arbetsbelastning och om det sker för många real- time API-förfrågningar samtidigt måste några ändå vänta.
3 Metod
Detta arbete kommer utföras på företaget Permobil ABs mjukvarutveck- lingsavdelning i Sundsvall, där handledning och hjälp kommer ges av de anställda under projektets gång. Tillsammans med handledaren på företa- get kommer den agila arbetsmetoden scrum [25], där avstämningsmöten planeras hållas med regelbundna intervall.
3.1 Arbetsgång
Detta arbete kommer delas upp i tre distinkta delar: behovsanalys, imple- mentationsval och prototyp, där varje del vägleder nästföljande.
3.1.1 Förstudie
För att få bra koll på vad som idag är möjligt med smarta hem-system kommer några dagar under projektets start ägnas åt att undersöka da- gens marknad. I denna förstudie undersöks även Permobils system idag genom att fråga handledare och anställda på företaget för att få en god bild över vad som potentiellt är möjligt och icke möjligt.
3.1.2 Behovsanalys
Projektets tidiga delar kommer ägnas åt att undersöka användarnas be- hov av att ha sin elektriska rullstol ihopkopplad med sitt smarta hem.
Detta kommer utföras med hjälp av en enkät som skickas till användare av elektriska rullstolar. Enkäten kommer ha både syftet att ta reda på in- tresset kring en potentiell Permobil-integration, samt att undersöka vilket allmänna intresse användarna har kring smarta hem system, där frågor kommer ställas om de idag har några system samt isåfall vilken funk- tionalitet dessa har. De personer som idag sitter i en modern ansluten Permobil-rullstol har godkänt Permobils avtal om att skicka data från de- ras stol över internet och det kommer därför inte ställas några frågor om denna säkerhet- och integritetsaspekt, utan fokus är endast på funktiona- litet.
Enkäten planeras skickas ut till en grupp användare som sitter i en mo- dern Permobil-rullstol och därmed är väl insatta i vilka möjligheter som finns med denna idag. Denna grupp har tidigare varit med och gett åter- koppling på andra projekt Permobil arbetar med och representerar därför väl den tänkta målgruppen.
3.1.3 Integrationsval
Efter att behovsanalysen utförts, kommer dess resultat utvärderas för att välja ett tillvägagångssätt för prototypen. Detta kan ske på de olika vis som diskuterades i avsnitt 2.6. IFTTT kommer med den stora fördelen att det enkelt kan integreras med väldigt många system, men det kräver också att användaren har en stabil internetuppkoppling för att fungera.
Det kan därför vara till vissa användares fördel att deras elektriska rull- stol kan kommunicera direkt med den hårdvara de har i hemmet, utan att behöva gå via någon molntjänst, då detta inte kräver någon internetupp- koppling alls. Dock kräver detta troligtvis mer arbete då en integration behöver byggas för varje enhet det ska finnas stöd för. Dessa olika tillvä- gagångssätt kommer med sina egna för- och nackdelar och de har därför analyserats för att välja den lösning som skapar störst värde hos Permo- bils användare.
3.1.4 Prestandatester
Under arbetets integrationsvalsdel kommer även prestandatester utföras mot IFTTT för att utvärdera ramverket. Detta planeras utföras i form av tidsmätningar där både IFTTTs grundtjänst med endast regelbunden poll- ning, samt deras Realtime API kommer att testas. En enkel integration mot tjänsten kommer utvecklas för att utföra dessa tester. Om en slutgil- tig prototyp skapas mot IFTTT kommer denna bygga vidare på samma test-integration som skapas här och prestandatester kommer därför med stor sannolikhet att ge samma resultat. Ytterligare prestandatester för en sådan integration kommer därför inte att utföras.
3.1.5 Prototyp
Projektets slutgiltiga del kommer tillägnas åt att skapa en prototyp för den lösning som anses bäst utifrån den analys som gjordes i 3.1.3. Den- na prototyp kommer ha det huvudsakliga syftet att kunna demonstrera hur en sådan integration kan se ut samt hur dess funktionalitet kan im- plementeras i Permobils idag existerande system för att därmed kunna användas som ett proof of concept.
3.2 Planering
En övergripande planering gjordes vid projektets start i form av ett Ganttsche- ma. Denna kommer inte följas till punkt och pricka under projektets gång utan kommer användas som riktlinje för ungefär när projektets olika de- lar bör vara klara. Ganttschemat kan ses i figur 3.
Figur 3: Övergripande ganttschema som skapades vid projektstart
För att under projektets gång hålla koll på vad som behöver göras kom- mer en Trello-tavla användas där uppgifter kommer sättes upp och prio- riterades under projektets gång. Se figur 4 för en bild på projektets Trello- tavla ett antal veckor in i projektet.
Figur 4: Projektets Trello-tavla
3.3 Verktyg
De programspråk, ramverk och utvecklingsmiljöer som kommer använ- das har valts utifrån vad Permobil använder sig av idag i existerande sy-
stem. Detta val gjordes då det både gör det lätt att få hjälp under pro- jektets gång, samt gör det lättare för Permobil att ta över projektet och fortsätta arbete med det efter projektets slut om så skulle önskas.
3.3.1 Programspråk
Server kommer skrivas i Typescript, där kod exekveras på servern med hjälp av Node. Ramverken express och mongoose används för att under- lätta hantering av HTTP-requests och koppling till databasen i MongoDB.
Frontend-delar kommer utvecklas med hjälp av Angular.
3.3.2 Mjukvaror
All kod för både backend och frontend kommer skrivas i textredigeraren Visual Studio Code [26]. För att under utveckling kunna undersöka och redigera databasens innehåll kommer Studio 3T [27] användas.
Server och databas kommer placeras på en av Permobils testservrar, där SSH [28] kommer användas för att ansluta till denna. Både Visual Stu- dio Code och Studio 3T har stöd för SSH, och därför kommer utveckling utförts direkt mot servern utan att behöva skriva koden lokalt innan den laddas upp och testas. I Studio 3T är detta stöd inbyggt och i Visual Studio Code använts ett tillägg [29].
Verktyget Postman kommer användas för att testa API endpoints under utveckling av prototypen, samt även för att kunna testa hur förfrågningar till andra API:er bör formuleras för att få tillbaka önskad data.
För att regelbundet skapa nya versioner av den kod som skrivs kommer git använts. Detta skapar backups med jämna mellanrum samt gör det även enkelt att byta mellan att arbeta med koden på eventuell Permobil server och lokalt på olika datorer.
Flödesscheman, arkitekturbilder och databasscheman i denna rapport är skapade med hjälp av gratisverktyget draw.io [30], där ett antal olika iko- ner från flaticons.com [31] har använts.
3.3.3 Test av endpoints
För att testa sin integration och se till att IFTTT får all data de behöver for- matterad på rätt vis finns två stycken test-verktyg tillgängliga. Det första [32] är för att se till att Oauth2 flödet mellan en tjänst och IFTTT sker kor- rekt. Verktyget säkerställer att flödet sker på korrekt vis och att all data är korrekt formaterad.
Det andra verktyget [33] testar samtliga trigger-endpoints genom att skic- ka en förfrågan till dessa och sedan kolla om det den får som svar är korrekt formaterat. Verktyget testar både korrekta förfrågningar samt för- frågningar där data är felformaterat för att säkerställa att den får ett kor- rekt felmeddelande som svar. Båda dessa verktyg kommer användas i kombination med egna tester för att säkerställa att prototypen fungerar som den ska.
4 Implementation
I detta avsnitt presenteras det integrationsval som gjordes för prototypen, följt av beskrivning hur prototypens funktionalitet är framtagen.
4.1 Integrationssätt
I avsnitt 2.6 presenterades tre olika tillvägagångssätt för en integrering mot ett smart hem. I detta kapitel kommer dessa tillvägagångssätt att un- dersökas noggrannare för att se hur en integration för Permobil skulle se ut i dessa tre olika fall. Vidare presenteras enkätens resultat i avsnitt 5.1, dessa kommer kopplas till i detta kapitel för att motivera det implemen- tationsval som gjordes för prototypen.
I avsnitt 2.6 och figur 2 presenterades ett kommunikationsdiagram för ett typiskt smart hem-system. Diagram i detta avsnitt kommer förenklas något med antagandet att läsaren är bekant med detta övergripande dia- gram.
4.1.1 Lokal-integration
En direkt integration där kommunikationen sker lokalt utan någon inter- netuppkoppling innebär att Permobils API ej kan utnyttjas eftersom det- ta är baserat i molnet. Istället skulle det innebära att stolen direkt skulle kommunicera med användarens hårdvara enligt figur 5.
Figur 5: Kommunikationsdiagram för en integration direkt mot en hubb.
Denna integrationstyp är lämplig för integrationer som kräver så lite tids- fördröjning som möjligt. Eftersom kommunikationen sker på använda- rens lokala nätverk utan att behöva gå över internet minimeras potentiella fördröjningar. Med samma motivering ger detta även säkerhet och skyd- dar användarens data från att potentiellt hamna i fel händer. Nackdelen med detta är, eftersom all kommunikation sker via användarens lokala nätverk, att funktionaliteten endast tillgänglig när användarens rullstol är hemma och har tillgång till detta nätverk.
Denna typ av integration kommer även med ett antal tekniska svårighe- ter. För det första kräver det att den hubb en integreration ska skapas mot har ett tillgängligt API som har stöd för all den funktionalitet Permobil vill uppfylla med sin integration. Alternativt kan Permobil starta ett sammar- bete med en hubb-tillverkare för att tillsammans med tillverkaren skapa en integration mellan dessa system.
Denna typ av integration skulle teoretiskt sätt kunna uppfylla de flesta av de noterade behoven från enkäten. Problematiken här är mängden arbete detta skulle kräva. Eftersom denna metod grundar sig i att bygga en integ- ration direkt mot hårdvara, stödjs endast hårdvara en integration faktiskt skapas mot. Detta innebär att så länge en integration mot något system som stödjer samtlig funktionalitet kan skapas (vilket idag inte finns på marknaden) behöver flera integrationer ske för att uppfylla dessa behov.
4.1.2 Moln-integration
Om en integration ska skapas där det möjliggörs att stolen kommunice- rar med användarens hårdvara när användaren inte är hemma kan en integration mot ett smart hem-systems molntjänst undersökas. Då kan Permobils API utnyttjas för att kommunicera via server-to-server model- len mellan API och molntjänst. Ett diagram för hur en sådan integration skulle se ut kan ses i figur 6.
Figur 6: Kommunikationsdiagram för en moln-integration.
4.1.3 Kombinerad integration
Vidare skulle en kombination av dessa två integrationssätt kunna tilläm- pas, där Permobil integrerar sig både direkt mot hubben samt dess moln- tjänst. På detta vis kan stolen styra användarens smarta hem-system när den inte är hemma samt kommunicera direkt med hårdvaran utan att gå
via internet när den är hemma. Detta är i sig en teknisk utmaning då sto- len själv måste bedöma huruvida den ska skicka instruktioner direkt till hubben via Wifi, eller via API:et. Detta kan lösas genom att stolen kontrol- lerar om den befinner sig på användarens hem-nätverk och utifrån detta bedömer vilken väg den ska skicka instruktionen.
Precis som i 4.1.1 kan denna integrationstyp teoretiskt sätt uppfylla be- hoven från enkäten, men samma problematik kring vad man väljer att integrera sig mot, samt mängden arbete det skulle kräva att skapa flera integrationer, uppstår även här.
4.1.4 IFTTT-integration
Det största problemet med de integrationssätt som presenterades i av- snitt 4.1.1 och 4.1.2 är att något specifikt system måste väljas att integrera sig mot. Därmed riskeras att alla användare inte kan utnyttja tjänsten ef- tersom de kan ha andra system än det Permobil har integrerat sig mot. Ett alternativ till detta är därför att använda tjänsten IFTTT. Då fås direkt stöd för alla system som har anslutit sig till IFTTT. Tjänsten står för kopplingen mellan två stycken API:er och kommer därför att ligga mellan Permobils API och smarta hem-systems molntjänster i kommunikationskedjan, se figur 7.
Figur 7: Kommunikationsdiagram för en integration via IFTTT.
Denna typ av integration skulle kunna täcka majoriteten av enkätens öns- kemål med en enda integration då det finns många anslutna tjänster som kan utföra de önskade uppgifterna. Det som saknas är möjligheten att lå- sa och låsa upp ytterdörren då de smarta dörrlås som har anslutit sig till IFTTT har utelämnat denna funktionalitet av säkerhetsskäl. De har endast triggers för att dörren blir låst eller upplåst och inga actions för att faktiskt utföra detta via IFTTT.
Denna tjänst kommer dock också med sina nackdelar och risker. Genom att förlita sig på en tredjepart på detta vis blir systemet begränsat av både dess prestanda och dess funktionalitet. Om IFTTT skapar stora tidsför- dröjningar i systemet, vilket artikeln som presenterades i avsnitt 2.8 indi- kerar, kan hela systemets funktionalitet bli begränsat till den punkt att det inte längre fyller någon funktion hos användaren.
4.1.5 Tidsmätning av IFTTT
Eftersom en av de potentiella nackdelarna med tjänsten IFTTT är dess prestanda utfördes egna tester av tjänsten. Detta gjordes genom att bygga en enkel integration mot tjänsten via en Node-server som sattes upp med hjälp av IFTTTs Hello World guide [34]. Denna server använder sig av den externa tjänsten glitch.me [35] för att hosta servern. För att ha bättre kontroll över servern placerades denna istället på en lokal Raspberry Pi.
För att göra tidsmätningar sattes två triggers upp i IFTTT-servern, en för att mäta standardpollningen och en för att mäta realtime API:et. Cron an- vänds för att varje halvtimme lägga till ny data för dessa att hämta. När data läggs till för realtime APIet skickas notisen till IFTTT samtidigt. När datat har lagts till startas en timer i servern. Som actions för dessa två applets skapades två actions i servern, när dessa körs stannas timern och den förflutna tiden exporteras till en CSV-fil med en datum- och tidsstäm- pel. Ett flödesschema över hur tidsmätningarna har utförts kan ses i figur 8.
Figur 8: Flödesschema för utförande av tidsmätningar.
Resultatet från dessa tidsmätningar presenteras i avsnitt 5.3, men kan kort sammanfattas till att om Realtime API:et används har IFTTT låg tidsför- dröjning och god stabilitet.
4.1.6 Integrationsval för prototyp
I avsnitt 5.1 presenteras svaren från den datainsamling som gjordes i form av en enkät, hela enkäten med samtliga svar kan ses i bilaga A. Resultaten från denna kan sammanfattas till ett antal punkter:
1. Användarna är i allmänhet intresserade av smarta hem och majori- teten av dem har idag flera olika system.
2. Användarna är intresserade av att få sin stol ansluten till sina smarta hem och visar ett intresse kring den funktionaliteten som potentiellt går att integrera.
3. Användarna har system från många olika tillverkare.
4. En stor majoritet av användarna har en snabb och stabil internetupp- koppling.
IFTTT valdes som integrationssätt för prototypen framförallt på grund av punkt 3 men också på grund av punkt 4 i kombination med de resultat som sågs i de tester som utfördes mot IFTTT. Vidare kan även många behov lösas idag med redan existerande smarta hem-system där det är något oklart vad en Permobil-integration skulle kunna tillföra. Vad som därför var intressantare att undersöka var möjligheten för användare att använda sin stol som en sensor och automatisera sitt smarta hem med hjälp av den data som finns i stolen. För detta ändamål öppnar IFTTT upp flest möjligheter mot alla de olika system som har anslutit sig dit och motiverar därför ytterligare prototypens integrationsval.
4.2 Prototyp
Prototypen har skapats genom att följa IFTTTs dokumentation [36] för att skapa en integration. Tjänsten skapas på platform.ifttt.com där triggers och actions sätts upp tillsammans med API URL:er.
Ett antal förslag på triggers från enkäten valdes i detta skede bort från att utvecklas vidare. Samtliga GPS-baserade från enkäten valdes bort från att implementeras i prototypen efter ett beslut tillsammans med Permobil.
Detta på grund av att de kommer bli begränsade och svåra att implemen- tera på ett bra sätt på grund av att GPS-uppdateringar endast sker varje 100 meter och det kommer då behövas en stor radie för att dessa ska fun- gera väl. Istället implementerades en rörelseaktiverad GPS-trigger som aktiveras när en användare är ute och kör. Vidare så valdes även triggern för att stolen kommer in i ett specifikt rum bort även den på grund av teknisk begränsning. Övriga triggers från enkäten implementerades på grund av det intresse som noterades. Det implementerades även triggers
för att stolen börjar- samt slutar ladda då denna idé kom efter enkäten ha- de skickats ut och de var trivialt att implementera när kodstruktur fanns för övriga triggers. Implementerade triggers presenteras i tabell 2. Dessa presenteras mer omfattande i bilaga B där även ingredienser och trigger- fält listas.
Tabell 2: De triggers som har implementerats i prototypen
Triggernamn Aktiveras när?
Starts Charging När stolen börjar ladda Stops Charging När stolen slutar ladda Fully Charged När stolens batteri når 100%
Battery Low När stolens batteri går under 15%
Battery Level När stolens batteri går över / under en gräns satt av användaren.
Need Service Stolen rapporterar en felkod med varningsnivå error.
Chair Is Moving När tre GPS-uppdateringar har skett inom 10 minu- ter.
Adjustments Before Time Om användaren inte har gjort ett försatt antal sittpo- sitionsändringar före ett bestämt klockslag.
Sitting Still Long Om användaren inte har ändrat sittposition på ett försatt antal minuter.
Vid projektets sista del var denna prototyp redan påbörjad eftersom en enkel tjänst mot IFTTT redan var framtagen för att utföra tidsmätningar av tjänsten. Vid detta tillfälle flyttades denna till en av Permobils test- servrar för att möjliggöra användandet av en databas samt underlätta kommunikation med Permobils API. Prototyp-servern står för koppling- en mellan IFTTT och Permobils API. En översiktsbild över prototypens systemarkitektur kan ses i figur 9.
Figur 9: Prototypens systemarkitektur.
4.2.1 Användarautentisering
När en användare för första gången ska ansluta sin stol till IFTTT gör de detta genom att länka sitt MyPermobil konto som sedan står för koppling- en till deras stol. Denna anslutning innehåller skapande av två stycken anslutningstokens, en för kommunikation mellan IFTTT och Prototypser- vern samt en för kommunikation mellan Prototypservern och Permobils API, båda dessa sker via protokollet Oauth2. En anslutningstoken är i det- ta fall en sträng med bokstäver som berättar för de båda API:erna vilken användare en förfrågan gäller.
Det första steget i denna anslutning är att användaren klickar på Connect Permobil hos IFTTT. IFTTT skickar vidare användaren till en anslutnings- sida där användaren ombeds ange in sin epost-adress. Prototypservern frågar Permobils API efter en anslutningskod för denna epost-adress som sedan kommer till användaren via e-post i form av en sexsiffrig kod. När användaren har angett dessa sex siffror på anslutningssidan skickas ko- den till Permobils API som svarar med en anslutningstoken. Vid detta tillfälle skapas en användare i databasen och denna token läggs till, ett fullständigt databasschema presenteras i bilaga C och figur C.2. Denna används sedan för att hämta användarinformation i form av för- och ef- ternamn från Permobils API som även det sparas till användaren i data- basen. Oauth2 kedjan för Permobils API är nu klar och prototypservern kan göra förfrågningar till Permobils API med denna token.
Vidare påbörjas Oauth2 för IFTTT vid detta tillfälle genom att en anslut- ningskod genereras av prototypservern i form av en 32 tecken lång sträng bestående av slumpade bokstäver. Användaren skickas tillbaka till IFTTT med koden som en URL-parameter. IFTTT frågar sedan prototyp API:et efter en anslutningstoken via en POST-request med koden som parame- ter. Servern genererar en 64 tecken lång token och skickar denna som
svar. Slutligen frågar IFTTT om användarens namn med denna token och vid detta tillfälle är anslutningsprocessen klar. Ett flödesschema för denna process kan ses i figur 10.
Figur 10: Flödesschema över autentiseringsprocessen
Den anslutningssida användaren skickas till från IFTTT är skriven i An- gular och rendreras av Express servern. Sidan är uppdelad i två delar, en för att ange epost-adress och en för att ange anslutningskod. Dessa två sidor kan ses i figur 11.
Figur 11: De två olika sidorna användaren besöker under anslut- ningsprocessen
Om en felaktig anslutningskod angels kommer Permobils API svara med status kod 403. Om detta sker visas ett meddelande för användaren som berättar att koden inte är korrekt och ger denna möjlighet att rätta till sitt misstag och prova skicka igen.
Datavalidering sker med hjälp av Angulars inbyggda valideringsramverk [37] som används för att kontrollera att inmatningen är en korrekt epost- adress, samt att kodinmatningen innehåller sex stycken siffror. Om dessa kriterium inte är uppfyllda under datainmatningen tillåts ej användaren att skicka formuläret då submit-knappen endast blir klickbar när korrekt data har matats in.
4.2.2 Trigger
IFTTT hämtar ny data för en trigger med en POST-förfrågan där varje trigger har en egen unik endpoint. IFTTT skickar den token som skapa- des för användaren i 4.2.1 som en header med nyckel authorization. För varje unik kombination av användare, trigger och triggerfält skapar IFT- TT en trigger-identitet. Denna skickas med som en parameter i förfrågans JSON-kropp. I denna JSON-kropp skickas även ett nästat objekt med den tidszon användaren har specificerat för sitt IFTTT-konto samt ett objekt med trigger-fält data om triggern har sådan. Ett exempel på en sådan för- frågan kan ses i figur 12.
P O S T { {a p i _ u r l} }/ i f t t t / v1 / t r i g g e r s /{ {t r i g g e r _ n a m e} } A u t h o r i z a t i o n: B e a r e r
b 2 9 a 7 1 b 4 c 5 8 c 2 2 a f 1 1 6 5 7 8 a 6 b e 6 4 0 2 d 2 Content - T y p e: a p p l i c a t i o n / j s o n {
" t r i g g e r _ i d e n t i t y ": " 9 2 4 2 9 d 8 2 a 4 1 e 9 3 0 4 8 ",
" u s e r ": {
" t i m e z o n e ": " E u r o p e / S t o c k h o l m "
},
" t r i g g e r _ f i e l d s ": {
" d u r a t i o n ": 60 }
}
Figur 12: Ett exempel på en POST-förfrågan från IFTTT för att hämta ny trigger-data.
När denna förfrågan tas emot kommer servern att spara trigger-identiteten i databasens triggerInfo-kollektion tillsammans med dess namn, token för den användare den tillhör samt potentiellt även dess trigger-fält-data och servern kan på så vis veta vilka triggers en specifik användare har an- slutit. Om en användare slutar använda en trigger (genom att ta bort en applet) skickar IFTTT en DELETE-request med trigger-identiteten som en URL-parameter till triggerns endpoint och servern tar då bort den från triggerInfo-kollektionen.
Som svar på en trigger-förfrågan ska tjänsten svara med de 50 senaste eventen. Varje event har ett unikt id som IFTTT använder för att bedöma om ett event är nytt och isåfall ska köra motsvarande action. Alltså ska alltid alla 50 senaste event skickas, oavsett om dessa har setts av IFTTT tidigare eller ej. Denna lista med events skickas till IFTTT i form av en JSON-array där varje objekt i listan är ett unikt event. Ett event innehåller ett nyckelvärdespar för varje trigger-ingrediens samt ett nästat objekt med meta-data. Meta-datat innehåller ett unikt id för eventet, samt en Unix- tidsstämpel [38]. Ett exempel på en respons-kropp med ett event-objekt kan ses i figur 13.
" d a t a ": [ {
c r e a t e d _ a t: "2020 -04 -24 T08:42:3 0 . 2 2 6 Z ", m e t a: {
id: " f 6 d 4 d5 4 a - c164 -48 cf - a9fb - a 2 3 7 a e 8 0 9 1 4 f ", t i m e s t a m p: 1 5 8 7 7 1 7 7 5 0
} } ]
Figur 13: Exempel på ett JSON-objekt för ett event med en ingre- diens för när eventet skapades.
4.2.3 Kontroll av event
Data om en ansluten användares stol hämtas från Permobils API med hjälp av den anslutningstoken som skapades i anslutningsprocessen som beskrevs i 4.2.1. Denna data används sedan för att bedöma huruvida ett event har skett eller inte. Händelser kontrolleras endast för de triggers en användare har anslutit och använder i en applet. Servern loopar ige- nom samtliga användare i databasen och hämtar sedan ut alla anslutna triggers från triggerInfo-kollektionen och kan på så vis kontrollera en- dast de triggers en användare har anslutit. När ett event har skett skapas ett JSON-objekt på det format som IFTTT slutligen vill ha datat (tidigare presenterat i figur 13). Dessa sparas sedan i en lista i databasens triggerE- vents-kollektion.
Samtliga triggers har en trigger_activated variabel i databasen som an- vänds för att en trigger bara ska aktiveras en gång när vilkoret är upfyllt.
Exempelvis om batterinivån går under 15% ska triggern bara aktiveras första gången detta sker och därmed inte aktiveras igen förrän batterini- vån har gått över 15% igen. Denna variabel sätts till true när eventet först noteras och sätts sedan till false när eventets kriterium inte längre är upp- fyllt.
Triggern chair is moving kräver något mer arbete för att kontrollera om dess kriterium är uppfyllt. För att bedöma om stolen är utomhus och rör på sig granskas datan för att se om det har kommit tre stycken GPS- uppdateringar inom tio minuter, vilket fungerar bra eftersom GPS-data uppdateras varje 100 meter stolen har rullat. Från Permobils API hämtas de tre senaste GPS-uppdateringarna där den äldsta av dessa jämförs mot klockan för att bedöma om den är inom tio minuter.
Både adjustments before time och sitting still long använder sig av antalet sittpositionsändringar för att bestämma om dess villkor är uppfyllt. An- talet sittpositionsändringar är en sammanslagning av antalet ändringar av ryggstödet, fotstödet och sitsen som räknas ut, slås ihop och ges av
Permobils API. Adjustments before time innehåller två trigger-fält specifi- cerade av användaren, antalet ändringar samt vilken tid detta antal änd- ringar ska ha skett före. Eftersom en tid används behöver olika tidszoner hanteras på något vis. Här fanns det två val, använda tidszonen använ- daren har specificerat för sitt IFTTT konto eller för sitt Permobil-konto, där det slutgiltiga valet blev att använda Permobil kontots tidszon. När en event-kontroll sker omvandlas server-tid till användarens tidszon och dessa jämförs för att se om detta klockslag har passerat. Om detta har skett granskas antalet sittpositionsändringar användaren har gjort för att sedan bedöma om triggern bör aktiveras eller ej. Hantering av tidszon görs med biblioteket moment timezone [39].
För att kunna bedöma om sitting still long triggern ska aktiveras behöver två saker vara kända för att kunna jämföra med stolens nyaste data; se- naste antalet sittpositionsändringar, samt när denna ändring gjordes. När ny data hämtas jämförs den mot dessa, om antalet sittpositionsändringar har ökat uppdateras detta med en ny tidsstämpel. Annars jämförs tids- stämpeln mot nuvarande tid för att bedömma om triggern ska aktiveras.
Triggern need service aktiveras på felkoder från stolen som har grad er- ror, förutom dessa finns det även varning och info. Eftersom dessa inte är enskilda händelser utan snarare datapunkter kan inte samma trigger_ac- tivated som använts tidigare tillämpas här. Istället används unika id:n för varje felkod där dubletter av dessa undviks vid insättning i databasen. För att låta användaren visa det felmeddelandet stolen rapporterar på något vis skickas detta med som en ingrediens.
4.2.4 Realtime API
IFTTT kommer med jämna mellanrum att hämta data för nya event, men för att undvika att behöva vänta på att detta sker och istället aktivera en trigger direkt när det finns ett nytt event har IFTTTs Realtime API im- plementerats. En förfrågan till Realtime API:et innehåller endast vilken trigger-identitet notisen gäller och skickar därför inte någon faktiskt data om det event som har skett. När ett event har skett och data har lagts till i databasen för detta på det vis som beskrevs i avsnitt 4.2.3 skickas den- na förfrågan till IFTTT via en POST-request. Ett flödesschema för denna datatransaktion kan ses i 14.
Figur 14: Ett flödesschema för datatransaktionen mellan prototyp- servern och IFTTT vid användande av Realtime API:et.
4.2.5 Trigger-fält
Tre stycken av de triggers som har implementerats använder sig av vad IFTTT kallar för trigger-fält. Dessa är battery level där användaren får spe- cificera en gräns samt om den ska aktiveras när batterinivån gör över eller under denna, adjustments before time där användaren får specificera anta- let ändringar samt ett klockslag, och sitting still long där antalet minuter utan en ändring specificeras.
Denna specificering sker vid skapandet av en applet, vare sig detta är via IFTTTs hemsida eller i deras app. IFTTT hanterar dessa som antingen vanlig textinmatning eller en lista där egna alternativ specificeras. En lista används för att välja över eller under den satta gränsen för battery level, övriga inmatningar använder textinmatning. För att validera inmatning används regex-uttryck. Detta används för att säkerställa att:
• Specificerad batterinivå för battery level är en siffra mellan 1-99.
• Specificerat antal sittpositionsändringar för adjustments before time är en siffra högre än 0.
• Specificerat klockslag för adjustments before time är ett giltigt 24-timmars klockslag på format hh:mm.
• Specificerat antal minuter för sitting still long en siffra högre än 0.
4.2.6 Kodstruktur
Varken Express.js eller Node.js presenterar något förslag eller standard- sätt att strukturera sina projekt [40], det finns därför många olika populä- ra sätt att göra detta. Den prototyp som tagits fram tillämpar en Model- Routes-Controllers-Services struktur. Detta är en populär struktur för No- de APIer som använder sig av ramverken Express och Mongoose. Struk- turen delar upp de olika stegen mellan en inkommande API-förfrågan
och en databasoperation för att göra koden lättare att skriva samt under- hålla. Figur 15 visar en översiktbild av hur de olika lagren förhåller sig till varandra.
Figur 15: Översiktsbild över hur de olika lagren i en Routes- Controllers-Services-Models struktur förhåller sig till varandra.
En API-förfrågan tas emot av en Router, som sedan skickar denna vida- re till rätt Controller beroende på URL och request-typ (GET, POST el- ler DELETE). Controllern tolkar sedan API-förfrågans innehåll och ber en service utföra de operationer som ska göras. Förhållandet mellan en Con- troller och Service liknas med en manager/worker struktur, där en ma- nager bestämmer vad som ska göras för att sedan tilldela detta arbete till en worker. I detta fall utför en Service oftast databasoperationer, där det sista lagret innan databasen, en Model, används för att definiera struktu- ren och typsätta databasen. En Model är i detta fall en Mongoose Model, som är en instans av ett Mongoose Schema.
Hur projektets källfiler övergripande har delats in i mappar kan ses i bi- laga C och figur C.1.
5 Resultat
I detta kapitel presenteras resultaten från projektets analysdelar följt av en övergripande beskrivning av den prototyp som tagits fram.
5.1 Enkätresultat
Detta arbetets första del var ämnat åt att undersöka användares behov och intresse av att få sin elektriska rullstol integrerad med sitt smarta hem.
Detta gjordes med hjälp av en enkätundersökning. Enkätundersökning- en besvarades av sammanlagt 13 personer och hade målet att ta reda på vilken smart hem-teknik respondenterna har idag, samt vilken funktio- nalitet de skulle vara intresserade av i en potentiell Permobil integration mot något smart hem-system. Enkäten börjar med att fråga om vilka var- dagliga uppgifter respondenten har svårt för. Här visades tydligt att re- spondenterna har svårt för många olika vardagsuppgifter då majoriteten bockade i samtliga alternativ. Frågan lät respondenterna fylla i ett övrigt svar om de skulle vilja, se de fem sista svaren. Detta är möjligt för samtliga flervalsfrågor i denna enkät. Frågans svar kan ses i figur 16.
Figur 16: Svarsresultat på enkätens första fråga.
Enkätens nästa del behandlar frågor kring det smarta hemmet. Denna dels första två frågor behandlar vilken funktionalitet som är mest intres- sant för en potentiell smart-hem integration att innehålla. Första frågan undersöker vilka rullstolsspecifika händelser de skulle vara mest intresse- rade av att få integrerade mot sitt smarta hem. Här visades stor spridning där de flesta alternativen var populära, se figur 17.
Figur 17: Svarsresultat på enkätens andra fråga.
Denna dels andra fråga behandlar vilken funktionalitet respondenterna tycker det vore mest intressant att integrera dessa händelser mot. Här var de stora favoriterna att kunna låsa/låsa upp dörren samt att kunna styra smarta lampor, vägguttag, persienner och liknande. Se figur 18.
Figur 18: Svarsresultat på enkätens tredje fråga.
I slutet av denna del frågades respondenterna om de idag äger några smarta hem-system där 69,2% svarade ja. Bland dessa var den populä- raste funktionaliteten smarta lampor, vägguttag samt röstassistenter från ett antal olika tillverkare. Av de som idag inte ägde några smarta hem- system svarade hälften att de skulle kunna tänka sig att investera i ett smart hem-system om det skulle kunna hjälpa dem i sin vardag.
I enkätens slut frågades respondenterna om vilken internethastighet de har hemma som en kontrollfråga att utvärdera prototypen mot. Majori- teten av respondenterna svarade att de har en internethastighet mellan 50 och 250 Mbps. Sist lämnades en öppen fråga där respondenterna kun- de skriva om de hade något mer de vill tillägga som kan hjälpa denna
undersökning. Svar på denna och samtliga andra frågor kan ses i bilaga A.
5.2 Implementationsval
Arbetets andra del var ämnat åt att analysera de tre olika tillvägagångs- sätten som presenterades i avsnitt 2.6. I avsnitt 3.1.3 förklarades hur Per- mobil skulle kunna integrera deras elektriska rullstolar mot ett smart hem- system med dessa olika integrationssätt. I detta avsnitt presenteras över- gripande resultat från denna analys.
Tabell 3 presenterar vilken funktionalitet som kan integreras med de olika integrationssätten.
Tabell 3: Vilken funktionalitet som går att skapa med de olika in- tegrationstyperna
Funktion Lokal
Integration
Moln Integration
IFTTT Integration Styra lampor, väggpluggar och
persienner
Ja Ja Ja
Skicka ett sms, email eller notis Nej Ja Ja
Låsa / låsa upp dörren Ja* Ja* Nej**
Styra köksapparater Ja Ja Ja
Styra TV / Stereo Ja Ja Ja
* Kräver nära samarbete med tillverkare på grund av säkerhetsrisk.
** De låstillverkare som har anslutit sig till IFTTT har utelämnat möjligheten att låsa / låsa upp dörren som en säkerhetsåtgärd.
Det är alltså potentiellt möjligt att uppfylla samtlig presenterad funktio- nalitet med en moln-integration. Men att endast titta på vad som går att göra speglar inte alltid vad som är det bästa valet. En undersökning av de olika integrationsmetodernas för- och nackdelar har gjorts för att kun- na väga dessa olika mot varandra. Tabell 4 presenterar för- och nackdelar med de olika tillvägagångssätten.
Tabell 4: För- och nackdelar med de olika integrationssätten.
Typ Fördelar Nackdelar
Lokal • Kommunikation sker lokalt, bra prestanda och säkerhet.
• Kräver ej en fungerande internetuppkoppling.
• Stödjer endast de system en integration byggs mot.
• Kräver upp till 4 separata integrationer för att få all funktionalitet från tabell 3.
• Enheter kan bara styras när användaren är hemma.
• Kan ej utnyttja Permobils molnbaserade API.
Moln • Kan utnyttja Permobils API för att underlätta en integration.
• Enheter kan styras när användaren inte är hemma.
• Stödjer endast de system en integration byggs mot.
• Kräver upp till 5 separata integrationer för att få all funktionalitet från tabell 3.
IFTTT • Samtliga fördelar för en molnintegration.
• All funktionalitet från tabell 3 kan skapas med en integration.
• Förlitar sig på ett till system mellan stol och hårdvara.
• Förlitar sig på att IFTTT ej orsakar fördröjningar eller driftstopp.
• Stödjer endast de system som har integrerat sig mot IFTTT.
5.3 Prestandaanalys
Eftersom en av de stora nackdelarna med IFTTT är risken för fördröjning och möjligtvis även driftstopp gjordes egna tester för att utvärdera syste- mets prestanda. Tidsmätningar utfördes på IFTTTs standard pollnings- tjänst samt deras realtime API för att utvärdera fördröjningen i systemet samt undersöka om driftstopp och/eller avvikelser i prestanda är vanliga.
Resultat från dessa kan ses i figur 19.
Figur 19: Tidsmätningar av IFTTTs standardpollning och Realti- me API. Omkring 200-300 mätpunkter styck utförda med jämna mellanrum under ett par dagar.
Medelvärde och standardavvikelse för dessa mätningar presenteras i ta- bell 5.
Tabell 5: Medelvärde och standardavvikelse för IFTTTs standard- pollning och Realtime API.
Typ Medelfördröjning [s] Standardavvikelse [s]
Standardpollning 1035.92 (≈17 min) 609.49 (≈10 min)
Realtime API 1.10 0.27
Resultatet från dessa tidsmätningar diskuterades med handledare på Per- mobil och på grund av att data från stolen skickas med 10 minuters inter- vall ansågs Realtime API:et ha tillräckligt låg respons för att inte orsaka märkbara fördröjningar i systemet. Vidare tyder dessa mätningar även på att Realtime API:et har god stabilitet då några större avvikelser ej kan noteras under dessa tester. Utan implementering av Realtime API:et är fördröjningen stor där det kan ta allt mellan några sekunder och en halv- timme innan IFTTT faktiskt kollar efter ny data på servern.
5.4 Prototyp
Den prototyp som har tagits fram är fullständigt implementerad mot bå- de IFTTT och Permobils API och uppfyller därför sitt syfte som ett proof of concept. Prototypen är fullt fungerande och klarar IFTTTs tester för en
integration utan några fel. De triggers som har implementerats i prototy- pen sammanfattas i tabell 6.
Tabell 6: De triggers som har implementerats i prototypen
Triggernamn Aktiveras när?
Starts Charging När stolen börjar ladda Stops Charging När stolen slutar ladda Fully Charged När stolens batteri når 100%
Battery Low När stolens batteri går under 15%
Battery Level När stolens batteri går över / under en gräns satt av användaren.
Need Service Stolen rapporterar en felkod med varningsnivå error.
Chair Is Moving När tre GPS-uppdateringar har skett inom 10 minu- ter.
Adjustments Before Time Om användaren inte har gjort ett försatt antal sittpo- sitionsändringar före ett bestämt klockslag.
Sitting Still Long Om användaren inte har ändrat sittposition på ett försatt antal minuter.
6 Slutsatser
Det här kapitlet innehåller övergripande slutsatser och diskussion kring det arbete som har utförts. Resultatet från arbetets tre delar: behovsana- lys, implementationsval och prototyp, diskuteras följt av diskussion kring vidareutveckling samt etiska och samhälleliga aspekter.
Detta arbete hade som mål att:
1. Ta reda på vilken funktionalitet användare av elektriska rullstolar har behov av att få integrerad med sitt smarta hem.
2. Utvärdera om automationsramverket IFTTT kan användas för att implementera noterad funktionalitet från mål 1.
3. Utföra tidsmätningar och tester av IFTTT för att utvärdera om tjäns- ten kan prestera så att funktionaliteten inte blir begränsad av drift- stopp och/eller fördröjningar.
4. Ta fram en prototyp som implementerar noterad funktionalitet från mål 1 och därmed kan fungera som ett proof of concept.
Hur väl mål 1 har uppnåtts diskuteras i avsnitt 6.1. Mål 2 och 3 diskuteras i avsnitt 6.2 och mål 4 i avsnitt 6.3.
6.1 Utvärdering av behovsanalys
Behovsanalysen hade som mål att undersöka användarnas behov och in- tresse kring att få sin elektriska rullstol ihopkopplad med sitt smarta hem.
Resultatet från denna pekar på ett tydligt intresse hos användarna med ett antal olika behov som skulle kunna uppfyllas. Vad som dock kan upp- levas som oklart, och även nämndes i enkätsvaren, är vad Permobil i sig skulle kunna tillföra till ett traditionellt smart hem. Eftersom mycket funktionalitet går att idag lösa med existerande system, vare sig det är via röstkommandon, en smartphone app, eller något annat, är det svårt att veta om intresset kring specifik funktionalitet är för en Permobil integ- ration eller bara ett intresse kring funktionaliteten i sig.
Vidare kan man även tänka sig att den grupp användare som enkäten skickades ut till är någorlunda teknikintresserade då de är villiga att ge respons på ny teknik som Permobil arbetar med. Det kan därför reso- neras kring hur väl dessa speglar Permobils genomsnittliga kund då de troligtvis är mer insatta i smarta hem än många andra. Det kan därför vara intressant att resonera ytterligare kring om dessa enkätsvar speglar den målgrupp Permobil vill rikta sig mot med en framtida smart hem-
integration eller om de vill göra fler studier kring vad en bredare mål- grupp potentiellt skulle ha för andra behov och intressen.
6.2 Utvärdering av implementationsval
Målet med analysdelen kring olika integrationsmetoder var att analysera vilken av dessa som bäst skulle lämpa sig för att uppfylla så många behov som möjligt. Det val som gjordes i denna del blev något viktat på grund av just detta mål. Genom att sikta på just detta, att uppfylla så många olika behov som möjligt faller intresset naturligt på den lösning som innehåller mest funktioner. Sen om detta faktiskt är den bästa lösningen behöver inte alltid stämma, men i detta projekt har den tjänst som öppnar upp flest möjligheter motiverats till den lämpligaste.
I denna del av projektet utfördes även tidsmätningar mot IFTTT. Dessa stämmer ej med de tester presenterade i artikeln An Empirical Characte- rization of IFTTT: Ecosystem, Usage and Performance [24]. Artikeln kommer fram till att IFTTTs Realtime API inte ger någon prestandaökning medan de tester som har utförts i detta projekt kommer fram till raka motsatsen.
Studien är utförd sent 2017 medan detta projekt är utfört under våren 2020, det är därför mycket möjligt att IFTTT har förbättrat sitt system un- der denna tid.
6.3 Utvärdering av prototyp
Målet för den prototyp som togs fram var att kunna fungera som ett proof of concept och demonstrera den tänkta funktionaliteten. Prototypen fun- gerar väl för detta ändamål där funktionaliteten är fullt fungerande och använder sig av en riktig version av Permobils API. Prototypen är även fullständigt integrerad mot IFTTT och uppfyller samtliga krav de har på en tjänst.
Prototypen integrerades mot en testversion av Permobils API där änd- ringar av stolsdata simulerades genom att modifiera databasen för API:et.
Företaget var nöjda med denna begränsning då de själv vet mycket väl hur kopplingen mellan API:et och en stol fungerar och har därför gott förtroende för att det som fungerar mot test API:et även kommer fungera mot riktiga stolar i produktion. Att koppla en teststol till API:et i endast testsyfte hade tillfört mycket arbetstid och liten betydelse för företaget.
Prototypen är idag endast lämplig som ett proof of concept och inte fullt redo för produktion då den har ett antal bekymmer som bör vidare un- dersökas innan något likt denna lanseras av Permobil. Dessa disskuteras vidare i nästföljande kapitel.
6.4 Vidareutveckling
Detta kapitel diskuterar föreslagen vidareutveckling som Permobil bör undersöka om de vill lansera en integration mot IFTTT. Den prototyp som har tagits fram i detta projektarbete kommer med ett antal nackdelar som det kan vara intressant att undersöka innan en lösning likt denna sätts i produktion. I detta avsnitt kommer dessa diskuteras.
6.4.1 Systemarkitektur
Den prototyp som har tagits fram tillämpar en pollningsarkitektur för att hämta nya inträffade event från Permobils API. Detta innebär både att det blir mer datatrafik än vad som behövs samt att det kommer finnas natur- lig fördröjning i systemet. I ett sådan system måste man alltid kompro- missa åt det ena hållet eller det andra. Om man behöver låg fördröjning i systemet behöver pollning ske oftare och man får då mer onödig datatra- fik mellan två händelser. Om man istället vill minska mängden datatrafik genom att utföra pollning mer sällan får man större fördröjning i syste- met där man riskerar längre fördröjning mellan det att ett event inträffar och att det hämtas av servern. Det är därför intressant för Permobil att undersöka en alternativ system-arkitektur.
En arkitektur som skulle kunna tillämpas är att istället för att servern hämtar data från olika endpoints på Permobils API för att bedömma om ett event har skett kan Permobils API istället skicka data till denna server när en datauppdatering kommer från stolen. Alternativt till detta skul- le något likt IFTTTs Realtime API kunna implementeras, där Permobils API skickar en förfrågan till servern när en stol har gjort en datauppdate- ring. Denna kan sedan hämta data från de endpoints den behöver för att bedömma om ett event har skett för denna stol. Den funktionalitet som prototypservern idag står för skulle även kunna byggas in direkt i Per- mobils API för att gå runt detta problem, och på så vis inte behöva någon mellanhandsserver alls, men detta kommer i sig med sina nackdelar.
6.4.2 Bedömning av när ett event har inträffat
I den prototyp som har tagits fram bedöms huruvida ett event har in- träffat eller inte av servern. Stolen skickar data till servern med jämna mellanrum och sedan bedömer servern utifrån dessa datauppdateringar huruvida ett event som exempelvis att stolen börjar ladda eller att dess batterinivå har gått under en gräns utifrån denna data.
Ett alternativ till detta skulle kunna vara att stolen själv kan bedöma om ett event har inträffat eller ej. Stolen skulle då kunna skicka en dataupp- datering till API:et direkt när detta har skett, istället för att det kommer
