回答:
MQTTは、デバイス間の「メッセンジャー」です。
/domotics/myplace/mydevice/temperatureX（「ペイロード」として）置くメッセージ内あなたの家の他の場所：
/domotics/+/+/temperatureにサブスクライブして、このトピック形式を使用するすべてのデバイスからすべての温度情報を受信します。MQTTトピックのワイルドカード（および）の詳細については、MQTT仕様を参照してください。+#X必要な処理を実行します。あなたの家の他の場所：
/domotics/myplace/mydevice/#にサブスクライブして、デバイスからすべての情報を取得してログに記録しますX必要な処理を実行します。MQTTは、サーバー全体にWebサービスとソケットを配置しないようにするのに非常に便利です。Node-REDはMQTTを使用し、Domoticzはシグナルを取得inおよび設定outするように構成できます。
私は個人的に自宅でMQTTを使用してコンピューターの電源を切ります：/house/computers/mycomputerペイロード：0
MQTTとして知られるMQ Telemetry Transport Protocolは、低電力および低帯域幅で動作するデバイス向けに設計されています。これは、他のデバイスが特定のトピックをサブスクライブできることを意味する、軽量のパブリッシュ/サブスクライブメッセージングプロトコルです。
HTTP / HTTPSは、クライアントサーバーコンピューティング用の要求/応答プロトコルとして設計されており、電力の使用を気にすることはなく、多くのデータオーバーヘッドがあります。
次の場合にMQTTを使用します。
MQTTはHTTPSと同等のセキュリティを提供しますか？
MQTTはトランスポートプロトコルとしてTCPに依存しています。つまり、デフォルトでは、接続は暗号化された通信を使用しません。MQTT通信全体を暗号化するために、HiveMQなどのほとんどのMQTTブローカーは、プレーンTCPの代わりにTLSを使用できます。
参照：HiveMQ
MQTT（Message Queue Telemetry Transport）は、提案されたアプリケーションに適しているようです。
帯域幅（わずか2バイトのヘッダーを持つ最小のパケットサイズ）とクライアントコードのフットプリント（ESP8266などのシンクライアント、典型的なIoTクライアントで実行可能）の両方に関して軽量です。送信データの削減は、センサーなどのオフグリッドバッテリ駆動クライアントのバッテリ寿命を延ばすのに役立ちます。
MQTTは、予期しないクライアントの切断後に接続を回復する永続サブスクリプションなど、IoTタスクに適した単純なメソッド（動詞）も提供します。HTTP / HTTPSと比較して、パッケージからデータを抽出する方が簡単です（パーサーは不要です）。
ここで、プロジェクトで使用した通信システムの進化と進化を示す記事を書きました。これはマイクロサービスに関するものですが、あらゆるセンサーがあらゆる種類のテレメトリデータを収集して公開するという仕事を持つマイクロサービスであると考えることができます。
したがって、最も重要な結論は、イベントをどこかに送信する必要があり、受信者について何も知らない場合にMQTTを使用する方が良いということです。また、受信者について何かを知っていて、何らかの応答が必要な場合は、HTTP（通常はREST）を使用することをお勧めします。
トラフィック、CPU、メモリ、エネルギー消費の観点から、MQTTとHTTPは基本的に同じです。
引用に関して、MQTTは「モノのインターネットのプロトコル」です。
はい、このプロトコルを使用する開発者は多数います（IoT Developer Survey 2018を参照）が、CoAP（UDPに基づいてIoT用に調整されたHTTP）は、あなたの申請。
一方、MQTTは組み込みのパブリッシュ/サブスクライブロジックを提供し、スケーリングに最適です（より多くのデバイスに対してより多くのゲートウェイを使用できます）。また、MQTT-SN（センサーネットワークのMQTT）と呼ばれるUDP代替（CoAPからHTTPなど）もあります。これにより、CoAPよりも小さなオーバーヘッドが提供されますが、R / Rは使用されません。