まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

2015年07月

前回の、このブログエントリ↓の続きです:


Mosquitto クライアントを使って、IBM IoTF(IoT Foundations) 内の QuickStart MQTT ブローカーにメッセージをパブリッシュする手順が分かりました。 今回は同じ手続きを自分がプログラミングするアプリケーションから実行するコードを紹介します。これができると、実際のデバイスやスマホ、PC などから取得した情報を自分なりに加工した上で QuickStart に送信して、Node-RED フローエディタでも使えるようになります。 なお、今回は Java でのアプリケーションコーディング例を紹介します。


ではその手順を紹介します。まず Java で MQTT プロトコルを扱うため、便利な Paho のライブラリをあらかじめダウンロードしておきます。

ちなみに Paho は MQTT のオープンソース実装を目的とした Eclipse プロジェクトの1つです。Java に限らず、非常に多くの言語向けに MQTT ライブラリが提供されています。

(2015/08/01 追記: 実際に利用可能な Paho のライブラリの入手場所が間違っていました)
では Paho のリリースディレクトリから mqtt-client-0.4.0.jar をダウンロードします:
https://repo.eclipse.org/content/repositories/paho-releases/org/eclipse/paho/mqtt-client/0.4.0/


では Paho のリリースディレクトリから最新の org.eclipse.paho.client.mqttv3-*.*.*.jar ファイルをダウンロードします:
https://repo.eclipse.org/content/repositories/paho-releases/org/eclipse/paho/org.eclipse.paho.client.mqttv3/


ダウンロードした org.eclipse.paho.client.mqttv3-*.*.*.jar を使って、以下の様なソースコードを作成します:
import org.eclipse.paho.client.mqttv3.IMqttDeliveryToken;
import org.eclipse.paho.client.mqttv3.MqttCallback;
import org.eclipse.paho.client.mqttv3.MqttClient;
import org.eclipse.paho.client.mqttv3.MqttConnectOptions;
import org.eclipse.paho.client.mqttv3.MqttDeliveryToken;
import org.eclipse.paho.client.mqttv3.MqttException;
import org.eclipse.paho.client.mqttv3.MqttMessage;
import org.eclipse.paho.client.mqttv3.MqttTopic;

public class SampleQuickstartPublisher implements MqttCallback {
  MqttClient myClient;
  MqttConnectOptions connOpt;

  static final String BROKER_URL = "tcp://quickstart.messaging.internetofthings.ibmcloud.com:1883";
  static final String M2MIO_THING = "91a19d112233"; //. DeviceId

  /**
   * connectionLost
   */
  @Override
  public void connectionLost(Throwable t) {
    System.out.println("Connection lost!");
  }

  /**
   * MAIN
   */
  public static void main(String[] args) {
    SampleQuickstartPublisher smc = new SampleQuickstartPublisher();
    smc.runClient();
  }

