docs(hass): 把主机文档收成现行状态

Quick 布局、季节 gauge、网卡 end1 和 Core 2026.9.3 与旧操作说明不一致。抓包命令改为 end1。

docs/matter-pairing-troubleshoot.md

@@ -60,7 +60,9 @@
 > [runbooks/matter-packet-capture.md](../runbooks/matter-packet-capture.md)。
 > 下面是最常用的两条。
 
-**视角必须在 LAN55**。**HA matter-server 作配对方时推荐直接在 hass `end0` 抓**——配对方
+hass 上网卡名是 `end1`（2026-09-23）。2026-08 笔记里的 `end0` 已经没有了。
+
+**视角必须在 LAN55**。**HA matter-server 作配对方时推荐直接在 hass `end1` 抓**——配对方
 必然参与配对流程的每一条通讯（mDNS 本段组播 + 自己的 TCP 5540 全程），覆盖最全；AP `br0`
 能看到全部 mDNS 组播 + 无线客户端单播，但**看不到有线↔有线单播**（如 Thread 设备经有线 M3
 配对时 HA↔M3 的 5540 在 AP 侧不可见）。66 网段电脑看不到 55 的组播。BusyBox 注意点仅适用
@@ -75,7 +77,7 @@ ssh zhiqiangf@192.168.55.5 "tcpdump -ni br0 -s 0 -vvv -tt 'udp port 5353 or tcp
 hass 侧（HA matter-server 作配对方，推荐；非交互 ssh 需显式 `sudo -n -i`）：
 
 ```bash
-ssh hassio@hass.windy.lan "sudo -n -i tcpdump -ni end0 -s 0 -vvv -tt 'udp port 5353 or tcp port 5540 or tcp port 5552'"
+ssh hassio@hass.windy.lan "sudo -n -i tcpdump -ni end1 -s 0 -vvv -tt 'udp port 5353 or tcp port 5540 or tcp port 5552'"
 ```
 
 精简过滤（只看 Matter 信号）：
@@ -193,7 +195,7 @@ ssh zhiqiangf@192.168.55.5 "tcpdump -ni br0 -s 0 -vvv -tt 'udp port 5353 or tcp
 | 新盏 `34:98:7a:27:10:bc`（`.148`，hostname `matter`） | DHCP 04:40 续租；gw ARP 完整；ping 通（93–122ms，ESP32 省电时延）；08-22 16:40 起稳定关联 `wifi0ap1`，关联时 `avg_rssi -70`。mDNS 宣告 3 实例：`4DF2B1455D19402D-02EF079EEB480D07`（**新 node ID——08-22 之后被重新配网过**）、`2F6E56020E1996E7-137147AF27BE4EB6`、`DCE86145C137AF0E-0000000000000011`（HA fabric）；host 记录 A `.148` + fe80 + **当前前缀** GUA `240e:3bd:238:4812:*`。支持单播 legacy mDNS 查询（`dig -p 5353 @.148 _matter._tcp.local PTR` 可用） |
 | 工作盏（MAC 已变）`fc:e8:c0:25:a1:f0`（`.146`，hostname `espressif`） | DHCP 07:17 续租；ping 通 v4/v6（v6 fe80 38–61ms）。mDNS 宣告 3 实例：`4DF2B1455D19402D-02EF4CA3F856B615`、`2F6E56020E1996E7-EE8F2E4F1A77BF05`、`DCE86145C137AF0E-000000000000000B`。原 MAC `34:98:7a:25:a1:f0` 全网消失（无租约/ARP/AP 日志）而新 MAC 末 3 字节相同 → 疑固件更新后改 MAC。**拒绝单播 5353**（ICMP port unreachable），只应答组播查询——同族固件行为差异。hass 残留其旧前缀 GUA `240e:3bd:235:1fb2:fee8:c0ff:fe25:a1f0` 的 **FAILED** 邻居项 |
 | 故障盏 `34:98:7a:27:7f:08`（曾 `.145`） | 无租约、ARP incomplete、AP 日志零事件 = 已离网 |
-| **TCP 5540 探测（两盏）** | IPv4（LAN66 与 hass 本段）、IPv6（fe80%end0 + 当前 GUA）全部 **RST（Connection refused）** —— SRV 宣告 :5540 且 TXT `T=1`，但实际无监听 |
+| **TCP 5540 探测（两盏）** | IPv4（LAN66 与 hass 本段）、IPv6（fe80%end1 + 当前 GUA）全部 **RST（Connection refused）** —— SRV 宣告 :5540 且 TXT `T=1`，但实际无监听 |
 | hass matter-server | `started`，v9.0.4，无更新；宣告自身运营实例 `DCE86145C137AF0E-…1B669`（v4+v6，当前 GUA）；**无任何 established :5540 会话**；core/add-on 日志无 matter 错误 |
 | 其他 Matter 控制器 | Aqara M3 `.248` 在线（有线 0.8ms），宣告含自身 fabric 节点 `4DF2B1455D19402D-11E158E46D24A000`；SmartThings `.48` 在线并周期查询 `_matter._tcp.local`；手机（当前前缀 GUA）也在浏览。LAN55 共见 **5 个 fabric**：`4DF2B1455D19402D`（M3）、`DCE86145C137AF0E`（HA）、`2F6E56020E1996E7`、`03BCFAEDD6153944`、`6A6FF80C2DB84DEE` |
 
@@ -207,9 +209,9 @@ TCP 5540 恢复监听即可确认。
 
 - gw：`show dhcp leases` / `show arp`（经 `/opt/vyatta/bin/vyatta-op-cmd-wrapper`）。
 - AP：`grep -i <mac> /var/log/messages`（hostapd 关联事件 + stahtd RSSI/soft failure）。
-- hass：`sudo -n -i ha apps info core_matter_server`；`ip -6 neigh show dev end0`
+- hass：`sudo -n -i ha apps info core_matter_server`；`ip -6 neigh show dev end1`
   （看灯泡 fe80/旧新前缀 GUA 与 FAILED 项）；被动抓包
-  `sudo -n -i timeout 65 tcpdump -ni end0 -s 0 -tt 'udp port 5353'`——配对方周期查询
+  `sudo -n -i timeout 65 tcpdump -ni end1 -s 0 -tt 'udp port 5353'`——配对方周期查询
   会自然引出灯泡宣告，无需主动发包。
