タグ付けされた質問 「mqtt」

温度、湿度、質量を測定するデバイスを開発しています。現在、HTTPSを使用してデータをリモートサーバーにアップロードしています。「モノのインターネットのプロトコル」であると主張されているMQTTと呼ばれるプロトコルがあることを私は知っています。 どのような場合、なぜHTTPSからMQTTに切り替える必要がありますか？

34 mqtt  protocols  data-transfer  https 

私が検討してきたMosquittoをホームのIoTネットワーク用のMQTTメッセージ・ブローカーのために、私は、すべてのメッセージが通過する必要があるため、ブローカーは、それが失敗した場合、私のネットワーク全体をダウンさせる可能性が単一障害点となる可能性を懸念していますブローカーが何らかの理由でオフラインになった場合（偶発的なプラグの抜き取り、ハードウェア障害など）、ブローカーはまったく送信できません。 Mosquittoをインストールした状態で複数のブローカーを使用して、ネットワークの信頼性を向上させることは可能でしょうか？可能であれば、複数のブローカーを使用することに不利な点や重要なオーバーヘッドはありますか？

20 networking  mqtt  mosquitto 

仕様によると、サーバーへの接続を確立するのは常にクライアントです。 クライアント： MQTTを使用するプログラムまたはデバイス。クライアントは常にサーバーへのネットワーク接続を確立します。できる 他のクライアントが興味を持っている可能性があるアプリケーションメッセージを公開します。 それが受信することに関心があることを要求アプリケーションメッセージを購読します。 アプリケーションメッセージのリクエストを削除するには、登録を解除します。 サーバーから切断します。 このクライアントがアプリケーションメッセージをサブスクライブする場合、サーバーはこれらのメッセージをこの特定のクライアントに転送する必要があります。 サーバ： アプリケーションメッセージを発行するクライアントとサブスクリプションを作成したクライアントとの間の仲介として機能するプログラムまたはデバイス。サーバー クライアントからのネットワーク接続を受け入れます。 クライアントによって発行されたアプリケーションメッセージを受け入れます。 クライアントからのサブスクライブおよびサブスクライブ解除リクエストを処理します。 クライアントのサブスクリプションと一致して転送したアプリケーション・メッセージ。 これは、クライアントがサブスクライブした場合、ほとんどの時間にデータフローがなくても、サブスクリプションが有効な間、サーバーに接続されたままになることを意味しますか？ クライアントがサブスクリプション後に切断した場合、接続を確立するのはクライアントであるため、サーバーはメッセージを転送できないため、この結論に達します。しかし、それは、それを再確立したときに知ることができません。

19 mqtt 

私の理解では、クライアントが対応するトピック名で何かを発行すると、MQTTでトピックが作成されます。 トピックを構成する必要はありません。トピックを公開するだけで十分です。 ここから。 クライアントが自身のトピックをサブスクライブすることは可能ですか？仕様には制限がありませんでした。異常動作の可能性としてリストされていません： 5.4.8異常な動作の検出 サーバー実装では、クライアントの動作を監視して、潜在的なセキュリティインシデントを検出する場合があります。例えば： 接続試行の繰り返し 繰り返し認証試行 接続の異常終了 トピックスキャン（多くのトピックの送信またはサブスクライブの試行） 配信不能メッセージの送信（トピックの購読者なし） 接続するがデータを送信しないクライアント これに基づいて、私はそれが確かに可能であると思います。だから私はこの機能の使用例に興味がありますか？ なぜ標準ではそのようなメカニズムが許可されているのでしょうか？そのため、クライアントが自分のトピックにサブスクライブできるようにするだけです。 私が考えることができる1つのユースケースは、クライアントが公開されたデータを検証できるこの方法です。

18 mqtt 

MQTTとWeb Socketsの主な違いは何ですか？ ホームオートメーションにIoTを使用する場合-さまざまなデバイスでアクセスを制御および監視します。RestAPIベースおよびブラウザーベースのアクセシビリティが必要な場合は、どちらを使用する必要があります。 Raspberry Pi 2 B +でJava（Pi4Jライブラリ）を使用しています。 明暗、湿度、PIDなどのいくつかのセンサーのセットアップがあります。 また、必要に応じてデータを送信できるクラウドサーバーもあります。

17 communication  monitoring  mqtt 

HiveMQのブログには、すべてのメッセージをデータベースにダンプしようとするときにマルチレベルワイルドカードをサブスクライブしない「ベストプラクティス」の下にリストされています。彼らは、サブスクライブしているクライアントが高負荷のメッセージに追いつくことができないかもしれないと主張し、代わりにブローカプラグインを使用してメッセージのストリームに直接フックすることを提案します。 場合によっては、すべてのメッセージをサブスクライブする必要があります。これらのメッセージは、すべてのメッセージをデータベースに永続化する場合など、ブローカー経由で転送されます。これは、MQTTクライアントを使用して、マルチレベルワイルドカードをサブスクライブすることで実行しないでください。その理由は、多くの場合、サブスクライブしているクライアントが、送信されるメッセージの負荷を処理できないことです。特に、大量のスループットがある場合。推奨されるソリューションは、MQTTブローカーに拡張機能を実装することです。たとえば、HiveMQのプラグインシステムを使用すると、HiveMQの動作にフックし、非同期ルーチンを追加して各着信メッセージを処理し、データベースに保持できます。 どちらかありますか mosquittoブローカー用の同様のシステム（拡張機能/プラグイン）、 蚊と連携する別の推奨方法、または このアプローチがまったく不要であるという合理的な証拠、すなわち、購読しているクライアント#がうまくいくことができるということですか？ /programming//q/31584613/3984613は、この質問を網羅的に扱っていません。

