投稿日:

Cayenneとの接続

ここでは、デバイス(センサ)からCayenneを経由してデータを見るところまでを確認する。すでに、上記のProject Dまでは確認が終わっているのでTTNとCayenneの接続確認となる。　今回はCayenneに乗せるつもりでこれまで準備してきたのでちょっとずるい感もあるが、まずは完結させることが大事として進めていく。

まずCayenneとはIoTサービスを展開するMyDevicesの機能(サービス？)の一つである。TTNなどにUpされたデータや直接センサからのデータを受けて、データの表示やトレンド、メータ表示などを実施してくれる。 これも無料で使用できるが、メールアドレスの登録が必要である。

連携としてはCayenne側でTTNに登録したデバイスEUIを登録することで、Cayenne側で新たしいURL(ダッシュボード)が自動生成される。
このURL部分をTTN側に連携させてつながりが行われる。

MyDevicesのCayenne側での設定として下記を開いて”SIGN UP FREE”で登録する。
https://developers.mydevices.com/cayenne/features/

これから作るものはCyenneの中ではProjectと呼ばれるものである。
まだわからない部分も多いが、ダッシュボードにデバイスをどんどん登録していき、それをProjectという枠にデバイスのパラメータを割り付ける感じである。ここでは、ダッシュボードへデバイスを登録する部分を実施する。

Cayenneで最初の選択があるのは追加するDeviceがどこから来るのかという感じである。今回はLoRaを選択する。　

すると、LoRaのBroker一覧が出てくるので、そこでTTNを選択する。

このあと、いろんなセンサが出てくるが、ここでは”Cayenne LPP”を選択する。

ここで、詳細を入力する。
ここで出てくる名称にはデバイスの名前を入れるようにしている。
そのほかTTNで指定しているデバイスEUIを入れる。 そのあとセンサを設置している位置(住所)を入力して”Add Device”を押す。
コンフリクトのエラーが出た場合は、大体デバイスEUIに不整合があるケースであった。
ここでダッシュボードが出来上がるが、ここのURLがTTNと接続するためのキーとなる。

このあとは、このキーをTTNに割り付けるためにTTNでの操作を行う。
まず、データのフォーマットの指定としてPayload Formatで”Cayenne LPP”を指定する。

次にその右の”インテグレーション”ボタンを押し、MyDevicesと上記で控えたキーを入力する。
その前に、”インテグレーション”を押した後、連携先のMyDevicesを選択する。

その後、控えたURLの一部を”プロセスID”に入力し、”Access Key”に”default Key”を選択する。

その後下にある”インテグレーションの追加”でインテグレーションを指定する。
設定が正しければ、TTNとCayenneが連携されてCayenn側でデータが表示されるはずである。
(私はTry&Errorで横道それながら覚えていくタイプなので、すぐに表示でなくてもあせらずにゆっくり手順を確認する。 ほかのWebを参考にしながら)

データがうまく連携されていない場合は、センサ一の地図だけが出てしまう。
その場合は、センサから順にどこにデータが来ているかをみてみるとよい。

投稿日:

デバイスの立ち上げとTTNでの確認

ここでは、下記のCとDの部分の確認をする

ここではLoRa用のチップの乗ったArduino Uno相当である(DRAGINO LoRa Mini)を用いた。

これはArduino IDEを用いて開発することになるが必要なライブラリやサンプルを入手する。

•arduino-lmic-master-for-LG01-JP-REL20190308.zip
LMiCというのはIBMがLoRaを使用するために作成したライブラリである。これを改訂したものが上記である。ただし、上記はまだ日本版に対応していないので日本の周波数向けの定義を少し加えないとならない。　このLimicライブラリのlorabase_as923.hのなかで使用する周波数を手動で変更し定義している。

•DHT_sensor_library.zip
このモジュールはDHT11を使用するためのライブラリである。

•CayenneLPP.zip
ここで入手したデータはCayenneで利用するために、このライブラリを利用している。

その他、Adafruit Unified Sensorをライブラリの管理から追加している。このPCにはいくつかのライブラリが含まれているので、ライブラリの管理に表れてきたが落とし穴になる可能性がある。

