接收设备事件

开发者应用下的设备会产生动检报警、上下线、各类智能事件等消息。对接方式有两类：配置平台消息推送（平台 POST 到开发者回调地址），以及订阅消息通道（开发者按消费组拉取）。后台收到事件后，可以再推送到自有 App 或业务系统。

历史告警的查询和删除见查询与管理历史告警。报警图片地址与解密见获取与解密告警图片。收不到、重复、延迟等排查见排障：收不到推送、重复、延迟。

服务端与客户端

上述两种方案都由开发者后台完成。推送模式下，后台在回调地址接收 POST 后再转发给终端 App，步骤见配置平台消息推送。文档未单独写「手机 App 直连平台收事件」的步骤；终端侧通常经开发者自有后台间接获取。

拉取模式通过 HTTP 接口与消息通道消费组完成，见订阅消息通道。拉取侧配置的是消费组与 订阅位（subscribeFlag 位图等，见 pull 页），与推送回调里的 callbackFlag 不是同一项。报文类型定义见事件消息类型定义与事件消息格式定义。

推送还是拉取

下表用于对比两种投递方式（与历史「事件消息对接」说明一致）。

对比维度	平台主动推送（推送模式）	消息通道订阅（拉取模式）
消息实时性	高，近乎实时。平台一旦产生消息，会立即主动发送给开发者。	较低，存在延迟。消息临时存储在通道中，等待开发者下次拉取。拉取间隔直接影响实时性，文档建议间隔需在 30 秒以内。
服务端资源消耗	较高，有峰值风险。平台需处理大量并发推送，开发者服务器也需应对突发的高流量推送。	可控，较低。开发者按间隔轮询 `pullMessages`，服务器压力平稳；需遵守消费组与偏移量约束（见拉取模式）。
开发与运维复杂度	较低。开发者只需提供一个标准的 Webhook 回调地址来接收 POST 请求，实现一个消息处理接口即可，无需关心消息存储和状态管理。	中等。需实现拉取逻辑、管理消费者实例和偏移量，并处理状态管理。例如：每个消费组最多 3 个消费者，需自行管理其生命周期；需正确处理偏移量，避免消息重复或丢失。
可靠性	依赖开发者服务。若开发者服务宕机或网络故障，消息可能推送失败。	高。消息在通道中保留 2 天，给开发者充足的时间来处理故障和恢复消费，不易丢失。
安全性	需额外加固。开发者需暴露一个公网可访问的 URL。	较高。开发者主动发起连接，无需向平台暴露内部服务入口，减少了攻击面。
适用场景	适用于对实时性要求极高的场景，如安全告警、紧急事件通知、交易状态变更等，需要秒级触达。	适用于对实时性要求不高、消息量大且平稳、或开发者服务能力有限的场景。例如，批量处理设备上报的每日统计数据。

上表拉取模式一行已按 HTTP 轮询表述；「每个消费组最多 3 个消费者」等细节以教程为准。消费组固定为 group1 / group2 / group3，同一 appId + group 同时只允许一个拉取或提交，并建议单实例、单线程。见消息通道订阅（拉取模式）。

方案选型建议

业务要求消息被立即处理（例如人员倒地、区域人数超限等需秒级响应），希望只做一个消息接收接口、不处理拉取和偏移量，并且服务器能应对推送流量高峰时，优先选择平台主动推送。
可以容忍秒级甚至分钟级延迟，希望服务短暂故障、重启后仍能拉到积压消息，希望按需拉取、避免被突发流量冲垮，或不想对外开放服务接口时，优先选择消息通道订阅。
同时有实时告警和批量数据处理时，可以把两种方案一起用：用平台主动推送接收关键告警，用消息通道订阅定时拉取非关键事件。

拉取权限需要另行申请，见订阅消息通道。

本主题任务

任务	说明与入口
配置平台消息推送	设置回调地址并接收推送；验签与重试策略见推送配置页与排障
订阅消息通道	申请、消费组、偏移量、积压保留
查询与管理历史告警	查询、按 id 查详情、删除、关键词搜索、统计报表、准确性反馈
获取与解密告警图片	从告警/消息中取图 URL，按指南解密或转存