从你描述的现象和提供的日志来看，核心问题应该是发送到dev/data主题的消息格式不符合Live Objects的规范——虽然MQTT.fx提示“成功发布”，但Live Objects在接收后会对消息格式做严格校验，不符合要求时会主动断开客户端连接。下面是具体的排查和解决步骤：

1. 修正JSON格式的语法错误 #

你的日志里的消息存在一个明显的JSON语法问题：

{
 "s": "urn:lo:nsid:mqtt:MQTT_FX_Client!mqtt",
 "m" : "Model-1",
 "v" : { "counter": 32 },
 "t" : ["Test"],  // 这里多了一个末尾逗号（trailing comma）
}

JSON规范不允许对象或数组的最后一个元素后面保留逗号，这个小错误会直接导致Live Objects的消息解析失败，进而触发连接重置。把这个逗号去掉后，消息格式应该是：

{
 "s": "urn:lo:nsid:mqtt:MQTT_FX_Client!mqtt",
 "m" : "Model-1",
 "v" : { "counter": 32 },
 "t" : ["Test"]
}

2. 确认Live Objects dev/data主题的必填字段 #

除了语法正确，还要确保消息包含Live Objects要求的必填字段：

• s：设备的唯一标识符，格式要符合urn:lo:nsid:<protocol>:<device-id>，你的值看起来是合法的，但要确保和你在Live Objects平台注册的设备ID一致
• v：设备的数值数据，必须是有效的JSON对象或值
• 可选字段如m（模型）、t（标签）可以根据需求添加，但也要保证格式正确

3. 查看Live Objects平台的设备日志 #

登录Live Objects控制台，找到你的MQTT设备，查看设备的事件日志或消息日志，平台会明确提示断开连接的原因（比如“invalid payload”），这能帮你快速定位其他可能的格式问题。

4. 验证其他连接参数 #

虽然dev/info能正常发送，但也可以检查以下参数：

• 确认客户端ID和你在平台注册的设备ID匹配
• 尝试调整MQTT的QoS级别到1（dev/data主题通常支持QoS 0/1）
• 确保连接时使用的用户名/密码（或API密钥）权限足够发布到dev/data主题

先尝试修正JSON的末尾逗号问题，这大概率能解决你的连接断开问题，如果还有问题，再通过平台日志进一步排查。

内容的提问来源于stack exchange，提问作者Al Soderbeck