Martin Koksrud Bekkelund

Det sies at datadrevne beslutninger er de beste. Men hvordan henter og bruker man egentlig data fra et smarthus til å ta bedre beslutninger?

Ethvert smarthus produserer en stor mengde data i løpet av en dag. Når skrur varmtvannsberederen seg på? Når skrur den seg av? Hva kostet strømmen da den var på? Hvor lenge ladet bilen og hva kostet det? Hvor mange kilowattimer brukte huset i går? Eller i forrige måned? Hva var gårsdagens strømforbrukstopp, altså peak? Står det på lys og varme i rom vi ikke oppholder oss?

Og ikke minst, hvordan kan vi bruke disse dataene til å utføre automatiserte handlinger som hjelper oss med å spare — eller i beste fall tjene — penger?

I denne artikkelen skriver jeg om hvordan jeg samler og strukturerer ønskede data. I en senere artikkel skriver jeg om hvordan jeg analyserer dem, hvordan jeg viser dem frem for bedre å forstå dem, for så å ta både manuelle og automatiserte beslutninger basert på innsikten.

Litt om vurderingene

Da jeg startet med dette arbeidet, tok jeg utgangspunkt i hva jeg ville vite. Samtidig innså jeg at det er vanskelig å vite hva man vil vite, før man faktisk vet det. Dermed tok jeg utgangspunkt i at jeg ønsket en fleksibel løsning som kunne lagre mange forskjellige typer data, og at de lot seg presentere og visualisere på ulikt vis.

Det finnes mange separate løsninger som gjør en del av det jeg ønsket meg. Strømleverandøren leverer en app med oversikt over forbruk. Det samme gjør nettselskapet. Homey har en egen Insights-modul for visualisering. Problemet er at ingen av disse er mine. Data ligger et annet sted, og skulle jeg bytte dem ut forsvinner også historikken. Dessuten er det vanskelig å krysskoble data eller å lage presentasjoner slik jeg selv vil ha dem.

I begynnelsen testet jeg alt fra enkel logging til en Slack-kanal, til et regneark i Google Sheets. Jeg innså imidlertid at over tid er det lite som overgår en godt strukturert relasjonsdatabase, og at denne må være en frittstående komponent uavhengig av andre løsninger jeg har hjemme.

Det vil si en egen databaseserver.

Hardware med Raspberry Pi

Jeg har god erfaring med Raspberry Pi og har allerede mange i drift både hjemme og på hytta. Dens svakhet er imidlertid minnekortet som før eller siden ender opp med å bli korrupt, med mindre man kjøper en industriell type. Enten før dersom det er intensiv skriving til og lesing fra minnekortet, eller siden kun som et resultat av lang tids drift. I første omgang kommer jeg til å starte med en database rett på minnekortet. Det er ikke en varig løsning når antall transaksjoner øker, men som en start er det raskt å komme i gang. Backup blir et stikkord jeg kommer tilbake til.

Til sammenlikning vurderte jeg å sette opp en MySQL-database hos DigitalOcean for formålet. Problemet er bare at prisen starter på 15 dollar i måneden, så det får jeg vurdere hvis jeg vokser ut av en Raspberry Pi. Kan hende flytter jeg gamle data til DigitalOcean over tid, men foreløpig skalerer denne løsningen helt fint.

Installasjon og oppsett

Å få opp en Raspberry Pi med Raspberry Pi OS er en triviell oppgave. Man kjøper maskinvaren — det vil si en Raspberry Pi, et minnekort, strømforsyning og et kabinett — setter den sammen og kobler til skjerm, tastatur og mus. Minnekortet flasher man med Raspberry Pi Imager og deretter går resten av seg selv.

Jeg har noen standardting jeg setter opp på enhver Raspberry Pi. Jeg gir dem et navn fra den norrøne mytologien og har allerede servere som Bifrost, Utgard, Midgard og nå også Mimes brønn. Navnene er ikke tilfeldig valgt, de reflekterer bruksområdet. Og for en databaseserver er altså Mimes brønn et passende navn. Videre setter jeg opp VNC- og SSH-tilgang, slik at jeg kan pakke vekk tastatur, mus og skjerm straks jeg er ferdig med det innledende oppsettet. Deretter plasseres den på teknisk rom og kobles til nettverket med kabel.

MariaDB

MySQL ville vært et kjent valg for mange, men jeg gikk for den nyere og litt mindre kjente tvillingen MariaDB som er kompatibel med MySQL. For en som ikke jobber med databaser og drift til daglig, er installasjon av MariaDB ganske enkelt, men oppsettet er noe herk. I hvert fall fra kommandolinjen, hvor man må redigere konfigurasjonsfiler og kjøre ymse SQL-kommandoer for å få en kjørende instans på beina.

For mitt behov trenger jeg både å kunne få tilgang til MariaDB fra andre maskiner i nettverket, samt via SSH. Det gikk en del timer for å få alt til å fungere. Noen stikkord på veien er som følger.

Konfigurasjonsfilen for MariaDB ligger på /etc/mysql/mariadb.conf.d/50-server.cnf. I denne må man åpne for tilgang fra andre maskiner enn den som MariaDB kjører på. Se etter linjen bind-address = 127.0.0.1. Du må nesten søke deg frem til hva du bør ha satt denne til for ditt oppsett.

