RuView v0.7.0 Home Assistant 集成解析：MQTT 自动发现、Matter 桥接与语义自动化原语实战-创锋一号

RuView v0.7.0 Home Assistant 集成解析：MQTT 自动发现、Matter 桥接与语义自动化原语实战

【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView

v0.7.0（feat 分支feat/adr-115-ha-mqtt-matter）是 RuView 正式打通家庭自动化生态的里程碑版本：通过 MQTT 自动发现（HA-DISCO）与 Matter 桥接（HA-FABRIC）两条互补路径，把 WiFi 人体感知能力（存在、心率、呼吸、跌倒、多房间迁移等）以"每节点 21 个实体"的形式接入 Home Assistant；其架构核心是服务端推理的 10 个语义自动化原语（HA-MIND），让--privacy-mode下心率/呼吸/姿态不越过网络边界、但推断出的高层状态照常发布，从而支撑医疗护理与辅助居住（AAL）场景。读完本文，你将掌握该版本的完整 CLI 参数矩阵、实体映射、隐私模式、精度基线、验证命令与已规划的后续迭代方向。

版本速览（TL;DR）

RuView 在 v0.7.0 中为 Home Assistant 提供一等公民（first-class）集成：

通过 MQTT 自动发现接入 HA，仅需一个--mqtt参数，HA 即为每个 RuView 节点自动创建21 个实体：11 个原始信号 + 10 个推断语义原语（someone-sleeping、possible-distress、room-active、elderly-inactivity-anomaly、meeting-in-progress、bathroom-occupied、fall-risk-elevated、bed-exit、no-movement、multi-room-transition）。
语义原语是架构的基石：它们在服务端运行，因此--privacy-mode会在线上剥离 HR/BR/pose 数值的同时，仍发布推断出的状态——这正是 RuView 可以部署到医疗护理与 AAL 场景的关键设计。
附带 8 个可直接导入的 HA Blueprint 与 3 套 Lovelace 看板、ESP32 硬件验证脚本、可自校验的 witness 包，以及每次 CI 运行约 2,560 条模糊断言、420 项库级测试。

版本链路：ADR-115（设计）· 追踪 issue #776 · 实现 PR #778。

端侧用户能看到什么新能力

Home Assistant 集成（HA-DISCO）

wifi-densepose-sensing-server新增--mqtt参数（受 Cargomqttfeature 门控）。
按"每节点 21 实体"自动发现——完整实体对照表见 docs/integrations/home-assistant.md。
支持 mTLS、可配置的逐实体发布速率、面向医疗/AAL 部署的--privacy-mode。
发布说明标注的配对测试基线为Home Assistant Core 2025.5与Mosquitto 2.0.18（操作指南中另记录了 Mosquitto add-on 6.4 的组合）。

Matter 桥接脚手架（HA-FABRIC）

新增--matter参数接通桥接管道：cluster 映射、endpoint 树、配对码（commissioning code）。
v0.7.0 为SDK 独立版本——真正的rs-matter集成按 ADR §9.10 推迟到 v0.7.1。
桥接设备树规格定义了 Apple Home / Google Home / Alexa / SmartThings 的暴露面。

语义自动化原语（HA-MIND）

把 RuView 从"RF 传感器"升级为"环境智能基础设施"的推理层：10 个 v1 原语，每个都带 warmup 门控 + 迟滞（hysteresis）+ 可解释性标签，逐原语的 precision/recall 发布在 docs/integrations/semantic-primitives-metrics.md。

8 个开箱即用的 HA Blueprint

可直接导入的 YAML 位于 examples/ha-blueprints/，覆盖：distress 通知、睡眠感知的走廊调光、晨起流程、老人不活动升级告警、会议室自动化、卫生间排风扇、跌倒风险升级、无活动自动布防。各文件与所用原语的对应关系见 examples/ha-blueprints/README.md，其中 5 个在--privacy-mode下安全可用。

3 套 Lovelace 看板

开箱即用视图位于 examples/lovelace/：单房间概览、多节点网格、医疗/AAL 护理视图（兼容 privacy-mode）。

从零接入：快速开始

前置条件

LAN 内运行中的MQTT broker——最简单的是 Home Assistant OS 中一键安装的 Mosquitto add-on；EMQX 与 VerneMQ 同样可用。
Home Assistant 2025.5 或更新版本，已启用 MQTT 集成并指向同一 broker。
RuViewwifi-densepose-sensing-serverv0.7.0+二进制（或从源码cargo run）。