•Cayenne_TTN_ABP.ino
Arduino IDEに利用するサンプルである。
上記は(株)オープンウェーブ様の手を加えられているようだが、参考のために冒頭のコメントの一部をコピーしておく。
このソースプログラムでTTNのデバイスで(自動)定義されたデバイスアドレス、ネットワークセッションキー、APPセッションキーを入力する。

  • Copyright (c) 2015 Thomas Telkamp and Matthijs Kooijman
  • Changed 2017.11.01 OpenWave inc,
  • Permission is hereby granted, free of charge, to anyone
  • obtaining a copy of this document and accompanying files,
  • to do whatever they want with them without any restriction,
  • including, but not limited to, copying, modification and redistribution.
  • NO WARRANTY OF ANY KIND IS PROVIDED.
    • Change DEVADDR to a unique address!
  • See http://thethingsnetwork.org/wiki/AddressSpace
    *
  • Do not forget to define the radio type correctly in config.h.
    *
  • Required Library:
  • * https://github.com/matthijskooijman/arduino-lmic
  • * https://github.com/adafruit/DHT-sensor-library
  • * https://github.com/adafruit/Adafruit_Sensor
    • Require Hardware:
  • * LoRa Shield + Arduino
  • * LoRa GPS Shield + Arduino
  • * LoRa Mini etc.
    • このサンプルは、The Things NetworkにABPで、DHT11の
  • 温度、湿度のデータをCayenneLPPのペイロードで送信します。
    • 2017.11.01 株式会社オープンウェーブ
      */

デバイス側で
使用周波数の設定、デバイスアドレス、ネットワークセッションキー、Appセッションキーを定義する。
不思議なのがPiに搭載したdual_cahn_pkt_fwd.cppである。ここでは使用する周波数やポートの定義はあるが、デバイスとのリンケージを示す定義をした覚えはない。もしかすると、ゲートウェイは同じ周波数帯で受信したものは、勝手にInternetに挙げてしまう懸念がある。　これはおいおい試してみたいところである。


確認方法
確認方法としてはまず、センサ側から順に確認してみたい。

Arduino IDEにあるモニターで確認する。(余分なDebug Messageとして読み込んデータを入れているが気にしないでください。)

次はゲートウェイである。
PiにLoginして、dual_chan_pkt_fwdのログを確認すればよい。

dual_chan_pkt_fwdはデーモンとして動作しているのでdaemon.logにメッセージが(延々と)記録される。　それの最後部分を何度か見ることによって動作がわかる。もちろんこのファイルをすべて見てもよいが大変である。
grep dual /var/log/daemon.log | tail
これを見ると5月5日 12:02:27にパケットを受信し、rssiやsnrなどの通信指標値が上がってきているのがわかる。
もし、これらのデータが全く見つけられなければ、dual_chan_pkt_fwdが動作しているかどうかを確かめるとよい。
ps -ef | grep dual

このコマンドを入力した後の1行目があれば、プログラムは動作している。
2行目はこのプロセスを探すためのプロセスが表示されているだけなので、無視する。
上記コマンドのtailをheadにすると、起動時のメッセージが見れるので参考にしてもらえるとよい。

ゲートウェイでの確認が取れたらTTNで確認する。
コンソール画面からアプリケーションを指定し、デバイスが登録してあるアプリケーションを開く。するとの設定の画面を見るとデータという項目があるので、そこをクリックする。

これが出れば一安心である。少なくともTTNまでの経路が確認できた。

投稿日:

ペイロード(Payload Formats)

ペイロードとはその名前の通り、電文を運ぶところである。MQTTに関していえば、このペイロードの使い方の規定はあまりない。最大256Byteというものはあるものの、デバイスのデータを利用するものが取り決めを行っている。
今回の事例ではCayenneを使用するのでCayenneに即した設定を行う。

投稿日:

デバイスの定義

作成したアプリケーションを開くと、”デバイス(端末)”の定義がある。
デバイスの定義ではデバイスIDを入力するが、のちに出てくるCayenneとの連携がうまくいかないときに、デバイスIDをCayenne側で合わせたら動作した。変えたことが良かったのか、連携するときにデバイスIDが重要なのかは不明である。

デバイスEUIとApp Keyは自動生成されるが、この定義はセンサー側でアプリを作るときに連携される。

投稿日:

The Things Networkとは、とその定義

