必要な入力/出力（4〜20 mAを含む）とセンサー用の5〜30 Vの電源の存在に加えて、主な条件は、バッテリーで電力を供給できるように消費を最小限に抑えることでした。プロトコル。 シンプルで標準的なものが欲しかった。
MQTT。 しかし、MQTTは長所と短所をすべて備えたTCPです。 そして、私はバッテリーと3ヶ月の寿命を持っています。 テストのために、UDPの上にプリミティブプロトコルが記述されました。 しかし、私は自分自身を先駆者とは考えていないので、今では2日以内に何か消化できるものが書かれるだろうと確信しています。一般に受け入れられているものを探し続けました。
方法は覚えていません-MQTT-SNについて言及しました。 MQTTセマンティクスを継承しますが、UDPおよびバッテリー駆動のクライアントに適合したプロトコル。 IBMの腸内で開発され、その後コミュニティに開かれたものがあることが判明しました。 説明を読んだ後、ここにあることが幸福であることが明らかになりました。
ただし、ブローカーが必要です（サーバーはMQTTで呼び出されます）。使い慣れたMosquitto（2013年のJan Kragsによる）は、いつかMQTT-SNを使用できるようになりますが、現在は使用できません。 しかし、RSMBがあり、Gitハブのソースコードにもあります。
ソースは良好です。収集する必要があります。 アセンブリはVisual StudioでCygWinによって行われます（5年前に最後に見ました）。 私たちは無料版を置いて、プロジェクトを作成します-方法はありません。 5〜10回（一般的に、チャンスと頑固さが私の人生で重要な役割を果たします）プロジェクトは正しく処方されました-そして、奇跡、私はブローカーを得ました。 Linuxでは、このアクションがはるかに簡単になったことに注意してください。
荘厳に打ち上げられました。 残念ですが、機能しません。 結局のところ、あなたのプロトコルは出て行っているのでしょうか？ サーバーとクライアントの作成とデバッグの作業量を想像して、私はそうではないと決めました。私の選択はMQTT-SNです。 すべてがシンプルであることが判明しました-構成を登録し、ブローカーに示す必要がありました。
最小値は次のようになります。
trace_output off # , listener 1883 INADDR_ANY # MQTT listener 1883 INADDR_ANY mqtts # MQTT-SN
そしてその後、ブローカーが稼いだ。 要するに、MQTT-SNと従来のMQTTの違い。
- MQTT-SNプロトコルは、通常のTCPではなくUDP上で実行されます。 これにより、プログラマーへのメッセージ配信を制御する責任が変わります。 ただし、GSMを介した通信チャネルを維持するために、デバイスはより少ないエネルギー（これは私にとって重要）を使用できます。
- 新しいレベルのQoS（サービスの品質）-1が導入されました。 配信制御の欠如。 デバイスは起動し、必要な作業を行い、結果を送信し、確認を待たずにスリープ状態になります。
- 複数のデバイスからデータを集約してブローカーに送信できるゲートウェイがあります。
git eclipsaには、MQTT-SNクライアントのソースコードとサンプルが含まれています。 実際には、必要に応じてtransport_xxチャネルを操作する機能を登録する必要があります。 それ以外の場合、大きな問題はありません（エラーをいくつか見つけたので、テストする必要があります）。
残念ながら、スリープ状態のクライアントのサポートは実装されていません。 スタブがあります。 誰がプロトコルの作者に石を投げることができますか-ソースコードが利用可能です、助けがありがたいです。
最後に言いたかったこと。 少し時間を費やして、プロジェクトをさらに発展させるための既成のインフラストラクチャを手に入れました。 このプロトコルでは、4 MHzでSTM32を使用できます。 さまざまなプラットフォームで多くのクライアントを使用できます（プロトコルを記述するときに単独で行うのは非現実的です）。 さらに、Linuxのブローカーを構築する機会があったので、それをAmazonインスタンスに配置し、サーバーを維持および維持する必要なく、顧客がソリューションを得ました。 標準ソリューション（常にではありませんが、ほとんどの場合）でタスクを高速化します。
参照：
MQTTSNクライアント-Eclipse
RSMB- github