IoT service，mqtt，publish topic different from subscribe topic

最新推荐文章于 2025-05-21 13:50:22 发布

进击的魔法师

最新推荐文章于 2025-05-21 13:50:22 发布

阅读量2.4k

点赞数

CC 4.0 BY-SA版权

本文链接：https://blog.youkuaiyun.com/cleverlzc/article/details/48032267

博客揭示了一个IoT服务作为MQTT Broker的特殊功能——自动进行topic转换。当应用程序和设备通过IoT服务订阅和发布时，发现subscribe与publish的topic不一致。文中详细描述了这个过程，并举例说明了如何在设备端和应用端同时进行subscribe和publish操作。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

万万没想到，万万没想到~~

没想到的是IoT service不仅仅是一个MQTT Broker，”他“还”好心“帮你多做了一件事情，就是topic转换，哈哈，没想到吧，subscribe的topic竟然和publish的topic不一样！

神马？！是的，你没听错！当然，多加topic转换的一步是有一定原因的（至于为什么会有这样的顶层设计，我目前还无暇思考），也是容易实现的，因为app和device都是注册到”他“那里的，app和device的认证信息都在”他“那，做个topic转换还不简单！

至于”MQTT 连接成功订阅不成功“的难题也顺利解决了。因为IoT service不认识你publish的topic，所以MQTTListener不给你subscribe！所以有”一连一断（不断的循环往复connect和disconnect，就是不执行subscribe()方法）“。这个问题是不是socket closed by remote peer呢？好像还不一样。

MQTTGataway回调函数里subscribe的topic如下：

String topic = "iot-2/type/" + MqttUtil.DEFAULT_DEVICE_TYPE + "/id/+/evt/"

+ MqttUtil.DEFAULT_EVENT_ID + "/fmt/json";

MQTTListener的监听的onPublish中（用来监听device或者sensor端的publish的topic）的topic如下：

Pattern pattern = Pattern.compile("iot-2/type/"
+ MqttUtil.DEFAULT_DEVICE_TYPE + "/id/(.+)/evt/"
+ MqttUtil.DEFAULT_EVENT_ID + "/fmt/json");

XXDevice或者XXSensor端publish的topic如下（重要的事情说三遍，是的，你没看错！）：

connection.publish("iot-2/evt/eid/fmt/json", data.getBytes(),
QoS.AT_LEAST_ONCE, false);