16 mqtt  mosquitto 

問題のコントローラーはSTM32F030K6T6で、ARM®32ビットCortex®-M0低電力コア、32 kBフラッシュメモリ、4 kB SRAMを搭載しています。インターネット接続のためにSIM808とインターフェースします。 メモリに関するリソースは非常に限られています。 このデバイスにMQTTを実装することはできますか？ MQTTを使用/実行できるようにするには、マイクロコントローラーがどのような要件を満たす必要がありますか？ （プロトコルスタックの完全な実装については質問していません。）

15 mqtt  microcontrollers  stm32  arm 

Arduinoを使用してIoTをプログラミングする方法を知っています。しかし、デバイス側でプログラミングを必要としない既製のポータブルIoTデバイスが必要です。これらのデバイスを購入してネットワークに追加し（構成後）、（会社から提供されたドキュメントを使用して）コントローラロジックをそれらに書き込みたいだけです。 例えば： 既製のMQTTサーモスタットがいくつかのブローカーに接続し、いくつかのトピックで温度を公開します。誰かがそのサーモスタットを購入してインストールし、MQTTクライアントを使用してその温度を読み取ることができます。 CoAPサーバーに接続する既製のCoAPレギュラーライトは、誰かがそれを購入して自宅のライトをそれに置き換え、CoAPクライアントを使用してそのデバイスにCoAPメッセージを送信することにより、オン/オフを切り替えることができます。 親切に会社名またはリンクを共有します（REST / COAP / MQTTのみ）。検索しようとしたが、Rachio Smart WiFi Sprinkler（Docs）以外は何も見つかりませんでした

14 smart-home  mqtt  hardware  coap  open-source 

自宅でMQTTネットワークをセットアップしようとしています。実践的な演習で知識を積み上げたい。それは、私のラップトップ（Windows 7）でホストされるブローカーと、Raspberry Piを搭載したクライアントを備えた小さなネットワークです。また、携帯電話でクライアントを作成することも考えています（Android）。 私の目標は、簡単なネットワークを使用して実験できるようにすることであり、最初に実験して、セキュリティテストを実行することです。 悪意のあるMQTTクライアントとして機能するように設計されたMQTT Server Test Suiteを見つけました。開始することはかなり有望です。 テストツールの一般的な機能 完全自動化されたブラックボックスネガティブテスト 既製のテストケース Java（tm）で書かれています GUI、コマンドライン、リモートインターフェースモード 計装（ヘルスチェック）機能 サポートとメンテナンス 包括的なユーザードキュメント 結果の報告と分析 しかし、MQTTセキュリティ機能を検証するために使用できる、より簡単なプラクティスにも興味があります。初心者がMQTTネットワークでいくつかの基本的なセキュリティ検証を実行する最も簡単な方法は何ですか？

13 security  mqtt  mosquitto  testing 

通信手段としてBLEに依存する多数の弱いセンサー（Arduinoレベルのデバイスなど）があり、これらのデバイスがより強力なゲートウェイ（Raspberry piレベルのデバイスなど）に接続されているとします。 MQTTが測定値（短く、頻繁にバーストするメッセージ）を送信するための適切なプロトコルと見なされるかどうかを知りたいです。 多くのブログ/ドキュメントでは、MQTTがHTTPと比較して軽量で電力を節約できるため、「IoTアプリケーション」に適していると考えています。ただし、私の理解では、接続を開いたままにしておく必要がありますが、これはBLEやIoTに適した他の通信プロトコルには当てはまりません。BLEは、エネルギーを確保するために長時間接続を開いたままにしません。明らかに、WiFiなどのMAC層プロトコルが使用される場合、MQTTが適切です。これは、最初にMQTTを使用することの背後にある理論的根拠をほとんど破ります（つまり、デバイスがWiFiなどのプロトコルを計算可能に処理する場合、MQTTなどのプロトコルは必要ないかもしれません）。この論理に欠陥がありますか？ そのための代替アプリケーション層プロトコルはありますか？ゲートウェイと通信する場合、およびサーバーと直接通信する場合、これらのタイプのメッセージ（生のバイナリデータ、JSON、XMLなど）で最もよく見られる構造は何ですか？

12 mqtt  power-consumption  bluetooth-low-energy 

