hass.windy.lan: resolve health snapshot issues (W1N-70..76) and document findings

- Add tianqi weather recorder patch notes (W1N-75: _unrecorded_attributes)
- Document Bluetooth hci0 RTL8821CS instability (W1N-74) and eMMC lifetime
  10% (W1N-76) as known issues
- Rewrite runbook known-issues section: all snapshot items resolved; link
  hosts doc for the two remaining known issues

hosts/hass.windy.lan.md

@@ -107,6 +107,54 @@ getent hosts hass.windy.lan
 # expect 192.168.55.11
 ```
 
+## Local patches (custom components)
+
+**`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](../runbooks/home-assistant-maintenance.md) — `ha` CLI maintenance runbook + [script](../runbooks/scripts/ha-maintenance.sh)

runbooks/home-assistant-maintenance.md

@@ -190,16 +190,20 @@ installed CLI** (2026-08-13): backups are inspected with `ha backups info
 <slug>` (a slug is required) and `host` has no `update` subcommand. Trust the
 server CLI (`ha <cmd> --help`) over the docs.
 
-## Known issues on hass.windy.lan (observed 2026-08-13)
+## Known issues on hass.windy.lan (2026-08-13)
 
-From the health snapshot — follow-ups are optional, no action taken:
+All items from the original 2026-08-13 health snapshot were resolved same day
+(W1N-70/71/72/73/74/75/76): OTBR and the duplicate SSH add-on uninstalled, all
+resolution-center issues cleared (`ha resolution info` → empty), full backup
+`pre-maintenance-20260813` (slug `411a4ba5`) taken. Remaining known issues
+(documented in [hosts/hass.windy.lan.md](../hosts/hass.windy.lan.md)):
 
-- **2 add-ons in `state: error`**: `core_openthread_border_router`,
+- **Bluetooth hci0 instability (RTL8821CS)**: `bluetooth_auto_recovery`
-  `a0d7b954_ssh` (duplicate Advanced SSH & Web Terminal install).
+  power-reset times out every ~2 min; kernel `hci0 hardware error`. No BLE
-- **`ha resolution info` issues**: `systemd_unit_failed`
+  entities exist, so no user impact. HAOS image ships `x88-bt-hci-recovery`
-  (`systemd-vconsole-setup.service`), `no_current_backup`, 2×
+  workaround units.
-  `corrupt_repository` (store `d5369777`, `a0d7b954`).
+- `host info` reports `disk_life_time: 10` (boot eMMC ~10% life left) —
-- `host info` reports `disk_life_time: 10` (disk lifetime warning threshold).
+  monitor on each snapshot; plan disk replacement / data-disk migration.
 
 ## Pass criteria