Home Assistant: arkitektur, datamodell och drift

Home Assistant är en central styr- och automationsplattform för enheter, radionät, IP-tjänster och användargränssnitt. Instansen samlar tillstånd via integrationer, normaliserar dem till entiteter, distribuerar ändringar via en Event Bus och utför åtgärder utifrån dem. ”Lokalt” betecknar här en arkitekturpreferens, inte en generell egenskap hos varje integration: en Zigbee-ljuskälla kan vara helt lokalt nåbar, medan en tillverkarintegration hämtar sina tillstånd uteslutande från ett moln-API. Den officiella arkitekturöversikten skiljer mellan operativsystem, Supervisor och Core; integrationsarkitekturen beskriver utökningen av Core med Python-komponenter.

För administratörer är Home Assistant därför varken bara en dashboard eller en universell protokollkonverterare. Det är en tillståndsbärande orkestrerare med flera möjliga felpunkter: Python-körmiljö, integrationer, register, databas, autentisering, lokala nätverk, radiokontroller, broker, tillverkarens molntjänster och i förekommande fall Supervisor-appar. Ett grönt gränssnitt bevisar bara att frontendvägen fungerar. Det bevisar inte att händelser kommer i tid, att enheter är nåbara, att automationer körs deterministiskt eller att en backup inklusive externa beroenden går att återställa.

Förklaringen följer en enhetshändelse via integration, Event Bus och State Machine till automation och åtgärd. Därefter sätts persistens, tillägg, säkerhet, övervakning och återställning i sitt sammanhang.

Arkitekturprincip: central händelse- och tillståndsnod

Home Assistant Core är händelsedriven. Fyra dokumenterade byggstenar utgör kärnan (Core architecture):

1. Event Bus distribuerar händelser till registrerade lyssnare.
2. State Machine håller det senast kända tillståndet för varje laddad entitet och publicerar state_changed.
3. Service Registry hanterar anropbara åtgärder och behandlar tjänsteanrop.
4. Timer skapar tidshändelser för tidsberoende bearbetning.

Integrationer översätter enhets- eller tjänstetillstånd till denna modell. En integration kan polla, ta emot pushhändelser, använda lokala bibliotek eller anropa ett fjärr-API. Home Assistant enhetliggör det resulterande tillståndet, inte transporten. Det är den viktigaste driftsgränsen: två entiteter med samma domäntyp, exempelvis light, kan ha helt olika vägar för latens, autentisering och återställning.

Körningslager och installationsmodeller

Home Assistant erbjuder två installationsmodeller som stöds. Home Assistant OS är en hanterad appliance. Home Assistant Container kör Home Assistant Core som en container på en värd som driftansvarig ansvarar för. Den officiella jämförelsen anger HAOS som rekommendation för nästan alla installationer och beskriver Container som en fristående Core-installation utan Supervisor-appar (HAOS eller Container).

Home Assistant OS

HAOS byggs med Buildroot och består av Linux, GNU C Library, systemd och Docker. SquashFS bär de skrivskyddade systemdelarna, ZRAM temporära filsystem och swap, AppArmor begränsar processer och RAUC uppdaterar operativsystemet (Home Assistant Operating System). Ovanpå detta hanterar Supervisor Core, appar, DNS, ljud, mDNS, backuper och uppdateringar (Supervisor).

Appliance-modellen minskar variationerna men ger Supervisor ett omfattande ansvar. Ett fel kan finnas på minst fem nivåer: start-/OS-slot, Docker Engine, Supervisor, Core-container eller en enskild app. Supervisor kan återställa en misslyckad uppdateringsväg för Core; den mekanismen upptäcker inte automatiskt felaktigt enhets- eller databasbeteende.

Home Assistant Container

Container tillhandahåller endast Core. Värdoperativsystem, container engine, nätverk, volymer, databas, broker, radioserver, reverse proxy, backup och uppdateringar tillhör driftansvarig. Supervisor-appar är separat paketerade tjänster. I en containerdesign körs Mosquitto, Matter Server, Zigbee2MQTT, Z-Wave JS UI, PostgreSQL eller en reverse proxy som egna arbetslaster med egna volymer, versioner och hälsokontroller.

Fördelen är en uttrycklig plattformsarkitektur; priset är en större driftsyta. En backup av Core-volymen innehåller exempelvis varken den externa Recorder-databasen eller brokertillstånd, radio-NVM eller reverse-proxy-nycklar om dessa ligger utanför.

