タグ付けされた質問 「publish-subscriber」

特にRabbitMQを使用したセンサーデータの公開方法に関するWeb上のチュートリアルが多数あります。たとえば、温度、湿度など。値をメッセージキューに公開するだけで、誰でもそれを使用できます。 ここまでは順調ですね。しかし、アクチュエータはどうですか？ たとえば、ライトスイッチを考えてみましょう。ライトスイッチは、照明器具の現在の状態をキューに発行します。また、イベントをリッスンするために2番目のキューをサブスクライブします。これにより、双方向通信が可能になります。誰か/何かがライトをオンにしたい場合、ライトスイッチがリッスンしているメッセージキューにイベントを発行する必要があります。 アイデアをご理解いただければ幸いです。これはアクチュエータを使用する方法ですか？よりスマートなソリューションはありますか？たとえば、これをドアに使用することを考えて、セキュリティについてはどうでしょう。どこからでも開かれたイベントを公開することは可能ですか？どのくらい簡単にハッキングできますか？

16 security  publish-subscriber  actuators 

クラウドに一般的な少量のデータを保存/送信/公開（および反対の操作）できるIoTサービスは何ですか？ たとえば、デバイスがクラウドに値を保存できるサービスを探しています。また、他のエンティティ（別のデバイス、JSコードを持つWebサイト、Webサーバー、モバイルアプリ）がこの値を取得できます。 たとえば、キーと値のペア、<255バイト、整数、文字列、せいぜい小さなJSONオブジェクトなどの小さなものを格納および取得するための、何らかの種類の非同期通信である可能性があります。サービスは、認証するトークンと保存するキーと値を含むREST APIを提供できます（したがって、さまざまな言語でアクセスできます）。 ユースケースの詳細な例は次のとおりです。 自宅に温度センサーがあり、その値をクラウド（家の外のどこかに）に保存してほしい。このようにして、ホーム接続がダウンしているかどうかに関係なく、アクセスできます。さらに、これにより、専用サーバー+ portForwarding + DynamicDNSの保持と維持が回避されます。 これまでのところ、私はこのようなものを見つけることができませんでしたが、時々、私が説明することを意味するいくつかの例を見つけました： Particle.io publish（）subscribe（） Blynkバーチャルピン 他に類似した（無料/オープン）選択肢はありますか？

16 web-services  publish-subscriber 

しばらくの間、RPiに実装されたAWS IoTを使用しています。Atmega328のようなコントローラーやいくつかのNRFベースのコントローラー、またはSTM32を使用してAWS IoT MQTTブローカーをパブリッシュおよびサブスクライブできるかどうか疑問に思っていましたか？ 私はそれについて少し調査しましたが、証明書を使用してサーバーで認証を行う方法に行き詰まっています。 これらのコントローラーをAWS IoTと統合するにはどうすればよいですか？

8 mqtt  aws-iot  arduino  publish-subscriber  stm32 

それが一般的な質問ですが、ここではシナリオを提供します。 私はMosquittoサーバーを実行して、espリレーモジュール（IteadのSonoff）とHome Assistantの間にmqtt通信を提供しています。ほとんどの場合、問題なく動作します。各モジュールには独自のトピックがあり、HASSにはモジュールと同じ数の「軽い」構成があるため、個々のトグルボタンでWebフロントエンドから制御できます。 ただし、ライトが実際にオンになっていて、HASSのトグルがオフとして表示される（およびその逆の状況も）一貫性のない状態の状況を経験しました。ログを調査したところ、MosquittoがHASSに特定のメッセージを発行していないことがわかりました（すべてのモジュール状態トピックにサブスクライブする必要があります）。具体的には、4つのモジュールとそれに対応する状態トピック（state/sonoff_xx/POWER）を指定すると、HASSはモジュール2と4のトピックにのみサブスクライブされ、1と3にはサブスクライブされないようです。モジュール4の予想される動作は次のとおりです。他の作業モジュールですが、HASSへの公開は他の2つにはありません。 Jun 15 19:22:46 nas mosquitto[9486]: Received PUBLISH from sonoff4 (d0, q0, r1, m0, 'stat/sonoff4/POWER', ... (2 bytes)) Jun 15 19:22:46 nas mosquitto[9486]: Sending PUBLISH to home-assistant (d0, q0, r0, m0, 'stat/sonoff4/POWER', ... (2 bytes)) これはHASSとリレーモジュールに関する問題ではありませんが、特定のクライアントがサブスクライブしていると想定されているMQTTサーバーのステータスを調べる方法についてですが、ログを見るとわかりません。

8 mqtt  mosquitto  publish-subscriber 

MQTTやAMQPなどのパブリッシュ/サブスクライブパターンに基づいてモデル化されたプロトコルでは、メッセージの送受信を調整するために集中型のメッセージブローカーが必要です。IoTネットワークがスタートポロジに基づいている場合、これはそれほど問題にはなりません。すべてのメッセージがいずれにせよ中央ハブを経由する必要がありますが、メッシュネットワークの利点と、これらがどのように影響を受けるかについて考えていました。プロトコルの選択。 スレッドはじめにプレゼンテーションは、特にスレッドのメッシュネットワーク（ただし、これらは一般的に適用されるべきである）のいくつかの利点の概要を示します。 single単一障害点がない ✔自己回復 ✔干渉の堅牢性 ✔自己拡張型 critical重要なインフラストラクチャに十分な信頼性 後者の4つのポイントがプロトコルの選択の影響を受けるとは想像できませんが、メッセージブローカープロトコルを使用すると、メッシュネットワークの「単一障害点がない」という利点がなくなるかどうか知りたいです。 パブリッシュサブスクライブベースのプロトコルを使用すると、一般的に避けられない単一障害点が発生しますか。これが、スレッド紹介プレゼンテーションで、使用する可能性のあるプロトコルとして代わりにCoAPが提案されている理由です。 単一障害点を取り除くために複数のブローカーをサポートするMosquittoについてはすでに質問しましたが、これがメッシュネットワークとパブリッシュサブスクライブプロトコル間の根本的な競合であるかどうかを質問しています。

7 publish-subscriber  mesh-networks  thread