Arkiv

Automasjonsflyt: utløser, så betingelse, så handling

Automasjon

En automasjon i Home Assistant er en regel som utfører én eller flere handlinger automatisk når en bestemt utløser inntreffer. All automatisk oppførsel i et smarthus – et lys som tennes ved bevegelse, et varsel når en dør åpnes, en varmestyring som justeres etter værmeldingen – er i bunn og grunn en automasjon. Automasjonsmotoren er mekanismen som gjør alt dette mulig.

Automasjonsflyt: utløser, så betingelse, så handling

Hver automasjon er bygd av tre deler. Utløseren definerer hva som starter den: en tilstandsendring i en entitet, et klokkeslett, solnedgang, en MQTT-melding, en terskelverdi som krysses, eller en webhook. Betingelsen er et valgfritt filter som må være sant i øyeblikket utløseren slår til – tiden er innenfor et vindu, noen er hjemme, en enhet er i en bestemt tilstand. Handlingen er det som skjer når utløseren slår til og alle betingelser er oppfylt: kall en tjeneste, slå en enhet av eller på, send et varsel, kjør et skript. Én automasjon kan kjede flere handlinger i rekkefølge, parallelt, eller med forsinkelser mellom dem.

Automasjoner lages i automasjonseditoren, som gir et visuelt grensesnitt for å bygge utløser-, betingelse- og handlingsblokker uten YAML. Editoren dekker det vanligste med et pek-og-klikk-skjema, mens den underliggende YAML-en – via editorens kodevisning – gir full tilgang til alt, inkludert maler, løkker og parallell kjøring. Automasjoner kan også importeres og deles som Blueprints, som abstraherer bort de enhetsspesifikke detaljene til en gjenbrukbar mal.

Proff-tips: Bruk sporing (trace) for å feilsøke
Når en automasjon ikke kjører som forventet, viser sporingsverktøyet i Home Assistant nøyaktig hva som skjedde: hvilken utløser som slo til, om betingelsene besto eller feilet, og hvilke handlinger som ble kjørt – med de faktiske verdiene til hver entitet i det øyeblikket. Det er den raskeste måten å finne ut hvorfor en automasjon oppførte seg uventet.

Home Assistant skiller mellom automasjoner og skript. En automasjon utløses alltid av en hendelse – den kjører som svar på noe som skjer. Et skript er en gjenbrukbar sekvens av handlinger som må kalles eksplisitt, enten fra en automasjon, fra dashbordet, eller fra et annet skript. For logikk som skal brukes i flere automasjoner, lønner det seg å trekke den ut i et skript. Node-RED gir en tredje tilnærming for automasjoner som krever forgrening, løkker eller datatransformasjon som den innebygde editoren håndterer dårlig.

🏠 Visste du at: Automasjonsmotoren i Home Assistant er skrevet om to ganger siden 2013 – først i 2016 for å innføre utløser/betingelse/handling-modellen som fortsatt gjelder, og igjen i 2021 for å legge til den visuelle editoren og sporingsverktøyet. Omskrivingen i 2021 reduserte de vanligste support-spørsmålene på forumet betraktelig.

Relaterte artikler

No post found!

Kilder



En Blueprint-mal fylles inn med dine egne enheter og lager en ferdig automasjon

Blueprint

En Blueprint er en gjenbrukbar automasjonsmal i Home Assistant. Der en vanlig automasjon er knyttet til bestemte entiteter i ditt oppsett, abstraherer en Blueprint bort de spesifikke enhetene – du bestemmer hvilken entitet som spiller hvilken rolle når du importerer malen, og automasjonen genereres med dine valg fylt inn. Resultatet er at avansert automasjonslogikk kan skrives én gang, deles offentlig, og tas i bruk av hvem som helst på under ett minutt, uten å redigere YAML.

En Blueprint-mal fylles inn med dine egne enheter og lager en ferdig automasjon

Blueprints lagres som YAML-filer og importeres enten fra en URL – typisk et GitHub-repo eller Home Assistant-forumet – eller lastes opp direkte. Etter import dukker malen opp i Blueprint-seksjonen i automasjonseditoren, der du konfigurerer den ved å fylle ut et skjema: velg utløser-entiteten, sett terskelverdiene, velg målenheten. Home Assistant lager en komplett automasjon av det du fyller inn. Flere automasjoner kan lages fra samme Blueprint – én Blueprint for bevegelsesstyrt lys kan drive hvert eneste rom i huset, hvert med sine egne entiteter og tidsverdier.

