MQTTプロトコルは、BLEを介したセンサー読み取り値の送信に適していますか？

通信手段としてBLEに依存する多数の弱いセンサー（Arduinoレベルのデバイスなど）があり、これらのデバイスがより強力なゲートウェイ（Raspberry piレベルのデバイスなど）に接続されているとします。

MQTTが測定値（短く、頻繁にバーストするメッセージ）を送信するための適切なプロトコルと見なされるかどうかを知りたいです。

多くのブログ/ドキュメントでは、MQTTがHTTPと比較して軽量で電力を節約できるため、「IoTアプリケーション」に適していると考えています。ただし、私の理解では、接続を開いたままにしておく必要がありますが、これはBLEやIoTに適した他の通信プロトコルには当てはまりません。BLEは、エネルギーを確保するために長時間接続を開いたままにしません。明らかに、WiFiなどのMAC層プロトコルが使用される場合、MQTTが適切です。これは、最初にMQTTを使用することの背後にある理論的根拠をほとんど破ります（つまり、デバイスがWiFiなどのプロトコルを計算可能に処理する場合、MQTTなどのプロトコルは必要ないかもしれません）。この論理に欠陥がありますか？

そのための代替アプリケーション層プロトコルはありますか？ゲートウェイと通信する場合、およびサーバーと直接通信する場合、これらのタイプのメッセージ（生のバイナリデータ、JSON、XMLなど）で最もよく見られる構造は何ですか？

MQTTはTCP / IPで実行する必要があります（実際に仕様に含まれているか、そうするために十分な仮定がなされているか覚えていません）が、姉妹プロトコルMQTT-SNはデータを渡すことができるほぼすべてのプロトコルで実行できます、UDPとシリアルの実装を見てきました。

BLEで実行することで何が得られるかわからないが、BLEの組み込みの特性は、通知のようなものと同じ利点（1対1の場合のみ）を提供します。

覚えておくべき重要なことの1つは、IoTで「私」が何を意味するかです。それは、ある時点でインターネットにアクセスすることを意味します（ゲートウェイデバイスまたは電話であっても）。その時点でMQTTは非常に便利ですが、必ずしも（ブリーディング）エッジまでのすべてを意味するわけではありません。

間違いなく、文字通りBLEを介してMQTTを送信するのではなく、BLEパラダイムからMQTTへのデータの単純なマッピングを行う方が良いでしょう。

BLEは通常、特性の形でデータを交換します。これらには、価値の変化を発見するためのさまざまなBLE固有のメカニズムがありますが、これらのメカニズムは便利です。 ただし、最大データ長は20バイトです。

BLEでシリアルデータをストリーミングし、一度に20バイトを移動することができます。これは仮想シリアルポートを実装するために行われることがあり、これを介して完全なMQTTをトンネルすることができます。

ただし、BLE特性のコレクションを使用してさまざまなトピックのデータを保持し、特性IDをMQTTトピックにマップし、値をMQTTペイロードにマップするブリッジを使用する方がよいでしょう。

BLEには、接続されているセッションと接続されていないセッションとの独自の感覚があります。おそらく、BLEの使用法がアプリケーションに最適であるかを把握し、これを接続を維持するというMQTTの感覚にマッピングする必要があります。

BLE-> MQTTおよびMQTT-> BLEのいずれかまたは両方向でこれを実行できるはずです。