Historiska installationsformer

Den tidigare Core-installationen i en Python-miljö och den Supervised-installationen på ett självhanterat Linux avvecklades 2025. Sedan release 2025.12 stöds de inte; 32-bitarsarkitekturerna i386, armhf och armv7 förlorade samtidigt releasevägen. Projektmeddelandet anger HAOS och Container som återstående modeller (Avveckling av Core och Supervised). Ett historiskt installationsnamn får därför inte förväxlas med programvarukomponenten Home Assistant Core, som fortsätter att köras även i HAOS och Container.

Teknikstack

Home Assistant Core är en Python-applikation under Apache-2.0-licens. Det officiella Core-repositoriet visar Python, asyncio och den modulära integrationsstrukturen. I/O-intensiva integrationer ska inte blockera: kvalitetsreglerna föredrar asynkrona beroenden så att nätverks- och enhetsanrop inte stoppar den gemensamma eventloopen (async dependency). Blockerande bibliotekskod flyttas till executor-trådar; CPU-intensivt eller dåligt begränsat arbete förblir dock en kapacitets- och latensrisk.

Den synliga stacken omfattar mer än Python:

Integration Quality Scale bedömer integrationer efter konfigurationsflöde, tester, typning, diagnostik, effektiv dataanvändning och asynkront beteende. En hög nivå förbättrar den förväntade underhållbarheten, men är inget tillgänglighets-SLA för den bakomliggande enheten eller molnleverantören.

Efter installationsmodell och körmiljö följer datamodellen. Först när Config Entry, enhet, entitet och tillstånd hålls isär går det att förklara dubbla entiteter, saknade enheter och felaktiga automationer på ett korrekt sätt.

Objektmodell: Config Entry, enhet, entitet och tillstånd

Den operativa inventarienyckeln är inte den synliga rutan utan kedjan av konfiguration, enhetsidentitet och entitet.

Config Entries

En Config Entry sparar den beständiga konfigurationen för en integrationsinstans. Ett UI-konfigurationsflöde skapar den; alternativ, omkonfigurering, omladdning, avlastning, borttagning och migrering är definierade livscykeloperationer. Integrationer får inte mutera Entry-data direkt utan måste använda Config-Entry-hanteraren (Config entries). Ett autentiseringsfel, en oladdad Entry och en onåbar motpart är därför olika tillstånd.

Enheter och register

Device Registry grupperar tekniska ändpunkter till enheter. Identifiers eller Connections, exempelvis serienummer och MAC-adress, används för matchning; via_device kan avbilda en brygg- eller föräldrarelation (Device registry). En Zigbee-sensor kan därmed visas som en ansluten enhet via en Coordinator utan att Coordinators applikationstillstånd är dess eget.

Entity Registry ger entiteter med unique_id en beständig identitet och förhindrar kolliderande Entity IDs. IP-adress, värdnamn, URL, användarnamn eller e-postadress räknas uttryckligen inte som stabila Unique IDs (Entity registry). Det förklarar varför manuell namnändring av en värd inte får ersätta enhetsidentiteten och varför integrationsmigreringar behöver stabila tillverkaridentifierare.

Entitet och tillstånd

En entitet representerar en funktion eller mätstorhet: sensor, switch, light, climate, binary_sensor eller en annan domän. Dess tillstånd består av ett primärt State, attribut, ändringstider och Context. State Machine håller endast det senast kända tillståndet. unavailable betyder att entiteten för närvarande inte försörjs av ett aktivt Entity-objekt; unknown betyder att inget användbart värde finns. ”Senaste värde” betyder därmed inte automatiskt ”färskt mätvärde”.

Den dokumenterade interaktionen mellan enheter och tjänster skiljer mellan Entity Integration, Entity Component, Entity Platform och tillverkarspecifik integration. För diagnostik frågar man därför alltid:

• Vilken Config Entry äger entiteten?
• Via vilken integration och plattform skapas den?
• Vilket stabilt enhets- och Entity ID kopplar samman historik och konfiguration?
• Pollas eller pushas den?
• Vilken tids- och tillgänglighetsmodell har källvärdet?
• Vilken brygga, vilket bibliotek, moln-API eller radiolänk ligger framför den?

Integrationer och felisolering

