发布动态 MQTT 测试数据
把实时传感器快照 Recipe 插入每 5 秒执行一次的定时消息，再通过 Trace 的 SEND 与 RECV 记录验证持续变化的 JSON。
- 作者:
- Mqttable
- 更新:
本页目录12 个章节
加载中...
/docs/engineer/payload-templates
把实时传感器快照 Recipe 插入每 5 秒执行一次的定时消息，再通过 Trace 的 SEND 与 RECV 记录验证持续变化的 JSON。
加载中...
Payload Template 可以持续生成符合业务结构的动态 MQTT 测试数据，而不必手动修改每一条消息。本文将带你创建一条每 5 秒执行的定时消息，插入实时传感器快照 Recipe，并通过 Trace 的 SEND 与 RECV 记录确认数据已经成功发送和接收。
打开连接，选择隔离测试 Broker。本文截图使用：
Docs Template Demomqtt127.0.0.12883template-publishermqttable-docs-template-publisherMqttable 只连接这个 listener，不会启动 Broker。如果还没有已连接 Client，先完成 MQTT 快速入门或 Broker 与连接参数，看到这个 Client 显示已连接后再回来。如果 Broker 报告 Client ID 已占用，应停止旧教程连接，或由你自行修改后缀；本页使用的 Client ID 不是 Mqttable 自动生成的。
从已连接 Client 行开始；两个空列分别是接收证据与发送任务的入口。
本教程不要使用生产 listener、共享客户 Topic、真实设备标识或敏感 Payload。
在 mqttable-docs-template-publisher 行选择添加订阅，填写：
mqttable/docs/template-series不接收本地消息必须保持关闭：这样当前 Client 才能接收自己发布的消息。开启它会移除本教程的第二层 Broker 投递证据。
先建立 Subscription，之后每次动态发布才会有独立的 RECV 结果。
选择确认。只有 Client 行出现 Subscription Pill 后才继续。
Topic Pill 证明 Subscription 已保存；下一步之前，定时消息列仍然为空。
在同一 Client 行选择添加消息。在新建定时消息中填写：
mqttable/docs/template-series5 秒5 秒是当前表单默认值，便于观察，同时不会制造不必要的高频流量。第一次发布会在完整等待一个 Interval 后发生。
先设置固定目标和发送频率，再加入动态字段。
选择模板，打开配方，找到实时传感器快照。这份 Recipe 会插入一份完整 JSON，不必逐字段拼装测试 Payload。
Recipe 是可编辑的数据 Contract 起点，不是不可见的已保存模板对象。
插入后，左侧是 Liquid-compatible Source；右侧是使用当前 Client、Topic、已启用 Broker Variable 与内置动态 Helper 完成的一次渲染。
Source 定义数据 Contract；实时预览证明当前 Source 可以生成一份有效 JSON 样本。
核心 Source 是：
{
"ts": {{ now_ms }},
"device": "{{ "motor" | device_id }}",
"bearing_temp": {{ "bearing" | temperature }},
"rpm": {{ 1200 | rpm: 1800 }},
"quality_good": {{ 0.98 | quality_good }}
}
Preview 不能证明之后实际发送的字节。每次 Preview 和每个定时 Tick 都可能生成不同值；真正的发布证据来自 Trace。
关闭模板助手，为 Source、Preview 与最终投递设置留出空间。保存前逐项确认：
mqttable-docs-template-publishermqttable/docs/template-series
创建一个没有内置消息数或结束时间的 Schedule 前，先做最终投递检查。
选择创建定时消息。新 Pill 只能证明配置已保存并同步，还不能证明消息已被 Broker 投递。
测试的两部分已经同时激活：一个 Schedule 发布，一个 Subscription 接收。
等待约 15 秒，收集至少三次 5 秒渲染；然后删除定时消息，把 Trace 证据固定下来再开始比较。完成 RECV 检查前保留 Subscription。
在 Topic Filter 中输入 mqttable/docs/template-series。在 Grid 中比较至少两条 Route 为 SEND 的 PUBLISH。
过滤后的消息序列证明同一个已保存 Schedule 持续渲染出新的 JSON。
成功的 SEND 序列应同时满足：
PUBLISH；mqttable/docs/template-series；1，Retain 为否；ts、motor_… 设备后缀和多项读数发生变化。选择匹配的 Route 为 RECV 的 PUBLISH，打开详情。SEND 证明 Mqttable 调用了 Publish；RECV 证明 Broker 把消息投递给前面创建的 Subscription。
接收消息详情是第二层证据；仅保存 Schedule 不能证明 Broker 已投递。
不能把 Preview、Scheduled Message Pill 或单独一条 SEND 当成完整结果。只有变化的 SEND 序列与匹配的 RECV 证据同时存在，才算成功。
值 | 提供者 | 预期行为 |
|---|---|---|
Broker、Client ID、Topic | 你或本教程 | 保持固定，让全部结果都属于获准测试边界。 |
Interval、QoS、Retain | 你 | 除非主动编辑 Schedule，否则保持固定。 |
| now_ms Helper | 每次渲染都变成当前 Unix 毫秒时间。 |
| device_id Helper | 保留 motor_ 前缀，同时生成新后缀。 |
读数与质量 | Profile、Range 与概率 Helper | 在 Recipe 声明的范围内变化。 |
只有其它 Recipe 的 JSON Contract 与 Consumer 匹配时才应切换。用数据插入一个字段，用转换修改已有值，用语法添加受支持的 Liquid Control Flow。已启用 Broker Variable 可以加入少量非敏感环境值；它们是 Template Context，不是 Credential Store。
只删除本教程创建的两个对象：
mqttable-docs-template-publisher 上 Topic 为 mqttable/docs/template-series、5 秒、QoS 1 的定时消息。经过 15 秒证据窗口后，定时消息应已删除；如果仍然存在，现在将它删除。等待至少 6 秒——超过一个完整 Interval——确认过滤后的 Trace Count 不再增加，再删除 Subscription。不要为了清理本教程而在共享 Broker 上直接选择清空消息；这会删除其它 Trace 证据。
两个临时列都为空，而且等待窗口后不再出现新的定时 PUBLISH，才算清理完成。
Payload Template 在 Local Runtime 中没有独立 Pro 门禁。Remote Runtime 执行这条工作流需要当前在线 Pro entitlement、已登录 Session，以及 connections:write 与 messages:publish 权限。
未知 Variable、未知 Filter、无效参数、渲染后 JSON 错误、Timeout 与 Renderer 资源限制都会 fail closed，不会发布部分结果。定时消息没有消息数或结束时间字段，而且已保存 Client 重连后会恢复 Schedule，因此离开测试边界前必须删除它。
Literal 消息与 MQTT 5 投递选项见验证 MQTT 消息投递与定时发布。更深入的报文检查见 Trace。需要受控 Client 数、Rate、Duration、Threshold 与报告时，使用 Bench。