Intervju med Ulrik Eklund

Intervju med: Ulrik Eklund, rådgivare, arkitektur, Elis. Ämne: Integration av Philips Hue till Elis.

Ansvariga: Joakim Lithell, Per Johansson. Datum intervju: 2014-05-16

Datum transkribering: 2014-05-17

Joakim Lithell: Vad är din roll i utvecklingsteamet Elis?

Ulrik Eklund: I huvudsak har jag varit rådgivande när det gäller att ta fram arkitekturen för Elis-plattformen.

Joakim Lithell: Hur omfattande har detta arbetet varit? Har du varit med och jobbat fram en arkitektur eller bara biståt med rådgivning?

Ulrik Eklund: På ett sett är jag ansvarig för arkitekturen, i betydelsen att det ska nnas en arkitektur. Men om man faktiskt tittar på vem som gjort, eller fattat besluten på hur den ska se ut så kan jag inte säga att det är jag som fattat alla dom besluten själv. Utan då är det ju andra, som till exempel Johan Holmberg och Marcus Ljungberg som varit minst lika delaktiga som jag. Men sen har jag också faktiskt varit ansvarig för att dokumentera ner det här.

Joakim Lithell: Har du någon tidigare erfarenhet av vad Philips Hue är? Och vad den kan göra för någonting?

Ulrik Eklund: Bara som användare. Jag har bott på ett hotell som hade Philips Hue. Jag har lekt lite med fjärrkontrollen men inte systematiskt gått igenom den. Men jag vet ju det här med att det går och ändra färg och ljus intentitent och i viss mån programmera dem för förändringar men har bara använt det förinställda programmen som fanns där.

Joakim Lithell: När vi ändå är inne på ämnet, Vad tror du att Philips Hue skulle kunna ge för värde till plattformen? Och kan den ge värde?

Ulrik Eklund: Just i det begreppet i plattformen att man bygger upp här med scheman egentligen. Till exempel att man skulle kunna programmera, så att platt- formen faktiskt upptäcker att jag använder Philips Hue vid era tillfällen. Olika vid olika tidpunkter under dygnet och där den sedan lär sig och kanske ger förslag på hur du vill ha ett system som automatiskt beter sig på det här sättet.

Joakim Lithell: Detta är väl mera plattformens intelligens, nns det något sätt där ?lampan? Philips Hue kan användas till något?

Ulrik Eklund: Ja. Efter som lampan faktiskt kan ge så intensiva färger kan man använda den för att göra information. Dvs säg att jag skulle vara hörselskadad, då skulle jag faktiskt kunna koppla så att lampan ändrar färg när någon ringer på dör- ren. Den typen av funktioner ser jag.

Joakim Lithell: Det är ett område vi inte tittat så mycket på, men det låter smart. Ulrik Eklund: Sen kan man ju använda lampans färg för att ge information om förändrade tillstånd. Dörrklockan var ju bara ett enkelt exempel. Hela iden med en öppen plattform är ju att man inte kommer på alla funktioner från början.

Joakim Lithell: Vi har kommit fram till fram till att plattformen är väldigt öppen, var är grundtanken med det?

Ulrik Eklund: I arkitekturen tidigt för drygt ett år sedan så gick vi systema- tiskt igenom vad plattformen skulle ha för egenskaper. Då såg vi att den skulle vara möjlig att bygga ut. Och då inte bara för att bygga ut för större lägenheter utan för nya typer av devices och typer av tjänster. Dom egenskaper har präglat mycket av de konstruktionsval man gjort när man utformat till exempel APIet på toppen, även om det var Marcus Ljungblad som mycket specicerade den biten förra året. Men också valen hur man jackar in proprietärasystemen som Philips Hue underifrån. Då var ett beslut att man faktiskt valde bort vissa specika saker som varje (tex Eon eller Schniders) system kunde göra bara för att få det så lätt programmerat eller lätt

använt som möjligt. Det skulle vara enkelt att stoppa in nya system som Philips Hue underifrån. Så prioritering har varit enkelhet framför att man ska kunna utnyttja alla funktioner som systemen har.

Joakim Lithell: När man bygger en öppen plattform, var går gränsen på öppenhet? Ulrik Eklund: Öppenheten balanserades mot två andra egenskaper. Den viktigaste var att det skulle gå snabbt för en utvecklare att bygga tjänster ovanpå plattformen. Det gör att det hela måste vara konkret, det ska inte vara så abstrakt. Det innebär om man tittar på API-dokumentationen att dom saker man ser är väldigt lätt att översätta till fysiska saker, man pratar om rum eller devices och så vidare. Man försöker konkretisera det på det sättet. Den andra egenskapen är att man successivt utvecklar plattformen när man får en ide om konkreta tjänster. Nu har det inte rik- tigt varit i balans i projektet tack vare hur samarbetet med till exempel Malmö Stad har sett ut. Men tanken var att man successivt skulle kunna bygga ut tjänsterna i plattformen när man faktiskt såg konkreta behov av det.