En integration definierar en domän och kan tillhandahålla plattformar som sensor, light eller switch. Plattformen abstraherar entitetstypen; enhetsintegrationen kommunicerar med det konkreta protokollet. Inbyggda integrationer levereras med Core och testas genom dess releaseprocess. Custom Integrations körs dock i samma Python-process och kan påverka importer, eventloop, starttid eller minnesförbrukning. Katalogen /config/custom_components är därför en del av inventarie, change management och återställning.

Den officiella integrationsöversikten skiljer bland annat mellan IoT-klasser som Local Push, Local Polling, Cloud Push och Cloud Polling. Denna klassificering är mer användbar för driftsmodeller än en lång tillverkarlista:

Integrationen är ingen processisolator. En ren felavgränsning inaktiverar eller laddar om den berörda Config Entry riktat innan hela Core startas om. En omstart förstör flyktig evidens och kan återställa tidsberoende automationstimers.

Protokoll- och nätverksmodell

För Home Assistant är en beroendegraf mer användbar än en allmän OSI-tabell. Plattformen ligger på applikationsnivån, men dess datavägar förgrenar sig:

• Frontend, REST och WebSocket körs över HTTP på TCP, som standard port 8123.
• DNS löser upp värd- och molntjänster; mDNS och SSDP upptäcker enheter i det lokala nätet.
• MQTT använder en separat broker och en publish/subscribe-modell över TCP eller WebSocket.
• Zigbee, Z-Wave, Thread och Bluetooth kräver radiokontroller eller nätverksproxyer.
• Matter använder IP-kommunikation men kräver för provisionering och Fabric-drift en Matter Server och eventuellt en Thread Border Router.
• Tillverkarintegrationer kan använda HTTPS, proprietära lokala protokoll eller molnströmmar.

De inbyggda discovery-integrationerna dokumenterar mDNS/Zeroconf och SSDP. Båda är beroende av segment och multicast. En reverse proxy för frontend reparerar inte discovery över VLAN-gränser. Multicast-relä, IGMP-snooping, WLAN-klientisolering, IPv6-RA, DNS-suffix och brandväggsregler kontrolleras för varje faktisk enhetsväg.

MQTT som eget tillståndsrum

MQTT är inte den interna Event Bus. Det är en extern brokertjänst som en integration kommunicerar med. Den officiella MQTT-integrationen beskriver Discovery Topics, retained messages, Birth/Last Will, Availability, TLS och MQTT 5. Retained Discovery kan återskapa enheter efter en omstart, men kan också bevara föråldrade Ghost Entities. Tillgänglighet kräver egen semantik; ett befintligt retained State bevisar inte att publiceraren fortfarande lever.

Robust MQTT-drift inventerar broker, Client IDs, autentisering, CA, Topics, QoS, Retain, Expiry, Birth/Will och Discovery-Origin. Brokerbackup och Corebackup är separata skyddsobjekt.

Radio- och bryggvägar

ZHA integrerar en Zigbee-Coordinator, Z-Wave JS använder en separat Z-Wave-JS-server och Matter ansluter en Matter Server. Thread hanterar relationer till Border Routers och nätverk, men är inte identiskt med Matter. Radioenheter, kontrollerns firmware, nätverksdata, nyckelmaterial och enhetskonfiguration utgör var och en en återställningshelhet. Att flytta ett USB-minne eller ersätta en Coordinator är ingen vanlig IP-adressändring.

Integrationer levererar tillstånd och händelser; automationer reagerar på dem. Deras flöde från Trigger, Conditions och Actions måste därför diagnostiseras separat från enhetskonfigurationen.

Automationskörning: Trigger, Condition, Action

En automation är en reaktiv körningsdefinition. Automationsgrunderna skiljer mellan Trigger, valfria Conditions och Actions. Trigger skapar en körning, Conditions kontrollerar tillståndet vid inträdet och Actions använder Scriptens sekvenssemantik (Actions).

Tidpunkten är viktig: State, attribut och mallvärden kan ändras mellan Trigger och en senare Action. En Delay håller ingen transaktion öppen. Flera körningar av samma automation behöver därför ett läge som Single, Restart, Queued eller Parallel samt en medveten konfliktmodell. Fysiska aktorer är sällan transaktionella; en delvis utförd körning kan behöva kompensationsåtgärder.

Trigger-dokumentationen påpekar att for-väntetider inte överlever en omstart eller omladdning av automationen. Den som måste bevara en tidsfrist över omstarter lagrar en tidpunkt, exempelvis i input_datetime, och utlöser mot den. Conditions är bara kontroller i den aktuella körningen; Condition-semantiken gör dem inte till ett lås mot parallella ändringar.