-- 5540 探测：hass 上 python3 对 v4 / fe80%end0 / GUA 各 connect 一次；RST=无监听，
+- 5540 探测：hass 上 python3 对 v4 / fe80%end1 / GUA 各 connect 一次；RST=无监听，
   超时=不可达（两者含义不同）。

hosts/hass.windy.lan.md

@@ -11,6 +11,7 @@
 | SSH | `ssh hassio@hass.windy.lan` |
 | **Host** | **x88 Pro physical box** (HAOS bare-metal, `machine: green`; verified 2026-08-18) |
 | Platform | Home Assistant OS; kernel `6.1.115-haos` (aarch64) |
+| Core | 2026.9.3; Supervisor 2026.09.2; HAOS 18.2 (verified 2026-09-23) |
 | 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
@@ -40,7 +41,7 @@ recovery codes in this repository.
 
 | Interface | Address / role |
 |---|---|
-| `end0` | IPv4 static `192.168.55.11/24` (gw `.254`, DNS `192.168.66.36`); IPv6 SLAAC `auto` with GUA on the current PD-derived /64 (`240e:3bd:235:1fb2:*` at 2026-08-22; rotates on PPPoE redial); primary LAN55 NIC (interface name verified live 2026-08-22 — `end1` does not exist) |
+| `end1` | IPv4 static `192.168.55.11/24` (gw `.254`, DNS `192.168.66.36`); IPv6 SLAAC `auto` (prefixes rotate on PPPoE redial; old GUAs can linger). Primary LAN55 NIC. Live name on 2026-09-23 is `end1`; the 2026-08-22 `end0` name is gone |
 | `wlan0` | Supervisor **disabled** (verified 2026-08-14, W1N-104); IPv6 remains off on this RTL8821CS radio |
 | `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`) |
@@ -99,7 +100,7 @@ See `~/.config/zsh/env/local/environment.env` for the client-side setting.
 ## Safe verification
 
 ```bash
-ssh -o BatchMode=yes hassio@hass.windy.lan 'hostname; ip -4 addr show end0'
+ssh -o BatchMode=yes hassio@hass.windy.lan 'hostname; ip -4 addr show end1'
 ```
 
 From a LAN client, confirm DNS and UI reachability:
@@ -262,8 +263,7 @@ no template errors; 14 csg_* entities total.
 
 **电力监控面板（`lovelace.dashboard_unknown` / view `power-monitor`）
 updated 2026-08-29 (W1N-240 + W1N-242):** 「本月累计」gauge 对齐夏季阶梯：
-`max:650`、segments `0/260/600`（绿/橙/红 = 一/二/三档；冬季 11-01 需切
+`max:650`、segments `0/260/600`（绿/橙/红 = 一/二/三档）。冬季档不要再手改，由下方 v4 的 `binary_sensor.csg_summer_tariff` 切换。「📊 统计
-`max:450`、`0/200/400` — **seasonal switch point**，见下文）。「📊 统计
 数据」卡新增本年/去年 4 行（原生传感器，口径标注「电费(账单)」、本年
 「(至今)」）+ 本月日均/预测进度 2 行（`csg_this_month_daily_avg` /
 `csg_prediction_progress`，W1N-242）；面板共引用 **20** 个实体。改前备份：
@@ -279,7 +279,7 @@ updated 2026-08-29 (W1N-240 + W1N-242):** 「本月累计」gauge 对齐夏季
 数据日）。备份 `csg_sensors.yaml.bak-20260829-w1n242`。验证：Core
 restart 后回归值不变（334.81 / -0.3 / 10.8 / 90.3 / 200.94 / 180.28）。
 
-**CSG 面板重构 2026-09-04（VPS-90，先核对计价后展示层改动）:** 核对
+**CSG 面板重构 2026-09-04（VPS-90；面板布局已被下方 2026-09-22 v4 取代。仍有效的是均价传感器和两条季节提醒）:** 核对
 `power-monitor` 计价与 8 月账单一致（198.65 vs 账单 198.64，差 ≤0.01 元，
 因模板用公众圆整价 0.589/0.639/0.889、账单用 6 位精确价），不改阶梯常量。
 改动：① `csg_sensors.yaml` Block B 新增
@@ -296,12 +296,9 @@ availability 照 W1N-239 惯例；**csg_* 实体 14→15**）；② 面板改名
 `.lovelace-backups/dashboard-unknown-power-monitor-20260904-204757-pre-refactor.json`、
 `.csg-backups/csg_sensors.yaml.bak-20260904-204757-pre-refactor`（及
 `-205301-pre-avgprice`）、`.automations-backups/automations.yaml.bak-*`。
-**WS 改法（2026.8，本机实测）**：core/主机 python 无 ws 库、core 容器内经
+**WS 改法**：`lovelace/config` 读、`lovelace/config/save` 写
-supervisor 代理 WS 被拒（loop prevention），用
+（`lovelace/config/get` 不存在）。客户端用 [`scripts/ha-ws-client.py`](../scripts/ha-ws-client.py)，
-`docker run --rm --network host -e SUPERVISOR_TOKEN`（supervisor 镜像
+见下方 Quick 节。勿直改 `.storage/`。验证：新实体
-`aarch64-hassio-supervisor:2026.08.0`）连 `ws://172.30.32.2/core/websocket`；
-命令名 `lovelace/config`（读）+ `lovelace/config/save`（写），
-`lovelace/config/get` 已不存在（unknown_command）。验证：新实体
 0.589 元/kWh、15 个 csg_* 数值齐全、回归值不变（14.09/198.65/331.22/
 304.99/181.89）、automations on、`ha core check` OK、日志无 template 错误。
 
@@ -417,18 +414,14 @@ live state 完全一致（`csg_30d_avg` 9.07 / `csg_predicted_usage` 268.45 /
 （`states_raw` 08:17:04Z 158.54 → 08:17:10Z 157.19）。**注意**：`w` 的爬升窗口
 （14 天）是回测选出来的单月参数，属弱证据，换季/换季后值得复看。
 