启动发布端

# Docker（推荐非开发者使用）： docker run --rm --net=host \ ruvnet/wifi-densepose:0.7.0 \ --source esp32 \ --mqtt --mqtt-host 192.168.1.10 \ --mqtt-username homeassistant --mqtt-password-env MQTT_PASSWORD # 或从源码检出运行（Rust 1.78+）： MQTT_PASSWORD='your-broker-password' \ cargo run --release -p wifi-densepose-sensing-server \ --features mqtt -- \ --source esp32 --mqtt \ --mqtt-host 192.168.1.10 \ --mqtt-username homeassistant

启动后约 5 秒内，HA 应自动创建：每个 RuView 节点对应一台设备（以 MAC 或 zones 配置里的friendly_name命名），每台设备 17+ 个实体（存在、人数、心率、呼吸率、运动、跌倒事件、信号强度、分区 occupancy 以及 10 个语义原语）。若 Settings → Devices 中没有任何显示，参见操作指南中的排障章节。

优雅停止

Ctrl-C 时发布端会先向每个 availability topic 推送offline，使 HA 立即把所有实体标为不可用；kill -9则触发 MQTT LWT（遗嘱消息），约 30 秒内产生同样效果。

实体参考：每节点 21 个实体是如何构成的

下表名称即unique_idslug，HA 会自动分配友好名称。语义原语相关的实体命名可对照 examples/lovelace/01-single-room-overview.yaml 与 02-multi-node-grid.yaml 中的真实引用（如binary_sensor.ruview_bedroom_someone_sleeping）。

原始信号（11 个实体）

HA 实体	Slug	HA 组件	单位	源字段
Presence	`presence`	`binary_sensor`	—	`edge_vitals.presence`
Person count	`person_count`	`sensor`	persons	`edge_vitals.n_persons`
Heart rate	`heart_rate`	`sensor`	bpm	`edge_vitals.heartrate_bpm`
Breathing rate	`breathing_rate`	`sensor`	bpm	`edge_vitals.breathing_rate_bpm`
Motion level	`motion_level`	`sensor`	%	`edge_vitals.motion`× 100
Motion energy	`motion_energy`	`sensor`	（无量纲）	`edge_vitals.motion_energy`
Fall detected	`fall`	`event`	—	`edge_vitals.fall_detected`
Presence score	`presence_score`	`sensor`	%	`edge_vitals.presence_score`× 100
Signal strength	`rssi`	`sensor`	dBm	`edge_vitals.rssi`
Zone occupancy	`zone_occupancy`	`binary_sensor`	—	`sensing_update.zones`
Pose keypoints	`pose`	`sensor`（属性）	—	`pose_data.keypoints`（需`--mqtt-publish-pose`开启）

其中 heart rate、breathing rate、pose 属生物特征实体：设置--privacy-mode后它们会从 MQTT 中剥离（且永不通过 Matter 发布）。

语义自动化原语（10 个实体）

每个原语是运行在服务端的小型有限状态机（FSM），带显式的 warmup、迟滞与 refractory（冷却）窗口。逐原语精度/召回数据发布在 semantic-primitives-metrics.md。

HA 实体	Slug	HA 组件	触发条件
Someone sleeping	`someone_sleeping`	`binary_sensor`	presence + motion<5% + BR ∈ [8,20] bpm 持续 5 分钟
Possible distress	`possible_distress`	`binary_sensor`	HR > 1.5× 基线 + motion >20% + 无跌倒，持续 60 s
Room active	`room_active`	`binary_sensor`	30 秒滑动窗口内 motion >10%
Elderly inactivity anomaly	`elderly_inactivity_anomaly`	`binary_sensor`	静止时长 > 2× 观测到的最大静止基线
Meeting in progress	`meeting_in_progress`	`binary_sensor`	≥2 人 + 低幅运动持续 10 分钟
Bathroom occupied	`bathroom_occupied`	`binary_sensor`	presence + 命中标记为`bathroom`的活动分区
Fall risk elevated	`fall_risk_elevated`	`sensor`	0–100 分；跨越 ≥70 时触发事件
Bed exit (overnight)	`bed_exit`	`event`	sleeping → 在 22:00–06:00 之间离开床区
No movement (safety)	`no_movement`	`binary_sensor`	presence + motion <1% 持续 30 分钟
Multi-room transition	`multi_room_transition`	`event`	10 秒内离开 X 分区并进入 Y 分区

