Gatewayも接続済みで、デバイスからのパケットもゲートウェイで受信しているのに,アプリケーションから見えない

1

初めまして、直近でTTNゲートウェイを岐阜にて導入いたしました。
TTNのコンソールからゲートウェイは「接続済み」で
アプリケーションをTTNに追加し、デバイスも登録いたしました。
接続にはOTAAで、 デバイスEUI、 アプリケーションEUI、 App Keyを
HEXでコピーして、Auduino IDEにて、ソースを修正して
デバイス（ LoRa Mini Dev-JP）をUSB経由でプログラムの書き込みを行いました。

ゲートウェイでは、下記のようにパケットを受信している事がわかるので、
デバイスが正常に送信していることまではわかったのですが、なぜかTTNコンソールから ステータス「発見できません」のままになっております。

どこが問題なのかわからず、悩んでいるのですが、調べるヒントなど頂戴できないでしょうか？

stat update: 2019-12-06 04:10:36 GMT 690 packets received
CE0 Packet RSSI: -62, RSSI: -99, SNR: 14, Length: 15 Message:’@…~Kz).’
rxpk update: {“rxpk”:[{“tmst”:990089523,“freq”:923.2,“chan”:0,“rfch”:0,“stat”:1,“modu”:“LORA”,“datr”:“SF10BW125”,“codr”:“4/5”,“rssi”:-62,“lsnr”:14.0,“size”:15,“data”:“QA4BAACA8QIBB35LeinJ”}]}

2

下記ツール TTNCTLツールをダウンロードいただき、コマンドラインから試してみてください。

アプリケーションを制御しているHandlerがきちんと動いているかどうか？

3

ありがとうございます。
いちど、内容を確認いたします。

4

少し、時間がかかりましたが、アドバイスをいただき、内容を確認しました。
web画面上では、ハンドラは
ttn-handler-asia-se
となっておりますが、
コマンドで確認すると
INFO Using Application AppEUI=70B3D57ED0027714 AppID=omoiyaapp1
INFO Discovering Handler… Handler=ttn-handler-eu
INFO Connecting with Handler… Handler=eu.thethings.network:1904
FATAL Could not get devices. error=Could not get devices for application from Handler: Application not registered to this Handler: handler:application:omoiyaapp1 not found source=Wrap: /go/pkg/mod/github.com/!the!things!network/ttn/utils/errors@v0.0.0-20190516093004-b66899428ed5/errors.go:222
などとなており、euのハンドラーとなっておりました。

register --handler-id ttn-handler-asia-se
でハンドラーを指定しても変化がありません。

アプリやデバイスを削除し、再作成してもeuのままです。
なぜ、そうなってしまうのかもわかりません。
なかなか手ごわいですね・・

5

まだ、解決には至っておりませんが、後の方の為に記録を残させていただければと思います。

事例としては、下記のURLに近い症状です。

6

OTTAでつかわれているゲートウェイは、何をつかっていますか？

7

吉田様
おはようございます。
GW は Raspberry pi 3B+ と Dragino LoRa/GPS_HAT
となります。

センサーノードは
LoRa and IoT Development board
となります。

設定は次のサイトを参考にさせて頂きました。
https://www.rs-online.com/designspark/azurepart02-jp

現在は、OTTAではなく、ABPにて設定を行いました。
ゲートウェイの「トラフィック」を確認したところ、
センサノードのデバイスアドレスが表示されておりましたので、
センサーノードからゲートウェイまではの疎通は出来ているのではないかと思っております。
これは、OTTAでも同様にデバイスEUI及びアプリケーションEUIに関して、「トラフィック」に表示されることを確認しております。

認証に問題がある可能性を感じ、センサーノードの各キーはmsb及びlsbともに設定をして確認を行いましたが、ゲートウェイへのトラフィックは同様に表示できておりました。

最初にご指摘の通り、アプリケーションの内部でハンドラとデバイスのハンドラがうまく設定できていないのではないかと感じております。
WEBでのコンソールの表示で「ハンドラ」は「ttn-handler-asia-se」を表示しております。

8

３日前に国内でttn-handler-asia-seの不具合が報告されていましたが、私の環境では問題ありませんでした。3日前不具合もその日の午後に修復されていたようです。

アプリケーションにつなぐ、ペイロードのデコーダーをチェックしてみてください。わたしもよくここでトラブルが発生します。

9

吉田 様

アドバイスありがとうございます。
お恥ずかしい話、「ペイロードのデコーダをチェックしてください」というご指摘を正確に理解できないでおります。

現在は

function Decoder(bytes, port) {
  // Decode an uplink message from a buffer
  // (array) of bytes to an object of fields.
  var decoded = {
   "Humidity": bytes[0],
   "Temperature": bytes[1]
  };

  return decoded;
}
をweb上で設定しており、値を01.02といれますと、それぞれ01,02と帰ってくるまでは確認ができております。
「いいね！」 1
10

一度、アカウントをすべて削除して、再作成したのですが、問題の切り分けとして一番疑わしいのは、センサーノードの設定かなと考えています。

一部、疑問に思うのですが、ABPにおいて、アプリケーションセッションキーとネットワークセッションキーがありますが、msbとlsbのどちらで設定をすべきか、よくわからない状態です。

皆様は、どちらで設定されていますでしょうか？

// デバイスアドレス
static const u4_t DEVADDR = 0x26041808;
// ネットワークセッションキー
//lsb
//static const PROGMEM u1_t NWKSKEY[16] ={ 0x51, 0x86, 0x59, 0x4D, 0xCF, 0xC5, 0x4C, 0x5E, 0xA4, 0x8D, 0x8B, 0x59, 0x2A, 0x4B, 0xBB, 0x69 };
//msb
static const PROGMEM u1_t NWKSKEY[16] ={ 0x69, 0xBB, 0x4B, 0x2A, 0x59, 0x8B, 0x8D, 0xA4, 0x5E, 0x4C, 0xC5, 0xCF, 0x4D, 0x59, 0x86, 0x51 };

// アプリケーションセッションキー
//lsb
//static const u1_t PROGMEM APPSKEY[16] ={ 0xDC, 0x6D, 0xA6, 0xC9, 0xE4, 0x69, 0xD9, 0x11, 0xDF, 0x1B, 0xE8, 0xB1, 0x89, 0x63, 0xBE, 0x42 };
//msb
static const u1_t PROGMEM APPSKEY[16] ={ 0x42, 0xBE, 0x63, 0x89, 0xB1, 0xE8, 0x1B, 0xDF, 0x11, 0xD9, 0x69, 0xE4, 0xC9, 0xA6, 0x6D, 0xDC };

11

global_config.jsonの、serversの、addressに、router.jp.things.networkを設定されてますか？
そのサーバー、障害が発生しているようで、もし、設定されているようであれば、router.as2.thethings.networkに変更して、リコンパイル（必要ないかもしれませんが）して、もう一度試してみてください。

「いいね！」 1
12

owashiさま

アドバイスありがとうございます。
確認させて頂きます。

13

吉田さま
owashiさま

GWの設定は変えておりませんが、本日確認をしたところ、APPLICATION DATAにてデータが出力されている事が確認できました。
大変、ありがとうございました。

昨日から設定を変えておりませんので、router経由での障害だったと考えられます。

ただ、今回の課題といたしまして、ネット上で出ている情報をもとに設定を行っても、うまく行かないケースだった為、今後障害の切り分け方法を明確にしていける環境づくりが、TTNのGW拡大や利用者の拡大に大きく影響するのではないかと感じました。

「いいね！」 1