Alljoyn：組み込み開発者の外観。 パート2：助けてくれるLinux

Alljoynサイクルの前の部分：組み込み開発者を見てください。 パート1：知る



AllJoynプロトコルに従って機能する「本物の鉄」を取得する方法の話を続けます。 サイクルの最終目標は、「スマートWi-Fi電球」のプロトタイプを入手することです。 そして、これはまさに「プロトタイプ」です。なぜなら、電球の電源部分の実装には触れないからです。これは、フレームワークや制御方法とは関係のない別の大きなトピックだからです。 したがって、SAMD21-XPROデバッグボード上のLEDに限定します。



フレームワークのマイクロコントローラーへの移植を開始する前に、開発プロセスで貴重な支援を提供する補助ツールを扱います。 原則として、AllJoynはクロスプラットフォームフレームワークであり、好みのバージョンのオペレーティングシステムを自由に使用できます。 私はLinux（Ubuntu）を使用しました-それは私にとって馴染み深いからです。

ソースをダウンロードし、コンパイルして試してください

これを行うには、公式Webサイトの指示の 4.1項の指示に従ってください。 確かに、この指示はGitを使用してソースをダウンロードすることを示唆していますが、この方法ではフレームワークはコンパイルを拒否しました（それ以降状況は変わる可能性があります）。したがって、公式サイトから1つのフォルダーにソースをダウンロードし、必要な構造に従ってレイアウトしました。 ソースをalljoyn / lsfディレクトリのホームフォルダーに配置します。

次のファイル構造を取得する必要があります。

~/alljoyn/lsf

|------ core

| |------ service_framework ( Lighting Service Framework Source)

| |------ ajtcl ( Thin Core Source)

| |------ alljoyn ( Standard Core Source)

|------ base_tcl

|------ base ( Base Services Source)







コンパイルには、追加のプログラムが必要です。 私たちはそれらを置きます：

 sudo apt-get install build-essential libgtk2.0-dev libssl-dev xsltproc ia32-libs libxml2-dev sudo apt-get install python sudo apt-get install scons sudo apt-get install libssl-dev
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

service_frameworkフォルダーに移動して、プロジェクトを組み立てます。

 cd ~/alljoyn/lsf/core/service_framework scons WS=off
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私はLinuxの専門家ではありませんが、Linuxを使用する過程で、異なるコンピューターで同じタスクを実行する2つの同一のソリューションはなく、それぞれの場合に常に微妙な違いがあると強く感じていました。 個人的には、すべてがうまくいく前に長い苦しみがありましたが、この記事の枠組みで自分の冒険を説明することにはあまり意味がありません。 先に進むと、最終的に次のように表示されます。

 scons: Reading SConscript files ... BULLSEYE_BIN not specified Using OpenSSL crypto GTEST_DIR not specified skipping common unit test build BULLSEYE_BIN not specified GTEST_DIR not specified skipping About Service unit test build GTEST_DIR not specified skipping alljoyn_core unit test build GTEST_DIR not specified skipping LSF unit test build scons: done reading SConscript files. scons: Building targets ... ... scons: done building targets.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、多くの多くのものがそこでコンパイルされます。 3つのプログラムが必要です。

1. lamp_service- 「スマート電球」のシミュレーター（以降、本文ではこのプログラムを「電球」と呼ぶことが多い）。 フレームワークのシン（ライト）バージョンを使用します。 サイクルの第3部で、このプログラムをAtmel SAMD21マイクロコントローラーに移植します。 また、このプログラムはLuminaire Androidアプリケーションの基礎です。 〜/ alljoyn / lsf / core / service_framework / build / linux / thin_core_library / lamp_service / binにあります
2. lighting_controller_serviceは、Thinデバイスのルーターです（最初の部分の理論部分を読んでください）。 フォルダ内にある〜/ alljoyn / lsf / core / service_framework / build / linux / standard_core_library / lighting_controller_service / bin
3. lighting_controller_client_sampleは、電球を制御する「コントロールパネル」です。 前の記事で言及したLSF Androidアプリケーションの基礎となるのは、このプログラムです。 〜/ alljoyn / lsf / core / service_framework / build / linux / standard_core_library / lighting_controller_client / samplesにあります

したがって、以前の記事の「抽象的」な写真をより実質的な形で提示できます。





次にWireSharkをオンにし、lamp_serviceを実行して、何が起こるかを観察します。

 cd ~/alljoyn/lsf/core/service_framework/build/linux/thin_core_library/lamp_service/bin ./lamp_service
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ネットワークトラフィックの流れにdrれないようにするには、WireShark udp.port == 5353 ||にフィルターを追加します udp.port == 9956



使用可能な3つの方法すべてを使用して、電球がルーターを検索してプレゼンテーションデータをネットワークに送信することがわかります（マルチキャスト224.0.0.113:9956、マルチキャスト224.0.0.251パラグラフ353、ブロードキャスト：9956）。 この場合、ルーターがネットワーク上にないため、これらの試行は無駄になります。 ランプは定期的にこれらのパケットをネットワークに送信し、その後しばらく（最大40秒）「停止」します。



楽しみのために、パッケージの1つの内容を検討してください。 ブロードキャストAllJoynパッケージを調べます。 （最初の記事で説明したように）古くなった形式ですが、MDNSに比べて面倒ではないため、理解しやすいです。 MDNSは同様の原則を使用します。