每次状态变更都会携带reason属性（例如["motion<5%", "br=12bpm", "presence=true"]），自动化模板可以直接引用它来解释触发原因。

从源码看，10 个原语由 semantic/bus.rs 中的SemanticBus统一持有（sleeping、distress、room_active、elderly_anomaly、meeting、bathroom、fall_risk、bed_exit、no_movement、multi_room十个 FSM 字段），tick()把每个RawSnapshot依注册顺序分发给全部原语，仅收集产生非Idle状态的SemanticEvent交给 MQTT/Matter 发布端，SemanticEvent携带kind、state、node_id与毫秒时间戳——这就是"新增一个原语只需改动一个文件"（ADR §3.12.6）的调用面设计。对应的原语单体实现各占一个模块，例如 src/semantic/sleeping.rs、src/semantic/distress.rs 等。

Matter 设备类型映射

按 ADR-115 §3.11.1，Matter 桥接把标准 cluster 可表达的子集暴露给 Apple Home / Google Home / Alexa / SmartThings；生物特征与 pose 仅走 MQTT——因为 Matter 至今没有 HR / BR / pose 关键点对应的 cluster。

RuView	Matter cluster	Matter endpoint 设备类型
Presence	`OccupancySensing`(0x0406)	`OccupancySensor`(0x0107)
Motion（>10%）	（同一 endpoint，OccupancySensing 的属性）	（同上）
Fall event	`Switch.MultiPressComplete`事件	`GenericSwitch`(0x000F)
Person count	厂商扩展属性 (0xFFF1_0001)	（同 OccupancySensor endpoint）
逐分区 occupancy	每个 zone 一个`OccupancySensor`endpoint	逐分区
Sleeping / room-active / bathroom 等	`OccupancySensing`（每个原语一个 endpoint）	逐原语
Fall-risk-elevated 事件	`Switch.MultiPressComplete`事件	`GenericSwitch`
HR / BR / pose	不暴露——仅 MQTT	—

运维视角：CLI 参数全矩阵

Flag	默认值	用途
`--mqtt`	off	启用 HA-DISCO 发布端
`--mqtt-host <HOST>`	`localhost`	Broker 主机
`--mqtt-port <PORT>`	1883（启用 TLS 时 8883）	Broker 端口
`--mqtt-username <U>`	—	Broker 认证用户名
`--mqtt-password-env <VAR>`	`MQTT_PASSWORD`	持有密码的环境变量
`--mqtt-client-id <ID>`	`wifi-densepose-<hostname>`	MQTT client ID
`--mqtt-prefix <PREFIX>`	`homeassistant`	发现主题前缀
`--mqtt-tls`	off	加密连接
`--mqtt-ca-file <PATH>`	—	TLS / mTLS 的固定 CA
`--mqtt-client-cert <PATH>`	—	mTLS 客户端证书
`--mqtt-client-key <PATH>`	—	mTLS 客户端私钥
`--mqtt-refresh-secs <N>`	600	发现消息重发间隔
`--mqtt-rate-vitals <HZ>`	0.2	HR / BR 发布速率（Hz）
`--mqtt-rate-motion <HZ>`	1.0	运动发布速率（Hz）
`--mqtt-rate-count <HZ>`	1.0	人数发布速率（Hz）
`--mqtt-rate-rssi <HZ>`	0.1	RSSI 发布速率（Hz）
`--mqtt-publish-pose`	off	开启姿态关键点发布
`--mqtt-rate-pose <HZ>`	1.0	开启后的姿态发布速率（Hz）
`--privacy-mode`	off	在 MQTT 与 Matter 上剥离 HR/BR/pose
`--matter`	off	启用 HA-FABRIC Matter 桥
`--matter-setup-file <PATH>`	—	写入 QR 码与配对码的文件
`--matter-reset`	off	清除 fabric 凭据并重新配对
`--matter-vendor-id <VID>`	`0xFFF1`（开发用）	CSA 分配的厂商 ID
`--matter-product-id <PID>`	`0x8001`	产品 ID
`--semantic`	on	启用推理层
`--semantic-thresholds-file <PATH>`	—	逐原语阈值覆盖
`--semantic-zones-file <PATH>`	—	分区标签映射（bathroom、bedroom…）
`--no-semantic <PRIMITIVE>`	—	禁用某个原语（可重复）

