V˚ar huvuddel av l¨osningen som koordinerar de andra delarnas samverkan ¨ar API:t mot den molnbaserade databasen fr˚an IDUN. Det ¨ar implementerat i Javascript med till¨agg f¨or MongoDB samt Azure Event-Hub. Till¨agget av MongoDB ¨ar till f¨or att kunna redigera vilka statusar som ¨ar aktiva i molndatabasen och Azure h¨amtar on-demand-signaler fr˚an Vasakronans databas IDUN. Signalerna fr˚an IDUN anv¨ands sedan som indata till databasens hanteraren som ansvarar f¨or att uppdatera molndatabasen. Hante-raren h¨amtar de notiser som korresponderar till indatan fr˚an den lokala databasen in-neh˚allandes samtliga m¨ojliga notiser och uppdaterar sedan informationen i molnet f¨or att matcha dessa. Vilka meddelanden som l¨aggs till vid en uppdatering beror p˚a vilken prioritetsniv˚a signalen fr˚an IDUN har p˚a en tregradig skala.
En g˚ang per dag ansvarar hanteraren ¨aven f¨or att ropa p˚a v¨ader API:et och uppdatera den befintliga v¨aderprognosen.
10 Utv ¨arderingsresultat
H¨ar beskrivs utv¨arderingsresultaten av de krav som st¨allts p˚a resultatet i 7.
10.1 Information och kommunikation
Utv¨arderingen av f¨ordr¨ojningen mellan att en f¨or¨andring i IDUN skett tills dess att mo-bilapplikationen var uppdaterad skedde p˚a s¨attet beskrivet i 7.
Fr˚an testerna med en simulerad on-demand-signal fr˚an IDUN fick vi en f¨ordr¨ojning p˚a i snitt 80ms, fr˚an det att signalen inkommit, till gr¨anssnittet mellan IDUN och moln-databasen tills dess att uppdateringen var synlig i mobilapplikationen f¨or anv¨andaren.
Dessa m¨atningar ¨ar beroende av utomst˚aende faktorer s˚asom hastighet p˚a anv¨andarens internetuppkoppling och serverns kapacitet eftersom de p˚averkar anv¨andarens m¨ojlighet att kontakta och h¨amta informationen fr˚an databasen. Tids˚atg˚angen f¨or dessa delar st˚ar f¨or ungef¨ar 80 procent vilket skulle kunna resultera i relativt stora variationer. Ef-tersom f¨ordr¨ojningen ¨and˚a ¨ar i storleksordningen av millisekunder anser vi ¨and˚a att f¨ordr¨ojningen alltid kommer befinna sig inom ett acceptabelt intervall d˚a milj¨o¨andringar f¨or en fastighet i regel inte har omedelbar effekt.
10 Utv¨arderingsresultat
10.1.1 Fastighetsanpassad information
F¨or att testa att informationen gick till avsedda adresser k¨ordes en sekvens d¨ar vi uppda-terade flertalet fastigheter i f¨oljd. Fr˚an resultatet kunde vi se att samtliga uppdateringar endast g˚att ut till de adresser som angivits f¨or uppdateringen b˚ade i den molnbaserade databasen och prototypen f¨or applikationen.
D˚a detta var tanken kunde kravet anses vara uppfyllt. N˚agot som vi uppt¨ackte under testerna var att indatan d¨ar gatuadresserna specificerades var skiftl¨agesk¨anslig. Detta gav konsekvensen att vi ibland skapade en ny adress med samma namn som innan in-te funnits i den molnbaserade databasen som fick uppdain-teringen ist¨allet f¨or den t¨ankta adressen. Skiftl¨agesk¨ansligheten f¨or denna insignal var inget som vi hade i ˚atanke un-der utvecklingen d˚a informationen kommer fr˚an en redan befintlig databas som all-tid kommer skicka adressen i samma format d˚a det inte finns n˚agon m¨ansklig fak-tor involverad. D¨arav ¨ar det inget problem f¨or den t¨ankta funktionaliteten att denna s¨akerhet inte finns implementerad ¨aven om det ¨ar bra praxis att implementera bort den-na skiftl¨agesk¨anslighet.
10.1.2 Automatiserad informationsuppdatering
Testningen av automatiserade notiser gjordes i samband med testningen f¨or fastighets-anpassad information d˚a utformningen var densamma. Eftersom samtliga uppdateringar som genomf¨ordes under en sekvens hamnade i den molnbaserade databasen samt visa-des i prototypen f¨or applikationen, anser vi att l¨osningen klarade kraven som st¨allts i 7.
10.1.3 Kommunikation med databasen
F¨or att kunna uppfylla detta krav implementerades en kontroll d¨ar vi h¨amtar vilket till-st˚and en adress befinner sig i innan n˚agot f˚ar uppdateras i databasen. Detta leder till en extra uppkoppling mot databasen i det fall d˚a en uppdatering ¨ar n¨odv¨andig. Denna me-tod tar extra tid, men det begr¨ansar samtidigt att inga on¨odiga uppdateringar g¨ors vilket sparar tid i ¨ovriga fall. F¨or v˚ara testk¨orningar har ingen on¨odig uppdatering forcerats till anv¨andarens applikation eller databasen vilket vi anser ¨ar tillr¨ackligt f¨or att kunna be-trakta m˚alet som uppfyllt d˚a vi d¨arav g¨or minimalt med anslutningar mellan databasen och klienten.
11 Resultat
10.2 Push-notifikationer
Anv¨andartesterna visade att endast de mest kritiska h¨andelserna ska uppdateras med hj¨alp av notifikationer. N¨ar ¨aven mindre kritiska h¨andelser skickades ut med push-notifikationer upplevde anv¨andarna att det blev upprepande och mindre vikt lades p˚a inneh˚allet. Detta tog bort syftet med funktionen vilket ledde till att vi var restriktiva med anv¨andandet av push-notifikationer.
Aven f¨or uppdateringar av v¨aderleksrapporten gav anv¨andartesterna oss information om¨ att push-notifikationerna b¨or anv¨andas sparsamt. Genom testerna kom vi fram till att ett utskick i veckan var bra f¨or att uppdatera anv¨andarna om det kommande v¨adret.
Informationen i prototypen f¨or applikationen uppdaterades ¨and˚a kontinuerligt men utan att det skickades ut nya push-notifikationer.
Fr˚an anv¨andartesterna framkom ¨aven ¨onskem˚al om utformningen f¨or notifikationerna samt push-notifikationerna. Push-notifikationer med flera rader text upplevdes ointres-santa och l¨astes inte av anv¨andarna, medan samma m¨angd text ist¨allet upplevdes passan-de i notifikationerna som visas i prototypen. Med hj¨alp av texten i mobilapplikationen fick anv¨andarna en klar inblick i vad som h¨ant och att de i m˚anga fall kunde vara intres-serade att bidra ifall de hade m¨ojlighet eller flexibla planer.
11 Resultat
Resultatet av projektet ¨ar en implementation av tv˚a olika komponenter. En databas som inneh˚aller unika notifikationer f¨or enskilda fastigheter, samt en prototyp ¨over hur en integration mellan databasen och en mobilapplikation skulle kunna se ut. Prototypens huvudfunktion ¨ar att visa notifikationer, d¨ar anv¨andaren beh¨over ¨oppna applikationen f¨or att se informationen och push-notifikationer, som visas p˚a startsida eller notifika-tionscenter i anv¨andarens mobil. Notifikationerna ¨ar klassificerade som olika kategorier och beror p˚a antingen f¨or¨andringar i en fastighet, v¨ader, eller meddelanden som upp-muntrar till ett smartare energit¨ank.
Den f¨ardiga produkten uppfyller tillsammans med prototypen, de fem krav som formu-lerades i 7.
12 Diskussion
11.1 Olika typer av notifikationer
F¨or f¨or¨andringar som sker i en fastighet ges en notifikation om ˚atg¨ard till hyresg¨aster vid en specifik adress. Notifikationerna ¨ar begr¨ansade till f¨or¨andringar genomf¨orda som en
˚atg¨ard till en on-demand-signal fr˚an eln¨atets akt¨or, och mikroregleringar gjorda av fas-tigheternas AI inkluderas d¨arf¨or inte som en notifikationsskapande process. ¨Ar f¨or¨andringarna som gjorts i fastigheten stora, skickas informationen ut som en push-notifikation till anv¨andaren. F¨or mindre f¨or¨andringar hittas informationen om f¨or¨andringen ist¨allet som notifikation i mobilapplikationen.
Notifikationer f¨or v¨ader skickas ut i form av en veckoprognos d¨ar anv¨andaren en g˚ang i veckan f˚ar en push-notifikation ¨over vilka dagar den kommande veckan som kan kom-ma att p˚averka eln¨atets kapacitet. Notifikationen inneh˚aller ¨aven inforkom-mation om hur hyresv¨arden kommer agera f¨or att undvika kapacitetsbristen och vad anv¨andaren sj¨alv kan vara med och bidra. V¨aderinformationen uppdateras kontinuerligt ¨aven efter det att push-notifikationen g˚att ut och en uppdaterad prognos finns alltid att hitta i prototypens informationsfl¨ode.
Dessa tv˚a notifikationer inneh˚aller b¨agge information om hur anv¨andaren sj¨alv kan hj¨alpa till f¨or att f¨orhindra kapacitetsbristen, framf¨or allt den tidsberoende som orsakas till stor del av samh¨allets beteendem¨onster. Beroende p˚a vilken prioritetsniv˚a notifika-tionen har ¨ar situanotifika-tionen olika akut, och blir antingen notifikationer i mobilapplikatio-nen eller push-notifikationer som visas p˚a mobilens startsida. Notifikationernas med-delanden ¨ar anpassade efter prioritetsniv˚aerna. Dessa uppmaningar f¨oljs sedan med en
˚aterkopplingsnotifikation, d¨ar anv¨andaren tackas f¨or medverkan. F¨or att uppmuntra ett energismartare beteende skickas det ¨aven ut information om till vilken grad f¨oreg˚aende energibesparingar lyckades. Tanken ¨ar att detta ska ge incitament till fortsatta bespa-ringar d˚a anv¨andarna f˚ar visuell bekr¨aftelse p˚a att deras insatser g¨or skillnad.
12 Diskussion
I det h¨ar avsnittet f¨or vi en diskussion kring projektet. Vi diskuterar v˚art resultat och arbetsg˚ang, samt konsekvenserna av att digitalisera informationsspridningen och vad f¨or¨andringarna som sker p˚a elmarknaden har f¨or p˚averkan p˚a akt¨orerna.
12 Diskussion
12.1 Resultatet
Projektets syfte var att f¨orebygga och motverka kapacitetsbristen i eln¨aten, samt att underl¨atta f¨or Vasakronan i deras kommunikation med sina hyresg¨aster. F¨or att uppn˚a syftet, rent konkret, var m˚alet att skapa ett till¨agg till Vasakronans mobilapplikation.
Resultaten av den f¨ardiga produkten ¨ar vid slutet av projektet en prototyp av detta till¨agg.
V˚art resultat ¨ar d¨arf¨or inte riktigt vad vi hade som m˚al, men resultatet ¨ar med tanke p˚a omst¨andigheterna rimligt. Resultatet ¨ar rimligt f¨or att utan tillg˚ang till Vasakronans mobilapplikation har vi utvecklat en prototyp s˚a l˚angt det g˚ar utan denna tillg˚ang.
V˚ar l¨osning kommer inte l¨osa hela kapacitetsbristen i eln¨aten, utan det ¨ar snarare en dell¨osning och ett steg n¨armre en smartare elanv¨andning och ett ¨andrat anv¨andarbeteende.
En l¨osning som inte kr¨aver utbyggnad av eln¨atet.