最近書いたように（ MQTT / UDPに関する最初の短い記事 ）、MQTT / UDPはMQTTに基づくプロトコルですが、
- UDPブロードキャストの上に移動します（ブローカーは不要で、構成はほとんど必要ありません）
- 実装は非常に簡単です（C + UDP / IPスタックで10行-センサーからデータを送信します）
- 誰もがみんなを聞く
ある意味では、これはCANですが、イーサネット経由です。
なぜだ。
私のアパートは、実際には「家は完全に横隔膜ではない」などのシステムの管理下で数年間住んでいます。 それをインテリジェンスと呼ぶのは不要ですが、光と気候は自動化されています。 災害の規模を想像するために、システムは幅約19インチ、高さ2メートルの満杯のラックを占有します。 2つのラックの壁は、ほぼ床に向かっています。
このすべてを設計したとき、フォールトトレランスの問題が最初に現れました。 数年にわたる運用実績があります。それは事実です。 すべてを拒否します。 遅かれ早かれ。 しかし、電気機械式リレーはまだ故障しておらず、故障に対する保護の最後の段階です。
フォールトトレランス後の次の問題は動物園です。 人生の自然な流れ、私の好奇心と緊急のニーズのために、通常のPC上の通常のUnix、Aries PLC、Raspberr + Orange PI、Atmegaモジュール、NodeMCUベースのモジュール（ESP8266）はシステムに存在し、これらはすべてmodbusを介して相互に送信されます485、modbus TCP、http、および側では、落ち着きのないMQTTブローカーが、キャンプ全体で切り替えに失敗したという遺産としてハングアップします。
MQTTへの切り替えが失敗する理由。 第一に、鉄の一部は重いか複雑です。 CodeSys PLCに隠れているPascalのフラグメントでは、マゾのみがMQTTを書き込むことができます。 ただし、デバッグする必要があります。 同様にatmega：詰め込むことはできますが、密接にできます。 しかし、これはすべての問題ではありません。
MQTTはそのまま（そして3.1.1のどこでも受け入れられます）、PUBLISHパケット（つまり、ブローカーへのメッセージ）を送信者を含むすべての受信者に送信することを主張します。 この狂気の効果は魅力的です-同じOpenHABは同じ名前でMQTTでデータを送受信できません。 つまり、MQTT（同じオブジェクトの値を更新して使用するいくつかのモジュール）に基づいてバスを編成することは不可能です。 そして、これがまさにPLC通信の編成方法であり、メインのライトコントロールが存在し、OpenHABはウェブインターフェースとモバイルアプリケーションからのライトを制御し、スマートスイッチはどこにでも追加できます。 もちろん、この問題は回避できますが、実際には独自のプロトコルSURFACE MQTTを構築することを意味し、これはすでに多すぎるようです。
同時に、何が必要ですか？ パラメーター値の更新を送信し、関心のあるすべてのポイントで取得します。 実際、祖父はブロードキャストアドレスに対してUDPを実行しました。
Habréに関する最後の投稿の後、長い間読者の一人がUDPプロトコルの信頼性のなさを非難しました。 私は推測して、IoTの場合、UDPはTCPよりも信頼性が高いと答えました：ネットワーク上のパケット損失が50％の場合、TCPは横になるだけでなく、一般的に、UDPを介して測定値を送信する温度センサーはカウントの半分を失うだけで、何らかの方法でシステムの操作。 一般的に。
しかし、それは投機的でした。 ただし、シャンパンを飲み終えて自問するために、新年の祝日も人に与えられました。今日は自宅のLANをシャベルに乗せますか？ そして何があっても。
MQTT / UDPを取得し、プリミティブテストを作成しました。 片側は、可能な限りパケット間の休止なしに連続したパケットを送信します。 2番目は、速度とパケット損失を考慮します。 実験は簡単でした。このm笑を開始し、2台のHD TVがインターネットの映画を並行して表示し、デスクトップコンピューターが巨大なファイルをNASに書き込みます。
結果を評価します。 私はすべてを待っていましたが、... UDPの最大損失は0.5％に達し、両方のテレビが表示を停止しました。 だから私はまだ悲観論者でした。 実際のホームネットワークでは、UDP配信の信頼性は絶対に近いです。 それにもかかわらず、私はおそらく確認付きのバージョンを作成し、パッケージを再送信します。 困難はほとんどありませんが、質問は完全に削除されます。
2番目の質問はセキュリティですが、そうです、もし彼らが私のホームネットワークに侵入した場合、温度センサーからのデータの損失は私が悲しむ最後のものです。 ただし、ここでも、課題トラッカーでパッケージにデジタル署名するタスクが存在し、実装のためにMQTTパッケージを拡張する方法を既に理解しています。
一般的に、ホームネットワークの最初のデバイスペアで先日MQTT / UDPに切り替える予定です。
そして、あなたのプログラムとデバイスで試してみることをお勧めします： 英語の リポジトリとドキュメント 。
利用可能なもの：
Java、Python、およびCのかなり完全な実装。 Luaの基本的な実装。 これまでのところ、ArduinoとCodeSys PLCにのみ送信しています（Ariesでテストおよび動作しますが、何でもできます）。
何が起こっているのか、介入しているのかを見るためのGUIツール：
Python、Lua、Javaでデータを送受信するためのプログラム。
通常のMQTTとの統合およびOpenHABとの直接統合のためのPythonコネクター。 サイクルに対する保護を行い、順方向に通過した後の5秒間のメッセージの逆ブロードキャストを禁止します。 さらに、繰り返されるデータの流れを制限するライブラリがあります。 指定した時間にこのトピックの更新が既にあるかどうかを確認し、更新がある場合は、データが変更された場合にのみ新しい更新をスキップします。
私は徐々にこのプロトコルに完全に移行することを計画していますが、ここにセンサーで得たいものの一例を示します。
1つの部屋に3つのセンサーがあります（まあ、路上でも構いません）。 彼らはMQTT / UDPを介してサンプルを送信します。 これらの測定値は、メインのスマートホームシステム（OpenHAB）、履歴データベース、居住者の気温を表示する壁モニターによって同時に受信されます。
MQTT / UDPの魅力は、このようなスキームでは、ブロックの障害が他のすべての人に問題を引き起こさないことです。 そして、これはプロトコルの魅力的なシンプルさです。
さらに、重複を伴う冗長制御スキームは、同じスキームで簡単に実装できます。 データベースサーバーは問題なく複製できます。 管理を扱うモジュールを複製するのは難しいでしょう。 たとえば、温度を聞くと、ラジエーターで制御動作が行われます。 しかし、おそらくこれは次の話です。 今日は、センサーから信号を収集し、スマートホームのモジュール間で交換することに集中する予定です。