From d6fbbe13c54d4ea78c49c36ff7f8ac888114927b Mon Sep 17 00:00:00 2001 From: windyboy Date: Wed, 23 Sep 2026 08:36:57 +0800 Subject: [PATCH] =?UTF-8?q?docs(hass):=20=E6=8A=8A=E4=B8=BB=E6=9C=BA?= =?UTF-8?q?=E6=96=87=E6=A1=A3=E6=94=B6=E6=88=90=E7=8E=B0=E8=A1=8C=E7=8A=B6?= =?UTF-8?q?=E6=80=81?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Quick 布局、季节 gauge、网卡 end1 和 Core 2026.9.3 与旧操作说明不一致。抓包命令改为 end1。 --- docs/matter-pairing-troubleshoot.md | 14 +- hosts/hass.windy.lan.md | 273 ++++++------------------- runbooks/home-assistant-maintenance.md | 4 +- runbooks/matter-packet-capture.md | 19 +- 4 files changed, 88 insertions(+), 222 deletions(-) diff --git a/docs/matter-pairing-troubleshoot.md b/docs/matter-pairing-troubleshoot.md index 8b57ad4..92e4b2d 100644 --- a/docs/matter-pairing-troubleshoot.md +++ b/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 /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=无监听， 超时=不可达（两者含义不同）。 diff --git a/hosts/hass.windy.lan.md b/hosts/hass.windy.lan.md index 67ac37c..60b8b62 100644 --- a/hosts/hass.windy.lan.md +++ b/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:450`、`0/200/400` — **seasonal switch point**，见下文）。「📊 统计 +`max:650`、segments `0/260/600`（绿/橙/红 = 一/二/三档）。冬季档不要再手改，由下方 v4 的 `binary_sensor.csg_summer_tariff` 切换。「📊 统计 数据」卡新增本年/去年 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 容器内经 -supervisor 代理 WS 被拒（loop prevention），用 -`docker run --rm --network host -e SUPERVISOR_TOKEN`（supervisor 镜像 -`aarch64-hassio-supervisor:2026.08.0`）连 `ws://172.30.32.2/core/websocket`； -命令名 `lovelace/config`（读）+ `lovelace/config/save`（写）， -`lovelace/config/get` 已不存在（unknown_command）。验证：新实体 +**WS 改法**：`lovelace/config` 读、`lovelace/config/save` 写 +（`lovelace/config/get` 不存在）。客户端用 [`scripts/ha-ws-client.py`](../scripts/ha-ws-client.py)， +见下方 Quick 节。勿直改 `.storage/`。验证：新实体 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** 把 -> `power-monitor` 视图「本月累计」gauge 切到冬季 `max:450` / -> `0/200/400`，**5-01** 切回夏季 `max:650` / `0/260/600`（与模板 -> `now().month` 季节逻辑对齐；模板常量在 Block B/D `variables`）。 -> **提醒 automation（2026-09-04 起，VPS-90）:** -> `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 无法 -> 模板化，仍需人工改卡配置。 +> **季节 gauge：** 不要手改 max/segments。`binary_sensor.csg_summer_tariff` +> （`on` = 5–10 月）切换夏季 `650 / 260 / 600` 与冬季 `450 / 200 / 400`， +> 见上方 VPS-90 v4。`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 提醒；提醒正文这次没核对。 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**) - + `quick_sensors.yaml` (scaffold for Quick-derived `quick_*` sensors, empty - list with convention header). **`!include_dir_merge_list` merges per-file - lists; non-list files are silently skipped** — every file in `templates/` - must be a top-level list (`- sensor:` blocks). Directory include only picks - up `*.yaml`, so the `.bak` / `.pre-*` backups in the dir are ignored. After - adding sensors, verify template-platform entity count = 12 + N (entity - registry `platform: template`). +- `templates/`: `csg_sensors.yaml` (15 `csg_*` template sensors, top-level **list**) + + `quick_sensors.yaml` (`sensor.quick_wen_cha`, same top-level list). + **`!include_dir_merge_list` merges per-file lists; non-list files are silently skipped** + — every file in `templates/` must be a top-level list (`- sensor:` blocks). + Directory include only picks up `*.yaml`, so `.bak` / `.pre-*` backups in the + dir are ignored. UI helpers such as `binary_sensor.csg_summer_tariff` are not + in this directory. After adding sensors, count template-platform entities + 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: }`（`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 小时不够」。 - 各 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 仪表盘（`dashboard-quick`，现行 2026-09-23） -- **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：`d` 档实际渲染成 n 小时（VPS-92 的扩容其实没生效）**。 - 非 energy 档走 `const hours = parseInt(this._selectedRange) || 24;`， - `parseInt("7d") === 7`。全卡唯一能解析 `d` 的 `parseDurationToMs()` - （正则 `/^(\d+)(m|h|d)$/`）**只被 `resolveEnergyWindow()` 调用一次**， - 即只服务 energy 卡。后果：`3d` 比 `24h` 还短（3h），`14d`→14h、`30d`→30h。 - **修复**：改用 `Math.max(1, parseDurationToMs(...)/3600000)`；顺带把采样密度 - 目标 80 → 160 点（7d 档从 2.1h/桶降到 1.05h/桶）。备份 - `.lovelace-backups/timescale-plotly-card.js.bak-20260921-pre-dayfix`。 - 实测（本地 node 跑卡里的 `parseDurationToMs`）：`3d→72h / 7d→168h / - 14d→336h / 30d→720h`，各档均 ~160 点；`node --check` JS 语法 OK。 - **资源 URL 已加 `?v=20260921` 强制浏览器重取**（原来无 hacstag，缓存问题会 - 让修复「看不见」）。 +| 分区 | span | 现在有什么 | +|---|---|---| +| 灯与开关 | 4 | 2 列网格：卫生间灯、厨房灯、客厅长明灯、厨房远灯、Matter 开关「马桶换气电源」(`switch.wei_sheng_jian_ma_tong_huan_qi_dian_yuan`)。不放 `switch.0xa4c138a4c2fe4c8b`。徽章「换气功率」= `sensor.0xa4c138a4c2fe4c8b_power` | +| 实时功率 | 2 | apexcharts donut，11 路当前功率（与下面两张功率图同一批）。末项「马桶换气」= 上面那颗 Zigbee 功率。图例在右，`chart.height` 510；card-mod 把 `ha-card` 撑到 520px。徽章「插座合计」= `sensor.dang_qian_zong_gong_lu` | +| 人体感应 | 2 | 厨房 / 卫生间 / 厨房(电池)。`state_map` 0–11，`downsample_method: last`。卡高 280，card-mod 520px，和圆环并排。默认 12h | +| 峰值负载 | 2 | 厨房电器、空调、电水壶、咖啡机、电脑。`downsample_method: avg`，高 280，默认 6h。徽章：空调、电脑。不要把约 25 W 的马桶换气放这里 | +| 基础负载 | 2 | 主网络、冰箱、大房、水设备、无线AP、马桶换气（`sensor.0xa4c138a4c2fe4c8b_power`）。卡 `fill: tozeroy`；主网络和冰箱有 `fill_color`，其余 4 条 `fill: false`。同样 `avg`、高 280、默认 6h | +| 今日用电 | 4 | `energy_mode`，11 路 kWh。末项「马桶换气」= `sensor.0xa4c138a4c2fe4c8b_energy`（`total_increasing`）。高 320，默认 today | +| 温湿度 | 4 | `sensor.quick_wen_cha`（室内均温 − 室外）+ 湿度 4 条。两张卡 card-mod 520px，默认 24h。徽章：卫生间 / 客厅 / 卧室 / 室外温度 | - **② 功率卡画的是瞬时采样而非统计量**。reader 对 `table=sensor_minute` - （时间列名 `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` 对分类信号也对。 +功率图档 `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 天的档前半段是空的。 - **③ 标题与分组名不副实**。按 7d 实测（峰值/均值）重分组并改名： - | 位置 | 改前 | 改后 | - |---|---|---| - | 分区 | 大功率电器 | **峰值负载**（厨房电器 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 轴顶飞， - 待查。 +「插座合计」是 min_max **sum**（entry `01M16N648QBFG13P07XQMESBSP`，`round_digits: 0`），含上面 11 路功率，不含灯。任一源掉线则 unknown。2026-09-23 读回 380 W，与 11 路之和一致。 - **④ 新展示**：新增「此刻耗电」区 = `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）撑满 - 整行（span 4）且不满、马桶换气开关 tile `columns: "full"` 占满整行太宽、整体 - 布局需要重新思考。改动： +- 功率图必须 `downsample_method: avg`。reader 对 `sensor_minute` 默认 `last`（桶末瞬时值），空调会画成停机。今日用电用累计表的 `last` 再 diff，不要改成 avg。人体感应保持 `last`。 +- 卡 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。 - **布局重排**（阅读流：控制 → 此刻 → 趋势 → 今日 → 环境）： - | 行 | 左 (span 2) | 右 (span 2) | 主题 | - |---|---|---|---| - | 1 | 灯与开关 (span 4) | | 可操作项置顶 | - | 2 | 实时功率 (donut) | 人体感应 | 「此刻状态」 | - | 3 | 峰值负载 | 基础负载 | 「功率趋势」（原配对保留） | - | 4 | 今日用电 (span 4) | | 11 条堆叠柱需要宽度 | - | 5 | 温湿度 (span 4) | | 温差+湿度两图并排 | +**改法：** WS `lovelace/config` 读、`lovelace/config/save` 写。勿改 `.storage/`。 +用 [`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 的 +`POST /core/api/config/config_entries/options/flow`。`scribe.yaml` 已是 `record_states: true`，新传感器不用改它。 +`sensor.quick_wen_cha` 在 `templates/quick_sensors.yaml`，`template.reload` 即可，不用重启 Core。 - **标题改名**：此刻耗电→**实时功率**（与峰值负载对仗）、环境→**温湿度** - （更具体）。删饼图卡内冗余标题 "各插座当前功率 (W)"。 - - **开关收窄**：马桶换气电源 tile 从独立 `columns: "full"`（48 列全宽）→ 移入 - 灯的 2 列嵌套网格第 5 格，与灯卡等宽（半行）。 - - **饼图高度**：`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: -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 条。 - 保存后实时功率圆环曾缩在卡片一角，卡片配置未改；拖动窗口触发重算后恢复。 +**回滚：** 计量改动前 +`.lovelace-backups/dashboard-quick-20260923-080213-pre-meter-plug.json` +（SHA-256 `a30b200350923633ddde0f2f071f2b75f0f37b347da4dd9a688da295dd8c8f35`）。 +布局和卡 JS：`dashboard-quick-20260921-pre-titles.json` + +`timescale-plotly-card.js.bak-20260921-pre-dayfix`。 +还原 JSON 用 WS save。改过卡 JS 要把资源 `?v=` 再 bump。 ### 地图仪表盘：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 编辑器自动切 - OSMF 矢量瓦片；届时可保留 custom 卡（继续 keyed CARTO）或用备份还原 - 内置卡。zone 编辑器等其余内置地图的水印在 2026.9 前无解。 +- **Follow-up:** Core 现为 2026.9.3（2026-09-23）。内置地图是否已切 OSMF + 矢量瓦片没有复查；本仪表盘仍用 keyed CARTO 的 `custom:map-card`。 ## 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` 改为 - `…_energy`；新增 `column_span: 2` 的「开关」区块（heading + tile - `switch.…` + `toggle` feature + 功率徽标）→ 视图 6→7 分区。 +- **Quick（已过时）：** 2026-09-13 曾把用电量图指到 `…_energy`，并单独加过开关分区。 + 现行 Quick 见上方。不要按本段把 Quick 改回去。 **口径警告**：`…_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； -如需彻底放弃估算电量 = 删除 config entry `01M2D53T188FW8WEC547ENHSVH`。 +回滚能源估算 = 把能源 prefs 的源 [8] 指回 `…_dian_li`。 +不要用 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 复核时已自动消失——建辅助元素后**不要**把这条 diff --git a/runbooks/home-assistant-maintenance.md b/runbooks/home-assistant-maintenance.md index 607e4cc..5db40a5 100644 --- a/runbooks/home-assistant-maintenance.md +++ b/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. diff --git a/runbooks/matter-packet-capture.md b/runbooks/matter-packet-capture.md index 003ae28..ba1ebd6 100644 --- a/runbooks/matter-packet-capture.md +++ b/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`.