Joakim Lithell: Vi upplevde att det krävdes mycket implementation av klasser i Elis för att kunna göra enkla saker som att styra lampor. Vad tänker du om det? Är det oundvikligt?

Ulrik Eklund: Nej det är inte oundvikligt. Det kanske inte är något vi i det diskus- sioner jag varit med i har prioriterat. Det vi prioriterat är att det ska vara enkelt att bygga ovan på plattformen. Enkelheten under ifrån har inte varit fokus på. Sen har vi gjort några konstruktionsval till exempel att hela plattformen ska köras på OSGi om det sen underlättar eller gör det krångligare får du fråga någon av utvecklarna, jag är inte tillräckligt insatt. Jag är dessutom ingen Java-programmerare.

Joakim Lithell: Kravet på att sätta upp hela plattformen lokalt anser vi vara ett hinder för att komma igång med utveckling. Ser du någon annan lösing?

Ulrik Eklund: Om man skulle drivit detta som ett kommersiellt projekt så skulle jag tycka man ska erbjuda någon sorts prototyp eller test-plattform som var moln-

baserad som utvecklarna ska kunna testköra sina appar mot. Men det var inte din fråga?

Joakim Lithell: Vi tänker oss väl främst integration underifrån och inte appar som jobbar mot plattformens api.

Ulrik Eklund: Jag förstår. Men vi reekterade inte över detta. Plattformen är byggd som en monolit dvs man har hela plattformen. Men sen har vi ju det här ?löklagren? där man kan välja o bygga sin egen plattform i olika steg inifrån och ut. Men vi hade ingen tanke på att bara plocka en liten bit av plattformen att testa en adapter mot under ifrån. Och detta kanske i efterhand var korkat, men vår priori- tering aldrig att bygga en så modelär och lättanvänd plattform som möjligt utan plattformen skulle vara lätt att använda.

Joakim Lithell: Så vår fråga om vad ni gjort för att externa utvecklare ska kunna jobba med egna adaptrar mot elis är svaret?

Ulrik Eklund: Det var inte prioriterat vad jag kommer ihåg.

Joakim Lithell: Som sagt vi har haft mycket stöd från Johan och så när det gäller jobba mot plattformen. Vi har frågat väldigt mycket och det har varit många luckor även sådana här grejer som varit implementerade för att vara öppna, har vi haft funderingar på varför är dom öppna och vad ska in där? Vem bestämmer vad? Men hur tänker du, tänker du att Elis ska fungera fritt utan support?

Ulrik Eklund: Nej som plattformen ser ut idag så tror jag den kommer få svårt att överleva efter att Elisprojektet slutar, även om man lägger upp den som open source. Joakim Lithell: Så det krävs någon form av huvudgrupp som ansvarar för den? Ulrik Eklund: Ja. Jag tror det.

Ulrik Eklund: Ja.

Joakim Lithell: Hur mycket erfarenhet har du av adaptrar generellt? Ulrik Eklund: Inte jättemycket inom just den här tillämpningen. Joakim Lithell: Men inom någon annan kanske?

Ulrik Eklund: Ja bilvärlden.

Joakim Lithell: Vad anser du är en bra adapter, funktionalitetsmässigt?

Ulrik Eklund: Problemet med en adapter är ju, vi kan ju ta ett konkret exempel från Elis-plattformen. Eons och Schneiders devices fungerar i olika principer uppåt dvs Schneiders talar om när den gör en tillståndsförändring medan Eons måste man fråga om den ändrat tillstånd. Det är två helt olika arkitekturella principer, dom skillnaderna kan man inte dölja. Man får lägga väldigt mycket funktionalitet i ad- aptern för att det ska se likadant ut uppifrån. Och det är lite det som är problemet när man gör en plattform så, plattformen får bli rätt intelligent för att alla dom här systemen ska uppfattas som likadana. Sen om man faktiskt gör tvärtom, dvs att man denierar plattformen först och den blir en industristandard, då blir det lättare för folk att anpassa sig till adapterlagret underifrån. Det är lite så det ser ut i bilindustrin. Där nns inte de där arkitekturella skillnaderna på samma sätt, där är det mer fråga om att du översätter variabler och api:er för dom heter lite olika, där blir ju adapterlagret mycket enklare. Det blir ju en wrapper egentligen om man ska prata mönster.

Joakim Lithell: IoT-arkitekturen, hur var tanken med den och plattformen? Har ni följt den strukturen under hela processen?

Ulrik Eklund: Nej, IoT-arkitekturen, som den ser ut, ger egentligen exempel på där du börja, den är en extremt öppen standard, så öppen egentligen så att steget

går därifrån till någotnting konkret du kan köra på en server, är jättestort. Vi bör- jade faktiskt när jag kom in i projektet, med att titta på detta och jämföra. Sen nns det vissa element i den arkitekturen där man gör en skillnad på vad som är en resurs och vad som är en tjänst. Det är två seperata saker som IoT-a arkiteturen har. Den distinktionen inte kanske var meningsfull för en tredjepartsutvecklare som ville utveckla en app. Så Elisplattformen är i en viss mån en förenkling men på det he- la taget så följder den Iot-arkitekturen men använder andra namn för saker och ting. Joakim Lithell: Är det ett försök att följa någon form av standard?