Project AはRaspberry PiにDevice(Node)と接続するためのLoRa無線機器であるLoRa/GPS HATを接続した。このProject Aの部分はGatewayなので、二つの通信の橋渡しを行う。このProjectではInternet上にあるTTN（The Things Network)との接続について述べる。

TTN（The Things Network)とは、たぶん世界最大規模の無料LoRa WANネットワークと紹介されているケースが多い。 ここを把握しておくことは重要であると思われる。

１．Internetへの接続
２．TTN へのアカウント定義
３．ゲートウェイの設定
４．アプリケーションの設定

１．Internetへの接続
LoRa ゲートウェイは各種のセンサの情報を集めてInternet上のTTNへ情報送る役目を持つ。そのために、LoRa ゲートウェイであるRaspberry PiはInternetへの接続を行う。今回は、自宅の無線LANに接続を行っている。このゲートウェイを移動させる場合は、モバイルルータなどに接続させることになる。 こらはRaspberry Piの通常の設定で問題ない。（Raspberry Piを立ち上げるためにInternetに接続しているはずなので、その設定で使われる方が多いであろう)

２．TTNへのアカウント定義
TTNへのアカウントは下記のURLより実施する。
https://account.thethingsnetwork.org/register
ここでUser NameやEMail Addressを入力するが、アクティベートが必要となるために、受信できるアドレスにする必要がある。また、一度使用したアドレスは再利用ができないので注意すること。

３．ゲートウェイの設定
サインインすると下記の画面となる。　この画面はコンソール画面と呼ばれ、作業する上でのホーム画面と考えればよい。

このTTNはMQTTにおけるBrokerの役割をなす。このBrokerとはセンサから適当なタイミングで送信されたMQTTのデータを受け取り、適切な受信者との橋渡しをする。
センサからは殆どのケースにおいてゲートウェイ経由で送られるので、まず右のゲートウェイの設定が必要である。
ここをクリックした後にゲートウェイを登録に進む。

また、EUIという言葉がこれから多く出てくるが、これは識別子の意味である。ゲートウェイEUIと言ったらゲートウェイを識別するためのIDでありデバイスEUIとであれば、デバイスを識別するIDである。もちろん世界で一つである必要がある。
ゲートウェイEUIといえば、ゲートウェイの識別IDである。TTNではMACアドレスの中間部分をFFFFにしたものが採用される。ほかのセンサ単位に割り振られるデバイスEUIなどは自動発番される。

記載した内容は適当であるが、Raspberry PiがInterenetに接続するインターフェースのMAC Addressを利用する。
今回は、Raspberry PiにDual_Chan_Pkt_Fwdを利用している。この場合、
”I’m using the legacy packet forwarder”にチェックを入れる。
周波数計画は、日本で使用する場合、”Asia 923-925MHz”を選択しなくてはならない。
Routerはおすすめで、”ttn-router-asia-se”が出てくるので、これを用いる。
当然Raspberry Piがわでもこの設定をしている必要がある。

場所についてはMapが現れるので、ダブルクリックすれば緯度経度が自動入力されるので非常に便利である。

４．アプリケーションの設定
アプリケーション設定ではゲートウェイから上がってくるデータの振り分けやほかのアプリケーションとの連携の定義を行う。ほとんどのケースにおいて多くのデバイスを分類して、その分類ごとにアプリケーションを作ることとなる。
アプリケーションの登録には、自由に設定するアプリケーションID、その説明文、(自動的に割り振られる)アプリケーションEUI、ハンドラー登録を行う。これは、想定だが、ここで定義するハンドラー登録には”ttn-router-asia-se”を定義する。
また、過去に一度登録したアプリケーションIDは使えないようである。

ここで定義したアプリケーションにデバイスと連携するサービスを割り付けていく。
一覧から作成したアプリケーションを開けてみると、
アプリケーションオーバーフロー
アプリケーションEUI
デバイス
コラボレータ
アクセスキー
が表示される。

アプリケーションオーバーフロー
ちょっとどっきりするエラーやワーニングを示している項目に思えてしまうが、
どうやら”アプリケーションオーバービュー”と言いたかったのか？ 不明である。

アプリケーションEUI
これはこのアプリケーションを示すIDでありこのTTN内では固有のものとなる。(自動発番)

デバイス
ここにデバイスを登録することによってデバイスからのデータを受けれるようになる。

