Home Assistant OS (HAOS) VM¶

Overview¶

Property	Value
Hostname	haos
IP Address	192.168.0.202 (static in HAOS since 2026-07-06, was DHCP - see proxmox doc 25)
VMID	101
Type	KVM Virtual Machine (not LXC)
OS	Alpine Linux 3.23.3 (add-on sandbox)
Kernel	6.12.67-haos
Purpose	Home automation platform
Web UI	http://192.168.0.202:8123
HA Version	2026.8.1

Note: HAOS is a full KVM VM, not an LXC container. It is listed here for consistency. The SSH shell runs inside the Advanced SSH & Web Terminal add-on sandbox (Alpine Linux), not on the host HAOS system directly.

Architecture¶

HAOS uses a layered architecture:

KVM VM (VMID 101)
└── Home Assistant OS (haos kernel 6.12.67)
    └── Supervisor (Docker-based)
        ├── Home Assistant Core (2026.8.1)
        ├── Mosquitto broker add-on
        ├── Zigbee2MQTT add-on
        ├── go2rtc add-on
        └── Advanced SSH & Web Terminal add-on  ← SSH lands here

Resources¶

Resource	Value
RAM	6144 MB (allocated in Proxmox)
Swap	none
Disk	32 GB (local-lvm, LVM thin)

Installed Add-ons¶

Add-on	Notes
Advanced SSH & Web Terminal	SSH access, user=hassio, port=22
Mosquitto broker	MQTT broker, ports 1883/1884/8883/8884
Zigbee2MQTT	Zigbee coordinator via Sonoff USB dongle, v2.8.0
go2rtc	RTSP/WebRTC camera stream proxy

Integrations¶

Domain	Description
mqtt	Mosquitto broker (Zigbee2MQTT devices)
cast	Google Cast - nappali TV + hálószobai TV
androidtv_remote	Android TV Remote - nappali TV vezérlés
go2rtc	go2rtc camera proxy
upnp	Router UPnP
met	Home weather (Met.no)
google_translate	Text-to-speech
radio_browser	Radio Browser

Eltávolított integrációk (2026-05-31): - dlna_dmr - letiltva (nappali TV DLNA renderer, duplikátum volt a Cast/Android TV Remote mellett) - dlna_dms - törölve (NEX-PC DLNA médiaserver, Jellyfin miatt felesleges)

Egyedi (HACS) integrációk:

Integráció	Verzió	Mire jó
`hacs`	2.0.5	maga a HACS
`view_assist`	-	Voice/dashboard assist
`dawarich`	1.0.0-beta6	a Companion App helyadatait továbbítja a Dawarich szervernek (LXC 100, `192.168.0.110:3005`), 2026-08-09 óta. 4 config entry: Norbi/Ancsi/Enci telefon + Enci tablet

A dawarich bejegyzés helyettesíti a telefonokon futó külön tracker appot - a részletek, a kompromisszumok és a telepítés buktatói: 22 - Dawarich GPS Tracking. Egy config entry = egy személy (saját API kulcs + saját device_tracker).

Külső MQTT kliensek (nem HA add-on, a Mosquitto brokerre kívülről csatlakoznak): - scrutiny (LXC 100, 192.168.0.110:8082) - lemez S.M.A.R.T. állapot, 2026-08-02 óta. MQTT discovery-vel 5 eszközre publikál (temperature/status/power_on_hours/power_cycle_count sensor + problem binary_sensor), auth: meglévő HA user (neximus), broker tcp://192.168.0.202:1883. Jelszó: /srv/docker-compose/.env → SCRUTINY_MQTT_PASSWORD (LXC 100).

Open Ports¶

Port	Protocol	Service
22	TCP	SSH (Advanced SSH & Web Terminal add-on)
8123	TCP	Home Assistant web UI + REST API
1883	TCP	MQTT (unencrypted)
1884	TCP	MQTT (WebSocket)
8883	TCP	MQTT TLS
8884	TCP	MQTT TLS WebSocket
4357	TCP	Zigbee2MQTT frontend
8485	TCP	go2rtc web UI
18554/18555	TCP	go2rtc RTSP

Key Config Files¶

File	Description
`/homeassistant/configuration.yaml`	Main HA configuration
`/homeassistant/automations.yaml`	Automation rules
`/homeassistant/secrets.yaml`	Sensitive values
`/homeassistant/home-assistant_v2.db`	SQLite history database
`/homeassistant/.storage/core.config`	Instance config
`/homeassistant/.storage/core.config_entries`	Installed integrations
`/addon_configs/45df7312_zigbee2mqtt/`	Zigbee2MQTT config

SSH Access¶

SSH is provided by the Advanced SSH & Web Terminal add-on. The shell runs inside an Alpine Linux sandbox - not on the HAOS host directly.

Setting	Value
Username	`hassio`
Port	`22`
Auth	Key-based only
Protection mode	enabled

# Direct
ssh hassio@192.168.0.202

What SSH can access:

Accessible	Not accessible
`/homeassistant/` (config, DB, automations)	Docker daemon
`/addon_configs/`, `/share/`, `/backup/`	Supervisor API
Network info (`netstat`, `ping`)	Host OS filesystem
System stats (`df`, `free`, `uptime`)	`ha` CLI commands

REST API¶

The HA REST API is the preferred way to query and manage HAOS programmatically.

Setting	Value
Base URL	`http://192.168.0.202:8123/api/`
Auth	Long-lived access token (Bearer)

# Quick health check
curl -s -H "Authorization: Bearer <token>" \
  http://192.168.0.202:8123/api/

# All entity states
curl -s -H "Authorization: Bearer <token>" \
  http://192.168.0.202:8123/api/states

# Call a service (e.g. turn on a light)
curl -s -X POST \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"entity_id": "light.example"}' \
  http://192.168.0.202:8123/api/services/light/turn_on

HTTP config moved out of YAML (2026-08-08)¶

Home Assistant deprecated the http: block in configuration.yaml; it stops working in 2027.2.0. The block here held only the reverse-proxy settings, which is exactly the risky case - the UI page under Settings > System > Network does not expose use_x_forwarded_for or trusted_proxies, so "just delete it and check the UI" is not a safe verification:

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 192.168.0.0/24
    - 172.16.0.0/12
    - 100.64.0.0/10

The real check is the storage file the import writes. Read it before deleting anything:

ssh hassio@192.168.0.202 'sudo cat /config/.storage/http'

Both settings were present there with "yaml_migration_done": true, so removing the YAML block was safe. Verified after the restart that the file still held all three proxy ranges, that haos.lan through Caddy still answered 200, and that the log contained no "X-Forwarded-For header from an untrusted proxy" warnings.

Backups left in place: /config/configuration.yaml.bak-2026-08-08 and /config/.storage/http.bak-2026-08-08.

Note: ha core check does not work from the SSH add-on (no Supervisor token). Use the REST API instead - POST /api/services/homeassistant/check_config, then look for a new persistent_notification.* entity, which is where a failure would show up.

Scheduled Maintenance¶

Task	Schedule	Command (Proxmox host)	Reason
Full VM reboot	Daily 04:10	`qm reboot 101`	Workaround for memory leak in 2026.4.x

The daily reboot is configured in the Proxmox host crontab (crontab -e as root on 192.168.0.109). Remove once the memory leak is fixed upstream.

Known Issues¶

Memory leak in HA Core 2026.4.x (RESOLVED in 2026.5.x)¶

HA Core 2026.4.0-2026.4.2 had a memory leak that caused RAM to fill up over hours and eventually crash the VM. The leak filled 6 GB in ~13-15 hours. HAOS was updated to 2026.5.4 on 2026-05-31, which resolves the leak.

Workaround that is still active (can be removed once 2026.5.x is confirmed stable): daily full VM reboot via Proxmox cron at 04:10 (qm reboot 101 in root crontab on 192.168.0.109).

References: - GitHub issue #167401 - memory leak + crash in 2026.4.0/4.1

Periodic public 503 errors via Pangolin (diagnosed 2026-05-31)¶

Symptom: Uptime Kuma reports ha.homelabor.net down for ~1 minute every ~10 minutes. Error: HTTP 503.

Root cause: Newt (running on Proxmox host 192.168.0.109) health-checks HAOS at http://192.168.0.202:8123/ on a ~10-minute interval with a 5-second timeout. HAOS occasionally takes longer than 5 seconds to respond (periodic internal task - exact cause unknown, possibly Recorder WAL flush or Supervisor health poll). With the default hcUnhealthyThreshold=1, a single failed check immediately marks the resource unhealthy and Traefik returns 503.

Fix applied 2026-05-31 (via direct DB update on VPS + Pangolin restart): - hcTimeout: 5s -> 10s (more time for HAOS to respond) - hcUnhealthyThreshold: 1 -> 2 (two consecutive failures needed; HAOS always recovers within 30 seconds so the second check succeeds)

To verify or update these settings: Pangolin UI -> Resources -> Home Assistant -> Edit -> Health Check tab. DB location: /opt/pangolin/config/db/db.sqlite on the VPS (table targetHealthCheck, row where targetHealthCheckId=6).

Diagnosis commands:

# Check Newt health check failures on Proxmox host
journalctl -u newt --since "1 hour ago" | grep -E "(WARN|deadline|health check)"

# Check Pangolin for site offline events
docker logs pangolin 2>&1 | grep -E "(offline|unhealthy|healthcheck)"

Zigbee Devices (Zigbee2MQTT)¶

