设备接入阿里云IoT平台后，数据不会自动出现在某个现成的页面里。平台负责接收和管理设备上报，数据最终去哪里，由你在规则引擎里决定。取数的关键是先配好转发路径，再让业务系统从目的地读取。
数据从规则引擎转出
规则引擎用 SQL 风格的语句筛选字段、转换格式，再把结果转发到目标。常见目标有三类：
- 消息队列：后端服务订阅队列，逐条消费。设备多、数据集中到达时，下游可以按自己的速度处理，不会被直接压垮。
- 数据库：用于历史查询和报表。表结构要和物模型字段一一对应。物模型里改了字段名，入库规则也要同步改，否则新数据会悄悄少掉字段。
- 函数计算：适合做轻量处理，比如换算单位、判断阈值。函数要记录日志并处理失败重试，否则出错后很难追查。
规则配完后，先用一台测试设备上报一条数据，在目标库或队列里查到这条记录，再批量接入。很多人只看到规则保存成功，就以为数据已经打通了。
核心能力
- 设备接入：支持 MQTT、CoAP、HTTP(S)，设备可以用 Wi-Fi、蜂窝网络或 LoRa 连接。
- 物模型：用属性、服务和事件描述设备能力，例如温度、开关状态、告警上报。同类设备即使来自不同厂商，也能用同一套数据格式管理。
- 设备影子：设备离线时，云端保存最新的期望状态，设备重新上线后自动同步，指令不会丢。
- 规则引擎：筛选、转换设备数据，并转发到消息队列、数据库或函数计算服务。
- OTA 升级：支持批量推送固件，可以按设备分组灰度发布，并查看每台设备的升级进度。
接入流程
- 创建产品：在控制台定义产品名称、节点类型和通信协议，并编写物模型文件。后面所有数据字段都以物模型为准，这一步先定稳。
- 注册设备：为每台设备生成唯一的三元组（ProductKey、DeviceName、DeviceSecret）。设备数量多时，可以用一型一密或动态注册批量发放。
- 设备端开发：使用官方提供的 C、Java、Python 等 SDK，或直接按 MQTT 协议连接平台并上报数据。
- 配置规则：设置数据流转规则，把数据送到业务系统或数据分析服务。
- 联调与上线：先用少量设备验证数据格式和告警逻辑，确认无误后再批量接入。
案例：冷链温控监测
以下是示意场景，具体数量和参数以实际项目为准。某区域配送企业在 300 辆冷藏车上安装温度、湿度和车门传感器，车载网关通过 4G 连接阿里云IoT平台。
- 数据上报：网关每 30 秒上报一次温度和湿度，车门开关时立即上报事件。
- 告警数据：温度高于 8℃ 并持续 5 分钟，规则引擎触发告警，消息转发到企业微信群和运维人员的短信。告警类数据适合直接推送给人看。
- 历史数据：温湿度记录写入数据库，供轨迹回放和报表使用。只算温度一项，每 30 秒一条，一天约 2880 条，300 辆车合计约 86 万条。目标库的容量和保留时长要提前估算。
- 离线补报：车辆进入地下车库时网络中断，网关本地缓存数据，恢复连接后补报，保证轨迹和温度记录完整。补报数据应按设备上报的时间入库。如果按到达时间记录，恢复连接那一刻会集中出现大量数据，曲线会失真。
- 远程升级：网关固件有问题时，平台先向 10 台车推送新版本，观察两天无异常后再全量升级。
上线三个月后，该企业的温控异常处理时间从平均几小时缩短到十几分钟。这个结果来自企业内部的运营统计，不同项目的效果会有差异。
选型与注意事项
- 协议选择：资源受限的设备优先用 MQTT，数据量小，连接开销低。
- 费用评估：计费通常与消息量、设备数和数据存储相关。接入前按实际上报频率算出每天的消息条数，再估算月度用量。以上面的冷链场景为例，光温度一项每天就约 86 万条。
- 安全配置：设备密钥不要写进公开代码仓库，并定期轮换。使用一型一密或设备证书，避免同一密钥被多台设备共用，一台设备泄露时不会影响整批设备。
- 数据规划：上报频率过高会增加成本和存储压力。先确定哪些数据需要实时处理，哪些可以批量上传。