コラボレータ、アクセスキー
ここは、意識的に定義はしていない。定義したユーザやデバイスとメッセージをつなぎつけるキーが自動生成されるようである。

投稿日:

代品の入手

故障を断定した後は、代品をどうするかという話である。

いっそのこと既製品のLoRa Gatewayを購入してそのサービスを体験しようという考えもあり、SORACOMのGatewayにはかなり興味を持っていた。
しかし、本当にHATの故障を証明したいのと、まずは素材レベルでいろいろと知見を確保したいので結局HATを購入することとした。

新しいHATが到着後、、おそるおそるPiに接続して動作確認すると、下記のように問題なく立ち上がった。

pi@raspberrypi:~/dual_chan_pkt_fwd $ ./dual_chan_pkt_fwd
server: .address = router.jp.thethings.network; .port = 1700; .enable = 1
server: .address = router.as2.thethings.network; .port = 1700; .enable = 0
Gateway Configuration
XXXXXXXXXXXXXXXXXXX　← ここは自主規制
testing IoT
Latitude=0.00000000
Longitude=0.00000000
Altitude=10
Interface: wlan0
Trying to detect module CE0 with NSS=6 DIO0=7 Reset=3 Led1=unused
SX1276 detected on CE0, starting.
Trying to detect module CE1 with NSS=6 DIO0=7 Reset=3 Led1=unused
SX1276 detected on CE1, starting.
Gateway ID: xx:xx:xx:ff:ff:xx:xx:xx ← ここは自主規制
Listening at SF10 on 923.200000 Mhz.
Listening at SF10 on 923.200000 Mhz.
stat update: 2020-05-03 00:36:27 GMT no packet received yet
stat update: 2020-05-03 00:36:57 GMT no packet received yet

そのた、ここ似たどつくまでに試したものとしては、

Single_chan_pkt_fwdもWebで見つけて試してみた。動作を確認するためにはプログラムがシンプルで大いに助かった。

投稿日:

SPIの調査

(ちょっと効果的だったあがき1)
怪しいのはSPI。でもSPIの機器はちょっと考えてみたのだが、手元にはなさそう。
そこで、考えたのが、とりあえず自分で折り返してPi側の健全性を確認する。
まずは、SPI関連のモジュールを確認した。

参考にさせてもらったのは下記のページ。
https://tomosoft.jp/design/?p=5428

これで、動作確認をしてみると、Piのみで配線を折り返してLoopbackを実施すると問題ない。試しにLoopBackの配線を外した結果と。HATを接続した場合は同じ結果となる。
ここまで、証拠を突きつければおのずと、HATの単品故障と断定した。

SPI機器の動作がうまくいかないときにはおすすめである。

投稿日:

HATが応えない！

(無駄なあがき1)
ソース( dual_chan_pkt_fwd.cpp )を見てみると、、、
”Unrecognized transceiver” が出るときは、プログラム終了？ まぁ、認識できないんだからそうあるべきだが、この”Success”は SPI デバイスからの戻り値が予想外ということだった。

この手のトラブルは日常茶飯事なので、さっそく幾つが戻ってくるかをDebugメッセージを追加。 すると、”0”が戻ってきていた。

SPIが調子悪いと思いつつ、Pin配置やほかのプログラムも確認。 まぁ問題はなさそう。

(無駄なあがき2)
そういえば、このPiでSPIを使ったことがない。 手持ちにあるほかのRaspberry Piを持ってきて、やっても結果は変わらず。　結局もとのPi Zeroで継続調査することとした。

試行錯誤すること1日 、気が付いたら赤いLEDがついている。　「？？？」 よく見たら電源のLEDである。　電源不足だったというオチでした。
そこで、容量の大きい電源に入れ替え、再実験。　それでも結果は同じ。

”Unrecognized transceiver” が出る。　
電源に気が付いたのは良いが、これまでのは無駄なあがきだった。。。

投稿日:

DRAGINO LoRa GPS HAT -JP とRaspberry Pi Zero の初期実験編

HAT(DRAGINO LoRa GPS HAT -JP)とRaspberry Piの接続方法については、多くの事例があるので、それらを参考にしてほしい。
ここでは、それらでトラブった内容について記載する。

Raspberry Piはこれまで使っていたものを再利用していたので、とりあえずパッケージの更新だけはしておいた。 かなり時間はかかるが保険のようなもの。ただし、これによって動作しなくなる可能性もある。 我が家では数台のPiとSDカードがあり、いくつかの実験の残痕を都度世代のバックアップとしても使っている。

$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade

特に、今回作業後に実施したのはSPIの有効化。 これは忘れないように実施する必要がある。

$ ls -l /dev/spi*

でファイルが出てくればOk。
その後、一度Shutdownして電源を落としてHATとPiを接続し、再起動。

その後、今回Piの中にいてDeviceからくる電文を受信し、Broketへ橋渡しする機能であるdual_chan_pkt_fwdを入手する。　

$ mkdir dual_chan_pkt_fwd
$ wget https://github.com/bokse001/dual_chan_pkt_fwd/archive/master.zip
$ unzip master.zip
$ mv dual_chan_pkt_fwd-master dual_chan_pkt_fwd

便利な世の中になったもんだと思いつつも、日本向けと使用する周波数の設定を行う。
これも、沢山Webで紹介が出ているので、それに従ってもらえればよい。

$ cd dual_chan_pkt_fwd
$ vi global_config.json
$ vi dual_chan_pkt_fwd.cpp

多くの方は、ここですぐにmake installを実施しているが、なんとなくmakeだけで実行。
すると、多くのワーニングが、、、、 ざっと下記の感じ。

エンコーディングらしきメッセージもたくさんあったので、エンコーディングを再度設定して見直したが、大きな改善は見られない。　実行形式もできているので、今回は無視し、先に進めることとした。　一応Webで同現象の人を探したのですが、見つけられなかった。

そこで、実行してみると、何か表示が足りない。
もしや修正したところかと思い、再度元のソースから、最低限だけの修正を実施して、実行。　でも結果は変わらず。　その時のメッセージが下記。

pi@raspberrypi:~/dual_chan_pkt_fwd $ ./dual_chan_pkt_fwd
server: .address = router.jp.thethings.network; .port = 1700; .enable = 1
server: .address = router.jp.thethings.network; .port = 1700; .enable = 0
Gateway Configuration
team katy (iot@space.mars.jp)
Dual channel pkt forwarder
Latitude=0.00000000
Longitude=0.00000000
Altitude=10
Interface: wlan0
Trying to detect module CE0 with NSS=6 DIO0=7 Reset=3 Led1=unused
Transceiver version 0x00
Unrecognized transceiver: Permission denied
pi@raspberrypi:~/dual_chan_pkt_fwd $ sudo ./dual_chan_pkt_fwd
server: .address = router.jp.thethings.network; .port = 1700; .enable = 1
server: .address = router.jp.thethings.network; .port = 1700; .enable = 0
Gateway Configuration
XXXXX XXXXX(XXXXXXXXXXXXXX) ←ここは自主規制で隠しました。
Dual channel pkt forwarder
Latitude=0.00000000
Longitude=0.00000000
Altitude=10
Interface: wlan0
Trying to detect module CE0 with NSS=6 DIO0=7 Reset=3 Led1=unused
Transceiver version 0x00
Unrecognized transceiver: Success
pi@raspberrypi:~/dual_chan_pkt_fwd $

Unrecognized transceiver？ 認識できない？
Success？ 成功？？？？

これが、泥沼の始まりだったとは。。。

投稿日:

Mosquittoでの実験(動作確認)

まずBrokerであるMosquittoを動かす。
単純にコマンドを入力するだけ。(エラーが出たらPATH設定の可能性が高い？)

この状態で、別のコマンドプロンプトからトピックをtopic_ABCでClient(購読)を立ち上げておく
mosquitto_sub -d -t toopic_ABC
これは、受信者(購読者)を一人立ち上げたということである。　この受信者はtopic_ABCというタイトルについての情報を得る。

さらに別のコマンドプロンプトでtpoic_ABCに123.456を発行する。
mosquitto_pub -d -t topic_ABC -m “123.456”

すると少し待っていると、Client側で123.456が受信できる。

今回は同じPCを利用してテストしたが、ネットワークを使用して実施する場合はIPアドレスとポート番号を指定する。 (mosquittoでのデフォルトポート番号は1883)

mosquitto_sub -d -h 192.168.56.42 -p 1883 -t topic_ABC
mosquitto_pub -d -h 192.168.56.42 -p 1883 -t topic_ABC -m “123.456″