Mallar utvärderas i Home Assistant med Jinja-uttryck. Indata- och typfel, unknown, unavailable, tidszoner och implicit strängkonvertering ska ingå i tester. Templating-dokumentationen beskriver triggerberoende variabler. En administratör testar inte bara happy path utan även omstart, saknad entitet, försenad händelse, dubbel Trigger och aktorfel.

Konfiguration, register och Source of Truth

Home Assistant kombinerar UI-styrda Config Entries, registerdata och YAML. configuration.yaml är roten för manuell konfiguration, men inte den fullständiga Source of Truth. Den officiella konfigurationsöversikten skiljer mellan UI och YAML; Packages kan strukturera sammanhängande YAML-block (Packages).

För Git och review lämpar sig endast den textuella delen utan hemligheter. secrets.yaml separerar värden från YAML men krypterar dem inte; härdningsguiden påpekar uttryckligen detta. UI-tillstånd, register, tokens och Config Entries ligger i konfigurationslagret och ändras via stödda UI-/API-vägar. Direkt redigering av interna storage-filer medan Core körs kringgår schema-, livscykel- och konsistenslogik.

En konfigurationsinventering omfattar:

• YAML, Packages, Blueprints och Custom Components,
• Config Entries med ursprung, ägare och autentisering,
• Device-, Entity- och Area-tilldelningar,
• automationer, Scripts, scener och dashboards,
• användare, tokens, MFA och externa Identity Providers,
• Supervisor-appar eller externa tjänster,
• radiokontroller, broker, databas och proxy,
• Secrets, certifikat och återställningsnycklar.

Recorder, historik och långtidsstatistik

State Machine håller det aktuella tillståndet i minnet. Historik uppstår först genom Recorder. Den skriver tillståndsändringar och utvalda händelser via SQLAlchemy till en databas; History, Activity, diagram och långtidsstatistik läser därifrån. Den officiella Recorder-dokumentationen anger SQLite som standard och rekommendation samt MariaDB, MySQL och PostgreSQL som alternativ som stöds.

Recorderdata är ingen händelsekälla för realtidsstyrning. En databas som har fallerat kan påverka historik och statistik medan aktuella tillstånd och automationer delvis fortsätter att fungera. Omvänt bevisar en komplett historik inte att en Action lyckades på den fysiska enheten.

De viktigaste driftparametrarna är:

• purge_keep_days för råhistorik,
• Include-/Exclude-filter för entiteter och händelser,
• commit_interval som förhållande mellan I/O och förlustfönster,
• databasstorlek, ledigt utrymme och skrivlatens,
• Purge och Repack,
• startordning och nåbarhet för externa databaser,
• långtidsstatistik och metadatakonsistens.

Ett byte av Recorder-databas migrerar inte den befintliga historiken på ett sätt som stöds. Externa databaser behöver egna konsistenta backuper och återställningstester. För SQLite anger dokumentationen ledigt utrymme på minst 2,5 gånger databasens storlek för korruptionshantering. Storage och Recorder är därmed en egen kapacitets- och återställningsväg, inte bara en valfri cache.

API, WebSocket och autentisering

Frontend och API:er delar som standard samma HTTP-listener. REST API använder JSON och Bearer Tokens; bassökvägen är /api/. WebSocket API ligger under /api/websocket, går igenom auth_required, auth och auth_ok och korrelerar kommandon via numeriska ID:n. WebSocket levererar händelseströmmar och register effektivare än upprepad REST-pollning.

Långlivade tokens är användaruppgifter. Authentication API beskriver OAuth/IndieAuth, Refresh Tokens, Long-Lived Access Tokens och kortlivade Signed Paths. En token ärver sin användares kontext; en Long-Lived Token som gäller i tio år hör hemma i en Secrets-hanterare, inte i YAML, shellhistorik, URL eller dashboard-JavaScript.

En API-monitor kontrollerar minst autentisering, /api/config, förväntade entiteter, last_updated, WebSocket-prenumeration och en ofarlig läs-/åtgärdsväg. HTTP 200 på / kontrollerar endast frontendens nåbarhet.

$headers = @{ Authorization = "Bearer $env:HA_TOKEN" }
Invoke-RestMethod -Headers $headers -Uri "https://ha.example.net/api/config"
Invoke-RestMethod -Headers $headers -Uri "https://ha.example.net/api/states/sensor.uptime" |
  ConvertTo-Json -Depth 8