Brukere som skal ha tilgang til databasen oppretter du med SQL i MariaDB-kommandolinjen med brukeren root. Her er brukernavn åpenbart brukernavnet, maskinnavn er maskinen den aktuelle brukeren kobler seg til fra og passord passordet.

CREATE USER 'brukernavn'@'maskinnavn' IDENTIFIED BY 'passord';

La oss si at du har en bruker som du kaller homey og din Homey har maskinnavnet homey.lan. Da ser det slik ut:

CREATE USER 'homey'@'homey.lan' IDENTIFIED BY 'passord';

Videre må du gi denne brukeren tilgang til MariaDB og de databasene og tabellene du ønsker.

GRANT ALL PRIVILEGES ON *.* TO 'homey'@'homey.lan' IDENTIFIED BY 'passord';

SQL

Jeg har knapt skrevet en eneste linje SQL siden jeg studerte, og jeg hadde rent glemt hvor tilfredsstillende SQL faktisk er. For den uinnvidde er SQL et språk for å opprette, lese, oppdatere og slette (CRUD) innhold i relasjonsdatabaser. Det er tilfredsstillende fordi datamodellen og språket til sammen gir lite rom for feil utover feil i de data du måtte putte inn, eller feil i modelleringen av databasen. Databaser og datamodellering var, sammen med prosessmodellering, de fagene jeg gjorde det best i da jeg studerte.

Man bruker SQL til alt fra å opprette databaser og tabellene inni databasene, til å fylle tabeller med data, lese data, oppdatere data og slette data. En annen tilfredsstillende egenskap ved SQL er at det er enkelt. Det er enkelt å lese selv for det utrente øye.

Kommandoen

CREATE DATABASE martins_database;

oppretter en database med navnet martins_database. Enkelt og greit.

CREATE TABLE martins_tabell (PersonID int, Etternavn varchar(255), Fornavn varchar(255), Adresse varchar(255), Sted varchar(255));

oppretter en tabell med de kolonner du leser i tabellen, etterfulgt av datatyper.

SELECT * FROM martins_tabell;

viser tabellen. Og så videre.

En fin egenskap ved MariaDB er at man kan kjøre SQL direkte fra kommandolinjen, altså via SSH, etter formatet

mysql --user=brukernavn --password=passord -e "SQL-kommando her;"

SQL er relativt lett å lære seg og det finnes plenty av veiledninger på nett.

Homey-app for MariaDB

Det er mange måter å få data inn i en database på. En av dem er via en egen app for Homey. På denne måten kan man utføre CRUD-operasjoner mot databasen rett fra Homey. Slik kan vi sende data til databasen for å bearbeide dem og deretter sende dem tilbake til Homey for å utføre handlinger basert på bearbeidede data.

Et eksempel er hvordan jeg håndterer strømstyring i huset. Jeg sender strømpriser til databasen hver time og returnerer et aggregert gjennomsnitt til Homey. På denne måten vet Homey hva gjennomsnittlig strømpris inneværende måned har vært, slik at jeg kan styre strømforbruket til tider der prisen er under snittet og jeg dermed vil få mer enn 90 % strømstøtte og i beste fall også tjene penger på strømforbruket. Denne metoden er ikke helt presis ettersom den baserer seg på historiske data, men det fungerer som en start, og vi jobber nå hjemme med å lage mer presise prediksjonsmodeller blant annet basert på sesong og kanskje også noe om antatt markedssituasjon i kraftmarkedet.

Det kommer en egen artikkel om akkurat dette, og den vil ha denne artikkelen som en forutsetning. Vær sikker på at du abonnerer på nyhetsbrevet, så får du den rett i innboksen.

Backup

Jeg nevnte backup. Før eller siden går minnekortet i dass. Da skal jeg opp med en ny og mer robust databaseserver og lese inn data fra backup.

Backup kan helautomatiseres. Jeg gjør det for alle mine databaser omtrent på følgende måte:

#!/bin/bash

# Sett mappe for backups
cd /home/brukernavn/Backup/Databasebackup/

# Ta backup

# --user	Brukernavn til databasen
# --password	Passord for angitt bruker
# database	Database det tas backup av
# xz		Komprimering

mysqldump --user=brukernavn --password=passord database | xz -9e > $(date +%Y-%m-%d)database.sql.xz

Dette returnerer en komprimert fil på formatet ÅÅÅÅ-MM-DD-database.sql.xz.

Dette skriptet kjører hver natt og deretter sendes filen til et NAS for permanent lagring.

Hva nå?

Med dette er grunnlaget lagt for å kunne samle data fra ulike kilder, enten det er fra Homey eller andre enheter som støtter SSH, som vist over.

Mitt første bruksområde er å samle innsikt om strømforbruk og timespriser, for så å ta beslutninger og handle basert på innsikten. Utover dette har jeg ingen konkrete planer ennå, men det kommer.

Akkurat nå leser jeg data fra databasen via SSH og kommandolinjen til MariaDB, og jeg skriver og leser data fra nevnte Homey-app. Jeg tenker å skrive en oppfølger om hvordan jeg tilgjengeliggjør data på en visuell og lettlest måte. Så langt har jeg ikke kommet ennå, men jeg tenker i skrivende stund en lokal webapp som leser og presenterer data direkte fra databasen. Enten det, eller så laster jeg data til en eller annen skyløsning for visualisering. Det kommer jeg tilbake til.

IoT Linux Programvare Smarthus