windyboy
fcb76d3d5a
The host note now states the aiohttp IPv4 client is live, Core loaded it, and home PPPoE IPv4 to 95598.csg.cn is currently blackholed while IPv6 works on gw. HA still has IPv6 disabled (W1N-85).
8.2 KiB
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.404on/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
Local patches (custom components)
china_southern_power_grid_stat IPv4 aiohttp (verified 2026-08-14, W1N-102):
/config/custom_components/china_southern_power_grid_stat was replaced from
GitHub windyboy/china_southern_power_grid_stat master (eb8b174, W1N-101).
The live client uses HA async_get_clientsession(hass, family=socket.AF_INET)
and bounded aiohttp timeouts; it no longer uses blocking requests. Backup of
the 2026-02-02 HACS/requests tree:
china_southern_power_grid_stat.bak-20260814-w1n102. HACS still tracks
CubicPill/china_southern_power_grid_stat — a HACS update would overwrite this
fork. This directory is a file copy, not a git clone; do not git pull in
place.
After deploy, Core loaded the new code (15:21:45). verify_login failed in ~5s
with CSGTransportError (no executor hang). Home PPPoE IPv4 to CSG is currently
blackholed: curl -4 https://95598.csg.cn from gw times out to
218.19.148.218; curl -6 from gw returns 200 via 240e:f9:8060::1:16.
HA end1/wlan0 have ipv6.method: disabled (W1N-85) and only fe80
addresses, so HA cannot use that IPv6 path. Remote IPv4 to the same A record
still works. Re-apply after any HACS/CubicPill update.
tianqi weather recorder patch (verified 2026-08-13, W1N-75):
/config/custom_components/tianqi/weather.py has a local patch adding
_unrecorded_attributes = frozenset({"hourly_temperature", "hourly_skycon", "hourly_cloudrate", "hourly_precipitation"}) to the WeatherEntity class.
Without it, weather.guangzhou's state attributes (~19 KB, dominated by the 4
hourly_* arrays of up to 48 entries) exceed the recorder 16384-byte limit, so
the recorder drops all attributes for the entity and logs
Recorder.db_schema: State attributes for weather.guangzhou exceed maximum size of 16384 bytes. The patch excludes only the 4 arrays from recording
(live state unchanged; other attributes still stored; ~6.3 KB payload). Backup
at weather.py.bak-w1n75. Re-apply after any tianqi component update.
The _unrecorded_attributes mechanism exists in Core 2026.8.1
(Entity.__init_subclass__ → state_info["unrecorded_attributes"], consumed
by recorder shared_attrs_bytes_from_event).
Known issues
Bluetooth hci0 instability — RTL8821CS (verified 2026-08-13, W1N-74):
The local Bluetooth controller hci0 is an RTL8821CS combo chip on the
x88 Pro board. Kernel logs show recurring hci0: hardware error 0x00,
Opcode 0x200c tx timeout (HCI_LE_Set_Scan_Parameters), Unable to disable scanning: -110, Peer device has reset — the chip hardware-stalls during
active scanning. HA's bluetooth_auto_recovery power-cycle then times out
after 5 s and retries every ~2 min:
bluetooth_auto_recovery.recover: Could not reset the power state of the Bluetooth adapter hci0 ... due to timeout after 5 seconds. The HAOS image
already ships custom systemd units to cope (x88-bt-hci-recovery.service and
a "Patch HA Bluetooth scanner mode for x88 RTL8821CS" service, visible in host
journal). No user impact: there are no BLE entities in HA
(xiaomi_ble / bthome / led_ble / bluetooth / esphome domains are all empty;
platforms merely load from stray advertisements). Real IoT devices are Zigbee
(via Zigbee2MQTT) or WiFi/MQTT/cloud. An ESPHome Bluetooth-proxy ESP32
(/config/esphome/bluetooth.yaml, bluetooth_proxy: active, WiFi ubnt-haas)
is configured but currently offline (ESPHome add-on stopped, port 6053
unreachable) and produced no entities. Follow-up (optional): disable the
local adapter and rely on the ESPHome proxy, or stop the bluetooth
integration entirely.
eMMC disk lifetime 10% (verified 2026-08-13, W1N-76): ha host info
reports disk_life_time: 10 — the boot eMMC (/dev/mmcblk2, CJTD4R
0xacacc064, 64 GB) has ~10% life left. disk_free: 40.2/56.4 GB. Full
backup pre-maintenance-20260813 (slug 411a4ba5, 144.26 MB) taken
2026-08-13 covers current config; monitor disk_life_time on each health
snapshot and plan a disk replacement / data-disk migration before the eMMC
fails.
Related docs
- runbooks/home-assistant-maintenance.md —
haCLI maintenance runbook + script - docs/lan-overview.md — LAN map and gw port-forward
- hosts/dns.windy.lan.md —
hass.windy.lan/hass.localrewrites