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.4.2

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.2.3)
        ├── 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)

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

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).