センスウェイのLoRaWANサービスを使ってみる　その２

引き続きLoRaWANデバイスからのデータを受信してみます。

[前回の記事はこちら](https://qiita.com/akira-tt/items/28e999435e2d8fb047b9)

# mqttクライアント

センスウェイのサービスでは、LoRaWANサーバが受信したデバイスからのデータはどこにも蓄積されず、下流のmqttクライアントによって即座に受信される必要があります。具体的には、センスウェイが用意するmqttサーバに対し、所定のtopicでサブスクライブすることになります。

## クライアントの準備

ここではクライアントとして実績のある[mosquitto](https://mosquitto.org)を使うことにしましょう。それぞれの環境に合わせてインストールすればいいですが、折角なので（意味不明）それ用のDocker imageを用意してみました。ここではdocker関連の説明は省略しますが、[説明に従って](https://github.com/greennote/docker-mosquito-client)作業すれば手軽にmosquittoクライアントを実行することができるようになります。

# サブスクライブとデータの受信

## サブスクライブの仕様

センスウェイのドキュメントによれば、サブスクライブの仕様は下記の通りとなっています。

項目| 内容|
---|---
host| mqtt.senseway.net
port| 1833
username| \<username>
passwd| \<password>
topic| lora/\<username>/\<devEUI>

topicの```<username>```、```<devEUI>``` についてはワイルドカード（#、+）の利用が可能です。topicの```<devEUI>``` 以下についてもいろいろ定義されていますが、まずはデバイスからのデータを受け取る```lora/\<username>/\<devEUI>/rx``` を使うことにします。

## サブスクライブしてみる

先程作成した環境にログインし、実際のデータをサブスクライブしてみました。

```
$ docker run --rm -it test/mosquitto-client /bin/sh
/ # mosquitto_sub -h mqtt.senseway.net -p 1883 -u <userneme> -P <password> -t lora/<username>/# -v -d
Client mosqsub|7-714e1aec8fde sending CONNECT
Client mosqsub|7-714e1aec8fde received CONNACK
Client mosqsub|7-714e1aec8fde sending SUBSCRIBE (Mid: 1, Topic: lora/<username>/#, QoS: 0)
Client mosqsub|7-714e1aec8fde received SUBACK
Subscribed (mid: 1): 0
```

ワイルドカード（#）により、LoRaWANサーバから送られてくる全データを受信するように設定します。また動作状況を観察するため、デバッグフラグ（-d）を立てています。

## データを送ってみる

この状態でデバイスからデータを送信してみます。シリアルコンソールからデバイスに接続し、JOINしてから

```
> lorawan tx ucnf 1 0102030405060708090a
>> Ok
>> tx_ok
```

としてデータを送信してみます。するとmqttクライアント側には

```
Client mosqsub|7-714e1aec8fde received PUBLISH (d0, q0, r0, m0, 'lora/<username>/<devEUI>/rx', ... (209 bytes))
lora/<username>/<devEUI>/rx {"gw":[{"date":"2018-04-21T01:18:02.493763Z","rssi":-42,"snr":10,"gwid":"<gwid>"}],"mod":{"fq":927.4,"cnt":11,"data":"0102030405060708090a","mt":"ucnf","devEUI":"<devEUI>","dr":"2","port":1}}
```

と表示されており、意図したとおりにデータが送信／受信されていることが確認できました。受信したデータを順次確認してみると

- データを受信したゲートウェイの情報（配列）
    - 受信時刻
    - RSSI（ゲートウェイ・デバイス間の信号強度）
    - SNR（信号雑音比）
    - ゲートウェイID
- モジュールから送信されたデータの内容
    - 周波数
    - データカウント（LoRaサーバが該当デバイスから受信したデータの総数）
    - データ本体
    - ACK確認の有無
    - devEUI
    - DR値
    - ポート

となっていることが分かります。ここでDR値というのが出てきますが、これは一度に送れるデータのサイズを表すもので[^1]、LoRaWANサービスにおいてはとても重要な値になります。今回のケース、すなわちデバイスの初期設定ではDR=2、すなわち一度に11バイトのデータが送れる設定になっているようです。

では、12バイト以上のデータを送ろうとしたらどうなるのでしょうか？

```
> lorawan tx ucnf 1 0102030405060708090a0b0c0d0e0f
>> invalid_data_length
```

ということになり、デバイス側から送信が拒否されます。ではDR値を大きくして最大サイズを増やすとどうでしょうか。

```
> lorawan set_dr 3
>> Ok
> lorawan tx ucnf 1 0102030405060708090a0b0c0d0e0f
>> Ok
>> tx_ok
```

となり、ちゃんとDR値に基づいた制御がされていることが確認できます。受信側では

```
lora/<username>/<devEUI>/rx {"gw":[{"date":"2018-04-21T01:40:25.50101Z","rssi":-42,"snr":11.5,"gwid":"<gwid>"}],"mod":{"fq":923.4,"cnt":12,"data":"0102030405060708090a0b0c0d0e0f","mt":"ucnf","devEUI":"<devEUI>","dr":"3","port":1}}
```

となっていて、見事15バイトのデータが送受信できたことが確認できました。なお、DR値ごとの最大データサイズは下記の通りです。

DR値| 最大サイズ|
---|---
2| 11バイト
3| 53バイト
4| 125バイト
5| 242バイト

# 次は

アプリケーション側からデバイスへのデータ送信を試してみましょう。

[^1]: 正確には無線のパラメータを表す値で、その結果として送れるデータのサイズや到達性能が決まります