完整 CLI 矩阵见 docs/integrations/home-assistant.md#configuration。源码侧，这些参数在 mqtt/config.rs 的MqttConfig::from_args()中被组装为MqttConfig：包含 host/port/用户名/密码、TlsConfig（Off/SystemTrust/PinnedCa/MutualTls四态）、逐实体PublishRates、publish_pose与privacy_mode。值得注意的实现细节：

端口默认值逻辑是mqtt_port.unwrap_or(if mqtt_tls { 8883 } else { 1883 })，与表格一致；
密码只从--mqtt-password-env指定的环境变量读取（源码通过std::env::var解析），确保密钥不出现在命令行与 shell 历史中；
validate()在建立任何网络连接前做预检（空 host、0 端口、refresh 为 0、非法速率都会立即报错），让用户得到清晰错误而非 30 秒后的连接失败。

分区标签文件格式（`--semantic-zones-file`）

# semantic-zones.yaml zones: bathroom: ["zone_3", "zone_7"] bedroom: ["zone_1"] kitchen: ["zone_2"] living: ["zone_5"] bed_zones: ["zone_1"]

阈值覆盖（`--semantic-thresholds-file`）

# semantic-thresholds.yaml sleep_dwell_secs: 300 distress_hr_multiple: 1.5 room_active_motion_threshold: 0.10 elderly_anomaly_multiple: 2.0 meeting_min_persons: 2 no_movement_dwell_secs: 1800 fall_risk_event_threshold: 70.0

阈值实现位于PrimitiveConfig（Rust，见 src/semantic/common.rs），默认取值偏向保守（宁精勿滥）以避免面向用户的自动化被噪声刷屏；若用于研究/演示场景可下调，医疗或商用部署建议保持默认或上调。

隐私模式：医疗与 AAL 部署的正确姿势

在医疗、AAL（居家养老）或商用场景部署时请设置--privacy-mode。它会：

从每一条外发 MQTT 发布中剥离心率、呼吸率与姿态关键点；
对这些实体整体抑制发现——HA 甚至看不到它们存在；
保持全部语义原语可用。sleeping / distress / room-active 等都是服务端推断出的状态，跨线传输的只有布尔值或分数。这正是让该平台可用于受监管场景的架构红利。

非 localhost broker 上务必把--privacy-mode与--mqtt-tls配对使用。

源码侧，这一契约实现在 mqtt/privacy.rs：decide(EntityKind, privacy_mode)对每个外发实体给出Publish/Suppress判定，且发现层与状态层共用同一过滤器——若某实体被剥离，它在每一层都被剥离，防止控制器从"状态缺失"反推实体的存在。单测覆盖了"privacy off 全发布""privacy on 仅抑制生物特征""privacy on 保留非生物信号"三组行为。

从 ADR-115 §6 的视角，privacy-mode 对应的合规论证为：HIPAA 式"最低必要"（生物数值不离开设备）、GDPR"目的限制"（推断状态是支撑自动化所需的最小数据集）、CCPA"敏感个人信息"（无线健康数据）。fall-risk-elevated / possible-distress / someone-sleeping 等标志照常工作，因为它们在传感器管道内部计算，只发布布尔输出。

语义原语质量基线（v1）

语义原语精度/召回文档给出的 v1 基线（2026-05-23，对 ADR-079 配对采集集留出 1,077 样本子集 + 合成压力场景计算）：

原语	Precision	Recall	F1	触发延迟	说明
`someone_sleeping`	0.92	0.78	0.84	5 min	recall 受限于留出子集中的 BR 检测（n_visible=14.3/17）
`possible_distress`	0.71	0.62	0.66	60 s	EWMA 基线需约 10 分钟静息 HR 种子；冷启动首会话性能下降
`room_active`	0.96	0.94	0.95	30 s	最简单的原语，已近上限
`elderly_inactivity_anomaly`	0.85	0.61	0.71	不定	30 分钟基线地板抑制误报
`meeting_in_progress`	0.88	0.81	0.84	10 min	依赖准确的`n_persons`（上游 ADR-103 cog-person-count）
`bathroom_occupied`	0.99	0.97	0.98	<1 s	分区派生，标签正确后近完美
`fall_risk_elevated`	0.74	0.55	0.63	不定	v1 用运动方差代理，v2 换步态不稳评分
`bed_exit`	0.94	0.89	0.91	<1 s	边沿触发
`no_movement`	0.91	0.93	0.92	30 min	定义上就长；recall 受运动地板噪声限制
`multi_room_transition`	0.86	0.78	0.82	<1 s	依赖准确的分区标签