Eszköz	Terület	Típus	Gyártó	Megjegyzés
Balkon_Lampa	Balkon	RGB+CCT lámpa	Philips	Hue Essential A60
Bejarati_Lampa	Kert	RGB+CCT lámpa	Tuya	Bejárati kültéri lámpa
Folyoso_Fenti_Lampa	Folyoso	RGB+CCT lámpa	Philips	Hue Essential A60
Folyoso_Lenti_Lampa	Folyoso	RGB+CCT lámpa	Philips	Hue Essential A60
Stekker_Furdo	Furdo	Smart plug (power monitoring)	Tuya	Törölközőszárítóhoz
Stekker_Kert	Kert	Smart plug (power monitoring)	Tuya	Zigbee mesh router (jelerősítő)
Stekker_Konyha	Kitchen	Smart plug (power monitoring)	SONOFF
Szenzor_Bejarati	Kert	PIR mozgásérzékelő	SONOFF
Szenzor_Folyoso_Fent	Folyoso	PIR mozgásérzékelő	Tuya
Szenzor_Folyoso_Kozep	Folyoso	PIR mozgásérzékelő	Tuya
Szenzor_Folyoso_Lent	Folyoso	PIR mozgásérzékelő	Tuya
Ajto_Szenzor_Bejarati	Folyoso	Ajtószenzor	Aqara
Ajto_Szenzor_Fent	Folyoso	Ajtószenzor	Aqara
Leak sensor	Technikai	Vízszivárgás szenzor	Moes

Media Players¶

A nappali TV három integráción keresztül volt regisztrálva - 2026-05-31-én rendszerezve:

Entitás	Platform	Név	Megjegyzés
`media_player.teve_a_nappaliban`	cast	Nappali TV - Cast	Mutatja mi megy (Jellyfin, stb.), valós állapot
`media_player.tv_a_nappaliban`	androidtv_remote	Nappali TV - Android Remote	Teljes vezérlés, `assumed_state`
`remote.tv_a_nappaliban`	androidtv_remote	Nappali TV - Távirányító	Nyers gombparancsok küldése
`media_player.teve_a_haloszobaban`	cast	Hálószobai TV - Cast	Unavailable amikor a TV ki van kapcsolva (normális)
~~media_player.teve_a_nappaliban_192_168_0_236~~	~~dlna_dmr~~	~~Tévé a nappaliban(192.168.0.236)~~	Letiltva 2026-05-31

Automations¶

Automation	Állapot	Leírás
`automation.vizerzekelo_riasztas`	ON	Vízszivárgás riasztás - ismétlődő push 10 percenként
`automation.vizerzekelo_helyreallt`	ON	Vízszivárgás helyreállt - "all clear" értesítés (2 perces debounce)
`automation.bejarati_lampa_be`	ON	Bejárati lámpa vezérlés
`automation.folyoso_lampa_fenti_ajto_5mp`	ON	Folyosó lámpa - fenti ajtószenzor (5 mp)
`automation.folyoso_lampa_bejarati_ajto_5mp`	ON	Folyosó lámpa - bejárati ajtószenzor (10 mp)
`automation.folyoso_lampa_vezerles`	ON	Folyosó lámpa vezérlés
`automation.torolkozoszarito_idozites_20_40_21_00_es_21_40_22_00`	ON	Törölközőszárító - 20:40-21:00 és 21:40-22:00
`automation.tobb_szaritas`	OFF	Régi törölközőszárító timing (19:25-19:45, 20:10-20:25) - megtartva
`automation.nightly_ha_restart`	OFF	HA belső restart - nem hatékony a memory leak ellen, Proxmox cron váltja
`automation.zona_notifikacio_gps`	OFF	GPS zóna értesítés - GPS bounce miatt letiltva
`automation.legujjabb`	OFF	Teszt automation
`automation.new_automation_2`	OFF	Teszt automation

Vízérzékelő automations (2026-05-29)¶

Trigger: binary_sensor.leak_sensor_water_leak (on=vizes, off=száraz)
Push célpontok: notify.mobile_app_norbi_telo, notify.mobile_app_ancsi_telo
Tag: leak_sensor_alert - minden ismétlés felülírja az előző értesítést
All-clear debounce: 2 perc stabilan száraz kell az "OK" értesítéshez (GPS bounce-szerű false trigger ellen)

Lessons Learned¶

HAOS is a KVM VM, not an LXC - pct exec does not work; qm terminal 101 gives the HAOS console, which is very limited.
SSH user is hassio, not root - the add-on config UI shows the username field set to hassio, which must match the SSH login.
SSH add-on must be configured before starting - starting it without authorized_keys or password causes a fatal error and the add-on immediately stops.
The ha CLI requires Supervisor API token - commands like ha core info fail from the SSH add-on shell; use the REST API instead.
Protection mode blocks Docker access - to run docker ps or interact with containers, Protection Mode must be disabled in the add-on settings. Leave it enabled unless absolutely needed.
Alpine Linux inside, HAOS outside - the SSH session runs in an Alpine 3.23 container sandbox, not on the HAOS host. Some host-level commands are unavailable or proxied.
Newt health check vs. actual downtime - context deadline exceeded in journalctl -u newt means HAOS was slow (>timeout), not unreachable. connection refused means HAOS is actually down. Brief periodic 503s on the public URL almost always mean Newt's health check timed out, not a real outage.
Pangolin hcUnhealthyThreshold should be 2 for HAOS - with threshold=1, a single slow health check response (e.g. during a recorder flush) immediately causes 503. Set to 2 so two consecutive failures are required. HAOS recovers within 30 seconds so the second check always succeeds. Current config: hcTimeout=10, hcUnhealthyThreshold=2 (set 2026-05-31).