433 MHzデバイスを操作するための別のライブラリ

みなさんこんにちは!



最近取り組んでいるホームオートメーション無線デバイス(通常は433.92 MHz)を操作するためのJAVAライブラリを共有したいと思います。 本格的な使用にはまだ十分ですが、ホームクラフトにはちょうどいいです

githubのアドレスはgithub.com/eschava/rf-protocols-javaです



作成の前提条件



購入後、CubietruckはArduinoで実行されたスマートホームのすべてのタスクを転送することにしました。 基本的には、ホームオートメーションデバイス(ソケット、センサー、暖房)への無線メッセージの受信と送信です。

ネットワークで見つかったすべての処理は、Raspberry Piに対してのみ行われたか、特定の機能に対してはあまりにもシャープにされました。 したがって、私は使い慣れた開発言語(Java)を使用してすべてを自分で実装し、可能な限り柔軟で拡張可能なものにすることを決定しました(Javaの慣例である工場の登録など)



GPIOポート経由でRFデバイスを操作するために、私はすべてが実行されているプラ​​ットフォームから抽象化できる、あまり知られていないが有望なライブラリlibbulldogを選択しました。 現在(理論的に)Raspberry Pi、BeagleBoard、Cubieboardをサポートしていますが、使用可能なCubieboard3(別名Cubietruck)でのみテストされています。

Raspberry PI Pi4jの一般的なライブラリもサポートされています(理論上)が、残念ながら、実際に試してみることができませんでした







主なアイデア







実装されるもの



現在、以下のプロトコルを実装しています

-オレゴンV2(THN132N、THR238NF、THWR800、THGN132Nなどの温度、湿度センサー)

-オレゴンV3(温度、湿度センサー)

-オレゴンSL109(温度、湿度センサー)

-フクロウ(電流センサーOwl Micro +)

-PT2262 / PT2272(中国語の無線リレー、対応するarduinoライブラリはRCスイッチと呼ばれます)

-RemoteSwitch(中国の無線リレー、有名なArduinoライブラリに似た名前)

プラス

-プロトコルの研究と診断のためのいくつかのユーティリティ(下記参照)

-スマートホームシステムとのシームレスな統合のためのMQTTクライアント(以下を参照)

計画は、できるだけ多くの一般的な無線プロトコルのサポートを追加することです(まず、NooliteとLa Crossが欲しいです)



建築



無線プロトコルの使用は、3つのレベルに分けられます。

-レシーバーからGPIOポートに直接送信される信号(信号レベル)

-信号はパケットに変換されます。 これは通常、ビットのシーケンスです(パケットレベル)

-パケットが分析され、メッセージになります。 メッセージには既に特定のユーザープロパティ(温度、コマンドなど)があります(メッセージレベル)



各レベルは隣接するレベルから独立しており、再利用できます(たとえば、多くのデバイスで信号からパケットへの変換は多くの場合同じですが、パケットからのメッセージの形成は既に一意です)



多くの定数(パルス幅など)はデバイスごとに異なる可能性があるため、すべてのプロトコルは.propertiesファイルを使用して最大限に構成できます。



プロトコル研究ユーティリティ



現時点では2つあります。 PT2262チップ(aliexpressで最も人気のある)を使用して、無線リモートコントロールからのプロトコルを処理するためにそれらの両方を使用する方法を示します。



-内訳:受信機から来るパルスの長さを調べるのに役立ちます。 原則として、デバイスが空中にデータを送信しない場合、レシーバーはGPIOポートで異なるパルス長のノイズを受信しますが、トランスミッターのボタンを押すか、信号を待つと、受信したパルスが継続的に特定のグループに分類されることがわかります。 たとえば、電源ボタンの場合、プログラムはそのようなデータを出力します(マイクロ秒単位のパルス持続時間)。

 cubie @ Cubian:〜/ gpio $ sudo java -cp bulldog.cubieboard.jar:rf-protocols-0.1-SNAPSHOT.jar -DpropertiesFile = Breakdown.properties -Dlistener.groupCount = 20 -Dlistener.maxLength = 2000 rf.protocols.analysis .breakdown.BreakdownMain
 <100 <200 <300 <400 <500 <600 <700 <800 <900 <1000 <1100 <1200 <1300 <1400 <1500 <1600 <1700 <1800 <1900 <2000> = 2000
 2054 1099 573223137 92 45 48 13 12 9 8 5 3 5 6 1 0 2 1 30
 2399 1417 686317155111 52 30 6 2 7 0 3 2 1 0 0 1 1 1 7
 2479 1396 675319189103 59 28 5 6 4 0 1 0 1 2 3 0 0 1 5
 2333 1351 751 316 199 91 34 26 9 7 2 2 2 2 1 3 2 0 1 1 7
 2307 1254712297175108106 20 6 5 1 3 1 0 0 1 2 2 0 1 9
 1249 714 368164182158 33 12 3 6 0 4 10110 63 2 2 0 1 0 12
 1 0 1 0 171 232 0 0 0 0 0 1 0 252 127 3 0 0 0 0 22
 0 0 0 0 173 226 0 0 0 0 0 0 1 247 131 2 0 0 0 0 21
 1 0 1 0 201196 0 0 0 0 0 0 1 217 156 4 0 0 0 0 20
 0 0 0 0 216188 0 0 1 0 0 0 0 218159 4 0 0 0 0 22
 0 0 0 1 195 205 0 0 0 0 0 1 0 227 152 2 0 0 0 0 21


