1

Google、AWS、Azure などのさまざまなサービス プロバイダーからの MQTT ブリッジを介してダッシュボードと通信するように構成された IoT ベースのアプリケーション デバイスがあります。

したがって、フローは次のとおりです。

  1. デバイスがサービス プロバイダーとの TLS セッションを開始します。
  2. 特定のトピックにサブスクライブし、5 秒のタイムアウトでサービス プロバイダーからのメッセージを待ちます。
  3. ダッシュボードは、定期的に同じトピックにメッセージを発行します。
  4. IoT サービス プロバイダーは、サブスクライブしているすべてのデバイスにそれをブロードキャストします。

パブリッシュおよびサブスクライブ メッセージは、MQTT QOS 1サービスを使用します。

観察：

AWS と Azure は上記のフローで正常に動作しますが、ダッシュボードが Google IoT MQTT ブリッジにメッセージを発行しているにもかかわらず、3 ～ 5 回の反復が成功すると、デバイスは Google MQTT ブリッジからのメッセージの受信を停止します。

Google については、Azure や AWS と比較すると、制御フローが異なることがわかりました。

Google の場合、メッセージの受信を待機する前に、特定のトピックを毎回サブスクライブおよびサブスクライブ解除する必要がありますが、AWS および Azure では、MQTT 接続を開くときに 1 回サブスクライブする必要があります。

問題：

サブスクライブされたトピックのメッセージを Google MQTT ブリッジから受信できなかったため、5 秒のデバイス タイムアウトが発生することがあります。電源を入れてから 45 ～ 60 秒後にデバイスが操作された後、デバイスが Google MQTT ブリッジからメッセージを受信できなかったため、タイムアウトの問題を解決するために複数の再試行を追加しても失敗しました。

  • 毎回サブスクライブせずに定期的にメッセージを受信するには、Google MQTT ブリッジに制約がありますか?
  • Google MQTT ブリッジからタイムアウト (5 秒) せずにデバイスがメッセージを受信するにはどうすればよいですか?
  • MQTT 再接続の確立でタイムアウトになったデバイスを回復するための回避策はありますか?
4

2 に答える 2

0

これが私が使用したgolangコードです（gingi007の回答に触発されました、ありがとう！）

var onConn MQTT.OnConnectHandler
onConn = func(client MQTT.Client) {
    fmt.Println("connected")
    client.Subscribe(topic.Config, 1, handlerFunc)
}
mqttOpts.SetOnConnectHandler(onConn)
client := MQTT.NewClient(mqttOpts)

このようにして、構成の更新がデバイスに流れ続けますが、onConnectHandler の外部でサブスクライブすると、接続時に構成の更新が 1 つだけ受信されます。

于 2018-07-10T08:24:46.040 に答える