  /**
   * runClient
   */
  public void runClient() {
    // MQTT クライアントのセットアップ
    String clientID = "d:quickstart:MyDevice:" + M2MIO_THING; // クライアントID
    connOpt = new MqttConnectOptions();

    connOpt.setCleanSession(true);
    connOpt.setKeepAliveInterval(30);

    // ブローカーに接続
    try {
      myClient = new MqttClient(BROKER_URL, clientID);
      myClient.setCallback(this);
      myClient.connect(connOpt);
    } catch (MqttException e) {
      e.printStackTrace();
      System.exit(-1);
    }

    System.out.println("Connected to " + BROKER_URL);

    // トピックの指定
    String myTopic = "iot-2/evt/myeventtype/fmt/json";
    MqttTopic topic = myClient.getTopic(myTopic);

// 10回メッセージを送信する for (int i=1; i<=10; i++) { String pubMsg = "{\"d\":{\"intval\":" + i + "}}"; // 送信メッセージのJSON int pubQoS = 0; MqttMessage message = new MqttMessage(pubMsg.getBytes()); message.setQos(pubQoS); message.setRetained(false); // メッセージをブローカーにパブリッシュ System.out.println("Publishing to topic \"" + topic + "\" qos " + pubQoS); MqttDeliveryToken token = null; try { // パブリッシュ token = topic.publish(message); // ブローカーへの送信完了を待つ token.waitForCompletion(); Thread.sleep(1000); } catch (Exception e) { e.printStackTrace(); } } // ブローカーから切断 try { myClient.disconnect(); } catch (Exception e) { e.printStackTrace(); } } @Override public void deliveryComplete(IMqttDeliveryToken token) { } @Override public void messageArrived(String topic, MqttMessage message) throws Exception { } }

QuickStart の MQTT ブローカーホストは quickstart.messaging.internetofthings.ibmcloud.com です。ここに 1883 番ポートでアクセスします。またこの例ではデバイスID を "91a19d112233" という固定値にしていますが、実際にはここはユニークな値(MAC アドレスなど)を使ってください。

このプログラムの肝になっているのは runClient() 関数部分です。この runClient() の中でまず MQTT クライアントインスタンスを生成しています。そして
 d:quickstart:MyDevice:(デバイスID)
というクライアント ID を指定して、MQTT ブローカーに接続しています。

接続後は "iot-2/evt/myeventtype/fmt/json" というトピックを指定しながら for ループで10回メッセージを送信(パブリッシュ)する、という内容の処理を実行するプログラム構成になっています。


そして、Node-RED でもアプリケーションを用意します。Node-RED アプリケーションは前回 Mosquitto で動作確認した時と同じ内容で、"91a19d112233" (Java のプログラムで指定しているデバイスIDと同じもの)というデバイス ID を指定した IBM IoT ノードを用意し、デバッグノードに接続しただけのものです。このアプリを Deploy して、動作させておきます:
2015073101


ここで上記の Java プログラムを実行してみます。ソースコード内のデバッグライト(青文字部分)が実行され、コンソールに接続時と送信時のメッセージが表示され、処理が実行されたことが分かります:
2015073102


同時に Node-RED 側のデバッグタブを見ると、いままさにこの Java プログラムからパブリッシュされたメッセージを受け取って表示する様子が分かります。1秒毎にメッセージが送信されて、計10回のメッセージが送られた所で止まります:
2015073103


よく見ると、デバイスタイプが "MyDevice"、イベントタイプが "myeventtype" という文字列になっています。これは MQTT パブリッシュをする際のクライアント ID とトピックで指定しているものなので、これらの値を変更したい場合はクライアント ID やトピックを変更すればよい、ということもわかりました。

というわけで、Java のプログラムから IBM IoT Foundations の QuickStart MQTT ブローカーにメッセージを送信し、その内容を Node-RED で受け取る、というオペレーションが実現できることが確認できました! これを応用すると、とりあえず何らかのデータを MQTT QuickStart に送り、Node-RED で処理して例えば DB に格納するとか、リアルタイム処理を加えるといった Node-RED 得意の土俵で扱うことができるようになりますね。



以前のブログエントリでオープンソース MQTT 環境である Mosquitto の導入方法を紹介しました。このブログエントリではラズベリーパイ用と CentOS 用の紹介をしていますが、Mosquitto 自体には Windows などのバイナリも用意されていて、多くの環境で使えます:
ラズベリーパイにオープンソース MQTT の Mosquitto をインストールする


この Mosquitto を使って、IBM IoTF(IoT Foundations) 環境に用意されている QuickStart と呼ばれる MQTT ブローカーに任意のメッセージデータを送る方法を紹介します。センサーシミュレータなどを使って QuickStart に送られたデータを集めて取り出して加工して・・・という作業は Node-RED 環境があれば簡単ですが、その前段になるデバイスから QuickStart にデータを送るにはどうするか?という手段の紹介です。今回は MQTT クライアント(パブリッシャー)を使った例を紹介します。


準備として、まずは上記のリンク先の情報から、Mosquitto のパブリッシャー(mosquitto_pub)をインストールする所までは済ませておいてください。今回は mosquitto_pub を使って IoTF QuickStart にデータを送信します。

次に、IoTF QuickStart に送られてきたメッセージデータを確認するための環境を整えておく必要があります。IBM Bluemix の IoT Foundations Starter ボイラープレートや Node-RED Starter ボイラープレートを使って、Node-RED 環境を用意してください。この辺りの詳しい手順がよく分からない場合はこちらを参照してください:


Node-RED 環境ができたら、次のような IBM IoT ノードと Debug ノードをつなげただけの、シンプルなフローを作成してください:
2015072701


IBM IoT ノードをダブルクリックし、このような属性値に設定します。Authentication を "QuickStart" に、Input Type を "Device Event" に、そして Device Id には任意のユニークな文字列(下の例では "91a19d112233" にしていますが、同じものを使わないでください。実際にはネットに接続された機器の MAC アドレスを想定しています)を入力します。最後に Name に適当な名前を入力して OK をクリックします:
2015072702


Debug ノードの属性は以下のようにします。Output はデフォルトの payload のままでも実用的にはいいのですが、今回は送られてくるメッセージ全体を確認したいので "complete msg object" に変更して OK をクリックします。最後に "Deploy" をクリックして、デプロイまで済ませておきます:
2015072703


これで Device Id が(今回の例であれば) "91a19d112233" に設定されたデバイスから QuickStart に送られてくるデータを取得してデバッグタブに表示する、というアプリが動いている状態になりました。

では Mosquitto を使って、そのようなデータを QuickStart にパブリッシュしてみます。Mosquitto を導入した環境にログインし、ターミナルのプロンプトから以下のようなコマンドを実行します:
$ mosquitto_pub -h quickstart.messaging.internetofthings.ibmcloud.com -t "iot-2/evt/myeventtype/fmt/json" -m '{"d":{"name1":"stringValue","name2":10}}' -i d:quickstart:MyDevice:91a19d112233

このコマンドは、
 (1) quickstart.messaging.internetofthings.ibmcloud.com という MQTT ブローカーに対して、
 (2) "iot-2/evt/myeventtype/fmt/json" というトピックを指定し、
 (3) '{ "d": { "name1":"stringValue", "name2": 10 } }' という JSON 形式のメッセージを、
 (4) d:quickstart:MyDevice:91a19d112233 というクライアント ID で
パブリッシュする、という処理内容のコマンドです。

※ちなみに IoTF では送信メッセージは '{ "d": { (ここが実際の送信内容) } }' という JSON 形式で送付することを推奨しています。

2015072704


このコマンドを実行した直後、Node-RED アプリのデバッグタブにメッセージが表示されるはずです! 実行したパブリッシュコマンドのメッセージが届いた証拠です:
2015072705


ここで届いたメッセージはこのような内容になっているはずです:
{
 "topic": "iot-2/type/MyDevice/id/91a19d112233/evt/myeventtype/fmt/json",
 "payload": {
  "d": {
   "name1": "stringValue",
   "name2": 10
  }
 },
 "deviceId": "91a19d112233",
 "deviceType": "MyDevice",
 "eventType": "myeventtype",
 "format": "json",
 "_msgid": "6e152038.91eae" 
}

(3) で指定したメッセージは、"payload" の中身として届けられています。また (2) で指定したトピックは "topic" と、"eventType" の値として表示されています。また (4) で指定したクライアント ID は "deviceId""deviceType" として届いていることもわかります。"deviceType" と "eventType" はパブリッシュする側で任意に設定できる、デバイスとイベントの分類用文字列です。


ということは、上記の mosquitto_pub コマンドで実行した MQTT パブリッシュ処理に相当するコマンドを quickstart.messaging.internetofthings.ibmcloud.com に対して実行することで QuickStart にメッセージを送ることができる、ということが分かりました。QuickStart にメッセージを送ることができれば、後は Node-RED を使って便利に処理できます。

このコマンドをプログラミング言語から実行するにはどのようにすればよいのか、それは別途紹介させていただくつもりです。
 

自宅サーバー派の人は、独自ドメインを所有して使っているケースも多いと思います。自分もその一人です。

自宅サーバーで独自ドメインを使う場合、その多くはダイナミック DNS を使うことになると思っています。自宅のネットワーク環境は固定 IP アドレスではなく、大抵動的 IP アドレスであり、この割当はいつ変わるかわかりません。つまり固定の DNS で一度設定しても、IP アドレスの割り当てが変わってしまうと、再度新しい設定を DNS サーバーに知らせるまでは使えなくなってしまいます。そのため DNS を固定ではなく、動的に変更する前提で対応できるよう、ダイナミック DNS サービスを使うケースが大半になります。

これまで自分はダイナミック DNS 用の専用のクライアントアプリをインストールして、自分のアカウントを設定して、それを定期的に実行するよう設定して・・・ と面倒な手続きをしていました。 が、ダイナミック DNS サービスとして MyDNS.jp を使っている場合であれば、普通に Linux の cron でコマンドを実行するだけで定期的な IP アドレス更新ができることが分かりました。


具体的にはこんな感じです:
# crontab -e

(以下の1行を追加して保存)
*/10 * * * * wget -q -O /dev/null http://(mydns.jp のマスターID):(mydns.jp のパスワード)@www.mydns.jp/login.html


MyDNS.jp のアカウント(マスターIDとパスワード)を持っていることが前提になりますが、それらの情報をセットした URL に対して10分おきに HTTP GET リクエストを発行する、という内容のコマンドを指定しています。これであっさりと繋がってしまいました。。

自分の場合は、これを自宅ネットに接続したラズベリーパイに設定しています。自宅のラズベリーパイが自宅ネットワークのダイナミック DNS を定期的に設定してくれるクライアントとしての役目を果たしている、ということになります。なかなかいいラズベリーパイの使い方だと思ってます。


FireFox を使っていて https のサイトを訪れた時に「安全な接続ができませんでした」というエラーページに出くわすことがあります。それも選択肢が「再試行」と「報告」しかなくて、例外追加みたいな対応もできないケースです:
2015072501


よく見ると SSL が安全ではない、みたいなメッセージも書かれてます。この件に関する Mozzila としての見解はこちらです。昨年ですが、通称「プードルアタック」と呼ばれる脆弱性が SSL v3 に見つかり、SSL v3 は安全ではなくなってしまいました。その対策としてデフォルトでこのプロトコルを使ったサイトをブロックします、とのことです:
https://support.mozilla.org/ja/kb/enable-ssl-fix-cannot-connect-securely-error


まあ何もしないのはまずいと思うし、Mozzila の言いぶんはわかる。利用者には罪はなくて、サイトを提供する側に(安全ではない)SSL v3 を使わないでほしい、ということだと思っています。

とは言っても、すぐに対応できるとは限らないケースもあります。例えばサーバーイメージが仮想的に提供されているような場合は、その仮想イメージで SSL v3 を使っていることもあります。仮想イメージをすぐに更新してほしいと言われても困るし、仮に仮想イメージそのものは更新できたとしても既に仮想環境内で使われているイメージをどうやって更新するか、という問題だってあります。要はサイト提供側だけにこの問題の責任を追わせるのには無理があるのかな・・・と。

では諦めるしかないのか、というとそんなこともありません。ブラウザで利用するユーザーの自己責任にはなりますが、このような SSL v3 のサイトにアクセスするように FireFox の設定を変更することもできます。以下にその方法を紹介しますが、SSLv3 が安全ではないことに変わりはないので、社内の環境など、本当に安全が保証されているサイトでのみ、また目的のサイトへのアクセスが終わったらすぐに設定を元に戻るなど、自己責任で使ってください。

ではその設定方法を紹介します。まず FireFox を起動して、アドレス欄に about:config と入力します。「動作保証外である」という警告メッセージが表示されますが、「細心の注意を払って使用する」ボタンをクリックします:
2015072502


すると FireFox の挙動に関わる各種設定項目の一覧が表示されます。かなり大量にあるので、ここから目的の項目を探すのは大変なので、検索をします:
2015072503


「検索」と書かれたフィールドに "security.ssl3.dhe" と入力すると、少しずつ項目が絞られていきながら、ここまで入力した時点で2つの項目だけが表示されているはずです。またどちらも初期設定値の true が設定されているはずです:
2015072504


これら2行の項目の設定値を false に変更します。変更するには各行をダブルクリックすることで変更できます:
2015072505


この状態で先程エラーに成ったページに再度アクセスすると、ちゃんと見れるようになるはずです。



繰り返しになりますが、この設定状態は必ずしも安全ではないため、目的のページを見終わった後は、2箇所とも設定を元通りに戻しておくことを強くおすすめします:
2015072506


ちなみにプードルアタックとその対策についてはこちらで詳しく書かれていたので、是非参照してください:
SSLv3 の脆弱性 POODLE への対策を行う


IBM が Compose を買収しました:
IBM、DBaaSプロバイダーのComposeを買収

Compose は MongoDB や Redis といったオープンソースデータベースを DBaaS で提供していた企業です。Compose のサービスは早速 IBM Bluemix に統合され、既に Bluemix サービスとして個々の DBaaS が選択・利用できるようになっています:
2015072601


MongoDB や Redis に関しては(データベースとしては)既に Bluemix で使えるようになっていました。が、今回の統合で新たに Bluemix で使えるようになったサービスもあります。

それが ElasticSearch です。高速な NoSQL データベースでもあり、ユーザーの多いオープンソース全文検索エンジンとして知られていましたが、ついにこの ElasticSearch の DBaaS が Bluemix のサービスの1つとして選択できるようになりました:
2015072602


特に、これまで Bluemix には検索エンジンサービスが搭載されていなかったため、アプリケーション内での検索機能を作ろうとすると、外部のサービスを使ったり、自分で個別に検索機能を実装する必要がありました。これからは検索エンジンも Bluemix 内のものが(しかも ElasticSearch が)使えるようになります!

一人のプログラマーとしての立場でも、非常に嬉しく楽しみな新サービスです。


このページのトップヘ