ラインの前半-ノイズ、2番目-キーフォブのボタンが固定されている

ユーティリティの出力から、パルスが次のグループに分類されることが明らかになります:(400、600)および(1300、1600)(グループを少し試してみると、グループ(15000、16000)からのパルスがまだあることがわかります)

ここで、これらのグループからのパルスがどのように交互になるかを理解してみましょう。 このためには、次のユーティリティが必要です



-間隔:パルス間隔に名前を付けて、その順序を確認できます。 最初のグループに「0」、2番目に「1」、最後に最も長い「S」という名前を付けます。 そして、少なくとも20パルスが連続してこれらの間隔に入るグループのみを出力します。

 cubie @ Cubian:〜/ gpio $ sudo java -cp bulldog.cubieboard.jar:rf-protocols-0.1-SNAPSHOT.jar -DpropertiesFile = pt2262.properties rf.protocols.analysis.intervals.IntervalsMain
 [678] 10010101100110101001010 [1296](23)
 [-1] 01011001010101011001010110011010100101010101010S0101011001010101011001010110011010101101010101010S010101100101010101100101011000101011010101010100101010110010101010101101010101010101010101010101010
 [770] 100101011001101010010101010 [1281](27)
 [3418] S0101011001010101011001010110011010100101010101010S0101011001010101011001010110011010100101010101010S01010110010101010110010101100010100101010101010010101011001010101101101101101101101101101101101101101101101101101101101181011011011To1011


(説明-角括弧内の数字は、シーケンスの前後のパルスの持続時間です。シーケンスが途中で中断された理由を理解するのに役立つ場合があります。括弧内の数字は、シーケンス内の信号の数です)



Sと呼ばれるパルス間のシーケンスは1つのボタンに対して常に同じであり、次のように見えることがわかります。

01010110010101010110010001011001101010010101010101010010

異なるボタンから取得したシーケンスを調べると、これらは常にキャラクターのグループであることがわかります

0101

1010

0110

プラス最後に常にゼロ(同期)



3進数システムのように見えます。 それらに0.1 2という名前を付け、シーケンスを取得します

電源ボタンの場合は020020221000

020020220100オフボタン



ジョブが完了したと想定できます。



MQTTクライアント



ライブラリには、MQTTクライアントも含まれています。これは、既製のスマートホームシステム( openHABで計画)とのシームレスな統合のための別個のアプリケーションとして起動できます。

顧客:

-受信したすべてのデータのMQTTメッセージを自動的に送信します。 たとえば、オレゴンのデバイスから取得した温度はトピックごとに公開されます

rf / OregonV2 /温度

-rf / send / PROTOCOLトピックをリッスンし、トピックから受信したデータとともにラジオコマンドを送信します。 たとえば、前の段落のキーフォブからのコマンドをシミュレートするには、コマンド020020221000をトピックrf / send / pt2262に送信する必要があります

打ち上げ:

sudo java -cp bulldog.cubieboard.jar:mqtt-client-0.4.0.jar:ST4-4.0.8.jar:rf-protocols-0.1-SNAPSHOT.jar:antlr-runtime-3.5.2.jar -DpropertiesFile=mqtt.properties rf.protocols.external.paho.MqttMain









ライブラリに含まれるスタンドアロンアプリケーションを実行する方法



現時点では、ライブラリに含まれるすべてのスタンドアロンアプリケーションは、main()メソッドを使用して通常のJavaアプリケーションとして起動されます。

また、誰もが設定ファイル(ピン、ピンを操作するためのライブラリなど)を指定するための-DpropertiesFileパラメーターを持っています。 .propertiesファイルの例はgithub( github.com/eschava/rf-protocols-java/tree/master/examples )にあります



前述のアプリケーションに加えて、次のものがあります。



受信したすべてのメッセージをコンソールに出力します

sudo java -cp bulldog.cubieboard.jar:rf-protocols-0.1-SNAPSHOT.jar -DpropertiesFile=protocols.properties rf.protocols.analysis.PrintAllMessages







すべての受信パケットの出力(メッセージよりも低いレベルのデータ。通常はパケットの16進ダンプです)

sudo java -cp bulldog.cubieboard.jar:rf-protocols-0.1-SNAPSHOT.jar -DpropertiesFile=protocols.properties rf.protocols.analysis.PrintAllPackets







プロトコルメッセージの送信

sudo java -cp bulldog.cubieboard.jar:rf-protocols-0.1-SNAPSHOT.jar -DpropertiesFile=sendmessage.properties -Dprotocol=RemoteSwitch -Dmessage=111110222220 rf.protocols.analysis.SendStringMessage









すべてのようです

レビュー、バグレポート、機能リクエスト、その他の恐ろしい言葉を待っています



All Articles