小米米家 · 物模型与孪生：设备状态与家庭场景
技术栈：小米 MIoT-Spec 物模型 + 设备影子 + 家庭/房间/场景模型（以小米米家 / MiOT 为案例） 适用场景：千奇百怪的硬件如何抽象成统一数据，App 怎么自动生成面板
米家设备连上了、消息也会流了。但 App 怎么知道「灯现在是开着还是关着」？用户说「打开客厅灯」，系统怎么知道客厅灯是哪一台？
答案就是 MIoT-Spec（小米 IoT 设备协议规范）——一套用 property / event / action 三元组描述任意设备的统一语言。如果说第二篇解决了「进得来」、第三篇解决了「流得动」，本篇解决的就是「看得懂」。
1.问题背景：为什么需要「设备描述语言」
米家接入了上千款不同厂商的设备。如果没有统一描述语言：App 团队要为每款设备单独写 UI，接入周期从「周」退化成「月」；小爱同学无法自动语控新设备；规则引擎写不了跨品类联动（「任何检测到烟雾的设备触发所有报警器」）。
2.设计理念：MIoT-Spec 三元组
MIoT-Spec 把任意设备描述为三个维度：
| 维度 | 含义 | 示例 |
|---|---|---|
| property（属性） | 可读/可写的设备状态 | 开关（bool）、亮度（int 1-100）、温度（float） |
| event（事件） | 设备主动上报的瞬时通知 | 门开了、烟雾检测到、按键被按下 |
| action（行为） | 可被调用的设备能力 | 重启、校准、升级固件 |
弱网下设备离线是常态。设备影子在云端维护一份期望状态副本：desired（云端期望）和 reported（设备实际）。设备上线后自动对账差异并下发。用户 App 始终读影子而非直连设备——灯离线时 App 显示的仍是上一次 reported 的值，而不是"设备不在线"——这对用户体验至关重要。
App 里看到的是「客厅」「卧室」这样的空间，而非一串设备 ID。这层映射靠「家庭 → 房间 → 设备」三层模型完成——物模型只管设备自身，空间模型管组织。这种"人以空间为单位管理设备"的抽象，正是消费级 IoT 区别于工业的核心差异之一。
MIoT-Spec 还有一个关键特性：品类标准化。同一品类（如智能灯）的设备，无论来自哪家厂商，其核心 property/event/action 是统一的。这意味着换一个品牌的灯，用户场景和语音指令无需重新配置。
3.实际应用：从面板到语音的全链路
MIoT-Spec 定义了设备有哪些属性、事件、行为，米家 App 据此自动渲染控制面板——开关变 toggle、亮度变 slider、温度变仪表盘。新设备接入后，App 不需要发版就能显示正确 UI。
小爱同学无需额外配置即可将口语映射到对应操作：「打开客厅灯」→ 查找客厅下品类为 light 的设备 → 写 property: power = on。
规则引擎不看具体设备型号，只看物模型中是否有 smoke_detected 事件和 alarm 行为——让「任何检测到烟雾的设备触发所有报警器」成为可能。
举个例子：米家生态里有 A 厂的烟感和 B 厂的烟感，物理形态不同但 MIoT-Spec 里都定义了 event: smoke_detected。用户设置「任何烟感报警 → 所有灯闪烁 + 小爱播报」这条规则时，不需要关心具体是哪家的烟感——物模型把差异吞掉了。
小爱同学自动语控也是靠这套模型：物模型中的 property 和 action 自带语义标签（如"开关""亮度""温度"），小爱无需额外配置即可将口语映射到对应操作。新设备接入 MIoT-Spec 后，小爱当天就能语控它——这就是"模型驱动"和"逐个适配"的本质区别。
4.注意事项
- 物模型要预留扩展性：不要把所有变量塞进一个 property 列表，应按物理/业务语义分 service 分组，方便未来新增。
- 影子对账有延迟容忍：desired 和 reported 的差异对账是最终一致，不是强实时。依赖实时一致性的场景应走本地联动（第二篇）。
- MIoT-Spec 版本管理：物模型变更要向后兼容，否则老固件的设备在新版 App 上会显示异常。
5.小结
MIoT-Spec 是米家生态的「普通话」——用一套统一词汇表让 App、小爱、规则引擎、设备厂商用同一种语言沟通。它的核心价值在于：把硬件差异吞进模型里，让上层应用只面对标准化语义。
下一篇（五），我们看设备卖出去之后怎么办——OTA 如何批量升级固件、运营如何盯住十亿台设备。