-> **Seasonal gauge switch (W1N-240 已知事项):** 每年 **11-01** 把
+> **季节 gauge：** 不要手改 max/segments。`binary_sensor.csg_summer_tariff`
-> `power-monitor` 视图「本月累计」gauge 切到冬季 `max:450` /
+> （`on` = 5–10 月）切换夏季 `650 / 260 / 600` 与冬季 `450 / 200 / 400`，
-> `0/200/400`，**5-01** 切回夏季 `max:650` / `0/260/600`（与模板
+> 见上方 VPS-90 v4。`automation.csg_mian_ban_qie_dong_ji_dang_ti_xing`（10-25）
-> `now().month` 季节逻辑对齐；模板常量在 Block B/D `variables`）。
+> 与 `automation.csg_mian_ban_qie_xia_ji_dang_ti_xing`（4-25）仍会在 09:00
-> **提醒 automation（2026-09-04 起，VPS-90）:** 
+> 发 Matrix 提醒；提醒正文这次没核对。
-> `automation.csg_mian_ban_qie_dong_ji_dang_ti_xing`（10-25）与
-> `automation.csg_mian_ban_qie_xia_ji_dang_ti_xing`（4-25）09:00 经
-> `matrix_e2ee.send_message` 发操作步骤提醒；gauge 的 max/segments 无法
-> 模板化，仍需人工改卡配置。
 
 Home PPPoE IPv4 to CSG is still blackholed (`curl -4` to `218.19.148.218:443`
-times out). `end0` IPv6 is enabled (`ipv6.method: auto`); from HA,
+times out). `end1` IPv6 is enabled (`ipv6.method: auto`); from HA,
 `curl -6 https://95598.csg.cn` returns HTTP 200 via `240e:f9:8060::1:16`.
 
 **`tianqi` weather recorder patch (verified 2026-08-13, W1N-75):**
