为什么告警不触发？根源在三要素错配
当门磁'开合'无法触发告警、摄像头抓拍指令反复超时、故障码上报却无告警生成------这些并非网络或硬件问题，而是物模型三要素被系统性错配的典型征兆。
门磁'开合'本质是设备主动发起的状态跃迁，应建模为事件 ；若误设为可写属性，平台仅支持轮询读取，无法订阅实时变更，告警引擎彻底失敏。摄像头抓拍是平台向设备发起的指令动作，必须定义为服务；若错配为只读属性或缺失输入参数的服务，调用必然失败。而将故障码通过属性字段上报，虽传递了数值，却丢失发生时间、位置、等级等关键上下文，使告警中心无法识别其业务含义。
这类问题的根源，在于混淆了'状态描述''主动上报'和'远程操作'三类行为的语义边界。物模型不是JSON Schema的语法容器，而是对设备能力的语义化抽象------错配即意味着数字世界对物理世界的理解发生了根本性偏差。
属性、事件、服务的本质区别是什么
要避免误用，必须回归三要素在平台逻辑中的本质定义：
-
属性（Property） 表征设备当前静态或缓变的状态快照，如温度值、开关状态。它支持读写，但不携带时间戳或业务上下文，平台按需拉取或下发，无触发机制。
-
事件（Event） 是设备主动上报的、具明确业务意义的状态跃迁信号，如'门被打开''设备离线'。它必含输出参数（如
timestamp、level），由设备单向推送，平台据此触发告警或规则。 -
服务（Service） 是平台向设备发起的指令动作，如'设置温度''启动抓拍'。它严格区分输入参数 （指令）与输出参数（结果），并支持同步/异步执行，对应真实设备接口契约。
在TSL中，三者分属独立模块：properties、events、services。字段不可混用，配置项不可复用------例如事件页的'事件等级'、服务页的'是否异步'，在属性页中根本不存在。这种结构隔离正是语义边界的底层保障。
三类高频误用场景的正确建模路径
针对高频误用场景，严格遵循平台规范的建模路径如下：
-
门磁'开合' ：在控制台「物模型」→「事件配置」页新建事件，标识符须与设备固件实际事件名完全一致（如
door_opened）；事件等级设为'警告'；输出参数明确定义timestamp、location等字段；禁止在属性页添加同名字段。 -
摄像头抓拍 ：在「服务配置」页新建服务，标识符匹配设备API接口名（如
capture_photo）；输入参数声明width、height、quality；输出参数定义image_url与capture_time；根据设备响应耗时勾选'是否异步'。 -
设备故障上报 ：必须使用「事件配置」。在
events模块中定义故障事件（如device_fault），输出参数至少含code、message、occurred_at；同时确保properties模块中删除或禁用所有同名故障码字段。
所有配置均需在JVS-IOT控制台「物模型」标签页下，分别进入对应子页面完成，不可跨页修改字段类型或复用配置项。
如何验证物模型配置是否真正生效
配置完成不等于生效。必须通过四步闭环验证确保建模与设备行为严格一致：
-
操作调试 ：在平台调试工具中分别模拟属性上报、事件触发和服务调用，同步观察日志中心是否捕获结构合规的数据流------属性应出现在
properties日志段，事件须进入events通道，服务调用需在services执行链中完整记录输入与返回。 -
告警校验 ：触发门磁事件后，检查告警中心是否生成对应记录，并确认通知内容包含事件定义的全部输出参数（如
timestamp、location），而非空值或默认占位符。 -
端到端执行 ：对抓拍服务，不仅验证平台返回成功状态，还需确认设备真实执行，并比对设备原始响应报文与平台解析后的JSON输出（如
image_url格式、capture_time精度）是否完全一致。 -
报文溯源 ：启用原始报文查看功能，逐字段比对设备发送payload与TSL解析结果，重点验证字段归属（是否误入
properties而非events）、数据类型（如时间戳是否被解析为字符串）、必填输出参数是否存在。
只有当这四步全部通过，物模型才真正成为设备能力的可信数字映射。