Blueprint Exchange på Home Assistant-forumet er det viktigste offentlige biblioteket, med tusenvis av bidrag for bevegelseslys, tilstedeværelse, termostatstyring og varsling. Blueprints distribueres også via HACS, GitHub og direkte URL-import. Dokumentasjonen definerer et formelt skjema for inndatatypene: entitetsvelgere, enhetsvelgere, tallfelt, nedtrekkslister og av/på-brytere – som gir forfatteren finkornet kontroll over skjemaet sluttbrukeren ser.

Proff-tips: Sjekk Blueprintens forutsetninger før import
En Blueprint er skrevet med bestemte antakelser om hvordan entiteter oppfører seg – en bevegelseslys-Blueprint laget for binærsensorer fungerer kanskje ikke med en tilstedeværelses-integrasjon som bruker en annen tilstandsmodell. Åpne YAML-en før import og sjekk hvilke entitetsdomener og enhetsklasser den forventer. De fleste velbeskrevne Blueprints lister kravene tydelig i beskrivelsen.

For den som vil dele egne automasjoner, er en Blueprint en strukturert måte å gjøre logikken flyttbar på. Forskjellen fra et vanlig automasjons-eksport er bruken av inndata-variabler: der en spesifikk entitet eller verdi ellers ville stått, bruker en Blueprint en navngitt inndata-referanse. Home Assistant viser referansene som et skjema ved import, slik at sluttbrukeren aldri ser YAML-en med mindre hen vil. Det gjør Blueprints til den mest tilgjengelige måten å dele automasjonslogikk på, uansett teknisk nivå.

🏠 Visste du at: Blueprint-systemet ble innført i Home Assistant 2021.3 og var en av de mest etterspurte funksjonene i prosjektets historie. I løpet av den første måneden samlet Blueprint Exchange over 500 delte Blueprints – et tall som viste hvor stort gapet hadde vært mellom dem som kunne skrive automasjoner og dem som ville bruke dem uten å kode.

Relaterte artikler

No post found!

Kilder



DLMS/COSEM-telegram med OBIS-koder (1.8.0, 16.7.0, 32.7.0) som dekodes til Home Assistant-sensorer

DLMS/COSEM

DLMS/COSEM er den internasjonale standarden som bestemmer hvordan en smart strømmåler organiserer og kommuniserer dataene sine. Er HAN-porten den fysiske kontakten på måleren, er DLMS/COSEM språket som snakkes gjennom den. Uten å forstå standarden er de rå bytene som strømmer ut av måleren meningsløse. Med den knytter hver avlesning – effekt i watt, spenning, akkumulerte kilowattimer – seg til en presis, globalt definert struktur.

DLMS/COSEM-telegram med OBIS-koder (1.8.0, 16.7.0, 32.7.0) som dekodes til Home Assistant-sensorer

Forkortelsen kombinerer to utfyllende spesifikasjoner. DLMS står for Device Language Message Specification – den definerer kommunikasjonsprotokollen: hvordan en klient ber om data fra en måler, og hvordan måleren svarer eller dytter data ut av seg selv. COSEM står for Companion Specification for Energy Metering – den definerer datamodellen: hvilke objekter som finnes inne i måleren, hvilke attributter hvert objekt har, og hvordan verdiene kodes. Sammen utgjør de IEC 62056, vedlikeholdt av DLMS User Association. Norske AMS-målere implementerer en bestemt profil av standarden, med push-modus der måleren sender telegrammer automatisk uten å bli pollet.