ルーターがデバイスと「フレンド」になるかどうかを判断するために、ルーターはバス識別子を使用できます（または使用しない場合があります）。 開発者は、ルーターコードを記述するときに、自分が誰であるかを決定します。 IPアドレスとポートは、ルーターにTCP接続データを示すために使用されます。 この例では、電球がポート9955でTCPサーバーを上げたことがわかります。

ルーターを追加

基本的に、ルーターが物理的にlamp_serviceと同じデバイスにあるか、異なるデバイスにあるかは問題ではありません。 ただし、同じコンピューターでlighting_controller_service（このケースでは専用のルーター）を実行すると、マシン内で接続されるため、ネットワークカードを介した交換は機能せず、WireSharkはそれを修正しません。 交換を視覚化するには、別のコンピューターでlighting_controller_serviceを実行します。





今回見たように、「ランプの叫び」は聞​​かれることはなく、ルーターはUDP経由でランプを「聞いた」後、TCP経由で接続し、より詳細な情報を交換するかなり長いプロセスを実行しました。 原則として、フレームワークをうまく使用するためには、この交換の複雑さを理解する必要はまったくありません。これは同盟開発者の肩にあり、既製で提供されるためです。 しかし、よく見ると、あらゆる種類のBusHello、Introspectなどで同様のプロトコルのDBusを使用していることがわかります。 その結果、AllJoynは、さまざまなプロトコルとテクノロジーの一部で構成される一種のフランケンシュタインに似ています。 しかし、これは歌詞です。理論的には、深すぎるダイビングは必要ありません（この運命は私たちを追い越しませんでした。



電球がTCP経由でルーターと「友達になった」後、それ（電球）はUDPを介して「ノイズを発生」しなくなります。 現在、ルーターは彼女のためにそれを行い、コントロールパネルへのサービスを提供しています。 このプロセスは基本的に同じ方法で行われます-ルーターマルチキャストおよび/またはブロードキャストは、ローカルネットワークに電球（または電球）の存在を通知します。 コントロールパネルが必要な場合は、TCP経由で接続します。 そして、ここに重要な違いがあります。ルーターは、必要に応じて他のパネルも参加できるように、UDPを介して「ノイズを発生させる」ことを止めません。

実際、このような複雑な交換の組織が明らかになりました。 ルーターは、「深刻な」ハードウェアプログラムであり、TCP / IPスタックの通常の実装と、多数の同時接続のサポートを備えています。 電球の要件は削減されますが、マイクロコントローラーとスタックからは、1つのUDPソケットと1つのTCP接続をサポートする機能のみが必要です。



上記をコミックの形で想像してください。

「コントロールパネル」を接続します

今日の最後の演習は、上の画像から第4段階を実際に見ることです。 これを行うには、コントロールパネルを起動します。 これには別のターミナルインスタンスを使用します。 繰り返しますが、パネルがどの物理デバイスで起動されるかは関係ありません。

 $ cd ~/alljoyn/lsf/core/service_framework/build/linux/standard_core_library/lighting_controller_client/samples $ ./lighting_controller_client_sample
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、すべてが正しく行われた場合、パネルは電球を検出するはずです。



ここでは、UDPでブロードキャストされた電球の32ビットの一意の識別子が表示されます。 残念ながら、この記事の準備中にlamp_serviceのさまざまなインスタンスが起動されたので、スクリーンショットのこの識別子の値は一致しません-それは彼だと一言だけ言ってください。

lighting_controller_client_sampleを使用すると、検出に加えて、バルブを使用して多くの操作を実行できます（要求パラメーター、値の設定など）。 ご希望の場合は、彼女と「遊ぶ」ことができますが、記事を不当な割合に膨らませないように、この部分は省略します。 プログラムのインターフェースが友好的とはほど遠いことだけを警告します...しかし、これはAllJoynの先駆者の厄介な道で最も取るに足りない障害の一つです。



これについて、理論的、技術的、および道徳的な訓練が完了したことを考慮し、サイクルの3番目（おそらく最終）の部分で、ハードウェアでの「スマートバルブ」の実装とyoutubeの結果の撮影に進みます。

付録A. Linuxプログラムとモバイルアプリケーションのコンプライアンス

今日収集および使用されたプログラムは、 最初の記事で説明したAndroidモバイルアプリケーションと独自の共鳴を示しています 。 この瞬間を修正します。

Luminaireアプリケーションはlamp_serviceプログラムに対応しています。 3番目の部分でマイクロコントローラーに移植します。

LSFサンプルアプリはlighting_controller_client_sampleプログラムに対応しています。 その助けを借りて、電球を制御します。

付録B.サイクルの3番目の部分の問題の説明

私たちの研究の結果、コントロールパネル（LinuxのLSFサンプルアプリがインストールされ、 lighting_controller_client_sampleプログラムがインストールされた携帯電話）から検出および制御される物理デバイス（マイクロコントローラーとWi-Fiモジュールを使用したデバッグ）を取得したいと考えています。 ルーターとして、Linuxコンピューターで実行されているlighting_controller_serviceプログラムを使用します。



今日は以上です。おもしろかったと思います。 またね