我们有一个基于 IoT 的应用程序设备，它被配置为通过来自 Google、AWS 和 Azure 等各种服务提供商的 MQTT 桥与我们的仪表板进行通信。

所以流量是，

1. 设备启动与服务提供商的 TLS 会话。

2. 订阅特定主题并等待来自服务提供者的消息，超时 5 秒。

3. 仪表板定期向同一主题发布消息。

4. 物联网服务提供商将其广播给所有订阅的设备。

5. 使用 MQTT QOS 1服务发布和订阅消息。

观察：

AWS 和 Azure 在上述流程中运行良好，但设备在 3-5 次成功迭代后停止接收来自 Google MQTT 桥的消息，即使我们的仪表板正在向 Google IoT MQTT 桥发布消息。

对于 Google，我们发现与 Azure 和 AWS 相比，控制流是不同的。

对于谷歌，我们需要在等待接收消息之前每次订阅和取消订阅给定的主题，而对于 AWS 和 Azure，我们需要在打开 MQTT 连接期间订阅一次。

问题：

有时会发生 5 秒设备超时，因为它无法从 Google MQTT 桥接收订阅主题的消息。添加多次重试以克服超时问题未成功，因为问题仍然存在，因为设备无法在开机后 45-60 秒的设备操作后接收来自 Google MQTT 网桥的消息。

谷歌 MQTT 桥是否有限制定期接收消息而无需每次都订阅？

设备如何在不超时（5 秒）的情况下从 Google MQTT 网桥接收消息？

一旦建立 MQTT 重新连接超时，是否有任何解决方法来恢复设备？