Kan en liten dings til 219,- kroner forhindre en katastrofe? Det er selvfølgelig ingen garanti mot katastrofe, men du kan i beste fall redusere skadeomfanget ved vannlekkasje.
Før man går helt amok i nettbutikken og kjøper alt man kan komme over av utstyr til smarthuset, er det greit å gjøre en liten vurdering av behovet. En del utstyr faller i kategorien sikkerhet og når det er snakk om sikkerhet bør man gjøre en enkel risikovurdering. Som kjent — hvis det er kjent — er risiko produktet av sannsynlighet × konsekvens. Jeg skal ikke gjøre en lang utredning av hva en risikovurdering innebærer, og det er heller ikke nødvendig å gjøre den omfattende.
Når vi har kommet til dette produktet er dets oppgave å registrere og varsle om vannlekkasjer. Hva er sannsynligheten for at en vannlekkasje inntreffer? Hva er konsekvensen når den først inntreffer? Stort mer omfattende trenger ikke en risikovurdering av en lekkasje i huset å være. Sannsynligheten for at en vannlekkasje oppstår er lav, men samtidig er vannskader godt representert hos forsikringsselskapene. Konsekvensen av at en vannlekkasje oppstår er imidlertid stor. Vann som lekker kan være vanskelig å stoppe og gjør stor skade på kort tid. Jo fortere man klarer å avdekke en lekkasje og få stanset den, jo mindre skade er skjedd.
Videre, når du tenker over det så har du jo røykvarslere for å varsle om brann. Så hvorfor skulle du ikke ha lekkasjesensor også? Spesielt når den er så billig.
Med dette utgangspunktet har jeg handlet lekkasjesensorer både hjemme og på hytta. Etter en del vurderinger handlet jeg Aqara lekkasjesensorer. Jeg har lang erfaring med andre Aqara-sensorer, og de har aldri gitt meg overraskelser. Den er liten, billig, batteridrevet og støttet i Homey som jeg bruker som hub i smarthuset. I esken ligger sensoren med et CR2032-batteri installert og er klar til bruk.
Jeg har plassert dem under oppvaskbenken på kjøkkenet og på teknisk rom der der det både er plassert varmtvannsbereder og stoppekran for vannet. Jeg har ikke sett poenget med å ha dem på badet, da det ofte er vått der og badene er flislagt og drenerer til sluk. En lekkasje på badet vil således ikke gjøre samme skade som på kjøkkenet. Når det er sagt er også teknisk rom flislagt og drenert, men eventuelle lekkasjer på dette rommet vil jeg svært gjerne vite om, siden det er her fordelerskapet til vann er plassert og her rør-i-rør-systemet ender opp.
Her fra kjøkkenet. Som observant leser ser du selvfølgelig at det har vært fukt her før.
Det var en forutsetning at sensoren lot seg inkludere direkte i Homey, uten noen hub fra tredjepart. Man legger til en ny enhet, søker opp appen som heter Aqara & Xiaomi ZigBee, velger «Aqara Water sensor» og følger veiledningen. Det er ikke helt intuitivt hvor på sensoren man skal klemme for å få den til å lyse, men jeg fikk det til ved å klemme sensoren flat omtrent på toppen av dråpe-ikonet.
Som med det meste annet i Homey, skjer ingenting av seg selv. Du må lage en handling, en flow som det heter i Homey. Med den forteller du Homey hva som skal skje når lekkasjesensoren oppdager vann. For eksempel:
Før du plasserer sensoren under vasken i håp om å aldri høre fra den, bør du teste at den fungerer. Fukt fingrene under vannkranen og gni dem på polene på undersiden av lekkasjesensoren. Hvis alt er i orden skjer følgende.
Aqara-sensorer kjøper man mange steder. Man gjør aldri noe feil ved å handle dem til 219,- kroner fra Elektroimportøren.
Det er vanskelig å kunne si noe om et produkt man aldri har hatt brukt til det faktiske formålet. Nå ligger sensoren der og jeg hører forhåpentligvis aldri fra den, før jeg må bytte batteri. Og skulle det oppstå en lekkasje, så forventer jeg at den fungerer som da jeg testet den.
Selve installasjonen og oppsettet var så enkelt som det bør være. Pakk den ut, legg til i Homey, lag en flow, test den og ferdig med det. En billig forsikring som er verdt hver krone hvis den ender opp med å avverge en liten katastrofe.
Nå som du har en lekkasjesensor så må du også finne stoppekranen til huset, slik at du kan stenge vannet ved lekkasje. Det finnes selvfølgelig også fjernstyrte stoppekraner. Det får jeg vurdere på et senere tidspunkt.
Var denne artikkelen nyttig for deg? Som leser må du gjerne bidra til bloggen. Jeg bruker mye tid og penger på å lage gode artikler og bidrag hjelper meg med å skrive flere.
Som leser kan du gi et bidrag til produksjonen, til driften og til å skaffe utstyr til testing for å sikre regelmessige, uavhengige artikler, tester og vurderinger av høy kvalitet.
Husk å abonnere på nyhetsbrevet, det er gratis og du får alle artikler rett i innboksen.
Dette er ikke en kjempestor nyhet. Ikke ennå. Men i et smarthus utgjør den lille nyheten om at HomePod nå støtter norsk en stor forskjell.
Det var nærmest bare en tilfeldighet at nyheten om at HomePod støtter norsk fikk min oppmerksomhet i sommer. Allikevel utgjør det en relativt stor forskjell i vår husholdning.
Selv om barna hadde lært seg grunnleggende funksjoner på engelsk, er den største forskjellen åpenbart at alle hjemme hos oss nå kan snakke norsk til HomePod, enten det er å spille musikk eller å skru på lys.
Både i Homey-appen og Hjem-appen har jeg operert med norsk navngivning av alle rom og enheter. «Kjøkkenet», «Stua», «Loftet». Dette skapte utfordringer da HomePod kun støttet engelsk siden «Hey Siri! Turn on the lights in kjøkkenet!» ikke gir mening på noen som helst måte. Dermed byttet jeg til engelske navn på de mest brukte enhetene og rommene i Hjem-appen, som er den Siri på HomePod kommuniserer med.
Nå, derimot, har jeg byttet tilbake til norsk og det hele gir mer mening når jeg kan si «Hei, Siri! Skru på lyset på kjøkkenet!».
Det er mange funksjoner på HomePod som ikke har vært tilgjengelig i Norge. Nyhetene og været har vært de mest etterlengtede. Nå får man begge deler sammen med resten av tjenestespekteret som HomePod-eiere har hatt for de land HomePod har vært tilgjengelig i. «Hei, Siri! Hvordan blir været i dag?» «Hei, Siri! Hva er hovedsakene i nyhetene?»
HomePod er offisielt ikke lansert i Norge ennå. Og det med god grunn. Jeg synes ikke kvaliteten er produksjonsklar ennå, og skal jeg gjette på hvorfor HomePod fortsatt ikke selges offisielt i Norge ennå, er det fordi presisjonsnivået på stemmegjenkjenningen ikke er så god som den bør være. Der den på engelsk var ganske bra, får man på norsk ofte feil respons på en kommando.
Det er det kun Apple som vet. Det har vært kjent at Apple har testet HomePod i Norge siden begynnelsen av året, men status på arbeidet og tilgjengeligheten her i Norge vet vi nok neppe før den plutselig er til salgs. Kan hende må vi vente til en lansering, men jeg tviler på at vi må vente så lenge. Jeg vil tippe en gang i løpet av det neste halvåret, og da må vi i første omgang forvente å se HomePod mini. Apple har sluttet å produsere den opprinnelige HomePod, som avbildet over, og det er strengt tatt en skam siden det er en svært god høyttaler.
Har du en HomePod, men fortsatt ikke aktivert norsk, åpner du Hjem-appen på din iPhone eller Mac. På iPhone presser og holder HomePod-symbolet nede og velger «Informasjon om tilbehør». Deretter ruller du helt nederst og trykker på tannhjulet nede til høyre. På Mac høyreklikker du på HomePod. Her blar du ned til du finner «Språk» og endrer dette til «Norsk bokmål».
Som leser kan du gi et bidrag til produksjonen, til driften og til å skaffe utstyr til testing for å sikre regelmessige, uavhengige artikler, tester og vurderinger av høy kvalitet.
Husk å abonnere på nyhetsbrevet, det er gratis og du får alle artikler rett i innboksen.
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.
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.
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.
Å 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.
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';
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.
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.
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.
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.
Som leser kan du gi et bidrag til produksjonen, til driften og til å skaffe utstyr til testing for å sikre regelmessige, uavhengige artikler, tester og vurderinger av høy kvalitet.
Husk å abonnere på nyhetsbrevet, det er gratis og du får alle artikler rett i innboksen.
Enda flere artikler? Besøk arkivet.
Dette er Martin Koksrud Bekkelund sitt private nettsted, hvor han skriver om forbrukerteknologi, teknologiledelse og hvordan teknologi, samfunn og politikk påvirker hverandre. Martin er innehaver av konsulentselskapet Nivlheim. Les mer...
© 1995-2024 Martin Koksrud Bekkelund
Opphavsrett • RSS og abonnement • Kontakt • Personvern og informasjonskapsler