物模型设计最佳实践：属性、功能与事件怎么划分
物模型（Thing Model）是对物理设备在云端的标准化描述。设计得当的物模型能显著降低接入与联动的复杂度，反之则会让后期维护苦不堪言。
三要素的职责边界
- 属性（Property）：设备的状态量，可读写。例如温度、开关状态、工作模式。判断标准：这个值「现在是什么」。
- 功能/服务（Service）：云端让设备执行的动作，有输入输出参数。例如「重启设备」「设置定时任务」。判断标准：让设备「做一件事」。
- 事件（Event）：设备主动上报的瞬时消息。例如「门磁被触发」「电量过低告警」。判断标准：设备「发生了一件事」。
一个实例：智能插座
| 要素 | 标识符 | 类型 | 说明 |
|---|---|---|---|
| 属性 | power | bool | 通断电状态 |
| 属性 | voltage | float | 当前电压 |
| 功能 | setTimer | 输入：秒数 | 设置倒计时断电 |
| 事件 | overload | 输出：功率 | 过载告警 |
常见误区
- 把事件建成属性：告警触发是瞬时的，用属性保存会让「已恢复」语义含糊；
- 属性粒度过粗：把所有状态塞进一个 JSON 字符串属性，规则引擎将无法直接引用；
- 标识符随意命名：标识符会出现在 Topic 报文与规则脚本中，建议统一小写下划线风格；
- 忽略数据类型与单位：数值型属性务必配置单位与取值范围，大屏和告警都依赖它。
小结
先写物模型，再写固件。把物模型当作设备与平台之间的「接口契约」对待，前后端、规则、大屏都围绕它展开，返工成本最低。