curl --fail --silent --show-error \
  -H "Authorization: Bearer $HA_TOKEN" \
  https://ha.example.net/api/config | jq .
curl --fail --silent --show-error \
  -H "Authorization: Bearer $HA_TOKEN" \
  https://ha.example.net/api/states/sensor.uptime | jq .

Invoke-RestMethod och ConvertTo-Json bearbetar Windows-frågan; curl och jq gör samma sak i Unix. Token visas endast som processmiljövariabel; i produktion kommer den från en kontrollerad Secrets-hanterare.

HTTP, TLS och reverse proxy

HTTP-slutpunkten lyssnar som standard på TCP 8123. Direkt TLS, reverse proxy och Home Assistant Cloud är olika åtkomstmodeller. Vid en traditionell reverse proxy måste use_x_forwarded_for och trusted_proxies ställas in korrekt; annars blir klient-IP fel eller begäran avvisas (HTTP integration). En bred lista över betrodda proxyer möjliggör förfalskning av Forwarded-For-information.

Säkerhetsguiden rekommenderar unika lösenord, MFA, minsta möjliga administratörsbehörigheter och säker fjärråtkomst i stället för direkt internetexponering. TLS skyddar bara transporten. Tokenbehörigheter, proxyheaders, WebSocket-uppgraderingar, Rate Limits, DNS, certifikatförnyelse och säkerheten hos den framförliggande IdP:n förblir egna kontroller.

Resolve-DnsName ha.example.net
Test-NetConnection ha.example.net -Port 443
curl.exe -sS -D - -o NUL https://ha.example.net/api/
Get-NetTCPConnection -State Established | Where-Object RemotePort -eq 443

dig +short ha.example.net A ha.example.net AAAA
curl -sS -D - -o /dev/null https://ha.example.net/api/
ss -ntp state established '( dport = :443 )'
openssl s_client -connect ha.example.net:443 -servername ha.example.net -brief

Resolve-DnsName, Test-NetConnection och Get-NetTCPConnection testar Windows; dig, ss och openssl s_client testar Unix. Det oautentiserade anropet /api/ får returnera 401; avgörande är namnupplösning, TLS-identitet, proxyväg och förväntad autentiseringsgräns.

MQTT-diagnostik

Brokertillståndet kontrolleras utanför Home Assistant. En Subscriber observerar Discovery, Availability och State utan att ändra Topics. Ett Publish-test använder en särskilt reserverad testsökväg; produktiva Command Topics beskrivs inte i förbifarten.

mosquitto_sub.exe -h mqtt.example.net -p 8883 --cafile .\ca.pem `
  -u ha-observer -P $env:MQTT_PASSWORD -v -t "homeassistant/#"
mosquitto_pub.exe -h mqtt.example.net -p 8883 --cafile .\ca.pem `
  -u ha-probe -P $env:MQTT_PASSWORD -t "ops/probe" -m "online" -q 1

mosquitto_sub -h mqtt.example.net -p 8883 --cafile ./ca.pem \
  -u ha-observer -P "$MQTT_PASSWORD" -v -t 'homeassistant/#'
mosquitto_pub -h mqtt.example.net -p 8883 --cafile ./ca.pem \
  -u ha-probe -P "$MQTT_PASSWORD" -t 'ops/probe' -m 'online' -q 1

mosquitto_sub och mosquitto_pub är de officiella brokerklienterna. Lösenord på kommandoraden kan synas i processlistor eller historik; exemplen illustrerar vägen, medan produktionsanropet använder lösenordsfil, operativsystemets Secrets-hanterare eller kortlivade inloggningsuppgifter.

Drift av HAOS och Container

HAOS tillhandahåller kommandot ha via terminal-/SSH-åtkomst. Containerinstallationer drivs med verktygen för den valda runtime-miljön. Ett diagnospaket samlar systeminformation, Core-logg, integrationsdiagnostik, containerstatus, ledigt utrymme och tidpunkt.

docker inspect homeassistant | ConvertFrom-Json
docker logs --since 30m --timestamps homeassistant 2>&1 |
  Select-String -Pattern 'ERROR|WARNING|unavailable|timeout'
docker stats --no-stream homeassistant

docker inspect homeassistant | jq '.[0].State, .[0].Mounts, .[0].NetworkSettings.Networks'
docker logs --since 30m --timestamps homeassistant 2>&1 | grep -E 'ERROR|WARNING|unavailable|timeout'
docker stats --no-stream homeassistant
df -h /path/to/config && du -sh /path/to/config