I praksis er et DLMS/COSEM-telegram fra en norsk AMS-måler strukturert som en HDLC-ramme (High-Level Data Link Control) som inneholder et serialisert COSEM-dataobjekt. Hvert objekt i telegrammet identifiseres av sin OBIS-kode – en sekstall-delt numerisk identifikator som peker til en bestemt fysisk måling. Dataene kodes med ASN.1 BER (Abstract Syntax Notation, Basic Encoding Rules), som betyr at den rå bytestrømmen er binærpakket og ikke leselig før den dekodes. Biblioteker som gurux-dlms (for Python, Java og C#) håndterer dekodingen automatisk, og AmsToMqttBridge-fastvaren gjør det samme på ESP32/ESP8266 koblet rett til HAN-porten.

Proff-tips: Du trenger ikke dekode det manuelt
Bruker du en AMS-til-MQTT-bro eller Tibber Pulse med lokal MQTT, håndteres DLMS/COSEM-dekodingen transparent av fastvaren. Det som kommer inn i Home Assistant er ren JSON – watt, spenning, kWh – uten binærtolkning fra din side. Du trenger bare å forstå DLMS/COSEM hvis du bygger din egen leser fra bunnen eller feilsøker en parsefeil.

Den norske implementasjonen følger spesifikasjonen «Norsk HAN-grensesnitt» publisert av REN (Rasjonell Elektrisk Nettvirksomhet), som definerer nøyaktig hvilke COSEM-objekter telegrammet skal inneholde og med hvilke intervaller. Liste 1 (hvert 2. sekund) bærer momentan aktiv effekt. Liste 2 (hvert 10. sekund) legger til spenning og strøm per fase. Liste 3 (hver time) legger til akkumulerte måleravlesninger og målerens identifikasjonsdata. Denne tredelte strukturen er en norsk-spesifikk profil lagt oppå den generelle DLMS/COSEM-standarden.

🏠 Visste du at: DLMS/COSEM ble opprinnelig utviklet på 1990-tallet for automatisk måleravlesning over telefonmodem – lenge før WiFi eller smarthus fantes. Standardens uttalte mål var merkeuavhengighet mellom målere, slik at et nettselskap kunne bytte målere fra ulike produsenter uten å endre faktureringsprogramvaren. Den samme interoperabiliteten er grunnen til at Home Assistant-oppsettet ditt fungerer likt enten måleren er fra Aidon, Kaifa eller Kamstrup.

Relaterte artikler

No post found!

Kilder



ESPHome-flyt: YAML-konfig → kompilering → fastvare → ESP32/ESP8266 → Home Assistant over Wi-Fi

ESPHome

ESPHome er et fastvare-rammeverk som gjør rimelige ESP32- og ESP8266-mikrokontrollere om til fullt integrerte Home Assistant-enheter – uten å skrive en eneste linje kode. I stedet for å programmere i C++ eller MicroPython, beskriver du hva enheten skal gjøre i en YAML-konfigfil: hvilke pinner som kobles til hvilke sensorer, hva enheten skal rapportere, og hvordan den skal oppføre seg. ESPHome kompilerer konfigurasjonen til fastvare, flasher den til mikrokontrolleren, og fra da av dukker enheten automatisk opp i Home Assistant som en fullt fungerende entitet.

ESPHome-flyt: YAML-konfig → kompilering → fastvare → ESP32/ESP8266 → Home Assistant over Wi-Fi

ESP32 og ESP8266 er Wi-Fi-mikrokontrollerbrikker fra Espressif Systems, tilgjengelige på utviklingskort for så lite som 30–60 kr. De har nok kraft og minne til å kjøre sensorer, styre reléer, drive skjermer og kommunisere over Wi-Fi samtidig. ESPHome skjuler kompleksiteten i å jobbe rett mot brikken: du erklærer en DHT22-temperatursensor på GPIO-pinne 4, og ESPHome håndterer driveren, pollingintervallet, Wi-Fi-tilkoblingen, API-håndtrykket mot Home Assistant og OTA-oppdateringen automatisk. Maskinvareprosjekter som før krevde ukers fastvareutvikling, kan nå gjøres på en ettermiddag.

ESPHome snakker med Home Assistant via et eget API – en lett, kryptert protokoll bygd for HA-integrasjonen. Når en enhet med ESPHome-fastvare dukker opp på samme nett som Home Assistant, oppdages den automatisk og legges til med ett klikk. OTA-oppdateringer (over-the-air) betyr at du aldri trenger å koble enheten fysisk til en PC igjen etter første flashing: endringer kompileres og dyttes trådløst fra ESPHome-dashbordet, som kjører som et HA-tillegg. ESPHome støtter også MQTT som alternativ, men det egne API-et er enklest for de fleste.

Proff-tips: Start med et ferdig kort, ikke løse komponenter
Er du ny til ESPHome, start med et Wemos D1 Mini (ESP8266) eller et ESP32 DevKit-kort fremfor en egen PCB eller bar modul. Disse har USB-flashing innebygd, stabile 3,3 V-regulatorer og er godt dokumentert i ESPHome-komponentbiblioteket. Når du er trygg på YAML-arbeidsflyten og forstår hvordan GPIO-pinner kobles til sensorene, er overgangen til mindre eller egne kort enkel.

Maskinvaren ESPHome støtter har vokst kraftig. Utover temperatur, fukt og bevegelse har ESPHome nå egne komponenter for CO₂-sensorer, luftkvalitetsmålere, ultralyd-avstandssensorer, vekter, LED-stripestyring, e-blekkskjermer og Bluetooth-proxy – der en ESP32 med ESPHome fungerer som en Bluetooth-mottaker som utvider Home Assistants Bluetooth-rekkevidde gjennom hele bygget. Det siste har gjort ESPHome populær for å integrere Bluetooth-enheter – plantesensorer, badevekter, termometre – som ellers ville vært utenfor rekkevidde av HA-maskinen.

🏠 Visste du at: ESPHome ble laget av Otto Winter som et personlig prosjekt kalt esphomelib i 2018. Som HACS vokste det gjennom fellesskapet til å bli ett av de mest brukte verktøyene i Home Assistant-økosystemet – og som HACS ble skaperen senere ansatt i Nabu Casa. ESPHome er nå et førsteparts Home Assistant-prosjekt.

Relaterte artikler

No post found!

Kilder



Grafana spør InfluxDB og viser dataene som grafer, målere og statuspaneler i et dashbord

Grafana

Grafana er en åpen plattform for datavisualisering og analyse som gjør tidsseriedata om til interaktive dashbord. I Home Assistant-økosystemet er den visualiseringslaget for data lagret i InfluxDB – der InfluxDB håndterer langtidslagring og effektiv spørring av sensorhistorikk, håndterer Grafana presentasjonen: tilpassbare grafer, måler-paneler, statusvisninger, varmekart og varselterskler som gir smarthus-dataene dine et detaljnivå og en klarhet Home Assistants innebygde historikk-paneler ikke kan måle seg med.

Grafana spør InfluxDB og viser dataene som grafer, målere og statuspaneler i et dashbord

Grafana kobles til InfluxDB som en datakilde – et engangsoppsett der du oppgir InfluxDB-serverens adresse, databasenavn og påloggingsinfo. Når koblingen er på plass, lar Grafanas spørre-editor deg bygge paneler ved å skrive InfluxQL- eller Flux-spørringer mot Home Assistant-dataene, velge hvilke målinger og tagger du vil tegne, og hvordan de skal aggregeres. Et typisk energidashbord kan ha en tidsseriegraf over timesforbruk, et statuspanel med dagens totale kWh, en måler som viser solproduksjon nå, og et stolpediagram som sammenligner daglig forbruk de siste to ukene – alt fra samme InfluxDB-instans, alt oppdatert i sanntid.

Grafana kjører som et Home Assistant-tillegg, installert og styrt gjennom det vanlige tilleggsgrensesnittet sammen med InfluxDB og Mosquitto. Tillegget eksponerer Grafanas web-grensesnitt på en lokal port, tilgjengelig fra hvilken som helst nettleser på nettet ditt. Grafana støtter også å bygge inn enkeltpaneler som iframe, som gjør det mulig å vise Grafana-visualiseringer rett inne i et Home Assistant Lovelace-dashbord med webside-kortet – og kombinere Lovelace sin enhetsstyring med Grafanas analytiske dybde i ett grensesnitt.

Proff-tips: Bruk Grafana til analyse, Lovelace til styring
Grafana og Lovelace har ulike formål og fungerer best holdt fra hverandre. Lovelace er optimalisert for sanntidsstyring og status – slå lys av og på, sjekke hvilke dører som er åpne, se temperaturen nå. Grafana er optimalisert for historisk analyse – forstå mønstre, oppdage avvik, sammenligne perioder. Et veggnettbrett med Lovelace til daglig bruk og en nettleserfane med Grafana til ukentlig energigjennomgang er den naturlige arbeidsdelingen mellom de to.

Utover InfluxDB støtter Grafana dusinvis av andre datakilder – PostgreSQL, MySQL, Prometheus, Elasticsearch og mange flere – samt Home Assistant-datakilde-pluginen fra Grafanas plugin-bibliotek, som spør Home Assistants WebSocket-API direkte uten InfluxDB som mellomledd. Denne direkte integrasjonen er enklere å sette opp for grunnleggende visualisering, men mangler langtidslagringen og aggregeringsytelsen InfluxDB-stabelen gir for seriøs historisk analyse.

🏠 Visste du at: Grafana ble laget av Torkel Ödegaard i 2014 som en avgreining (fork) av Kibana – visualiseringslaget for Elasticsearch – fordi han ville ha bedre tidsserie-grafer enn Kibana tilbød for infrastrukturovervåking. Det har siden vokst til ett av verdens mest utbredte observabilitetsverktøy, brukt av NASA, CERN og tusenvis av bedrifter til infrastrukturovervåking – og av titusenvis av Home Assistant-brukere til å følge strømregningen.

Relaterte artikler

No post found!

Kilder



HACS som et lag over Home Assistant-kjernen, med integrasjoner, temaer og frontend-kort fra fellesskapets repositorier

HACS

HACS – Home Assistant Community Store – er en tredjeparts utvidelsesbutikk som kjører inne i Home Assistant og gir deg tilgang til et bibliotek av fellesskapsutviklede integrasjoner, temaer og frontend-kort. Der den offisielle Home Assistant-utgaven bare inneholder integrasjoner som har vært gjennom en formell gjennomgang, dekker HACS «den lange halen»: nyere integrasjoner under utvikling, svært spesifikk enhetsstøtte, eksperimentelle funksjoner og visuelle tilpasninger.

HACS som et lag over Home Assistant-kjernen, med integrasjoner, temaer og frontend-kort fra fellesskapets repositorier

HACS organiserer innholdet i fire typer. Integrasjoner legger til støtte for enheter og tjenester som ennå ikke er i den offisielle lista. Frontend-kort utvider Lovelace-dashbordet med egne visningskomponenter – målere, animerte værkort og planløsninger. Temaer endrer utseendet på grensesnittet, mens automasjoner og skript, lagt til i nyere versjoner, lar deg dele gjenbrukbare blueprints direkte gjennom butikken.

Installasjon krever en engangsjobb: laste ned HACS-integrasjonen, starte Home Assistant på nytt, og autentisere med en GitHub-konto. GitHub-pålogging kreves fordi HACS henter alt innhold rett fra GitHub-repositorier – hvert tillegg er et offentlig repo som HACS overvåker for oppdateringer. Oppdateringer er ikke automatiske; HACS varsler deg når nye versjoner finnes og lar deg se gjennom endringene før du installerer.

Proff-tips: HACS-innhold er vedlikeholdt av fellesskapet – sjekk før du installerer
I motsetning til offisielle integrasjoner er HACS-repositorier ikke gjennomgått av Home Assistant-kjerneteamet. Sjekk repoets GitHub-side før du installerer: antall stjerner, dato for siste commit, og om feilmeldinger besvares aktivt. Et godt vedlikeholdt repo med ferske commits er et trygt tegn; et forlatt repo med år gamle commits er en risiko.

HACS er særlig nyttig i markeder der spesifikke lokale integrasjoner ennå ikke er en del av den offisielle utgaven. Mange nyere norske strøm- og måler-integrasjoner dukker opp i HACS lenge før – om noen gang – de når den offisielle lista. For et oppsett med en blanding av vanlige og mindre vanlige enheter er HACS i praksis en nødvendig komponent.

🏠 Visste du at: HACS ble laget av Lukas Löfqvist – kjent som «Ludeeus» – som et personlig prosjekt i 2019. Det vokste organisk gjennom fellesskapet til å bli et av de mest installerte tilleggene i hele økosystemet, og Ludeeus ble senere ansatt i Nabu Casa, selskapet bak Home Assistant.

Relaterte artikler

No post found!

Kilder



AMS-måleren sender telegram via HAN-porten til en leser (Tibber Pulse/HAN-adapter), videre til Home Assistant over MQTT

HAN-port

HAN-porten – kort for Home Area Network-port – er en liten RJ45-kontakt innebygd i de fleste moderne strømmålere i Norge og Norden. Den finnes av én grunn: å gi deg direkte, lokal tilgang til målerdataene dine. I stedet for å være avhengig av nettselskapets servere for å vite hva huset bruker, strømmer HAN-porten informasjonen kontinuerlig – akkurat nå, i sanntid – til hva enn du kobler til den.

AMS-måleren sender telegram via HAN-porten til en leser (Tibber Pulse/HAN-adapter), videre til Home Assistant over MQTT

Porten bruker en seriell kommunikasjonsprotokoll over den fysiske RJ45-kontakten. I Norge følger dataformatet DLMS/COSEM-standarden (IEC 62056), og meldingene sendes som OBIS-kodede telegrammer – strukturerte datapakker med avlesninger som effekt i watt, akkumulerte kWh, spenning per fase og reaktiv effekt. Telegrammene dyttes ut av måleren automatisk, typisk hvert 2. sekund for effekt og hvert 10. sekund for energidata. Du poller ikke måleren – den kringkaster kontinuerlig enten noen lytter eller ei.

For å lese HAN-porten trenger du en liten adapter som gjør signalet om til noe en mikrokontroller eller enkortsdatamaskin kan tolke. Den vanligste løsningen er en M-BUS-til-UART-adapter, som oversetter målerens M-Bus-signal til et standard serielt grensesnitt. Derfra kan enheter som Tibber Pulse, Adax HAN-leser eller et eget ESP32-/Raspberry Pi-oppsett fange telegrammene og dytte dem via MQTT inn i Home Assistant. Resultatet: under 2 sekunders forsinkelse på live effektavlesninger, lokalt behandlet, uten noen skyavhengighet.

Proff-tips: Få porten aktivert hos nettselskapet
HAN-porten er fysisk til stede på alle AMS-målere i Norge, men er deaktivert som standard. Du må kontakte ditt lokale nettselskap og be om aktivering – det er gratis og lovfestet etter norsk forskrift. Uten dette steget sendes ingen data, uansett hvilken maskinvare du kobler til.

HAN-porten ble obligatorisk på alle nye norske strømmålere gjennom AMS-utrullingen (Avanserte Måle- og Styringssystem), fullført i 2019. Det rettslige grunnlaget – forskrift om måling og fakturering – pålegger nettselskapene å gi kunden tilgang til målerdata på forespørsel. Det gjør Norge til ett av få land der lokal, høyoppløst energimåling er en rettighet, ikke en betalt tilleggsfunksjon. Til sammenligning låser de fleste smarte målere i Storbritannia, USA og Mellom-Europa disse dataene bak proprietære apper og sky-API-er.

🏠 Visste du at: «Home Area Network» i HAN-port viser til det tiltenkte lokale nettet mellom måleren og display-enheter i hjemmet – et konsept fra de tidlige smartgrid-standardene rundt 2010. I praksis hopper de fleste norske huseiere over det offisielle displayet og sender dataene rett inn i Home Assistant i stedet.

Relaterte artikler

No post found!

Kilder



Arkitektur: Home Assistant kjører lokalt og kobler enheter via Zigbee, Z-Wave, Matter/Thread og Wi-Fi, styrt via dashbord, automasjoner og mobil-app

Home Assistant

Home Assistant er en åpen kildekode-plattform for hjemmeautomasjon som kjører lokalt på din egen maskinvare – en Raspberry Pi, en liten PC, eller en Home Assistant Green eller Yellow. I motsetning til skybaserte plattformer som Google Home eller Amazon Alexa holder Home Assistant alle data og automasjoner på ditt eget lokale nett. Lysene, sensorene og automasjonene fungerer enten produsentens servere er oppe eller ikke, og ingen bruksdata forlater hjemmet med mindre du selv velger å slå på fjerntilgang.

Arkitektur: Home Assistant kjører lokalt og kobler enheter via Zigbee, Z-Wave, Matter/Thread og Wi-Fi, styrt via dashbord, automasjoner og mobil-app

Plattformen er bygd rundt integrasjoner – moduler som kobler Home Assistant til en bestemt enhet, tjeneste eller protokoll. Hver integrasjon eksponerer enhetene sine som entiteter (sensorer, brytere, lys, termostater) som kan kombineres i automasjoner og dashbord uavhengig av merke eller protokoll. En Philips Hue-pære, et Shelly-relé, en Tibber-strømavtale og en robotgressklipper kan alle ligge på samme dashbord og trigge hverandre gjennom den samme automasjonsmotoren.

Home Assistant kjører på et eget Linux-basert operativsystem, Home Assistant OS, som håndterer oppdateringer, sikkerhetskopier og tillegg automatisk. Tillegg (add-ons) utvider plattformen med ekstra programvare – Mosquitto MQTT-megler, Node-RED for visuell automasjon, ESPHome for å flashe ESP32-brikker – alt styrt fra selve Home Assistant-grensesnittet. Resultatet er en plattform som skalerer fra et enkelt smartlys-oppsett til full husstyring uten å bytte plattform underveis.

Proff-tips: Start med Home Assistant OS, ikke Docker
Home Assistant kan installeres på flere måter – OS, Container, Supervised eller Core. For de fleste er Home Assistant OS på dedikert maskinvare det riktige valget: du får hele funksjonssettet med tillegg og automatiske sikkerhetskopier, med minst vedlikehold. Docker-baserte installasjoner bytter bort tilleggsstøtte mot fleksibilitet de færreste hjemmebrukere trenger.

Et særlig norsk poeng: Home Assistant kan lese AMS-måleren via HAN-porten og hente spotpris fra Tibber, slik at du kan styre forbruket etter strømprisen time for time. Plattformen får en ny versjon den første onsdagen hver måned, og HACS – Home Assistant Community Store – utvider den ytterligere med tusenvis av fellesskapsutviklede integrasjoner, temaer og kort som ikke er en del av den offisielle utgaven.

🏠 Visste du at: Home Assistant ble startet i 2013 av Paulus Schoutsen som et personlig prosjekt for å automatisere sitt eget hjem. I dag vedlikeholdes det av Nabu Casa – selskapet han var med å grunnlegge for å finansiere utviklingen – og har over 100 000 aktive installasjoner verden over.

Relaterte artikler

No post found!

Kilder



InfluxDB lagrer innkommende tidsstemplede sensorpunkter og indekserer dem på tid for raske spørringer

InfluxDB

InfluxDB er en tidsseriedatabase – en database optimalisert for å lagre datapunkter indeksert på tidsstempel. Der en relasjonsdatabase lagrer rader med strukturerte poster, lagrer InfluxDB målinger over tid: temperatur 14:32:01, effektforbruk 14:32:02, fukt 14:32:03. Det gjør den eksepsjonelt effektiv til å lagre, spørre og aggregere den typen kontinuerlige sensordata en Home Assistant-installasjon genererer – hundrevis av tilstandsendringer i timen, hver time, i det uendelige.

InfluxDB lagrer innkommende tidsstemplede sensorpunkter og indekserer dem på tid for raske spørringer

Home Assistant har sin egen innebygde recorder, som lagrer entitetshistorikk i en lokal SQLite-database. Recorderen fungerer godt for korttidshistorikk – de siste ti dagene i Historikk-panelet – men er ikke laget for langtidslagring eller komplekse analytiske spørringer. SQLite vokser raskt med mange entiteter, ytelsen synker over tid, og skjemaet er ikke optimalisert for aggregeringene – timesgjennomsnitt, dagssummer, rullende min/maks – som gjør sensordata nyttige for analyse. InfluxDB løser alle tre: den lagrer data effektivt i årevis uten ytelsestap, spørrespråket er bygd for tidsserie-aggregeringer, og den beholder data så lenge du vil i valgfri oppløsning.

Home Assistant kobler til InfluxDB via den offisielle InfluxDB-integrasjonen, som kjører som et HA-tillegg for lokale instanser eller kobler til en ekstern server. Når den er satt opp, skriver integrasjonen hver tilstandsendring til InfluxDB i sanntid – parallelt med den innebygde recorderen, ikke i stedet for. Du velger hvilke entiteter som skal med, intervallet for kontinuerlige sensorer, og om du bruker InfluxDB v1 eller v2. Dataene lander tagget med entitets-ID, domene og visningsnavn, klare til å spørres fra Grafana eller et hvilket som helst annet verktøy som støtter InfluxDB som datakilde.

Proff-tips: Ekskluder høyfrekvente entiteter for å holde databasen liten
Ikke alle entiteter er verdt å lagre i InfluxDB. Binærsensorer som skifter tilstand hundrevis av ganger om dagen – bevegelsessensorer, dørsensorer i travle områder – gir store datamengder med liten analyseverdi. Sett opp inkluder/ekskluder-listen i InfluxDB-integrasjonen til å skrive bare entitetene du faktisk spør på: energimålere, temperatursensorer, klima-entiteter og værdata. Da holder du databasen kompakt og spørringene raske uten å miste meningsfull historikk.

InfluxDB finnes i to versjoner med ulik arkitektur. InfluxDB v1 bruker et SQL-lignende spørrespråk kalt InfluxQL og lagrer data i databaser og målinger – kjente begreper for alle med databaseerfaring. InfluxDB v2 introduserer et nytt spørrespråk kalt Flux – kraftigere, men brattere læringskurve – og en ny datamodell basert på buckets og organisasjoner. Begge versjoner støttes av HA-integrasjonen og av Grafana. For nye installasjoner er v2 dagens standard; kjører du allerede v1, finnes det ingen tvingende grunn til å migrere.

🏠 Visste du at: InfluxDB ble laget av Paul Dix i 2013 etter at han ble frustrert over å bruke relasjonsdatabaser til å lagre tidsserie-overvåkingsdata i stor skala. Kjerneinnsikten var at tidsseriedata har fundamentalt andre tilgangsmønstre enn relasjonsdata – det skrives nesten alltid i kronologisk rekkefølge og spørres etter tidsrom – og at en database bygd rundt de mønstrene kan være størrelsesordener mer effektiv enn en generell relasjonsdatabase for samme arbeidslast.

Relaterte artikler

No post found!

Kilder



Et Lovelace-dashbord med visninger og et rutenett av kort som entiteter, måler, historikk og kart

Lovelace

Lovelace er navnet på dashbord-systemet i Home Assistant – det visuelle grensesnittet der du bygger egne visninger av smarthuset. Oppkalt etter Ada Lovelace, 1800-tallsmatematikeren som regnes som verdens første programmerer, erstattet det det gamle autogenererte grensesnittet i 2019 og har vært standard siden. Der det gamle laget en side automatisk, gir Lovelace deg full kontroll: du bestemmer hvilke entiteter som vises, hvordan de grupperes, hvordan de ser ut, og hvordan dashbordet er bygd opp.

Et Lovelace-dashbord med visninger og et rutenett av kort som entiteter, måler, historikk og kart

Lovelace-dashbord bygges av kort – selvstendige komponenter som hver viser eller styrer et sett entiteter. Det innebygde kortbiblioteket dekker det vanligste: et entitetskort lister flere sensorer eller brytere i en kompakt tabell, et målerkort visualiserer en tallverdi mot et område, og et historikkort tegner sensordata over tid. Kortene legges i et rutenett på tvers av én eller flere visninger (faner), slik at du kan dele smarthuset inn i logiske seksjoner: en varme-visning, en sikkerhets-visning, en visning per rom.

Lovelace kan redigeres på to måter. Den visuelle editoren – blyantikonet på et dashbord – lar deg legge til, flytte og konfigurere kort med pek-og-klikk uten YAML. YAML-editoren gir direkte tilgang til konfigurasjonen, som er nødvendig for avanserte kortvalg, egne maler med Jinja2, og fellesskapskort installert via HACS. De fleste starter i den visuelle editoren og går over til YAML etter hvert som dashbordene blir mer avanserte.

Proff-tips: Lag egne dashbord til ulike formål
Home Assistant støtter flere uavhengige dashbord, ikke bare flere visninger i ett. Et veggmontert nettbrett med en ren rom-for-rom-oversikt er et annet verktøy enn et detaljert energi-dashbord du sjekker på PC. Holder du dem adskilt, kan hvert optimaliseres for sin skjerm – store trykkflater på nettbrettet, tette data på PC-en.

HACS utvider Lovelace betraktelig. De mest brukte fellesskapskortene er Mushroom – et sett rene, minimalistiske kort mange foretrekker fremfor de innebygde – og ApexCharts Card, som gir et fullverdig grafbibliotek for energi-, temperatur- og sensorhistorikk. Mini Graph Card og Button Card er andre populære valg. De installeres via HACS og følger samme kort-API som de innebygde, så de glir rett inn i et eksisterende oppsett.

🏠 Visste du at: Navnet Lovelace ble valgt av Home Assistant-fellesskapet ved en avstemning i 2018. Ada Lovelace skrev det som regnes som den første algoritmen ment for en maskin, i 1843 – nesten hundre år før den første elektroniske datamaskinen ble bygd.

Relaterte artikler

No post found!

Kilder