1.9 KiB
1.9 KiB
02-物模型标准设计
底层网关屏蔽了 JT808、MQTT、TCP Binary 等各种异构协议后，所有推入平台核心业务流的数据必须服从统一的「物模型（Thing Model）」规范。
一、物模型三要素 (IotThingModelTypeEnum)
根据系统的定义，任何设备的物模型结构被强制约束为三大类型：
1. PROPERTY(1) (属性)
- 描述：反映设备连续的运行状态数据（如温度、电量、当前档位）。
- 上报：对应网关的方法
DEVICE_PROPERTY_POST。 - 业务处理：存入实时库或影子库。属性的设定可通过场景规则触发（
DEVICE_PROPERTY_SET）。
2. SERVICE(2) (服务)
- 描述：平台主动下发给设备的指令，设备执行后需要响应结果（如开阀、设置重启参数）。
- 调用：对应
DEVICE_SERVICE_INVOKE。这更像一种双向 RPC 调用，通常会携带参数 (IotThingModelParamDirectionEnum)。
3. EVENT(3) (事件)
- 描述：设备主动上报的瞬时、非连续通知（如硬件故障、越界告警）。
- 上报：对应
DEVICE_EVENT_POST。 - 业务处理：通常直接送入规则引擎（
IotSceneRuleTriggerTypeEnum）作为触发源。
二、数据消费去向 (IotDataSinkTypeEnum)
物模型解析后的数据并非只是存在 MySQL 中，系统支持将数据分发到各种目标（Sink）供不同业务消费：
- 消息队列：
ROCKETMQ(30),RABBITMQ(31),KAFKA(32)—— 适合大数据量的数仓抽取。 - 高速缓存：
REDIS(21)—— 适合大屏实时展示和设备影子。 - 协议转发：
HTTP(1),TCP(2),WEBSOCKET(3),MQTT(10)—— 适合外部系统对接。 - 持久化：
DATABASE(20)—— 适合历史轨迹和报表查询。
开发新业务时，请通过配置 Sink 来订阅数据，不要在核心解析链路里直接写死 DB 插入代码。