docker inspect, docker logs och docker stats visar containertillstånd. ConvertFrom-Json och Select-String bearbetar Windows-utdata; grep, df och du kompletterar Unix. En körande container är bara den första kontrollen; därefter följer integrations-, register-, händelse- och enhetsväg.

För felsökning läses signalvägen baklänges: åtgärd, Automation Trace, tillståndsändring, integration, nätverksprotokoll och fysisk enhet.

Observerbarhet och systematisk diagnostik

System Health samlar installationstyp, arkitektur, Python-, Core- och frontendinformation och erbjuder diagnostikfunktioner via Inställningar > System > Reparationer (System Health). Logger-integrationen styr globala och komponentspecifika loggnivåer. Debuggloggning begränsas tidsmässigt och till berörda namnrymder; radio- eller händelsestormar kan annars dominera minne och I/O.

En robust diagnostikkedja är:

1. Symtom och önskat tillstånd: Vilken entitet, Action, automation eller yta är berörd?
2. Tid och omfattning: Sedan när, för vilka enheter, användare, nätverk och integrationsinstanser?
3. Objektidentitet: Säkerställ Config Entry, Device ID, Entity ID, Unique ID och bryggrelation.
4. Körmiljö: Kontrollera Core, eventloop, minne, CPU, filsystem och databas.
5. Integration: Kontrollera Entry-tillstånd, autentisering, Coordinator-/pollningsstatus och diagnostiknedladdning.
6. Transport: Kontrollera discovery, DNS, TCP, TLS, broker, radiokontroller eller tillverkar-API.
7. Automation: Kontrollera Trace, triggerdata, Conditions, Run Mode och åtgärdsresultat.
8. Persistens: Bedöm Recorder-fördröjning och historik separat från live-tillståndet.
9. Kontrollerat test: Använd en skrivskyddad eller ofarlig testentitet.
10. Återställning: Reload före restart, restart före restore; säkra evidens först.

En entitet unavailable kan bero på en avlastad Config Entry, saknad brygga, radioförlust eller timeout i källan. En synlig gammal siffra är farligare eftersom den verkar trovärdig. Övervakning behöver därför färskhetsgränser, inte bara värdegränser.

Uppdateringar, releaser och Custom Integrations

Home Assistant publicerar frekventa Core-releaser och dokumenterar bakåtinkompatibla ändringar. En statisk referensartikel låser medvetet inte fast någon aktuell versionsnivå. Vid underhållstidpunkten kontrollerar utrullningen i stället release notes, integrationsändringar och målberoenden.

En kontrollerad uppdateringsväg omfattar:

1. Bekräfta backup och oberoende nedladdning respektive extern lagringsplats.
2. Kontrollera ledigt utrymme, databastillstånd och System Health.
3. Bedöm release notes samt berörda integrationer och Custom Components.
4. Inventera radio-, broker-, databas- och proxyberoenden.
5. Uppdatera Core respektive HAOS och appar i definierad ordning.
6. Kontrollera startlogg, reparationer och registermigreringar.
7. Testa kritiska sensor-, aktor-, automations-, API- och fjärråtkomstvägar.
8. Fastställ felgränsen och utlös först därefter rollback eller restore.

HAOS använder RAUC med två operativsystemslots; ha os info och rauc status visar slottillståndet (HAOS update system). Den mekanismen skyddar OS-uppdateringsvägen, men inte automatiskt Core-konfiguration, Recorderdata eller radionätverkstillstånd.

När körmiljön och datavägen är kända kan backupomfattningen fastställas. Konfiguration, register, Secrets, databas och add-on-tillstånd måste tillsammans passa den valda installationsmodellen.

Backup och återställning

Home Assistant kan skriva automatiska och manuella, krypterade backuper till lokala eller externa mål. Den officiella guiden för backup och restore beskriver backupplatser, Emergency Kit, nedladdning, restore vid onboarding och migrering till annan maskinvara. Sedan 2026 har backupernas kryptomodell moderniserats; meddelandet om backupkryptering dokumenterar formatändringen och kompatibilitetsgränserna.

En backup är bara komplett i förhållande till installationsmodellen:

Ett återställningstest slutar inte vid inloggning. Acceptanskriterier är: Config Entries laddade, register konsistenta, användaråtkomst möjlig, databas utan fel, broker och bryggor anslutna, radioenheter styrbara, kritiska automationer testade och fjärråtkomst med korrekt certifikat tillgänglig. Batterienheter kan först sova efter en migrering; ett saknat omedelbart värde ska inte förhastat tolkas som dataförlust.

Get-ChildItem .\ha-backups -File -Recurse |
  Get-FileHash -Algorithm SHA256 |
  Export-Csv .\ha-backups-manifest.csv -NoTypeInformation
Get-Content .\ha-backups-manifest.csv -First 5

find ./ha-backups -type f -print0 | sort -z | xargs -0 sha256sum > ha-backups-manifest.sha256
head -n 5 ha-backups-manifest.sha256
tar -tf ./ha-backups/example-backup.tar | head

Get-FileHash, Export-Csv och Get-Content skapar respektive läser Windows-manifestet. find, sort, xargs, sha256sum och tar hanterar Unix. En kontrollsumma bevisar att arkivet är oförändrat; endast återställningstestet bevisar dekrypterbarhet och funktionell återställning.

RPO, RTO och hög tillgänglighet

Home Assistant är i normal drift en tillståndsbärande enskild instans. Två aktiva Core-instanser mot samma enheter, register eller broker-Commands ger ingen automatiskt samordnad hög tillgänglighet. Dubbla automationer kan slå om aktorer flera gånger; radiokontroller och lokala enheter tillåter ofta bara ett aktivt ägarskap.

En realistisk resiliensmodell kombinerar:

• tillförlitlig enskild nod eller VM med övervakade resurser,
• UPS och lämplig lagring i stället för känsliga flashmedier,
• separata, automatiska och krypterade backuper,
• dokumenterad reservmaskinvara eller VM-målplattform,
• exporterbara radiokontrollertillstånd och nycklar,
• reproducerbara externa tjänster,
• kontrollerad restore med entydigt övertagande av enheter och nätverk.

RPO beror på den senast säkrade konfigurationen, registret, app- och externa tjänstekopian. Recorderhistorik kan ha ett annat RPO än automationskonfigurationen. RTO omfattar inte bara Core-start utan även DNS, proxy, databas, broker, radiokontroller, enhetsåteranslutning, sovande sensorer och acceptanstester.

Säkerhet och förtroendegränser

Home Assistant kan styra dörrar, värme, larmsystem och energiflöden. Påverkansområdet är därmed fysiskt. Säkerhetsdesign skiljer mellan:

• användare och administratörer,
• sessioner för webbläsare, Companion App och API,
• Long-Lived Tokens och webhooks,
• Core och Custom Integrations,
• Supervisor-appar eller externa containrar,
• IoT-, management- och användarsegment,
• lokala enheter och tillverkarmoln,
• radionät och deras nycklar,
• backupmål och Emergency Kit.

MFA skyddar interaktiva konton, men inte en stulen Long-Lived Token. Nätverkssegmentering begränsar lateral förflyttning, men får inte okontrollerat blockera nödvändig discovery och returkanaler. Custom Integrations har processnärhet till Core och behandlas som koddistributioner. Secrets förekommer varken i Git, diagnosfiler eller supportinlägg. Allmänna kontroller finns under härdning, grundläggande transportinformation under TLS och API-avtalsmodeller under API:er.

Teknisk historia

Home Assistant började 2013 som ett Python-projekt av Paulus Schoutsen. Återblicken över tioårsjubileet beskriver utvecklingen från en liten lokal automationsapplikation till ett stort open-source-projekt (10 år med Home Assistant). Python-Core och integrationsmodellen förblev den funktionella kärnan, medan frontend, mobila klienter, Supervisor, HAOS, enhetshårdvara och molnalternativ utvecklades runt dem.

Med Hass.io, senare Home Assistant respektive Home Assistant OS och Supervisor, uppstod en appliance-stack med operativsystem, containerhantering, Core och tilläggstjänster. Uppdelningen har språkligt förtydligats flera gånger: ”Add-ons” kallas i dag Apps, medan ”integrationer” fortfarande är Python-utökningar av Core. Dessa termer beskriver olika körnings- och säkerhetsgränser.

2024 övergick Home Assistant till den ideella Open Home Foundation; Nabu Casa förblev kommersiell partner. Projektmeddelandet om Open Home-ekosystemet beskriver ägarskap och styrning. 2025 minskade projektet de installationsvarianter som stöds till HAOS och Container. Den historiska trenden går därmed inte mot ett distribuerat kluster utan mot en stabilare central Core med tydligt stödda körmiljöpaket och fristående protokollservrar.