Ulrik Eklund: Den här standarden är så öppen så man hade nog kunnat byg- ga vilket system som helst och ändå säga att den följer denna standarden. Men som sagt man hade kunnat följa det mer strikt dvs att tydligt göra en skillnad på vad är en service och vad är en resource. Det är ju två skilda saker enligt den standarden. I Elis har man egentligen inte gjort den åtskillnaden, sett från apihållet, uppifrån. Sen nns det faktiskt en del bra element i den standarden som vi har tillämpat rakt av och det är liksom, när man pratar om deployment conguration, där vi har sett olika möjligheter att faktiskt husera var ska Elis-plattformen exekverar någonstans. Var är servern placerad? Är den placerad i nån molntjänst eller lokalt i byggnaden osv. Där har den varit mycket mer hjälpsam för att den har förtydligat vad är skillnaden till exempel när vi kör Elisplattformen i ett Eon eller Schneider hus.

Joakim Lithell: Våran forskningsfråga som vi försöker svara på med dom här frågorna är ju, vilken typ av problematik introducerar behover av generalisering när man integrerar devices mot existerande system? Det är ju för att svara på, när man arbetar med ett så generellt system som Elis, vad dyker det upp för problem? Från vårt håll har det varit att det varit svårt att tyda dokumentation för det inte funnits dokumentation eftersom det ska va öppet.

Ulrik Eklund: Jag tog upp ett konkret fall och det var ju det att dom faktiskt, dom smarta devices, från Eons system och Schneiders system, beter sig faktiskt olika när man gör en tillståndsförändring. Det tycker jag är en typisk problematik som dyker upp när man generaliserar det här för någonstans måste man ta hand om

dessa skillnaderna. Är det jag som måste gå och fråga eller kommer devicet tala om när det sker en förändring. Och den kan man egentligen trycka hela vägen upp om man väljer att inte ta hand om denna problematiken, då blir det faktiskt apput- vecklaren i telefonen som får ta hand om problematiken. Dvs den apputvecklaren måste hålla reda på vilken device det är. Den typen av problematik är det som alltid uppkommer och IoTa arkitekturen ger ju ingen vink överhuvudtaget av den typen, den är alldeles för generell för att ens diskutera sådana praktiska implementations- problem. Om jag skulle säga, det är den typen av problem som kommer upp, man har olika principer för hur ens devicer beter sig. Ett annat är tex om man följer REST strikt, då har man vad man kallar STATELESS tjänster, dvs min förfrågan eller request, exempelvis en PUT ska inte bero på vilka tidigare requests man har gjort och vilken ordning man har gjort dem. Men alla devices är inte programme- rade på detta sättet, så där också en skillnad, som då alltså måste bestämma om man ska hantera det i min plattform, då blir den mer komplicerad, eller ska jag skjuta upp det hela vägen till tredjepartsutvecklaren. Och det är ju det man gör, och man kan också vara så strikt så man säger att man inte tillåter devices som inte följer REST för att integreras i plattformen. Då har man ju löst det på ett sätt. Men då är det inte lika öppet, den accepterar inte lika många typer av devices längre. Joakim Lithell: Ja då skulle väl Eon inte fungerat heller?

Ulrik Eklund: Precis. Och det är den typen utav, jag skulle kalla det arkitekturella principer, som man har funderat på när man har funderat på när man konstruerar sin device, måste man hantera. I bilindustrin är det så att man faktiskt denierar vilka arkitekturella principer som man måste uppfylla för att jacka in saker och ting. Där har man inte riktigt samma problematik men där måste plattformen, bilvärldens mostvarighet till plattform, måste vara en så pass allmänt utbredd industristandard att det inte är några problem.

Joakim Lithell: Så om det kommer någon med nått nytt so blir det svårt?

Ulrik Eklund: Ja, och det är ju det problemet när man skapar en ny plattform, den konkurerar med massa annat som redan nns. Nu nns det kanske inte jättemycket

annat utav Elisplattformen men den är inte allmätn utbredd heller så det innebär att nästa gång någon tar fram någonting, typ Ninja Blocks eller Philips Hue eller någonting sånt så kanske dom hittar på egna principer.

Joakim Lithell: Så ett standardiserat sätt hade underlättat men det är jättesvårt att etablera?

Ulrik Eklund: Ja det nns ju två vägar att gå mot standardisering. Antigen så drar man det in stora standardiseringsorganisationer som ISO och det tar jättelångtid och man vet inte hur stort genomslag det får. Eller så blir det en de-facto standard, asså, mobiltelefoner nns det två de-facto standarder idag, Android och Iphone. För bilindustring nns det på elektrisk nivå, på kablarna i bilen, så är det ju CANN, en de-facto standard. Men det är ju faktiskt ett påhittat protokoll utav Bosch och Philips som ck så mycket genomslag så att efter dom publicerade sin spec så blev det faktiskt accepterat som en ISO-standard.