测试集由三部分构成：Rust 单测中的合成压力场景（位于v2/crates/wifi-densepose-sensing-server/src/semantic/*/tests.rs）、1,077 样本的相机配对留出子集（cognitum-v0，2026-04 采集）、以及semantic_events.jsonl现场采样日志。复现方式：单元级用cargo test -p wifi-densepose-sensing-server --no-default-features semantic::，回放评测用--source replay --metrics-out（该路径在 P6 落地）。文档同时给出 open-set 提醒：这些是单房间相机监督留出集的上界，跨环境域漂移（ADR-027 MERIDIAN）、多人同时在场、宠物/电子设备遮挡都可能导致真实部署 F1 降低 5–15 个百分点。

三大操作范式：Blueprint 与 Lovelace 组合

把 YAML 文件放入<HA config>/blueprints/automation/ruvnet/后，从 HA UI（Settings → Automations → Blueprints → Import）导入即可。以下为第一个示例"possible distress 推送通知"的完整内容（其余 7 个见 examples/ha-blueprints/）：

blueprint: name: RuView — notify on possible distress description: > Send a push notification when RuView detects sustained elevated heart rate + agitated motion (possible distress). domain: automation input: distress_entity: name: Possible distress entity selector: { entity: { domain: binary_sensor } } notify_target: name: Notify target (e.g. notify.mobile_app_pixel) selector: { text: {} } trigger: - platform: state entity_id: !input distress_entity to: "on" action: - service: !input notify_target data: title: "Possible distress detected" message: > RuView flagged sustained elevated heart rate + agitated motion. Reason: {{ state_attr(trigger.entity_id, 'reason') }}.

这里的reason属性正是 HA-MIND 可解释性标签的落地用法。其余常用模式还包括：基于someone_sleeping的走廊 10% 亮度睡眠调光、基于bed_exit（05:00–09:00 窗口）的 10 分钟缓亮 + 咖啡机 + 撤防晨起流程等，完整 YAML 与 privacy 兼容性对照见 examples/ha-blueprints/README.md。

开发视角：Cargo features、模块布局与测试

Feature 门控

在 v2/crates/wifi-densepose-sensing-server/Cargo.toml 中：

mqtt = ["dep:rumqttc"]——引入rumqttc-v4-next 0.34（关闭默认特性、启用use-rustls-ring，避免 Windows 上的 openssl 依赖）。该 feature 关闭时--mqtt-*参数仍可解析，但启用--mqtt会打 WARN 且发布端为空操作。
matter = []——仅脚手架，不引入任何 SDK，符合"v0.7.1 再接入rs-matter"的规划。
默认特性为空，使默认二进制保持精简。

新模块

mqtt::{config, discovery, privacy, publisher, security, state}——配置组装、HA 发现消息、隐私过滤、rumqttc 发布循环、线界安全不变量、实体状态编码。
semantic::{bus, common, sleeping, distress, room_active, elderly_anomaly, meeting, bathroom, fall_risk, bed_exit, no_movement, multi_room}——事件总线 + 10 个原语 FSM（外加record现场日志）。
matter::{clusters, bridge, commissioning}——cluster 映射、endpoint 树、配对码。
benches/mqtt_throughput.rs承载热路径基准；tests/mqtt_integration.rs对真实 Mosquitto 做端到端集成测试；examples/mqtt_publisher.rs提供独立发布示例。

测试规模

420 项库级单测全部通过，其中 10 个proptest用例对线界与语义分发做模糊测试（每次 CI 约 2,560 条模糊断言）。
3 个集成测试在 CI（mqtt-integration.yml，仓库 GitHub Actions 工作流）中对真实 Mosquitto 运行。
6 个 criterion 基准，见 docs/integrations/benchmarks.md。
ESP32 验证脚本scripts/validate-esp32-mqtt.sh可对实际挂接硬件做端到端冒烟验证。
witness 包生成器scripts/witness-adr-115.sh产出可自校验的 tarball。

安全审计要点

v0.7.0 在mqtt::security模块（见 src/mqtt/security.rs）落地了完整的线界审计：

Topic 段安全：拒绝 MQTT 通配符+/#、NUL 与/（分段不得内嵌分隔符），防止上游恶意负载注入订阅通配符——topic_segment_is_safe是纯函数，同时被单测与真实 broker 集成测试覆盖。
TLS 路径安全：拒绝含 NUL / 换行的路径（path_is_safe）。
32 KB 负载上限：MAX_PUBLISH_BYTES = 32 * 1024，远低于多数 broker 的 256 KB 默认上限，超限发布会打 WARN 供运维排查。
凭据卫生金丝雀：拒绝通过命令行直传的--mqtt-password（避免进入ps输出、shell 历史与 supervisor 的 argv 记录），只接受--mqtt-password-env。
RUVIEW_MQTT_STRICT_TLS=1：把"非 localhost broker 明文 MQTT"从 WARN 提升为致命错误，这是 v0.8.0 的默认行为升级路径（v0.7.0 目前为告警后继续运行）。
线界安全模块内含5 个基于 property 的 fuzz 用例，覆盖随机 Unicode 与在任意偏移注入通配符/NUL。
--privacy-mode在每一层强制：发现抑制 + 状态剥离 + Matter cluster 门控三管齐下（对应 src/mqtt/privacy.rs 的单过滤器复用设计）。

热路径基准（笔记本 release 构建）

热路径	实测	目标	超出
`state::event_fall`编码	259 ns	<2 µs	7.7×
`rate_limiter::allow_first`	49.7 ns	<100 ns	2×
`rate_limiter::allow_within_gap`	62.1 ns	<100 ns	1.6×
`privacy::decide_hr_strip`	0.24 ns	<50 ns	208×
`privacy::decide_presence_keep`	0.24 ns	<50 ns	208×
`semantic::bus_tick_all_10_primitives`	717 ns	<10 µs	14×

每项目标至少超出 1.6×，多项超过 100×。含义（摘自 benchmarks.md）：以每节点 1 Hz 发布速率计，ADR-115 全热路径（限速判定 + 隐私过滤 + 10 原语语义推理 + 状态序列化）在商用硬件上约花费每节点每 tick 1 µs——一台托管 100 个 RuView 节点的 Cognitum Seed 设备在 MQTT 路径上每秒只消耗约 100 µs CPU（0.01% 的负载地板）；10 原语 × 100 节点的 FSM 常驻内存约 30 KB。复现：cargo bench -p wifi-densepose-sensing-server --features mqtt --bench mqtt_throughput，或RUVIEW_RUN_BENCH=1 bash scripts/witness-adr-115.sh将结果封入 witness 包。注意这些数值来自单台笔记本，Pi 5 上的每操作延迟预计慢 3–5×，但速率预算（1 µs vs 100 ms tick 间隔）仍留有充足余量。

完整复现链路（Reproducibility）

git checkout v0.7.0 cd v2 cargo test -p wifi-densepose-sensing-server --no-default-features --lib # 420 passed cargo test -p wifi-densepose-sensing-server --features mqtt --no-default-features --lib # 同样 420 passed RUVIEW_RUN_INTEGRATION=1 cargo test -p wifi-densepose-sensing-server \ --features mqtt --no-default-features --test mqtt_integration -- --test-threads=1 cargo bench -p wifi-densepose-sensing-server --features mqtt --bench mqtt_throughput cd .. bash scripts/witness-adr-115.sh cd dist/witness-bundle-ADR115-*/ && bash VERIFY.sh # 输出 "ADR-115 witness bundle: VERIFIED ✓"

规划中：推迟到 v0.7.1 与 v0.8.0 的内容

推迟到 v0.7.1：

P8b——真正的rs-matterSDK 接线（对已锁定的 cluster/bridge/commissioning 契约执行 BIND/READ/INVOKE）；
P9b——多控制器验证，把同一座桥同时配对进 Apple Home + Google Home + HA Matter；
CSA Matter 认证决策门——开发 VID0xFFF1适合个人/仅 HA 使用，商用部署需申请正式厂商 ID。

推迟到 v0.8.0：

非 localhost broker 上的明文 MQTT 由 WARN 升级为 hard-fail（RUVIEW_MQTT_STRICT_TLS=1已先行落地）；
HACS 原生 Python 集成，作为不依赖 MQTT broker 的替代方案（ADR §6.A）。

企业官网建设流程全解析