vps/hosts/hass.windy.lan.md

hass.windy.lan — Home Assistant (HAOS)

Role and access

Item	Value
Role	Home Assistant automation hub
IPv4	192.168.55.11 (LAN55)
DNS	hass.windy.lan (AdGuard rewrite on dns.windy.lan; legacy hass.local alias)
SSH	ssh hassio@hass.windy.lan
Host	PVE VM 180 (haos) — not a separate physical host (verified 2026-08-09)
Platform	Home Assistant OS; kernel 6.1.115-haos (aarch64)
Web UI	http://hass.windy.lan:8123 (LAN); WAN port-forward hass on gw → :8123

Use hassio for routine SSH inspection. Key-only login was verified on 2026-08-13 from the WSL client (BatchMode=yes).

The ha supervisor CLI (/usr/bin/ha) authenticates with SUPERVISOR_TOKEN. Interactive login works because ~hassio/.zprofile runs exec sudo -i, which loads a root environment carrying the supervisor API token. Non-interactive ssh hassio 'command' does not source .zprofile and fails with unauthorized: missing or invalid API token. Run ha non-interactively via:

ssh -o BatchMode=yes hassio@hass.windy.lan 'sudo -n -i ha core info'

Verified 2026-08-13 that sudo -n -i ha core info works from the WSL client. Never copy the supervisor token into this repository.

The current SSH ED25519 host-key fingerprint is SHA256:DMcMOgDzFsFTon1fndXowEP7jlyOK3/AX3PVK8BATvk (verified 2026-08-13). Verify a changed key out of band before accepting it.

Do not store Home Assistant long-lived tokens, integration credentials, or recovery codes in this repository.

Network

Interface	Address / role
end1	192.168.55.11/24; primary LAN55 address
wg0	10.13.13.2/32; WireGuard (add-on / integration tunnel)
hassio / docker0	internal HAOS Docker bridges (172.30.32.0/23, 172.30.232.0/23)

LAN55 clients reach the HTTP API on dns.windy.lan:80 for the AdGuard Home integration; see hosts/dns.windy.lan.md.

API access

Home Assistant exposes a REST API at http://hass.windy.lan:8123/api/ (same as http://192.168.55.11:8123/api/). Authenticate with a long-lived access token created under Profile → Security → Long-lived access tokens.

HA_URL="http://hass.windy.lan:8123"
HA_TOKEN="<long-lived-access-token>"

# Health check — expect {"message":"API running."} and HTTP:200
curl -sS -w "\nHTTP:%{http_code}\n" \
  -H "Authorization: Bearer $HA_TOKEN" "$HA_URL/api/"

# Read one entity state
curl -sS -H "Authorization: Bearer $HA_TOKEN" \
  "$HA_URL/api/states/sensor.csg_30d_max"

# List entities / recent errors
curl -sS -H "Authorization: Bearer $HA_TOKEN" "$HA_URL/api/states"
curl -sS -H "Authorization: Bearer $HA_TOKEN" "$HA_URL/api/error_log"

• 401 → token invalid or expired; create a new one.
• 404 on /api/states/<id> → entity does not exist.
• The token is a secret: never commit it here; keep it in the shell environment or a secrets file outside the repo.

HTTP proxy gotcha (verified 2026-08-13)

The WSL client had http_proxy set to Mihomo (192.168.66.99:7890). LAN hostnames sent through that proxy returned empty 502, even though DNS resolved and the HA UI was up. Direct 192.168.55.11:8123 worked, and hass.windy.lan:8123 worked only after clearing the HTTP proxy.

Before debugging a "502" on a LAN URL, check env | grep -i proxy and bypass the proxy:

unset http_proxy HTTP_PROXY all_proxy ALL_PROXY
curl -sS -w "\nHTTP:%{http_code}\n" \
  -H "Authorization: Bearer $HA_TOKEN" "$HA_URL/api/"

For a persistent fix, add .windy.lan (leading dot) and the LAN ranges to NO_PROXY, or add *.windy.lan to the proxy's own bypass/skip-proxy list. See ~/.config/zsh/env/local/environment.env for the client-side setting.

Safe verification

ssh -o BatchMode=yes hassio@hass.windy.lan 'hostname; ip -4 addr show end1'

From a LAN client, confirm DNS and UI reachability:

getent hosts hass.windy.lan
# expect 192.168.55.11

Related docs

• runbooks/home-assistant-maintenance.md — ha CLI maintenance runbook + script
• docs/lan-overview.md — LAN map and gw port-forward
• hosts/dns.windy.lan.md — hass.windy.lan / hass.local rewrites