Raspberry Piに私の命令を任せるための継続的な努力の中で、Mosquitto MQTTブローカーをセットアップしました。基本設定では、すべてがかなりうまくいきました。 publishコマンドでテストメッセージを投稿し、subscribeコマンドで受信できます。次に、ログレベルを上げることにし、mosquitto.confファイルを次のように変更しました。基本的にログセクション全体がコメントアウトされたバージョンが機能します。もう一方はそうではありません。 ログファイルのある行に絞り込みました。 $ diff mosquitto.conf mosquitto.conf.old 408,410c408,410 < #log_dest file /var/log/mosquitto/mosquitto.log --- > log_dest file /var/log/mosquitto/mosquitto.log ファイルは存在しmosquitto:mosquitto、サービスを実行しているユーザーが所有しています。 ロギングを試みたときに得られる非常に役立つメッセージは次のとおりです。 mosquitto_pub -h localhost -t thisisme -m 5 Error: Connection refused 今では、このサービスは無言の死であると確信しています。 $ sudo service mosquitto status ● mosquitto.service - LSB: mosquitto MQTT v3.1 message broker Loaded: loaded (/etc/init.d/mosquitto) Active: …

12 mqtt  raspberry-pi  mosquitto 

状況は次のとおりです。 クライアント、パブリッシャーがいますが、どのトピックにもサブスクライブされていません。このクライアントには独自のトピックが1つあり、データを定期的に公開します。ただし、このトピックにサブスクライブしている他のクライアントはありません。 したがって、この貧弱で孤独なクライアントは異常と見なされる可能性があります（第5.4.8章）。 サーバー実装では、クライアントの動作を監視して、潜在的なセキュリティインシデントを検出する場合があります。例えば： [...] 配信不能メッセージの送信（トピックの購読者なし） それは持っていない加入しているどのように多くのクライアントについては考えそのトピックにします。したがって、異常な動作をしているクライアントと見なされる可能性があることはわかりません。 では、そのようなクライアントで何が起こるかは、サーバーの実装に依存しますか？プラクティスは何ですか、単に切断する必要がありますが、その後再接続を試行しませんか？

12 mqtt 

可能であれば、新しいデバイスをブローカーに接続するときに2FA（2要素認証）を使用するにはどうすればよいですか？ 簡単だと思われるため、2番目の要素は最初にソフトウェアソリューションにすることができますが、ハードトークン（RFIDの場合もある）を導入する方法についてのアイデアを歓迎します。 デバイスが最初の接続でのみ認証する必要があり、サーバーが「古い」クライアントを記憶している場合、それは理にかなっています。 アイデアは多分珍しいまたは不適切です-それが悪いアイデアである場合、私にその理由を教えてください。

12 security  mqtt  authentication 

クライアント（ClientAと呼ぶ）が特定のMQTTトピックにリクエストを発行できるシステムがあります。ブローカーは、重要な場合には、アマゾンウェブサービスです。次に、常に同じトピックにサブスクライブしている別のクライアント（MainSubscriberと呼ぶことにします）を用意します。これにより、ClientAからの要求を取得し、最終的にはデータベース操作になるいくつかの作業を実行できます。重要な場合は、データベースはDynamoDBです。 MainSubscriberは常にアクセス可能/オンラインであるとは限らないため、フェイルオーバーサブスクライバーがメインサブスクライバーのフェイルオーバーバックアップになることが望まれます。考えは、メインサブスクライバーが要求をタイムリーに処理しない場合、フェールオーバーサブスクライバーが起動し、同等の作業/データベース操作を実行するというものです。課題は、「作業」とその結果の「データベース操作」をメインサブスクライバーとフェイルオーバーサブスクライバーの両方で複製してはならないことです。 これは、このシステムの論理システムアーキテクチャ図です。 -----> MainSubscriber ---- / \ ClientA --> Broker ---> Database \ / ---> FailoverSubscriber -- 明らかに、このようなシステムにはいくつかの課題があります。 メインサブスクライバーは、フェールオーバーサブスクライバーに対して、要求を処理していることをどのように示しますか？ フェイルオーバーサブスクライバーは、メインサブスクライバーが要求を取得しておらず、要求の処理を開始する必要があることをどのように検出しますか フェールオーバーサブスクライバーは、突然突然オンラインに戻って要求を受け取った場合に、メインサブスクライバーをどのように保留しますか？ メインサブスクライバーとフェールオーバーサブスクライバー間の同期の問題に対処する方法 そのようなスキームの既存のソリューションがすでに存在する場合は、ホイールを再発明する必要はありません。それで、私の最初の質問は、すでに何かがあるかどうかです。 そうでない場合は、DynamoDBを非常に一貫した読み取りで使用して、メインサブスクライバーとフェールオーバーサブスクライバーの間のメディエーターとして機能することを考えていました。それで、私の2番目の質問は、これを行うための確立されたスキームがあるかどうかです。

11 mqtt  aws-iot  aws 

現在のところ、EMQ（Erlang MQTTブローカー）はQoS 1/2メッセージをディスクに永続化しないようです：EMQはどのようにQoS 1/2メッセージを永続化しますか？ したがって、予期しないサーバーの再起動が発生した場合、QoS 1/2レベルのメッセージを少なくとも1回だけ配信する必要があるにもかかわらず、メモリ制限やその他のイベントメッセージが失われる可能性があります。 QoS 1/2メッセージをディスクに永続化して配信を保証するMQTTブローカーはありますか？

11 mqtt