Checklista för administratörer

En grön dashboard räcker inte som driftsbevis. Checklistan sammanför installation, enhetsvägar, automationer, datahållning och återställning till en verifierbar helhetsbild.

• Installation: Dokumentera HAOS eller Container, arkitektur, värd, lagring, nätverk och ägarskap.
• Stack: Håll isär Core, Supervisor, appar/externa containrar, databas, broker, proxy och radioserver.
• Inventering: Registrera Config Entry, Device ID, Entity ID, Unique ID, Area och via_device.
• Dataursprung: Markera Local/Cloud samt Push/Polling för varje kritisk integration.
• Tillstånd: Skilj mellan unknown, unavailable, föråldrat värde och bekräftad enhetsframgång.
• Automation: Testa Trigger, Context, Condition, Run Mode, omstartsbeteeende och kompensation.
• API:er: Kontrollera användarkontext, tokenlagring, WebSocket, reverse proxy och TLS.
• Recorder: Övervaka databas, filter, commitintervall, purge, I/O, tillväxt och backup.
• IoT-nät: Kontrollera uttryckligen mDNS, SSDP, MQTT, VLAN, IPv6 och radio-/bryggvägar.
• Uppdateringar: Sammanför release notes, Custom Integrations, backup, utrullning och godkännande.
• Återställning: Testa Core, externa tjänster, radiotillstånd, nycklar och Emergency Kit tillsammans.
• Bevis: Verifiera inte bara UI och container utan minst en sensor-, aktor-, automations- och API-väg från början till slut.

Källor

• Home Assistant Developer Docs – arkitekturöversikt
• Home Assistant Developer Docs – integrationsarkitektur
• Home Assistant Developer Docs – Core architecture
• Home Assistant – HAOS eller Container
• Home Assistant Developer Docs – Operating System
• Home Assistant Developer Docs – Supervisor
• Home Assistant – avveckling av Core, Supervised och 32-bit
• GitHub – Home Assistant Core
• Home Assistant Developer Docs – Async dependency
• Home Assistant Developer Docs – Integration Quality Scale
• Home Assistant Developer Docs – Config entries
• Home Assistant Developer Docs – Device registry
• Home Assistant Developer Docs – Entity registry
• Home Assistant Developer Docs – enheter och tjänster
• Home Assistant – integrationer
• Home Assistant – Zeroconf
• Home Assistant – SSDP
• Home Assistant – MQTT
• Home Assistant – ZHA
• Home Assistant – Z-Wave JS
• Home Assistant – Matter
• Home Assistant – Thread
• Home Assistant – automationsgrunder
• Home Assistant – Automation actions
• Home Assistant – Automation triggers
• Home Assistant – Conditions
• Home Assistant – Automation templating
• Home Assistant – konfiguration
• Home Assistant – Packages
• Home Assistant – säkra Home Assistant
• Home Assistant – Recorder
• Home Assistant Developer Docs – REST API
• Home Assistant Developer Docs – WebSocket API
• Home Assistant Developer Docs – Authentication API
• Microsoft – Invoke-RestMethod
• Microsoft – ConvertTo-Json
• curl – handbok
• jq – handbok
• Home Assistant – HTTP integration
• Microsoft – Resolve-DnsName
• Microsoft – Test-NetConnection
• Microsoft – Get-NetTCPConnection
• BIND 9 – dig
• Linux man-pages – ss(8)
• OpenSSL – s_client
• Eclipse Mosquitto – mosquitto_sub
• Eclipse Mosquitto – mosquitto_pub
• Docker – inspect
• Docker – logs
• Docker – stats
• Microsoft – ConvertFrom-Json
• Microsoft – Select-String
• GNU Grep – handbok
• GNU Coreutils – df
• GNU Coreutils – du
• Home Assistant – System Health
• Home Assistant – Logger
• Home Assistant Developer Docs – HAOS update system
• Home Assistant – backup och restore
• Home Assistant – moderniserad backupkryptering
• Microsoft – Get-FileHash
• Microsoft – Export-Csv
• Microsoft – Get-Content
• Linux man-pages – find(1)
• GNU Coreutils – sort
• Linux man-pages – xargs(1)
• GNU Coreutils – sha2 utilities
• GNU Tar – handbok
• Home Assistant – 10 år med Home Assistant
• Home Assistant – Open Home Foundation och styrning