@@ -585,20 +578,20 @@ deployed 2026-08-18 from `216cc99` (backup
   `template: !include_dir_merge_list templates`. No `packages/`.
 - `scribe.yaml` (config root): the Scribe block, content identical to the
   former inline one; import semantics unchanged.
-- `templates/`: `csg_sensors.yaml` (12 template sensors, top-level **list**)
+- `templates/`: `csg_sensors.yaml` (15 `csg_*` template sensors, top-level **list**)
-  + `quick_sensors.yaml` (scaffold for Quick-derived `quick_*` sensors, empty
+  + `quick_sensors.yaml` (`sensor.quick_wen_cha`, same top-level list).
-  list with convention header). **`!include_dir_merge_list` merges per-file
+  **`!include_dir_merge_list` merges per-file lists; non-list files are silently skipped**
-  lists; non-list files are silently skipped** — every file in `templates/`
+  — every file in `templates/` must be a top-level list (`- sensor:` blocks).
-  must be a top-level list (`- sensor:` blocks). Directory include only picks
+  Directory include only picks up `*.yaml`, so `.bak` / `.pre-*` backups in the
-  up `*.yaml`, so the `.bak` / `.pre-*` backups in the dir are ignored. After
+  dir are ignored. UI helpers such as `binary_sensor.csg_summer_tariff` are not
-  adding sensors, verify template-platform entity count = 12 + N (entity
+  in this directory. After adding sensors, count template-platform entities
-  registry `platform: template`).
+  against these files plus the UI helpers, not against the old "12".
 - Convention (per review + W1N-233): pure sums/averages stay min_max helpers
   (e.g. `sensor.dang_qian_zong_gong_lu`); only template-logic derivations
   (ladder pricing, cross-entity conditions) go into `quick_sensors.yaml`.
 - Post-change verification 20:19 CST: `ha core check` ok, 92 s restart
   (2026.8.3), `binary_sensor.scribe_database_connection` on,
-  `scribe_states_written` 18581→19426 growing, template entities still 12,
+  `scribe_states_written` 18581→19426 growing, template entities still 12 that day (later 15 `csg_*` + `quick_wen_cha`),
   csg sensors numeric, no scribe/template log errors.
 
 ### Timescale Plotly card + database reader (verified 2026-08-29)
@@ -634,181 +627,48 @@ manual copies): reader `remmob/timescale_database_reader` **v1.1.0** (main
 - Scribe stores numeric sensor values in `states_raw.value` with `state` NULL,
   so `sensor_minute.state` shows `'0'` for numeric sensors; the card plots
   `avg_state` (from `value`) — expected, not a bug.
-- **Quick 仪表盘（`dashboard-quick`）图表套件**（2026-08-29 创建，经 WS
-  `lovelace/config/save` 写入；W1N-230 修复 + W1N-231 round-2 改进）：
-  5 张 timescale 卡——大功率电器/常驻负载功率（按量级拆图，避免尖峰压扁
-  <70 W 基线）、按插座用电量（`energy_mode` + cumulative/diff，数据质量前提
-  见 pgdb 的 refresh 过程补丁）、室内外温湿度（温度左轴/湿度右轴，4 位置同色
-  配对）、人体感应活动状态（3 个 `motion_state`，banded `state_map`
-  none/small/medium/large → 0-11，per-entity `line_color` 红/蓝/绿）。
-  空调实体引用为 `kong_diao_*`（`kong_tiao` 是笔误，W1N-230 修复；`grep -c
-  kong_tiao` 应为 0）。灯区：2×2 嵌套 grid（`grid_options: {columns: "full"}`，
-  内层 `columns: 2`）+ 4 卡统一 `mushroom-light-card`（显式 name、
-  `use_light_color: false`、内联亮度/色温控制），heading icon
-  `mdi:lightbulb-group`。heading badges：环境 4 温度（迷你/mini数显/数显/广州）、
-  大功率电器 空调/电脑当前功率、常驻负载 总功率
-  （`sensor.dang_qian_zong_gong_lu`，min_max **sum** helper，`round_digits: 0`，
-  任一源掉线 fail-closed → unknown）。常驻负载图卡级 `fill: 'tozeroy'` +
-  冰箱/主网络 per-entity `fill_color`（线色 20% 透明）+ 其余 5 条 `fill: false`
-  （per-entity fill 逐系列退出，卡 JS `seriesConfig.fill !== false`）。
-  布局：视图 `type: sections` + `max_columns: 4`；灯/用电/环境/人体感应
-  `column_span: 4`，功率两图拆两个 `column_span: 2` 分区**并排**（等高 280px，
-  桌面并排、手机回落堆叠；去卡内 title 省半宽图垂直空间）。
-  **分区/卡片是两套尺寸键，不可混用**：分区宽 = `column_span`
-  （`hui-sections-view.ts` 缺省按 1 列渲染，绝不省略）；卡片宽 =
-  `grid_options: {columns: <n|"full">}`（`hui-card.ts` 只读 `config.grid_options`，
-  写在卡片上的 `column_span` 被静默忽略；缺省 12 列，分区内格 = 12 × 分区
-  span，故 span-4 分区里缺省卡片只有 1/4 宽）。
-  修改前备份：`/homeassistant/.lovelace-backups/dashboard-quick-*.json`
-  （W1N-230 修复: `20260829-190256`；round-2 改进: `20260829-194040`）。
 
-- **Quick 时间范围扩容 (2026-09-13, VPS-92)**: 用户反馈「48 小时不够」。
+### Quick 仪表盘（`dashboard-quick`，现行 2026-09-23）
-  各 timescale 卡可选档上调——大功率电器/常驻负载 `…,24h` → `+3d,7d`；
-  环境 `6h,12h,24h,48h` → `+7d,14d,30d`；人体感应 `…,24h` → `+3d,7d`；
-  用电量(按插座) `energy_time_ranges` `today,week,month,custom` → `+3mo`。
-  **默认档未改**（6h / 6h / today / 24h / 12h）。备份
-  `.lovelace-backups/dashboard-quick-20260913-190912-pre-timerange.json`。
-  ⚠️ **本条的 `d` 档当天其实是坏的**——见下方 2026-09-21 修复；`energy_mode`
-  命名档（today/week/month/3mo）当时就是好的。卡片命名档只能是
-  `today|week|month|3mo|6mo|year|years|custom`。**数据下界注意**：scribe
-  `sensor_minute` 最早只到 **2026-08-29**，所以 >15d 的档（14d 边缘、30d 明显）
-  前半段仍是空白，等归档继续累积才好看。
 
-- **Quick 面板改造 + timescale 卡两个真 bug 修复 (2026-09-21)**：起因是用户
+`http://hass.windy.lan:8123/dashboard-quick`。视图 `type: sections`，`max_columns: 4`。
-  觉得「面板标题 + 统计方式」不对劲。只读审查查出三个问题并全部修掉：
+分区宽用 `column_span`（缺省是 1 列，不要省）。卡片宽用 `grid_options.columns`
+（写在卡片上的 `column_span` 会被忽略）。空调实体是 `kong_diao_*`；`kong_tiao` 是笔误，应为 0 处。
 
-  **① 卡 JS：`<n>d` 档实际渲染成 n 小时（VPS-92 的扩容其实没生效）**。
+| 分区 | span | 现在有什么 |
-  非 energy 档走 `const hours = parseInt(this._selectedRange) || 24;`，
+|---|---|---|
-  `parseInt("7d") === 7`。全卡唯一能解析 `d` 的 `parseDurationToMs()`
+| 灯与开关 | 4 | 2 列网格：卫生间灯、厨房灯、客厅长明灯、厨房远灯、Matter 开关「马桶换气电源」(`switch.wei_sheng_jian_ma_tong_huan_qi_dian_yuan`)。不放 `switch.0xa4c138a4c2fe4c8b`。徽章「换气功率」= `sensor.0xa4c138a4c2fe4c8b_power` |
-  （正则 `/^(\d+)(m|h|d)$/`）**只被 `resolveEnergyWindow()` 调用一次**，
+| 实时功率 | 2 | apexcharts donut，11 路当前功率（与下面两张功率图同一批）。末项「马桶换气」= 上面那颗 Zigbee 功率。图例在右，`chart.height` 510；card-mod 把 `ha-card` 撑到 520px。徽章「插座合计」= `sensor.dang_qian_zong_gong_lu` |
-  即只服务 energy 卡。后果：`3d` 比 `24h` 还短（3h），`14d`→14h、`30d`→30h。
+| 人体感应 | 2 | 厨房 / 卫生间 / 厨房(电池)。`state_map` 0–11，`downsample_method: last`。卡高 280，card-mod 520px，和圆环并排。默认 12h |
-  **修复**：改用 `Math.max(1, parseDurationToMs(...)/3600000)`；顺带把采样密度
+| 峰值负载 | 2 | 厨房电器、空调、电水壶、咖啡机、电脑。`downsample_method: avg`，高 280，默认 6h。徽章：空调、电脑。不要把约 25 W 的马桶换气放这里 |
-  目标 80 → 160 点（7d 档从 2.1h/桶降到 1.05h/桶）。备份
+| 基础负载 | 2 | 主网络、冰箱、大房、水设备、无线AP、马桶换气（`sensor.0xa4c138a4c2fe4c8b_power`）。卡 `fill: tozeroy`；主网络和冰箱有 `fill_color`，其余 4 条 `fill: false`。同样 `avg`、高 280、默认 6h |
-  `.lovelace-backups/timescale-plotly-card.js.bak-20260921-pre-dayfix`。
+| 今日用电 | 4 | `energy_mode`，11 路 kWh。末项「马桶换气」= `sensor.0xa4c138a4c2fe4c8b_energy`（`total_increasing`）。高 320，默认 today |
-  实测（本地 node 跑卡里的 `parseDurationToMs`）：`3d→72h / 7d→168h /
+| 温湿度 | 4 | `sensor.quick_wen_cha`（室内均温 − 室外）+ 湿度 4 条。两张卡 card-mod 520px，默认 24h。徽章：卫生间 / 客厅 / 卧室 / 室外温度 |
-  14d→336h / 30d→720h`，各档均 ~160 点；`node --check` JS 语法 OK。
-  **资源 URL 已加 `?v=20260921` 强制浏览器重取**（原来无 hacstag，缓存问题会
-  让修复「看不见」）。
 
-  **② 功率卡画的是瞬时采样而非统计量**。reader 对 `table=sensor_minute`
+功率图档 `1h,3h,6h,12h,24h,3d,7d`。人体感应档 `3h,6h,12h,24h,3d,7d`。温湿度档 `6h,12h,24h,48h,7d,14d,30d`。今日用电档 `today,week,month,3mo,custom`。`sensor_minute` 最早只到 **2026-08-29**，长于约 15 天的档前半段是空的。
-  （时间列名 `minute`）默认 `downsample_method = "last"`
-  （`custom_components/timescale_database_reader/__init__.py` L385-389），
-  即每桶取「末一分钟的瞬时值」。实测空调 1 小时桶：03:00 真实均值 241.6 W /
-  峰值 1128 W，图上只画 157；19:00 真实均值 97.6 / 峰值 676，图上画 **13**
-  （看起来像停机）。因 `sensor_minute` 已是均匀 1 分钟 LOCF 序列，`avg()`
-  才是正确时间均值。**修复**：两张功率卡加 `downsample_method: "avg"`。
-  **用电量卡不用改**——累计计数器配 `last()` 就是桶末读数，卡片再 diff，
-  本来就是对的；人体感应卡显式 `last` 对分类信号也对。
 
-  **③ 标题与分组名不副实**。按 7d 实测（峰值/均值）重分组并改名：
+「插座合计」是 min_max **sum**（entry `01M16N648QBFG13P07XQMESBSP`，`round_digits: 0`），含上面 11 路功率，不含灯。任一源掉线则 unknown。2026-09-23 读回 380 W，与 11 路之和一致。
-  | 位置 | 改前 | 改后 |
-  |---|---|---|
-  | 分区 | 大功率电器 | **峰值负载**（厨房电器 1839 / 空调 1128 / 电水壶 957 / 咖啡机 882 / 电脑 363 W） |
-  | 分区 | 常驻负载 | **基础负载**（主网络 75 / 冰箱 137 / 大房 290 / 水设备 171 / 无线AP 976* W） |
-  | 分区 | 用电 | **今日用电** |
-  | 分区 | 灯 + 开关（分开在最顶和最底） | **灯与开关**（合并置顶，可操作项集中） |
-  | 分区（新） | — | **此刻耗电** |
-  | 徽标 | 总功率 | **插座合计**（只是 9 个插座之和，不含灯/换气） |
-  | 实体 | 迷你 / mini数显 / 数显 | **卫生间 / 客厅 / 卧室**（HA area 本来就有，之前用的是设备型号名） |
-  | 实体 | 电池(移动) | **厨房(电池)**（该设备 area 也是厨房） |
-  删除 3 张与分区标题重复的卡 title（用电量(按插座) / 室内外温湿度 / 活动状态）。
-  \* 无线AP 7 天里只有 2 分钟 >150 W 却记到 976 W —— 单点毛刺，会把 y 轴顶飞，
-  待查。
 
-  **④ 新展示**：新增「此刻耗电」区 = `custom:apexcharts-card` **donut**，11 个
+**别按旧说明操作：**
-  插座当前功率（`graph_span: 10min` + `update_interval: 1min`），回答「现在什么
-  在吃电」；环境区拆成**室内外温差**（新模板传感器 `sensor.quick_wen_cha` =
-  3 个室内温度均值 − 室外，画零线上下 fill）+ **湿度**（4 条），4 个温度进徽标。
-  传感器加在 `templates/quick_sensors.yaml`（W1N-238 约定的落点，顶层列表，
-  `quick_` 前缀 + unique_id），非 trigger 型模板卡，**`template.reload` 即可生效，
-  无需重启 Core**（实测 `POST /core/api/services/template/reload` → 200，
-  `sensor.quick_wen_cha` = 3.9 °C）。备份
-  `templates/quick_sensors.yaml.bak-20260921-pre-wencha`。
-  最终分区顺序（按「可变性」）：灯与开关 → 此刻耗电 → 今日用电 →
-  峰值负载(2) → 基础负载(2) → 环境 → 人体感应。
 
-  **⑤ Quick 布局重构 (2026-09-21 晚)**：用户反馈饼图（apexcharts donut）撑满
+- 功率图必须 `downsample_method: avg`。reader 对 `sensor_minute` 默认 `last`（桶末瞬时值），空调会画成停机。今日用电用累计表的 `last` 再 diff，不要改成 avg。人体感应保持 `last`。
-  整行（span 4）且不满、马桶换气开关 tile `columns: "full"` 占满整行太宽、整体
+- 卡 JS 曾把 `7d` 解析成 7 小时。2026-09-21 已改用 `parseDurationToMs`，资源 URL 带 `?v=20260921`。换 JS 后要再 bump `?v=`。命名档只有 `today|week|month|3mo|6mo|year|years|custom`。
-  布局需要重新思考。改动：
+- apexcharts 的 `chart.height` 含图例，timescale 的 `height` 只是绘图区。并排等高用 card-mod 的 `ha-card`，不要把两个数字写成一样。
+- 保存后圆环可能缩在角落。配置没变，拖一下窗口让它重算。
+- 无线 AP 曾有单点 976 W，会把基础负载的 y 轴顶飞。未查。
+- `/energy` 的马桶换气仍是 Matter 积分 `sensor.wei_sheng_jian_ma_tong_huan_qi_dian_yuan_energy`，不是这颗 Zigbee 电量。能源面板也没有主网络、无线 AP。
 
-  **布局重排**（阅读流：控制 → 此刻 → 趋势 → 今日 → 环境）：
+**改法：** WS `lovelace/config` 读、`lovelace/config/save` 写。勿改 `.storage/`。
-  | 行 | 左 (span 2) | 右 (span 2) | 主题 |
+用 [`scripts/ha-ws-client.py`](../scripts/ha-ws-client.py)（supervisor 镜像里的 python3 + `SUPERVISOR_TOKEN`，不要 `-v /tmp`）。
-  |---|---|---|---|
+min_max 在 HA 2026.9 没有 WS `config_entries/options/flow`，走 supervisor 的
-  | 1 | 灯与开关 (span 4) | | 可操作项置顶 |
+`POST /core/api/config/config_entries/options/flow`。`scribe.yaml` 已是 `record_states: true`，新传感器不用改它。
-  | 2 | 实时功率 (donut) | 人体感应 | 「此刻状态」 |
+`sensor.quick_wen_cha` 在 `templates/quick_sensors.yaml`，`template.reload` 即可，不用重启 Core。
-  | 3 | 峰值负载 | 基础负载 | 「功率趋势」（原配对保留） |
-  | 4 | 今日用电 (span 4) | | 11 条堆叠柱需要宽度 |
-  | 5 | 温湿度 (span 4) | | 温差+湿度两图并排 |
 
-  **标题改名**：此刻耗电→**实时功率**（与峰值负载对仗）、环境→**温湿度**
+**回滚：** 计量改动前
-  （更具体）。删饼图卡内冗余标题 "各插座当前功率 (W)"。
+`.lovelace-backups/dashboard-quick-20260923-080213-pre-meter-plug.json`
-
+（SHA-256 `a30b200350923633ddde0f2f071f2b75f0f37b347da4dd9a688da295dd8c8f35`）。
-  **开关收窄**：马桶换气电源 tile 从独立 `columns: "full"`（48 列全宽）→ 移入
+布局和卡 JS：`dashboard-quick-20260921-pre-titles.json` +
-  灯的 2 列嵌套网格第 5 格，与灯卡等宽（半行）。
+`timescale-plotly-card.js.bak-20260921-pre-dayfix`。
-
+还原 JSON 用 WS save。改过卡 JS 要把资源 `?v=` 再 bump。
-  **饼图高度**：`apex_config.chart.height` 280→350（11 项底部图例占 ~100px，
-  280 时饼图本体太扁）。
-
-  **⑥ card-mod 等高 (2026-09-21 晚)**：不同卡类型（apexcharts vs timescale-plotly）
-  的 `height` 渲染比例不同（apexcharts 含图例/内边距，timescale 是纯绘图区），
-  直接对齐数字无法视觉等高。安装 **card-mod**（HACS → card-mod + card-mod-studio）
-  后用 CSS 强制 `ha-card` 高度：
-
-  ```yaml
-  card_mod:
-    style: "ha-card { height: 520px !important; }"
-  ```
-
-  **最终高度**：饼图+人体感应 = **520px**，温湿度双图 = **520px**。其余图表
-  （峰值/基础负载 280、今日用电 320）保持各自原生高度，不强制统一——不同图表
-  类型适合不同高度，强行统一反而让简单图表显得太空。
-
-  **关键认知**：apexcharts `chart.height` 包含图例区域，timescale-plotly `height`
-  是纯绘图区。同一数字渲染出来 apexcharts 视觉上更矮。card-mod 直接控制
-  `ha-card` 容器高度，绕过内部渲染差异。
-
-  备份：`.lovelace-backups/dashboard-quick-20260921-pre-titles.json`（同日早期
-  备份，覆盖标题+布局全部改动的回滚）。
-
-  **验证**：`ha core check` OK；WS 读回与写入 payload **逐字节相同**；
-  新配置引用的 **40 个实体全部存在**且无 unknown/unavailable；
-  卡 JS `node --check` 通过、时长解析实测正确。
-  **改法（可复用）**：写 Lovelace 配置必须走 WS
-  `lovelace/config/save`（**勿直改 `.storage/`**）。本机 python/HA 容器内经
-  supervisor 代理连 WS 会被 loop-prevention 拒；可行路径是
-  `docker run --rm -i --network host -e SUPERVISOR_TOKEN --entrypoint python3
-  r.hassbus.com/home-assistant/aarch64-hassio-supervisor:<ver> -c "..."`
-  跑本仓库的 [`scripts/ha-ws-client.py`](../scripts/ha-ws-client.py)（纯 stdlib，
-  不依赖 websockets/aiohttp，也不依赖 `-v` 挂载——`-v /tmp/...` 会落到 Docker 宿主
-  而不是 SSH add-on 的 `/tmp`）。读配置：`{"action":"get","url_path":"dashboard-quick"}`；
-  写：`{"action":"save",...,"config":{...}}`。备份
-  `.lovelace-backups/dashboard-quick-20260921-pre-titles.json`。
-
-  **回滚**：还原 `dashboard-quick-20260921-pre-titles.json`（WS save）+
-  `timescale-plotly-card.js.bak-20260921-pre-dayfix` + 删 `quick_wen_cha`
-  （还原 `quick_sensors.yaml.bak-20260921-pre-wencha` + `template.reload`）。
-  改了卡 JS 就要把资源 URL 的 `?v=` 再 bump 一次。
-
-  **马桶换气计量插座 (2026-09-23)**：Zigbee/Tuya `0xa4c138a4c2fe4c8b`
-  （设备名「卫生间马桶换气电源」）替换 Quick 上原 Matter 风扇插座的计量点。
-  Matter 开关 `switch.wei_sheng_jian_ma_tong_huan_qi_dian_yuan` 仍是「灯与开关」
-  里唯一的插座开关；不放 `switch.0xa4c138a4c2fe4c8b`（曾加过磁贴，同日撤掉）。
-  徽章「换气功率」与实时功率圆环「马桶换气」改为
-  `sensor.0xa4c138a4c2fe4c8b_power`；今日用电「马桶换气」改为
-  `sensor.0xa4c138a4c2fe4c8b_energy`（kWh，`total_increasing`）。
-  基础负载追加 `sensor.0xa4c138a4c2fe4c8b_power`（名称「马桶换气」）。
-  峰值负载未改。min_max「当前总功率」（`type: sum`）追加该功率实体；
-  HA 2026.9 已无 WS `config_entries/options/flow`，改走
-  `POST /api/config/config_entries/options/flow`。`scribe.yaml` 未改
-  （`record_states: true`，新传感器本来就记）。写入前备份
-  `.lovelace-backups/dashboard-quick-20260923-080213-pre-meter-plug.json`
-  （SHA-256 `a30b200350923633ddde0f2f071f2b75f0f37b347da4dd9a688da295dd8c8f35`）。
-  Timescale `scribe.states_raw` / `sensor_minute` 已有这两条（设备加入起就在写，
-  未改 `scribe.yaml`）：power 末值 25 W，energy 末值 0.28 kWh，
-  `sensor_minute` 与空调/冰箱同停在当时的最新分钟。
-  验证：WS 读回无新开关、Matter 开关仍在、计量实体已换；合计 380.0 W 与 11 路功率之和差 0。
-  基础负载读回 6 条，末条「马桶换气」；峰值负载仍 5 条。
-  保存后实时功率圆环曾缩在卡片一角，卡片配置未改；拖动窗口触发重算后恢复。
 
 ### 地图仪表盘：CARTO keyed tiles via `custom:map-card` (verified 2026-08-30, W1N-261)
 
@@ -839,9 +699,8 @@ manual copies): reader `remmob/timescale_database_reader` **v1.1.0** (main
 - **验证 8/30:** 同瓦片无 key=水印 / 带 key=干净（256×256 PNG 视觉对比）；
   resource HTTP 200 text/javascript；WS 读回卡片配置（type/entities/key/
   attribution/options）全部符合；HA 主机 `curl -4` 带 key 瓦片 200。
-- **Follow-up:** Core 升 2026.9.0 stable 后内置地图/zone 编辑器自动切
+- **Follow-up:** Core 现为 2026.9.3（2026-09-23）。内置地图是否已切 OSMF
-  OSMF 矢量瓦片；届时可保留 custom 卡（继续 keyed CARTO）或用备份还原
+  矢量瓦片没有复查；本仪表盘仍用 keyed CARTO 的 `custom:map-card`。
-  内置卡。zone 编辑器等其余内置地图的水印在 2026.9 前无解。
 
 ## Known issues
 
@@ -904,6 +763,10 @@ advertised correctly over v4+v6. Both ESP32-C2 bulbs now announce `_matter._tcp`
 
 ## 马桶换气电源（Matter 插座，半计量）+ 电量估算 (2026-09-13)
 
+Quick 从 2026-09-23 起不再用这颗插座的功率或积分电量，见上方 Quick 节。
+下面的积分实体仍是 `/energy` 的第 9 个 grid 源（当日读回）。Matter 开关仍在「灯与开关」。
+
+
 **设备**：Matter `Smart Plug`（SIXWGH，`model_id 3596`，hw 1.0 / sw 1.3.0），node 18
 (0x12)，`device_id 5ef1850953466d6e7a9c6b901fbebe1c`，config entry
 `01JF51VQ48PGJGXX3RNAG6MVAA`，区域**卫生间** (`wei_sheng_jian`)，label `power`；
@@ -939,9 +802,8 @@ Voltage / ActiveCurrent / ActivePower 都随负载变化（实测 220.3 V / 118
 - **能源仪表盘** (`/energy`)：grid 源 `[8]` 由 `…_dian_li` 改为 `…_energy`，
   其余 8 条插座源未动。注意这 9 条「插座」全部以 `type: grid` 注册，被当作
   全屋用电代理；`switch` 卡片所在的 Grid 卡片此前第 9 行是空的，即本次修复点。
-- **Quick 仪表盘**：「用电量(按插座)」图第 11 项由 `…_dian_li` 改为
+- **Quick（已过时）：** 2026-09-13 曾把用电量图指到 `…_energy`，并单独加过开关分区。
-  `…_energy`；新增 `column_span: 2` 的「开关」区块（heading + tile
+  现行 Quick 见上方。不要按本段把 Quick 改回去。
-  `switch.…` + `toggle` feature + 功率徽标）→ 视图 6→7 分区。
 
 **口径警告**：`…_energy` 是**估算值**（Riemann 积分，只在 HA 运行期间累计、
 非账单级），与另外 8 个原生计量插座的累计电量口径不同；功率传感器更新
@@ -971,13 +833,14 @@ curl -s -X POST -H "Authorization: Bearer $SUPERVISOR_TOKEN" \
 **备份/回滚**：`.lovelace-backups/dashboard-quick-20260913-181251-pre-ma-tong-plug.json`
 （改动前原件）、`…-20260913-183210-pre-repoint.json`（改名/换源前）；
 `.ha-backups/energy-20260913-183135-pre-ma-tong-repoint.json`（能源 prefs）。
-回滚 = 把能源 prefs 的源 [8] 指回 `…_dian_li` + 还原 Quick 面板 JSON；
+回滚能源估算 = 把能源 prefs 的源 [8] 指回 `…_dian_li`。
-如需彻底放弃估算电量 = 删除 config entry `01M2D53T188FW8WEC547ENHSVH`。
+不要用 2026-09-13 的 Quick JSON 覆盖现在的面板，那会撤掉后来的布局和 Zigbee 计量。
+彻底放弃估算电量 = 删除 config entry `01M2D53T188FW8WEC547ENHSVH`。
 
 **验证 (2026-09-13 18:3x)**：`…_energy` 0.002→0.003 kWh 且随 24.6 W 负载
 增长（换气扇关掉后回落 0.0 W，累计值保留）；`recorder/list_statistic_ids`
 已含该实体；Quick 面板 WS 读回 7 分区、用电量图 11 项指向新实体、旧
-`_dian_li` 引用 0 处；能源 prefs 读回 9 源、第 9 条为新实体。
+`_dian_li` 引用 0 处；能源 prefs 读回 9 源、第 9 条为新实体（Quick 的这次读回只对 2026-09-13 有效；2026-09-23 起 Quick 改指 Zigbee，`/energy` 第 9 源仍是该积分实体）。
 **`energy/validate` 已全绿**（9 源 0 issue）：创建后 ~5 min 内曾报
 `statistics_not_defined`（recorder 的统计任务周期是 5 min，`statistics_meta`
 行由该任务建立），18:39 复核时已自动消失——建辅助元素后**不要**把这条

runbooks/home-assistant-maintenance.md

@@ -1,7 +1,7 @@
 # Runbook: Home Assistant maintenance (hass.windy.lan)
 
 Target: [hass.windy.lan](../hosts/hass.windy.lan.md) (physical x88 Pro box, HAOS `machine: green`)
-Upstream: HAOS 18.2 / Supervisor 2026.09.0 / Core 2026.9.1 (verified 2026-09-13)
+Upstream: HAOS 18.2 / Supervisor 2026.09.2 / Core 2026.9.3 (verified 2026-09-23)
 
 This runbook covers routine Home Assistant maintenance through the **`ha`
 supervisor CLI**. All commands are wrapped by a single script
@@ -395,7 +395,7 @@ full backup `pre-maintenance-20260813` (slug `411a4ba5`). Remaining:
 - `host info` reports `disk_life_time: 10` (boot eMMC ~10% life left) —
   monitor on each snapshot; plan disk replacement / data-disk migration.
 - **Home PPPoE IPv4 to CSG is blackholed** (`curl -4` to
-  `218.19.148.218:443` times out). `end0` IPv6 works (`curl -6
+  `218.19.148.218:443` times out). `end1` IPv6 works (`curl -6
   https://95598.csg.cn` → HTTP 200). Entry `ip_family: ipv4` still
   matches the stored option; first post-restart poll can still time out
   — reload the config entry rather than reinstalling.

runbooks/matter-packet-capture.md

@@ -11,6 +11,7 @@ is read-only and changes no device or network state.
 
 - Environment: LAN55 (`hass.windy.lan`, Aqara M3, ESP32-C2 Matter bulbs,
   phone / HA matter-server all on the 55 subnet).
+- NIC on hass is `end1` (verified 2026-09-23). Notes from 2026-08 called it `end0`; that name is gone.
 - Subject: Matter over Wi-Fi and Thread relay nodes. The Thread 802.15.4 air
   side itself is not capturable — only IPv6 forwarding by a Thread relay such
   as the M3 is visible.
@@ -28,11 +29,11 @@ equals capturing the whole flow.
 
 | Capture point | Sees | Blind spot | Notes |
 |---|---|---|---|
-| **hass `end0` — commissioner side (recommended)** | The full HA-driven commissioning conversation: all mDNS queries/announcements (segment multicast) + the complete TCP 5540 PASE/CASE session | Phone-as-commissioner flows (the phone's session to the device does not pass through hass) | `core_matter_server` uses **host networking**, so tcpdump on `end0` sees the add-on's traffic directly; `/` is overlay with ~42 GB free — no 60 MB tmpfs rotation needed |
+| **hass `end1` — commissioner side (recommended)** | The full HA-driven commissioning conversation: all mDNS queries/announcements (segment multicast) + the complete TCP 5540 PASE/CASE session | Phone-as-commissioner flows (the phone's session to the device does not pass through hass) | `core_matter_server` uses **host networking**, so tcpdump on `end1` sees the add-on's traffic directly; `/` is overlay with ~42 GB free — no 60 MB tmpfs rotation needed |
 | **UAP-AC-Lite `br0` (192.168.55.5)** | All mDNS multicast (flooded; igmp snooping off) + all wireless-client unicast + unicast to/from the AP | Wired↔wired unicast — e.g. HA↔M3 TCP 5540 while a Thread device commissions via the M3 (wired, observed) — is switched locally and never traverses the AP | AP `/tmp` is a ~60 MB tmpfs → rotating capture is **mandatory** |
 
 For the common "add device" case with HA matter-server as the commissioner,
-capture on hass `end0`. Use the AP `br0` point for wireless-device or
+capture on hass `end1`. Use the AP `br0` point for wireless-device or
 phone-driven flows (a wireless client's unicast to/from its AP is only visible
 there).
 
@@ -45,7 +46,7 @@ A third point, `gw` `switch0`, is **verified as a limited capture point**
 - Owner: personal ops (Windy)
 - Last reviewed: 2026-08-22
 - Related systems: UAP-AC-Lite AP `192.168.55.5` (br0), `core_matter_server` on
-  `hass.windy.lan` (`end0`), Aqara M3, ESP32-C2 Matter bulbs
+  `hass.windy.lan` (`end1`), Aqara M3, ESP32-C2 Matter bulbs
 
 ## Preconditions
 
@@ -89,7 +90,7 @@ A third point, `gw` `switch0`, is **verified as a limited capture point**
 
 **Action**
 
-- HA matter-server is the commissioner (the "add device" case) → hass `end0`.
+- HA matter-server is the commissioner (the "add device" case) → hass `end1`.
 - Wireless device or phone-driven flow → AP `br0`.
 
 **Expected**
@@ -114,7 +115,7 @@ ssh zhiqiangf@192.168.55.5 "tcpdump -ni br0 -s 0 -tt 'udp port 5353 or tcp port
 hass (commissioner side):
 
 ```bash
-ssh hassio@hass.windy.lan "sudo -n -i tcpdump -ni end0 -s 0 -tt 'udp port 5353 or tcp port 5540 or tcp port 5552'"
+ssh hassio@hass.windy.lan "sudo -n -i tcpdump -ni end1 -s 0 -tt 'udp port 5353 or tcp port 5540 or tcp port 5552'"
 ```
 
 Keep the window open, trigger the device behavior (enter commissioning mode /
@@ -153,7 +154,7 @@ ssh zhiqiangf@192.168.55.5 "tcpdump -ni br0 -s 0 -C 5 -W 12 -w /tmp/matter.pcap
 hass (rotation optional — overlay disk):
 
 ```bash
-ssh hassio@hass.windy.lan "sudo -n -i tcpdump -ni end0 -s 0 -C 5 -W 12 -w /tmp/matter.pcap 'udp port 5353 or tcp port 5540 or tcp port 5552'"
+ssh hassio@hass.windy.lan "sudo -n -i tcpdump -ni end1 -s 0 -C 5 -W 12 -w /tmp/matter.pcap 'udp port 5353 or tcp port 5540 or tcp port 5552'"
 ```
 
 Trigger the traffic, then `Ctrl+C`. Files are `/tmp/matter.pcap`,
@@ -246,7 +247,7 @@ ssh zhiqiangf@192.168.55.5 "tcpdump -ni br0 -s 0 -C 5 -W 12 -w /tmp/matter-\$(da
 > command so the remote shell expands it.
 
 For the hass point, prefix the same commands with
-`ssh hassio@hass.windy.lan "sudo -n -i tcpdump -ni end0 …"`.
+`ssh hassio@hass.windy.lan "sudo -n -i tcpdump -ni end1 …"`.
 
 ## Capture point: gw switch0
 
@@ -266,7 +267,7 @@ LAN55.**
 - **What `switch0` still sees:** cross-subnet (66↔55) unicast, traffic to/from
   the gateway itself (DHCP, DNS forwarding, port-forwards), and LAN55 mDNS
   multicast (flooded up the uplink). Use it only for those flows; for a full
-  commissioning conversation use the hass `end0` or AP `br0` point instead.
+  commissioning conversation use the hass `end1` or AP `br0` point instead.
 - **Full mirror:** only via SE5420 port mirroring (the switch cannot run
   tcpdump). Not configured; out of scope here.
 - **Verification commands (EdgeOS v3.0.1 build 5862409):**
@@ -295,7 +296,7 @@ LAN55.**
 - Realtime capture consistently shows the target device's mDNS announcements
   (`_matterc` / `_matter._tcp`) on the chosen point.
 - Commissioning shows the TCP 5540 handshake (SYN/SYN-ACK/ACK); on the hass
-  `end0` point this includes wired Thread-relay commissioning (HA↔M3), which
+  `end1` point this includes wired Thread-relay commissioning (HA↔M3), which
   the AP point cannot see.
 - Saved pcap opens in Wireshark and filters by `mDNS` / `tcp.port==5540`.