Dataingenjör 180 hp
Att jämföra billigast energi med spotpris och väder
Examensarbete 15 hp
Halmstad 2020-09-13
Jennifer Dinh
Sammanfattning
Idag är det möjligt att koppla upp utrustningar mot nätet hemma och ha ett Smart Hem. Ett hushåll har två elavtal, elnät och elhandel. Elnät är bunden till området man bor och kan inte bytas ut, men det är annorlunda med elhandel. Hos elhandel vill man ha det lägsta priset på el och det är där timpris spelar roll. Elkostnader kan bli höga och för att minska kostnaderna samt använda grön energi har detta examensprojekt tagit fram ett system som ska kunna informera en användare om spotpriset respektive väder.
Projektet har använt sig av Android Studio (front-end), Firebase Realtime database och ett javaprogram (back-end). Med Grönt Väders API och Google Maps Geocoding API har data om användaren, elpriser och väder samlats i databasen. Resultatet av projektet blev en mobilapplikation som visar information om dagens elpris, väder och andra faktorer som hjälper ett hushåll med egenproducerad energi att följa. Dock kunde elpriser inte jämföras med vädret.
För vidareutveckling hade back-end kunnat vara på en Raspberry Pi där man kopplar en vitvara
som man kan styra i framtiden.
Abstract
Today it is possible to connect equipment to the network at home and have a Smart Home. A household has two electricity agreements, electricity networks and electricity trading.
Electricity network is tied to the area you live and cannot be changed, but electricity trading is a different matter. In electricity trading, what you want is the lowest price and that is where the hourly rate matters. Electricity costs can be high and to reduce costs and use green energy, this degree project has developed a system that will inform a user about the spot price and weather.
The project has used Android Studio (front-end), Firebase Realtime database and a Java
program (back-end). With the Green Weather API and the Google Maps Geocoding API has
information about the user, electricity prices and weather been collected in the database. The
results in this project was an app that showed electricity prices of the day, weather and other
factors that helps a household with self-produced energy to follow. However, electricity prices
could not be compared with weather. Further development would be to have the back-end
running on a Raspberry Pi where appliances could be controlled in the future.
Ordlista
Spotpris - Dagens elpris i 24 timmar
Front-end - Användargränssnitt orienterad bearbetning (vad användaren ser) Back-end - Själva bearbetning på servernivå (det som händer i bakgrunden)
Förkortningar
API - Application Programming Interface
Innehållsförteckning
1. Inledning 1
1.1 Syfte 1
1.2 Mål 1
1.3 Krav 1
1.4 Avgränsningar 2
2 Bakgrund 3
2.1 Mobilapplikation 3
2.2 Programmeringsmiljöer 3
2.2.1 Android Studio 3
2.2.2 Java och Kotlin 3
2.2.3 Alternativt 4
2.3 Elsystem 4
2.3.1 Efterfrågeflexibilitet 4
2.4 Nord Pool 5
2.5 Elpriser 6
2.5.1 Negativa elpriser 6
2.6 Väder API:er 6
2.6.1 SMHI 6
2.6.2 Grönt Väder 7
2.7 REST API 7
2.8 Relevanta lösningar 7
2.8.1 Tibber 7
3 Metod 9
3.1 Mjukvara 9
3.1.1 Front-end 9
3.1.2 Back-end 9
3.2 Datainsamling 10
3.2.1 Geografiska data 10
3.2.2 Väderprognos 10
3.2.3 Prisdata 10
3.3 Tester 10
3.3.1 Android Studio Profiler 10
3.3.2 Firebase Realtime Database Profiler 10
4 Resultat 13
4.1 Applikation 13
4.1.1 Profiler 15
4.2 Databas 16
4.3 Java-program 17
5 Diskussion 19
5.1 Samhällskrav på teknisk utveckling 19
6 Slutsats 21
7 Referenser 23
8 Bilagaöversikt 25
8.1 Bilagor för figurer i rapporten 25
8.2 Bilagor resultat 25
1 Inledning
Det finns intresse att koppla upp olika utrustningar i hemmet mot nätet för att bygga ett s.k.
Smart Hem. Teknik för detta har funnits under många år men först på de senaste 10 åren har det blivit vanligare att även icke tekniskt kunniga kan se ett värde i detta. Det finns på marknaden ett mycket stort utbud av olika produkter som har rimliga priser och enkelt kan installeras och drivas av icke tekniskt kunniga.
Ett intressant steg på vägen mot ett Smart Hem är att utnyttja informations- och kommunikationsteknik för att optimera energianvändningen i en fastighet. Detta är relevant då allt fler fastigheter har lokala energikällor som sol och vind. Det finns också möjlighet att lokalt lagra energi i batterier eller andra lagringsformer som vatten. Till detta kommer att priset på elenergi kan variera ganska mycket på kort tid. Energipriserna varierar nu inte längre bara per säsong utan även ner på timnivå. Elhandel på timbasis är möjligt sedan några år men det krävs mycket manuell hantering idag för att verkligen kunna utnyttja dessa variationer. Det kan bli till egen fördel genom att förskjuta den egna energiförbrukningen i tiden utan att uppleva några större komfortförluster. Detta examensprojekt har som mål att visa på möjligheter att automatiskt styra energianvändningen på ett så effektivt och optimalt sätt beroende på de lokala förutsättningar som en fastighet har.
1.1 Syfte
Syftet med projektet är att hjälpa en användare att välja grön energi samt handla billig elektricitet. Eftersom det är möjligt att handla el per timme som privatperson, kan man sänka sina kostnader. Genom att jämföra bestämda elpriser med väderprognoser ska det i framtiden kunna vara en faktor när vitvaror är uppkopplade och kan styras utanför hemmet.
1.2 Mål
Projektet har en första målsättning att i en mobilapplikation i realtid ge information till en användare vilket energislag som är mest optimalt att använda för en aktuell fastighet.
Informationen baseras på hur fastighetens energisystem ser ut samt aktuella energipriser.
Projektets andra målsättning är att utveckla funktionen i en plattformsdator t.ex. Raspberry Pi där information om optimalt energislag läggs på en output pin.
1.3 Krav
K1 Möjlighet att bygga upp en digital lokal funktionell beskrivning avseende energisystemet för en fastighet. Exempelvis om användaren har solpaneler, solvärmepaneler, värmepump, pelletseldning, direktel etc.
K2 Insamling av väderinformation (sol, temp och vind) från lämplig service de närmaste 4 timmarna
K3 Insamling av spotpris på elenergi för minst 12 timmar i förväg
K4 Systemet gör en prediktering för de närmaste fyra timmarna vilket energislag som är
optimal att använda baserad på den konfiguration som en fastighet har.
1.4 Avgränsningar
I projektet kommer enbart mjukvara hanteras. API:er från Grönt Väder och Nord Pool kommer att användas för att hämta data om väderprognoser och elpriser på timnivå. Projektet kommer bestå av tre delar, en front-end, back-end och databas. Projektet körs lokalt och säkerhet kommer inte att implementeras.
2 Bakgrund
2.1 Mobilapplikation
Mobilapplikationer är utformade för att köra på mobila enheter som telefon, surfplatta eller klocka. Smartphones är en viktig del av våra liv eftersom de har gjort livet enklare. Smartphone- användaren spenderar 90 procent på appar av sin tid på mobilen. Mobilappar utgör mer än hälften av tiden som spenderas på digital media [1].
I början var de till för mejl, kalender och kontaktlistor men p.g.a. hög efterfrågan på mobilapplikationer har det expanderat till andra områden som GPS och platsbaserade molntjänster, mobilspel, biljettköp, matbeställning, kommunikation och nu finns det flera miljoner.
Det finns olika typer av mobilapplikationer. Det finns native-, hybrid- och webbaserad app.
Applikationer som är riktad mot en viss mobil plattform kallas native appar. Hybridbaserad app går att installera på mobilerna men körs genom webbläsare. Webbaserad applikation kräver internet och all personlig data kan hämtas med vilken mobil som helst [2]. Projektet kommer att skapa en native app som är riktad mot androidenheter.
2.2 Programmeringsmiljöer
2.2.1 Android Studio
Android Studio är en av flera utvecklingsplattformer som ägs av Google. Fördelen är att det är gratis och att det finns verktyg som förenklar processen. Android Studio har en smart kodredigerare som hjälper programmeraren att arbeta snabbare och koda mer produktivt med hjälp av omstrukturering av kod och kodanalys. Android Studio har ett visuellt verktyg som kan skapa komponenter genom att dra in de i applikationen istället för att skriva XML-kod från början. Det även finns emulatorer för flera modeller av Android telefoner där man kan simulera hur applikationen skulle se ut.
2.2.2 Java och Kotlin
Java är ett välkänt språk bland programmerare men språket är inte felfritt. Språket kräver mycket kod för att göra simpla saker. Detta gör att utveckling och felsökning tar lång tid.
”NullPointerException” [3] gör även Java till ett språk som inte är helt säker att koda i vilket är det största problemet med Java inom Android utveckling då plattformen ger själv ut ”Null Pointers” under körning. Detta leder ofta till att en applikation som har missat att ta hand om alla former av ”Null Pointers” kraschar och stoppas helt.
Kotlin däremot är nästintill motsatsen till Java när det kommer till mängden kod som behövs och hur den hanterar ”Null Pointers”. Lösningen som Kotlin använder för ”Null Pointer”
problemet är att problemet har flyttats över från körtid till kompileringstid, d.v.s. att programmeraren blir varnad medan koden blir skriven om de olika felen som kan uppstå ifall en ”Null Pointer” skulle uppstå.
Numera är Kotlin det officiella programmeringsspråket för Andoridutveckling. Kotlin körs på
samma sätt som Java kod, d.v.s. en ”Java Virutual Machine” och kan till viss del bli översatt
från Javakod. Det betyder att nästan all form av hjälp som finns att hitta på nätet för
Javaprogrammering är även relevant för Kotlin. Det är även möjligt att blanda Javakod och
Kotlinkod om det skulle vara så att översättningen skulle vara otillräcklig [4]. Men Kotlin har
även nackdelar. Kompileringstiderna är längre än andra språk och storleken på kodpaketen som måste inkluderas är större. Språket är också nytt jämfört med Java vilket leder till att antalet utvecklare som går att diskutera diverse problem inte är i närheten av lika stor som med Java.
2.2.3 Alternativt
Det finns andra alternativ att programmera en applikation, såsom plattformsoberoende arbetssätt där man kan konvertera en kod som kan visas i både Android och iOS. Ett exempel är Visual Studio tillsammans med Xamarin där det är till för att göra applikation för båda operativsystem. Där kodar man i programmeringsspråken .NET och C#. Xamarins utvecklingsgrupp är inte så stor som Androids vilket kan vara en nackdel om man inte kan hitta en lösning till sitt problem. Dessutom om Android skulle släppa ut en ny version skulle det ta en tid innan Xamarin uppdaterar.
Ett annat alternativ är plattformen Swift där applikationer är till för iOS. Nackdelen med den är att det kostar för att få använda deras tjänster. Det är också native vilket innebär att resultatet inte kommer kunna köras på en Android mobil.
2.3 Elsystem
I Sverige ligger systemansvaret för el på Svenska kraftnät. Deras ansvar är att se till att elsystemet kan upprätthålla balansen mellan elproduktion och elkonsumtion. Eftersom det inte går att lagra el i elnätet måste det produceras exakt lika mycket som används varje sekund.
För att hålla balansen har Svenska kraftnät lämnat över det ekonomiska ansvaret till de s.k.
balansansvariga. Alla elproducenter och elkonsumenter är bundna till en balansansvarig aktör som ser till att planera kundernas elanvändning/elproduktion. Den balansansvariga ser till att handla eller sälja el så att elanvändning och elproduktion hamnar i balans som oftast görs via elbörsen Nord Pool [5].
Elnätet står inför två grundläggande tekniska utmaningar när det gäller att tillgodose förnybara energikällor som plats och variation. Förnybara resurser ligger ofta långt ifrån befolkningen som ska använda dem. Detta sätter ytterligare krav på man har tillgång till långdistansöverföring med hög kapacitet för att matcha tillgång med efterfrågan. Skillnaden hos styrkan i vädret leder till att förnybara energikällor också får hög variabilitet. Dessa siffor kan vara upp till 70% för sol på dagtid på grund av passerande moln och 100% för vind på vindstilla dagar [6]. Genom att korrekt förutspå vädret och anpassa elanvändningen utefter väderprognoser så kan elen användas på ett mer effektivt sätt.
2.3.1 Efterfrågeflexibilitet
Efterfrågeflexibilitet är när kunden kan anpassa sin elförbrukning utifrån olika signaler, t.ex.
när elnätet är hårt belastad kan kunder minska sin elförbrukning eller öka när det är mindre belastat.
Idag uppstår det effekttoppar eftersom många använder el samtidigt. Om alla använde el när det finns mycket elproduktion och utrymme att transportera elen i nätet skulle balansering och driften av elsystemet underlättas.
I Sverige är konsumenternas effektbehov personberoende och apparatberoende. I större
utsträckning skulle apparatberoende effektbehov kunna styras automatiskt och inte påverka
kundens komfort genom att flytta till optimala tidpunkter på dygnet. Potentialen att styra värme,
kyla, m.m. har uppskattats till omkring 25 procent av toppeffektbehovet [5]. Med
efterfrågeflexibilitet kan kunder hålla frekvensen i elnätet genom att öka eller minska sin elanvändning eller flytta elanvändningen till en annan tidpunkt [7].
Figur 1. Olika typer av efterfrågeflexibilitet från Energimarknadsinspektionen, finns i Bilageöversikt [1]
Elsystemet kräver konstant balans när el produceras samt förbrukas. Om balansen blir störd kan risken bli att elavbrott uppstår eller att elektrisk utrustning blir skadad.
Om kunderna är flexibla kan man minska effektbrist när många använder el samtidigt, vilket sparar samhället en kostnad. Dessutom kan resurser utnyttjas bättre såsom vind- och solkraft om det går att styra elanvändningen. För att detta ska kunna fungera behöver kunderna få rätt prissignal från sin elhandlare som reflekterar elpriset timme för timme. Då kommer efterfrågan på el bli lägre när det är högt pris och högre när det är lågt pris [8].
2.4 Nord Pool
Nord Pool är en nordisk elbörs som driver den största elmarknaden i Europa. Aktörer som deltar i Elmarknaden kan delas in i tre marknader, dagen-före-, intradags- och balansmarknaden [7].
o Dagen-före-marknaden
Priset bestäms på alla timmar för nästkommande dygn, det s.k. spotpriset.
o Intradagsmarknaden
På intradagen har aktörer möjlighet att handla sig i balans, d.v.s. justera tidigare handel om prognoser visade sig vara fel. Marknaden stänger en timme före leveranstimmen.
o Balansmarknaden
Det är en handel där Svenska kraftnät använder automatiska och manuella reserver för att upprätthålla kraftbalansen inom drifttimmen.
Nord Pools spotmarknad utför den viktigaste uppgiften att balansera utbud och efterfrågan i
kraftmarknaden med lite framtidsplanering. Stora elproducenter och elkonsumenter styr
elpriserna genom att ge bud och utbud till spotmarknaden och beräknar ett timpris. Nord Pool
publicerar ett spotpris den kommande dagen för att balansera tillgång och efterfrågan. Varje
morgon deltar alla företagen som är med och publicerar sina beställningar på auktionen för den
kommande dagen. Varje order anger volymen i MWh/h som en deltagare är villig att köpa eller
sälja för varje enskild timme för den kommande dagen [9].
2.5 Elpriser
Elpriset bestäms av utbud och efterfrågan på el.
I Sverige har vi fyra elområden:
1. SE1 – Luleå 2. SE2 – Sundsvall 3. SE3 – Stockholm 4. SE4 – Malmö
Anledningen till indelning av områden är för att det lönar sig att producera el i sina egna områden istället för att transportera elen, eftersom det finns inte tillräckligt med bra elledningar. Elpriserna varierar mellan områden och det produceras överskott av el i norra delen av Sverige och underskott i södra delen där efterfrågan är större än tillgången [10].
En förutsättning av att teckna timavtal är att det finns information.
Dock är det ungefär hälften av elhandelsföretagen som kräver att
kunden själv kontaktar de för att få information. Det blir sökkostnader för kunderna eftersom mycket tid läggs ner för att leta efter information. Med timavtal är att har elanvändarna möjlighet att påverka sin förbrukning och på så sätt spara pengar [11].
2.5.1 Negativa elpriser
För att det ska bli negativa priser innebär det att det finns ett överskott på el och för första gången i Sverige uppstod det negativa elpriser på Nord Pool. Detta hände under natten den 10 februari 2020 klockan 00–04 när Ciara stormen bidrog till hög vindkraftsproduktion. Vidare säger en elexpert på företaget Godel:
- ”Och ser man till alla nya vindkraftverk som planeras nu bör vår produktion ha fördubblats om tre år. Så jag skulle tro att negativt elpris kommer bli ett vanligare inslag i Sverige framöver” [12].
Med höga negativa elpriser kan man få betalt av sin elleverantör för att använda el eftersom det överproduceras el. De som får betalt är de som handlar upp el på Nord Pool och för att få betalt som enskild kund måste man handla el på timpris.
2.6 Väder API:er
2.6.1 SMHI
”SMHI står för Sveriges meteorologiska och hydrologiska institut och är en expertmyndighet under Miljö- och energidepartementet” [13]. Deras uppgift är att ta fram prognoser för väder, vind, samt klimat och miljö. Med SMHIs API kan man ta reda på väderdata och väderprognoser i realtid.
Figur 2. Elområden i Sverige från Elen.nu, finns i
Bilageöversikt [2]
2.6.2 Grönt Väder
Grönt Väder är en vädertjänst som jämför SMHI, YR och GFS samt kombinerar alla tre tjänster för att få en pålitligare väderprognos. Information om vädret finns 10 dagar framåt men endast den aktuella dagen finns vädret på 24 timmar [14].
Med Grönt Väders API kan man hitta vädret på två sätt:
o Det första är att ange en plats eller en del av platsen som finns med i deras databas. Då kan resultatet bli flera platser som har samma namn eller andra namn som liknar.
o Det andra är att ange koordinater på platsen.
Med dessa två alternativen kan man få ut en id på den närmaste väderstation som används för att hitta vädret på det valda området.
2.7 REST API
REST API står för Representational State Transfer och är en arkitektur för distribuerade system.
Arkitekturen går ut på att funktioner och data körs/hämtas via URI (Uniform Resource Identifiers) länkar. Data och funktionerna hanteras med enkla operationer. Gränssnittet som vanligtvis brukar användas för kommunikation mellan servern och klienten är HTTP (Hypertext Transfer Protocol). Informationen som skickas mellan servern och klienten representeras ofta i JSON-format, XML-format eller liknande.
2.8 Relevanta lösningar
2.8.1 Tibber
Tibber AB [15] är ett elbolag som levererar 100% grön energi från förnyelsebara källor. De har en egenproducerad app “Tibber” som hjälper kunder sänka sina elkostnader genom att köpa el automatiskt när timpriserna är som lägst. Applikationen jämför priser med andra elbolag i Sverige och hjälper kunder analysera sin förbrukning i realtid. Tibber har integrerat med smarta bilar som t.ex. Volvo, Tesla, BMW, Jaguar etc. Med bilmodellens API kan kommandon skickas ut när bilen behöver laddas utifrån priser.
Det finns en väderstation “Netatmo Weather Station” visar väder och klimatet inomhus.
Väderstationen mäter temperatur, luftfuktighet, lufttryck, CO2-nivå och ljudnivå samt data för
klimatet. Det finns dessutom tillbehör för vind- och regnmätning som kan kopplas tillsammans
med Tibber.
3 Metod
Figur 3. Hela systemet med annan priskälla istället för Nord Pool, Ikoner tagna från Bilagor [1]
3.1 Mjukvara
I examensarbetet har plattformen Android Studio och Eclipse använts för front-end och respektive back-end. Produkten har använt sig utav programmeringsspråken Java och Kotlin.
3.1.1 Front-end
Till front-end har en mobilapplikation programmerats på Android Studio. Applikationen skrivs i programmeringsspråket Kotlin. Fördelen med Android Studio är att det är gratis att använda plattformen för att utveckla appar. Men p.g.a. att det är en native app kommer den inte fungera på exempelvis på mobiler med iOS. Som nämnt under 2.2.2 Java och Kotlin är Kotlin bättre när man skriver koden eftersom man blir varnad om ”Null Pointers” under kompileringstid.
Applikationens programkod låter en användare skapa ett konto och registrera sig med sina uppgifter. Med uppgifterna kommer front-end hämta information från Grönt Väders API och Google Maps Geocoding API, dessa API-anrop görs med hjälp av HTTP-requests, mer specifikt GET-requests. GET-kommandot inom HTTP används för att säga till servern som klienten kommunicerar med att den utpekade filen (eller programsvar från filen) ska skickas till klienten. Resultatet från båda API:er hämtar specifik data för att sedan läggas upp på databasen.
Grönt Väder och Geocoding är REST API:er vilket gör det enkelt för klienten att hämta data med HTTP protokollet.
Efter en användare har skapats finns det en inloggningssida där användaren loggar in och efter inloggning kommer en tabell att visas med spotpriset från Nord Pool och väderprognoser från Grönt Väder. På sidan kommer det att visa vilket alternativ som är billigast just nu och under hela dagen.
3.1.2 Back-end
Back-endens uppgift är att spara och uppdatera information i en databas samt hämta spotpriset
och få det att efterlikna hur Nord Pool hanterar sin information med deras API. Back-end består
av ett java-program och en databas. Med programmet skrivet i Java kan de flesta plattformar
användas. Programmet hanterar data i bakgrunden och hämtar spotpriset för de fyra elområden
(SE1, SE2, SE3 och SE4) i Sverige. Java-programmet hämtar spotpriset med HTTP-request
och lägger det i databasen. Den uppdaterar Grönt Väders väderprognoser mer frekvent än
spotpriset i databasen. Spotpriset är redan satt med Dagen-före-marknaden och förändras inte
under dagen till skillnad från väder. Android Firebase Realtime Database är databasen som
används till projektet.
3.2 Datainsamling
3.2.1 Geografiska data
Google Maps Geocoding API används för att hitta platsen/adressen som användaren vill att applikationen ska verka över. Geocoding API:n kan konvertera en adress till koordinater, detta svaret får man tillbaka via ett HTTP-response där man kan hitta datan organiserat i JSON- format. I användarfallet för applikationen så skickas en användargiven adress som input till Geocoding API:n. API:n skickar då tillbaka koordinaterna för den adressen. Dessa koordinater används sedan för att hitta den relevanta väderprognosen för användarens område med hjälp av Grönt Väders API.
3.2.2 Väderprognos
För att hämta väderprognoser på en specifik plats kommer Grönt Väder att användas tillsammans med Google Maps Geocoding. Grönt Väder kan inte söka efter specifika adresser som t.ex. Kristian IV:s väg 3 eller Högskolan i Halmstad. Med Geocoding API plockar man ut en adress koordinater och använder till Grönt Väders API för att hitta plats id. Med id:et kan vädret hämtas från närmaste väderstation. Funktionen kör ett call till Google Maps Geocoding via http och returnerar ett JSON-objekt.
Eftersom Grönt Väder hämtar väderprognos från GFS, YR och SMHI finns det en kombination av alla tre för en noggrann prognos. Dock visar det ingen beskrivning av vädret på kombo så projektet hämtar YR och GFS med Grönt Väders API.
3.2.3 Prisdata
För optimala resultat hade Nord Pools API varit alternativet att använda för att hämta dagens elpriser. Men projektet har tagit en annan riktning för att hämta priserna och har utgått från en annan källa som skiljer lite från priserna på Nord Pools egna sida. Priserna är exklusive påslag av elleverantör, avgift för elcertifikat, elskatt och moms. När prisdatan har hämtats läggs den i en JSON-struktur som efterliknar Nord Pools data.
3.3 Tester
3.3.1 Android Studio Profiler
Android Studio Profiler är ett verktyg på Android Studio där applikationen analyseras hur mycket CPU, MEMORY, NETWORK och ENERGY den tar från mobilen som körs. Detta verktyget kommer att användas för att ge en grafisk bild över hur systemet beter sig under några normala användarfall. Testet kommer köras på en verklig hårdvara (OnePlus 7T), inte i emuleringsverktyget som ingår i Android Studio. Testet i sig kommer innebära att testaren kommer att använda applikationen för att skapa en ny användare, logga in på den nya användaren och sedan visa informationsvyn för den användaren. Resultatet från detta test kommer vara några grafer (representerat i bildform då datan som spelas in endast kan läsas av och visas via Android Studios egna vy). Grafernas data kommer sedan att jämföras gentemot den hårdvaran den kördes på samt med de värden som rimligt förväntades.
3.3.2 Firebase Realtime Database Profiler
Firebase Realtime Database Profiler är ett sätt att testa databasen när applikationen körs. Den
läser av de operationer som utförs i applikationen och ger ut data som beskriver hur snabbt och
hur mycket applikationen läser och skriver till databasen. Detta testet kommer utföras under
samma förhållanden som Android Studio Profiler testet, d.v.s. att ett normalt användarfall
kommer att utföras på en verklig hårdvara (OnePlus 7T). Resultatet av detta testet kommer att
representeras i form av två tabeller, en tabell där responstider visas för hämtningar av olika
variabler i databasen och en tabell som visar storleken på de hämtningar som gjordes under
körningen. Detta test kommer att utföras på användarens sida av systemet, d.v.s. resultatet
kommer visa hur mycket en användares nätverk påverkas av att använda applikationen.
4 Resultat
4.1 Applikation
Mobilapplikationen blev simpel där man skapar en användare där man fyller i användarnamn, mailadress, lösenord, adress, postnummer och prisområde. Informationen sparas i databasen där lösenordet är hashat. Användaren loggar in och startsidan är en tabell som visar information om tid, spotpris, väder, temperatur och vindhastighet.
Figur 6 och 7. Billigast pris och maximal vindhastighet för 23 augusti 2020.
Figur 8. Ett flödesschema över front-enden.
Detta flödesschema beskriver resultat hos front-enden och hur en användare skapar ett konto.
Om användaren (användarnamnet och/eller mejladressen) redan finns i databasen måste en ny användare skapas. Om användaren redan har en inloggning kan den gå direkt till login sidan.
Om det lyckats skapa en användare med unikt användarnamn och mejladress och fyllt i resten
(lösenord, adress, postnummer och elområde) kommer mobilapplikationen kolla om adressen
ger ut ett nytt Grönt Väder id eller om den redan finns i databasen. Finns den inte i databasen
hämtas den m.h.a. Grönt Väders API och läggs till i databasen samtidigt som användaren. När
det är klart kan användaren logga in och se sin valda information i form av tabell.
Figur 9. Flödesschema över back-enden.
Back-end består av ett Javaprogram och en databas. Programmet börjar med att läsa av alla väder id:en i databasen. När den har gjort det har programmet en tråd som kollar om det har 30 minuter. Om det inte har gått 30 minuter så sover den och räknar ner tills den vaknar. Tråden återställer räknaren och hämtar nya väderprognoser med Grönt Väders API. Därefter skickar programmet det till firebase databasen. Direkt när det är klart så hämtar programmet elpriser från dess källa och skickas till databasen. Elpriserna hämtas varje 30 minuter också men det förändrar inget på elpriserna eftersom de är redan bestämda.
4.1.1 Profiler
I Android Studio kan man använda Profiler för att kolla applikationens status om CPU,
MEMORY, NETWORK och ENERGY. För testet har OnePlus 7T mobilen använts för att
registrera en användare, logga in på och visa sin valda information.
Figur 10. Applikationens CPU, MEMORY, NETWORK och ENERGY vid användning.
Resultatet finns längst ner i Bilagor resultat. På figur 10 visar Profiler att applikationen endast använder en bråkdel av CPU:n och belastar inte mobilen i någon större utsträckning. Detta var även förväntat då applikationen i sig inte hanterar några större uträkningar utan endast hanterar färdig data. Applikationen använder sig inte av någon avancerad grafik eller animationer vilket leder till att uppvisningen av datan inte heller påverkar CPU:n särskilt mycket.
Figur 11 visar MEMORY tar ungefär 40-50MB och detta är väldigt lågt eftersom moderna mobiler har i lägsta fall 4GB RAM-minne. Mobilen som testet utfördes på har 8GB RAM- minne. Denna minnesåtgången kommer inte märkas av användaren på samma sätt som användaren inte märker av att Androids inbyggda väckarklocka tar 47MB RAM-minne att ha igång (Testat på samma mobil som Profiler testet kördes på).
Figur 12 med NETWORK, visas två områden av blåa respektive gula spikar. De gula spikarna visar när information skickas och blåa spikar visar vad applikationen fick tillbaka. Dessa visar enbart när vi loggar in och kommer in p [16]å sidan som visar information.
Slutligen figur 13 visar ENERGY nivån på Y-axeln och på bilden ser man att användning av applikationen ligger under “Light”. Det betyder att när man skapar en användare så drar det inte mycket energi eller batteri på användarens mobil. Detta är även förståeligt då applikationen inte är särskilt krävande och kan i de flesta fallen (förutom NETWORK) prestandamässigt jämföras med Androids egna väckarklocka-applikation.
4.2 Databas
Databasen testas med Firebase Realtime Database profiling tool. Tabell 1 & 2 visar när en
användare skapas på applikationen och resultatet visar hur snabbt det tar att skriva till
databasen. Men resultatet kan variera för varje användare p.g.a. faktorer som
nätverksförhållanden som latens på klientsidan.
Tabell 1. Hur snabbt det tog för applikationen att skriva till databasen.
Tabell 2. Hur mycket data som skickas upp till databasen
.
4.3 Java-program
För att testa back-end har programmet få stå igång i 40 timmar och fungerar att uppdatera databasen. Programmet uppdaterar rätt information även när man manuellt försöker ändra i databasen med felaktig data. Under dessa timmar har minnesförbrukningen varit stabil, detta visar att programmet inte har några märkbara minnesläckor. Detta var även förväntat eftersom Java sköter sin egna minnesstädning.
Under en längre körning så låg minnesåtgången mellan 110-120MB och processoråtgången låg
i snitt runt 1% av den totala processorkraften hos en Macbook Pro 2017. Denna mätningen visar
även att programmet i sig inte är särskilt krävande och skulle potentiellt även kunna köras på
en enheter med mindre prestande tillgängligt, som t.ex en Rasberry Pi 3 B. Att köra back-enden
på en sådan Rasberry Pi hade inte heller tagit upp en stor del av dess kapacitet, så samma enhet
som kör denna koden hade även kunnat utökas till att hantera andra smarta hem funktionaliteter
om det koden skulle vidare utvecklas.
5 Diskussion
Det är lätt att ta isär delsystemen eftersom de är delvis oberoende av varandra. Applikationen har ingen koppling till programmet som sköter uppdatering av databasen. Applikationen är en exempelkod som kan enkelt byta firebase realtime-databas, detsamma gäller för back-end. Allt som krävs är att de har adressen till databasen. Men applikationens input påverkar back-end för att back-end måste fungera så krävs det någon form av input som skapar strukturen på databasen som den är nu.
Tibber är ett exempel på applikation som har liknande ändamål som detta projekt, som även ger en bild av vad som hade kunnat vidareutvecklas med detta projekt. Mobilapplikationen Tibber kan jämföra priser mellan olika elbolag och samtidigt erbjuda billigare och grön energi eftersom de är ett elbolag. De visar också timpriser för att optimera elförbrukningen och har dessutom integrerat med utrustningar i hemmet och smarta bilar. Projektets syfte är gemensam med Tibber men de har använt sig av artificiell intelligens vilket är något projektet skulle kunna använda för att förbättras. Däremot så hade detta antagligen krävts en del extra väderprognoser med mer relevant data än vad Grönt Väder för nuvarande ger för att få ett någorlunda positivt resultat. Som till exempel, en bättre skala för solljusnivåer och/eller fler prognoser per timma.
Detta hade dock ökat komplexiteten på projektet och den teorin som ingår. Därför hade en vidareutveckling i denna stilen passat bättre som projekt på Master-nivå.
För att hämta väderprognoser finns det flera API:er att välja mellan. Till exempel har SMHIs API vissa parametrar som Grönt Väder inte har. SMHI har medelvärde för (total) molnigt, (delvis) molnigt, sannolikhet för åska o.s.v. Deras API har väderbeskrivningar som representerar en siffra vilket kan förenkla att välja prioritera vädertyper. Men eftersom Grönt Väder tilldelades av uppdragsgivaren kunde projektet inte göra det som projektet hade tänkt sig. Med Grönt Väders API står ingen data om vilka väderbeskrivningar som finns och för att programmera en algoritm krävs mer information.
För vidareutveckling hade projektet kunnat använda riktig Nord Pool data och använda den geografiska datan för att ta reda på vilket elområde adressen ligger i så användaren slipper manuellt välja ut det. Att lägga till artificiell intelligens hade varit något som kan förbättra projekten. Men för det behövs även Grönt Väder förbättra för att kunna jämföra elpriser med väder. Grönt Väder kan ha tomma beskrivningar på vädret vilket försvårar jämförelsen om billigast energi. Det är svårt att veta vad som är billigast om man t.ex. har solpaneler, vindkraftverk och köper timpris. Att jämföra energikällorna var för sig funkar men det går inte riktigt att jämföras med varandra om inte man har mer information.
Back-end hade kunnat flyttas till en Raspberry pi istället för att ha den igång på en hårdvara som laptop. Det är billigare och för vidareutveckling skulle någon enhet kunna kopplas till Pi:en via en output pin. Back-endens kod hade kunnat förbättrats så att den körde alla calls parallellt till Grönt Väder. Men eftersom Grönt Väder svarar långsamt skulle det även påverka prestandan.
5.1 Samhällskrav på teknisk utveckling
Projektet påverkar miljön på ett positivt sätt då ett hushåll kan planera och se priserna på
applikation och förbruka när priserna är som lägst. För när priserna är som lägst är det mindre
belastat på elsystemet. Skulle allt fler människor börja handla el på timnivå och planera sin
elanvändning hjälper det elsystem så att de slipper de handla el och det kostar en stor summa
speciellt om det skulle uppstå strömavbrott. Men ett grönare tankesätt kan det uppmana andra att tänka mer på miljön samt vara snäll mot plånboken.
När det gäller säkerhetskrav skulle examensarbetet kunna förbättra sin säkerhet kring
databasen. Autentisering skulle kunna databasen säkrare så att inte vem som helst ska kunna
skriva och läsa från databasen. Informationen hos användaren skulle kunna vara hashat med en
egen hash-funktion istället för att använda Android Studios egna.
6 Slutsats
Projektet kunde delvis uppnå första målsättning om att ge information i realtid till en användare om de olika energislagen men inte om vad som är optimalt. Andra målsättningen uppfylldes inte eftersom projektet bytte riktning och hade back-end på laptoppen.
Programmet har inte uppfyllt kraven K3 och K4 eftersom det inte finns tillgång till Nord Pools API där priserna för nästa dygn är tillgängliga 12h innan. Elpriserna som projektet utgår ifrån stämmer överens med Vattenfall men den uppdaterar sina priser vid midnatt. Eftersom det inte går att hämta elpriserna för nästa dag i förväg är det inte möjligt att visa de senaste 4h och jämföra det med väder.
Projektet är ett sätt att använda grön energi och betala mindre för el om man kan anpassa efter
timpriser. Genom att handla billigt jämnas elsystemet ut och Svenska kraftnät slipper betala
stora kostnader för att upprätthålla elsystemet. Men projektet kunde inte jämföra olika
energislag med varandra. För att förbättra projektet skulle man kunna lägga till artificiell
intelligens och flytta back-end till en Raspberry Pi.
7 Referenser
[1] BuildFire, ”8 Steps to Understanding The Mobile App Development Lifecycle,”
[Online]. Available: https://buildfire.com/understanding-mobile-app-development- lifecycle/. [Använd 30 Juni 2020].
[2] Charter Global, ”UNDERSTANDING THE 3 TYPES OF MOBILE APPS,” 23 Mars 2020. [Online]. Available: https://www.charterglobal.com/understanding-the-3-types- of-mobile-apps-development-services/. [Använd 10 Augusti 2020].
[3] Android Developers, ”www.developer.android.com,” 27 December 2019. [Online].
Available: https://developer.android.com/reference/java/lang/NullPointerException.
[Använd 6 Mars 2020].
[4] M. Jangid, ”Kotlin – The unrivalled android programming language lineage,” Imperial Journal of Interdisciplinary Research (IJIR), vol. 3, nr 8, pp. 256-259, 2017.
[5] Power Circle, ”http://powercircle.org/,” 28 November 2019. [Online]. Available:
http://www.powercircle.org/stodtjanster.pdf. [Använd 6 Mars 2020].
[6] G. Crabtree, J. Misewich, R. Ambrosio, K. Clay, P. DeMartini, R. James, M. Lauby, V.
Mohta, J. Moura, P. Sauer, F. Slakey, J. Lieberman och H. Tai, ”Integrating Renewable Electricity on the Grid,” November 2011. [Online]. Available:
https://www.researchgate.net/publication/253964852_Integrating_Renewable_Electrici ty_on_the_Grid. [Använd 07 September 2020].
[7] Energimarknadsinspektionen, ”Åtgärder för ökad efterfrågeflexibilitet i det svenska elsystemet,” Eskilstuna, 2016.
[8] Energimarknadsinspektionen, ”Efterfrågeflexibilitet en outnyttjad resurs,” Eskilstuna, 2016.
[9] A. Auväärt, A. Rosin, N. Belonogova och D. Lebedev, ”NordPoolSpot price pattern analysis for households energy management,” i 2011 7th International Conference- Workshop Compatibility and Power Electronics (CPE), Tallinn, 2011.
[10] ”Energimarknadsbyrån,” 21 Mars 2019. [Online]. Available:
https://www.energimarknadsbyran.se/el/elmarknaden/elomraden/. [Använd 10 Mars 2020].
[11] Energimarknadsinspektionen, ”Uppföljning av timmätningsreformen,” Eskilstuna, 2014.
[12] F. Tano, ”Stormen Ciara gav negativt elpris för första gången någonsin,” Dagens Nyheter, 2020.
[13] SMHI, ”Stockholm,” [Online]. Available: https://www.smhi.se/. [Använd 09 09 2020].
[14] Grönt väder, ”Grönt väder,” Grönt Väder AB, 2018. [Online]. Available:
https://grontvader.se/. [Använd 7 Mars 2020].
[15] Tibber AB, ”Ett elavtal för dig som är lite mer 2020,” 2020. [Online]. Available:
https://tibber.com/se/smart-elavtal. [Använd 22 Augusti 2020].
[16] L. Richardson och S. Ruby, ”RESTful Web Services,” O'Reilly Media, Inc, Maj 2007.
[Online]. Available: https://tinyurl.com/y2fgnqmx. [Använd 10 September 2020].
[17] M. Alpman och J. Hållén, ”Köp el – få betalt,” Ny Teknik, 10 Maj 2010. [Online].
Available: https://www.nyteknik.se/energi/kop-el-fa-betalt-6420565. [Använd 6 Mars
2020].
8 Bilagaöversikt
8.1 Bilagor för figurer i rapporten
[1] Figur 1, Efterfrågeflexibilitet från Energimarknadsinspektionen
https://www.ei.se/Documents/Publikationer/rapporter_och_pm/Rapporter%202016/Ei_R2016 _15.pdf
[2] Figur 2, Elområden i Sverige från Elen.nu https://elen.nu/elomraden
[3] Figur 3, Ikoner
https://docs.google.com/document/d/1zn-I-
RW2W1Lh6yK48UyvaenUgUJqYiR8f7Rd1Oq5c7U/edit?usp=sharing
8.2 Bilagor resultat
[10] Resultat från Android Profiler för CPU, MEMORY, NETWORK och ENERGY [11] Resultat från Android Profiler för MEMORY
[12] Resultat från Android Profiler för NETWORK [13] Resultat från Android Profiler för ENERGY [14] Resultat från applikationen - Registringssida [15] Resultat från applikationen - Inloggningssida
[16] Resultat från applikationen - Högst temperatur den 23 augusti 2020
[17] Resultat från applikationen - Profilsidan
Figur 10. Resultat från Android Profiler för CPU, MEMORY, NETWORK och ENERGY
Figur 11. Resultat från Android Profiler för MEMORY
Figur 12. Resultat från Android Profiler för NETWORK
Figur 13. Resultat från Android Profiler för ENERGY
Figur 14 och 15. Registrings- och inloggningssida.
Figur 16 och 17. Högst temperatur den 23 augusti 2020 och profilsidan.
Besöksadress: Kristian IV:s väg 3 Postadress: Box 823, 301 18 Halmstad Telefon: 035-16 71 00
E-mail: registrator@hh.se www.hh.se
