diff --git a/docs/design/pre-m8-warmtelink-p1-poc.md b/docs/design/pre-m8-warmtelink-p1-poc.md index 114719f..4fc64c2 100644 --- a/docs/design/pre-m8-warmtelink-p1-poc.md +++ b/docs/design/pre-m8-warmtelink-p1-poc.md @@ -51,6 +51,36 @@ python -m scripts.p1_probe \ - 可只显示发生变化的字段,便于观察更新频率。 - 原始 telegram 默认只写到 `/tmp`;未经脱敏不提交到 Git。 +### 3.1 分两步 bring-up:Bash 冒烟验证 → Python probe + +Home Assistant Community 的一份 WarmteLink 实例提供了一个适合作为硬件 +bring-up 起点的[最小 Bash 读取方法](https://community.home-assistant.io/t/solved-dsmr-add-warmtelink-as-data-source/485255/2): +先把串口设为 115200 baud,逐行读取设备,并从带 `GJ` 的行中取出累计值。该帖展示的 +telegram 样例还给出了以下**候选事实**: + +- 设备头为 `/NWA-WARMTELINK`,版本字段为 `1-3:0.2.8(50)`。 +- M-Bus channel 1 的 device type 样例为 `004`。 +- 累计热量样例位于 `0-1:24.2.1()(*GJ)`。 +- telegram 以 `!` 加四位 CRC 结束。 + +这些是其他用户在 2022 年记录的单机样本,只用于提出假设,不能替代本机 firmware、线材和 +实际 telegram 的验证。当前 Home Assistant 的 +[DSMR 文档](https://www.home-assistant.io/integrations/dsmr/)确认其 DSMR 集成支持 DSMR v5 与 +M-Bus subdevice;该集成底层使用 +[`dsmr_parser`](https://github.com/ndokter/dsmr_parser)。实现 probe 时可把它作为候选解析基线 +进行对照,但是否引入为本项目正式依赖留到 M8 Planning 决定。 + +线到货后的执行顺序调整为: + +1. **Bash 冒烟验证**:用稳定的 `/dev/serial/by-id/...` 路径配置串口并短时读取;先保留完整 + 原始字节流,再确认是否能看到 `/NWA-WARMTELINK`、帧尾和带 `GJ` 的行。论坛脚本中的 + `GJ` 文本提取只能用作快速可见性检查,不能算解析或验收通过。 +2. **Python probe**:在已确认物理链路工作的前提下,实现上面的 `scripts.p1_probe`,完成 + 完整 framing、CRC、全部字段枚举、结构化解析、连续多帧变化观察和人工面板对照。 + +不复制论坛脚本的 MQTT 发布步骤:Pre-M8 仍只输出到终端和 `/tmp`,MQTT / Home Assistant +集成属于 M8 设计范围。 + ## 4. 人工对照 probe 运行期间,人工从热力表和相关水表面板记录同一时间附近的显示值,并与终端结果对照: