ArduinoからThingSpeakにデータを送る

手元のArduinoからThingSpeakにデータを送れるようになったのでその手順を書き留めておきます。

1)ThingSpeakにアカウントを作る

2)”My Channels”にチャネルを作ると、Channel IDとAPI Keyが発行される

3)Arduino IDEにライブラリをインストールし、サンプルスケッチを手に入れる → 例えばこちら

4)入手したスケッチのChannel IDとAPI Keyを2)に書き換える
(とりあえず最初にArduino -> ThingSpeakの通信を確認したいだけなので、温度や電圧を送るような動きは余計です。ここでは「変数を+1しながら送る」だけに書き換えて使いました)

5)コンパイル&GOすると例えば下記のようなグラフが得られる
(ここではスケッチの内容を「変数を+1しながら送る」にしたので右上がりの直線になっています)

今日はここまで

 

 

ThingSpeak

弊社は所謂IoTシステムの中で一番下流の、センサー値をクラウドに送るまで、を手掛けています。

センサー値を拾ってクラウドに送るまでの主にハード、無線等の技術を評価し確立しておきたいのですが、そのためにクラウドにセンサー値を貯めて、表示して、スマホアプリに送って、等々のシステムを構築するのは大仕事で完成するのを待っていられません。

そこで、可能な限り安価もしくは無料で簡単に使えるクラウドサービスが欲しくなるのですが、適当なものを見つけました。ThingSpeakです。

まずはゲートウェイもどきを作ってThingSpeakに表示させるところまで確認して、その次にセンサー値をゲートウェイ経由でThingSpeakに表示させるところまで実現してみたいと思います。

今日はここまで

無線のトラブル

最近、無線が飛ばない、繋がらない、時々切れる、等々の相談を受けるケースが多々あります。最近特に多いのがBluetooth Low Energy(以下、BLE)のトラブルで、スマホがBLEを受信できて、そのアプリを作るのも以前に比べると容易で、チップやモジュールが手に入りやすく電子工作レベルでも扱えるようになった、等の理由によるものでしょう。

ところが、プロとして製品に組込んで販売する場合、安定した通信を保証したい場合には注意してほしいことがあります。

それは送受信の両方に責任を持てる人を(自社他社に限らず)アサインするべきと言うことです。対スマホだと割り切らないといけないケースが出てきますが。より具体的に言えば、同一人物(同一組織)が送受信に責任を持てるような体制を作ってから開発・設計をスタートすべきと言うことです。それには同じメーカ・代理店から送受信モジュールを購入し、同一人物がFAEとして面倒を見ることができる体制にするのが基本でしょう。ときどき「BLEが分かる技術者を付ければ大丈夫だろう」みたいなことを言う人がいますが、送受信それぞれのチップ・モジュールのハード・ファームの詳細を把握してなおかつ異なるベンダー間の課題を解決できるような人がいるわけがありません。偶然、その問題が解決することはあるでしょうが、どんな問題が起きてもいつでも解決可能かどうかは分からない。技術確立をする前に、もしくは技術確立をするのと並行して商品企画を進めるのは否定はしませんが、コスト優先で扱いにくいチップもしくは送受信のメーカが異なって両方面倒を見ることができない体制で進めるのは危険だと言うこと。

無線に関する仕事のクオリティを上げ、自分たちは他の仕事に専念できるような体制を取るべきです。

ここまで

 

 

センサー・インターフェースについて

当社は所謂「無線センサー」のベンダーを自称しているので、「無線インターフェース」の市場動向・開発動向を気にしながら仕事をしています。

もう一つ気にしている規格がセンサー・デバイス、例えば温度、湿度、照度、気圧、人感、ドア開閉、等々を検知するデバイスと、コントローラボードとの間のインターフェースです。ここでは「センサー・デバイス・インターフェース」としておきましょうか。

「センサー・デバイス・インターフェース」の電気仕様には主なものに、SPI, I2C, UART, GPIO、等々があるのですが、プロトタイピングをする際に気にしなければいけないのがコネクタの物理仕様です(そのデバイスを使うことが決まっている基板を起こす場合、以下の議論は不要です)。なぜならコネクタで取り外しが簡単にできないと、ブレッドボードを使ったりはんだ付けしたり、制御のためのソフトウェア・ファームウェアを書く以外に余計な仕事が増えるからです。設計が一通り終わった後、思った通りに動かないときいちいち自分が工作した部分を疑わないといけないのは辛いでしょ。

今までSeeed Studio社の4ピンのGroveコネクタに注目していましたが、最近Digilent社の策定したPmodという規格を知って、汎用性・拡張性に優れ、基板に固定できる(Groveはケーブルで繋ぐ)、などから、IoTのプロトタイピングに向いているな、と感じました。

まだ流動的ですが、今日はこんなところです。

 

ESP-WROOM-32開発ボードに火を入れる

Arduino IDEで開発できる、Wi-Fi, BLEが内蔵されたマイコンESP-WROOM-32の開発ボード、ESP32-DevKitCが手に入ったので、早速火を入れてみました。

ここではWindows10で開発しますが、まずArduino IDE1.8.1がインストールされているものとします。

1. https://github.com/espressif/arduino-esp32

の緑の”Clone or download”ボタンを押下してDownload ZIPからファイル一式を適当なフォルダに持ってきて、自分のArduino関連のフォルダに展開します。

../Arduino/hardware/espressif/esp32/cores,doc,libraries,,,

2. ../esp32/toolsの中のget.exeをダブルクリックして終わるまで待ちます。

3. Arduino IDEのメニューで、ツール>ボード>ESP32 Dev Moduleを選択します。

ハードが正しく動くか試したいのですが、この基板には電源LEDしかなく、俗に言うLチカが基板単体ではできません。ブレッドボードに載せてLEDを外付けすればいいのですが、動かなかったときあれやこれや気を回さないといけなくなるので、最初は何も繋がずテストできるのがベターです。そこでスケッチ例の中からASCIITableと言う、文字列をただコンソールに出力するだけのスケッチを動かしてみます。

結果がこちら

今後はこの基板・CPUをベースに開発を進めてみたいと思います。

ここまで

 

 

LoRaモジュールを動かす

LoRaモジュールを単独で(メーカから提供される評価ボードを使わずに)動かしてみます。

ブレッドボードで、PC->(USBシリアル変換)->LoRaモジュール、の回路を組んでみます。

これでPCからTeratermで操作できるようになりました。

次はArduinoなどマイコンボードから制御することを試みます。

ここまで

Wi-Fi, Bluetooth Low Energy(BLE)

昨日東京出張の折り、久々に秋葉原に寄ってみたらESP-WROOM-32の評価・開発ボードが発売されていたので即買いしました。

Raspberry Piシリーズでは既に”3″にてWi-FiとBLEが最初から内蔵されるようになりましたが、ArduinoシリーズではESP-WROOM-32で内蔵され、それが今回開発しやすくなったと言うことです。

IoTはいよいよWi-FiとBLEが標準、と言う流れが加速します。

ここまで

LoRaWANプロトコル「超」概説

LoRaWANのプロトコル階層は以下のようになっています。

LoRaWANアライアンスが定めている仕様は上の図のLoRa MAC以下で、アプリケーション層は(現在のところ)規定されていません。アプリケーション層は予め送受信双方で取り決めておく必要があります。

LoRa MAC層に見えるClass A, B, Cとは、センサーノードの電池寿命を伸ばす目的で、用途によって3種の使い分けができ、

Class Aは、端末側の送信から通信を始め、その端末が受信動作をするのは送信した直後の2回だけ(端末が送信してきたときだけ上流からデータを送れる)
Class Bは、センサーノードは定期的に受信動作をしており、送信せよという指示を受信したら送信する方式(端末は通常は送信しないが、上流から問い合わせがあったときに答えるような動作ができる)
Class Cは、送信時以外はいつも受信している

と言う使い分けができます。

LoRa MAC以下の仕様は、”LoRaWAN 1.0.2″と”Reginal Parameters”の2つに分かれており以下のサイトから誰でもダウンロードできます。

LoRaアライアンスの仕様書ダウンロードページはこちら

ここまで