BASICコマンドをLTE送信!PCやスマホからIchiogoSodaを遠隔制御

LTEモバイル通信機能を搭載したIchigoSodaへBASICコマンドを送る実験をしてみました。

PCやスマホから「LED 1」「BEEP」「?”こんにちわ”」といったIchigoJam BASICのコマンドを送信する(上図)と、IchigoSoda上で実行することが出来ます。※ただし8文字まで

β版IchigoJam BASICで8文字受信

ベータ版のIchigoJam BASIC 1.3.2 bata 11で、8文字までの文字列の受信に対応していただけたので、対応プログラムを作ってみました。

IchigoSoda用プログラム

以下にIchigoSoda側のプログラムを示します。sakura.ioモジュールがBASICコマンドを受信すると、キーバッファへBASICコマンドを取込み、IchigoSoda上で実行します。

new
 1 cls:?"SAKURA IoT RX
 2 ?"CC BY Wataru Kunino
 3 T=1:?" シュウキ=";T;" ビョウ
 9 M=#114E :'Ver. 1.3.2

 100 ?"== RX マチウケ ==
 110 ?".";:wait T*60

 200 '== RX ==
 210 poke M,0
 220 I=IoT.in()
 230 if peek(M)!=1 goto 110
 260 cls:?"Ch=";peek(M+2)
 270 if peek(M+3)=98 goto 300
 280 ? I
 290 goto 200

 300 '== String ==
 310 I=0
 320 C=peek(M+4+I)
 330 poke #1004+I,C
 340 I=I+1
 350 if C AND I<8 goto 320
 360 P="/goto 200/"
 370 poke P,10:poke P+9,10
 380 copy #1004+I,P,I+10
 390 poke #1003,I+10
 400 end
 999 ?"MJ GET bokunimowakaru.github.io/MJ/803.txt

行番号100番台は、1秒ごとに「.」を表示するだけです。何か他の処理をさせたいときのために確保しました。

行番号200番台は、sakura.ioからの受信の待ち受け部です。行番号220のIoT.inコマンドが、sakura.ioから受信データを取得します。文字列(バイナリ)の受信に成功したら、行番号300番台へgotoします。数値を受信した時は、行番号280で数値を表示します。

行番号300番台は、受信したバイナリデータをキーバッファへ取り込む部分です。行番号330で、キーバッファへ書き込みます。また、行番号360で「goto 200」の命令をキーバッファへ入れておきます。これで、プログラムを終了後、受信した命令を実行し、goto 200で再び、プログラムに戻ります。

キーバッファへの操作コマンドは、あまり自信がありません。誤っていたら、コメント欄などから教えてくださいますよう、お願いします。

WebSocket 確認ツール Message IoT からBASICコマンドを送信する

BASICコマンドの送信には「WebSocket 確認ツール Message IoT 」を使用しました。
冒頭の画面のように、Tokenを入力し、sakura.ioへの接続に成功したら、Module IDを入力し、Message欄へBASICコマンドを入力し、実行してください。

https://bokunimowakaru.github.io/IchigoJam/message_iot/index.html

以上で、8文字までのBASICコマンドをIchigoSodaへ送ることが出来ます。

ただし、コマンドに誤りがあるとSyntax Errorが発生し、プログラムが停止してしまいます。

試しに

on error goto 200

と、入れてみましたが、動きませんでした。

セキュリティに関するご注意
sakura.ioモジュールのtokenやモジュールIDが流出すると、攻撃者にIchigoSodaを乗っ取られる可能性が考えられます。また、攻撃などに要した通信料が課金されます。十分に注意して下さい。

by ボクにもわかるIchigoJam用マイコンボード
https://bokunimo.net/ichigojam/

IchigoSodaから複数の測定値を同時送信!β版ファームウェアを試してみた

β版ファームウェアを使って、IchigoSodaから複数の測定値を同時送信する実験を行ってみました。

IchigoSodaから複数値の同時送信

IchigoJamの開発者のブログに、β版のファームウェアで最大128バイトのデータをsakura.ioモジュールで送信する記事が掲載されていました。

(参考文献)福野泰介の一日一創
sakura.ioの4G格安IoTで拡充オープンデータ! 128byteまとめて送信、新IOT.OUTコマンド対応 IchigoJam 1.3β10
https://fukuno.jig.jp/2490

そのファームウェアを使って、送信データをRaspberry Piで受信する実験を行ってみました。

ダウンロードするもの

まずは、上記の記事で使用しているichigojam-1.3b10.zipをダウンロードし、IchigoSodaへ書き込みます。
https://ichigojam.github.io/ichigojam-1.3b10.zip

また、筆者が作成したRaspberry Pi側で動作する受信用ソフトウェアもダウンロードします(ダウンロード方法は後述)。
https://raw.githubusercontent.com/bokunimowakaru/iot/master/server/ws_logger_sakura.py

sakura.ioモジュールの設定などは下記をご覧ください。
https://bokunimo.net/ichigojam/sakura.html

なんと、ありがたいことに、IchigoJamの開発者のブログ「福野泰介の一日一創 」の当該ページに当方ウェブサイトのリンクを掲載していただきました。

動かしてみよう①複数の変数を送信する

それでは、早速、動かしてみましょう。まずは、Raspberry Pi側からです。起動するには、sakura.ioで取得したToken(トークン)が必要です。

《Raspberry Pi》
$ cd
$ git clone http://github.com/bokunimowakaru/iot
$ cd ~/iot/server
$ ./ws_logger_sakura.py sakura.ioのトークン

起動後に「CONNECTED」が表示されたら準備完了です。


こんどは、IchigoSoda(ファームウェアはIchigoJam 1.3β10 )から以下のコマンドを送ってみます。

《IchigoSoda》
[0]=1:[1]=-1:[2]=32767:[3]=-32768
IoT.out #800,8

これで、4つの変数の数値(8バイト)が、sakura.ioから LTE送信されます。


Raspberry Pi側を見てみると、以下のように表示されていると思います。下から2行目のvalueの部分に受信した数値が表示されました。

2019/05/19 22:47, {"module":"uXXXXXXXXXXX","type":"channels","datetime":"2019-05-19T13:47:02.71463767Z","payload":{"channels":[{"channel":1,"type":"b","value":"0100ffffff7f0080","datetime":"2019-05-19T13:47:02.713638539Z"}]}}
from = uXXXXXXXXXXX
datetime = 2019-05-19T13:47:02.713638539Z
channel = 1
type = Binary
value = [1, -1, 32767, -32768]
Message = yyy€

動かしてみよう②少し長め、文字列「Message from IchigoSoda!」の送信

今度は文字列です。福野さんのブログと同じ文字列を送信するために、IchigoSodaで「IoT.out “Message from IchigoSoda!”,24」と入力すると、Raspberry Pi側(下図)の最下行に同じメッセージが表示されました。

2019/05/19 22:44, {"module":"uXXXXXXXXXXX","type":"channels","datetime":"2019-05-19T13:44:13.121625999Z","payload":{"channels":[{"channel":1,"type":"b","value":"4d65737361676520","datetime":"2019-05-19T13:44:13.120626868Z"},{"channel":1,"type":"b","value":"66726f6d20496368","datetime":"2019-05-19T13:44:13.120626868Z"},{"channel":1,"type":"b","value":"69676f536f646121","datetime":"2019-05-19T13:44:13.121626868Z"}]}}
from = uXXXXXXXXXXX
datetime = 2019-05-19T13:44:13.120626868Z
channel = 1
type = Binary
value = [25933, 29555, 26465, 8293]
datetime = 2019-05-19T13:44:13.120626868Z
channel = 1
type = Binary
value = [29286, 28015, 18720, 26723]
datetime = 2019-05-19T13:44:13.121626868Z
channel = 1
type = Binary
value = [26473, 21359, 25711, 8545]
Message = Message from IchigoSoda!

動かしてみよう③いよいよ本命。変数64値、128バイトを送信

最大128バイト、変数[0]~[63]を送信するには、「IoT.out #800,128」と入力します。
datetime、channel、type、valueが16回、表示され、全64値を受信することが出来ました。
(同じような結果画面につき、valueのみを抽出)

《IchigoSoda》
for I=0 to 63:[I]=i:next
IoT.out #800,128

《Raspberry Pi》
value = [0, 1, 2, 3]
value = [4, 5, 6, 7]
value = [8, 9, 10, 11]
value = [12, 13, 14, 15]
value = [16, 17, 18, 19]
value = [20, 21, 22, 23]
value = [24, 25, 26, 27]
value = [28, 29, 30, 31]
value = [32, 33, 34, 35]
value = [36, 37, 38, 39]
value = [40, 41, 42, 43]
value = [44, 45, 46, 47]
value = [48, 49, 50, 51]
value = [52, 53, 54, 55]
value = [56, 57, 58, 59]
value = [60, 61, 62, 63]
Message = 123456789:;<=>?

受信側プログラム(抜粋)

以下は、今回、作成したRaspberry Pi用の受信側のPythonブログラムの抜粋です。データタイプ(data_type)が’i’なら整数、’b’ならバイナリとして処理します。
複数の変数は’b’のバイナリとして送られてくるので、2バイトごとに数値変数valへ代入し、配列変数data_valueへ蓄積します。

data_text=''
for data in res_payload_dict:
data_type = data['type']
data_ch = data['channel']
data_time = data['datetime']
data_type_s= 'Unknown'
if data_type.lower() == 'i':
data_type_s= 'Integer'
data_value = data['value']
if data_type == 'b':
data_type_s= 'Binary'
data_str = data['value']
i=0
data_value=[]
while i < len(data_str):
if i % 4 == 0:
val = int(data_str[i+2:i+4] + data_str[i:i+2],16)
if val >= 32768:
val -= 65536
data_value.append(val)
c = chr(int(data_str[i:i+2],16))
if ord(c) >= 16 and ord(c) < 256:
data_text += c
i += 2
print('datetime =', data_time)
print('channel =', data_ch)
print('type =', data_type_s)
print('value =', data_value)
print('Message =', data_text)

100回目の投稿

今回、IchigoJamに関連したブログの投稿記事数が、100記事に達しました。
このところ、Yahoo!ジオシティーズのサービス終了とYahoo!ブログのサービス終了予定にともない、引っ越し作業に時間がとられていました(実は、まだ古いリンクが残っている)。
本来の記事を書く作業も、ぼちぼちと進めてゆこうと思います。
本日、下記のIchigoJamに関連したページの更新を行いましたので、お時間がありましたら、お立ち寄りください。

IchigoSoda / sakura.io の接続方法
https://bokunimo.net/ichigojam/sakura.html

by ボクにもわかるIchigoJam用マイコンボード
https://bokunimo.net/ichigojam/

IoT Express × TTGO Camera 玄関カメラで0.8fpsパラパラ漫画表示

M5Stackで0.4fpsの動画表示が出来たので、IoT Expressで試したところ2倍の0.8fps動画表示が出来ました。
紙芝居からパラパラ漫画へと進歩しました 。
表示部には、フルカラー有機ELディスプレイSSD1331を使用しました。

(参考)下図は前回の記事です。

概要

TTGO T-Cameraの映像をフォトフレーム端末へ転送する玄関カメラシステムです。
カメラ側は中国で2000円程度で売られています。
フォトフレーム端末側は、前回、M5Stackを使用しましたが、今回、ESP32マイコンボードとしてCQ出版社およびaitendoが販売しているIoT Expressに変更してみました。
詳細は、前回やそれ以前の記事をご覧ください。

前回からの変更点

フォトフレーム側のマイコンボードをCQ出版社のIoT Expressに変更し、ディスプレイに有機ELディスプレイSSD1331を接続しました。

プログラムは同じM5Stackとレポジトリのフォルダ「iot-photo_oled」へ収録しました。

フォトフレーム(GitHub):
https://github.com/bokunimowakaru/iot-photo/tree/master/iot-photo_oled

動作確認結果

QQVGAで再生してみたところ、2倍の0.8fpsで動作することが分かりました。

 HTTP://192.168.0.2/cam.jpg
Recieving…HTTP/1.1 200 OK
Content-Type: image/jpeg
Content-Length: 4000
Connection: close
loading….http END
4000 Bytes, 257ms, Done
Loading image '', 4000 bytes
HTTP time :290 ms
JPEG time :939 ms
Total time:1229 ms (0.814 f/s)

HTTP://192.168.0.2/cam.jpg
Recieving…HTTP/1.1 200 OK
Content-Type: image/jpeg
Content-Length: 3546
Connection: close
loading….http END
3546 Bytes, 256ms, Done
Loading image '', 3546 bytes
HTTP time :288 ms
JPEG time :939 ms
Total time:1227 ms (0.815 f/s)

HTTP://192.168.0.2/cam.jpg
Recieving…HTTP/1.1 200 OK
Content-Type: image/jpeg
Content-Length: 3200
Connection: close
loading….http END
3200 Bytes, 255ms, Done
Loading image '', 3200 bytes
HTTP time :288 ms
JPEG time :935 ms
Total time:1223 ms (0.818 f/s)

考察

QQVGAで0.8fpsを達成しましたが、QVGAでも0.7fpsでした。
HTTP処理部については、TCP接続部や応答遅延などが影響しており、JPEG処理部についてはデコード部ではなく、描画部が影響しているようです。

by ボクにもわかる電子工作
bokunimo.net

M5Stack×TTGO Camera 玄関カメラ用デモの高速化

M5Stackと、 中国で 約2000円で売られているTTGO T-Cameraを使って製作した、玄関カメラシステム用の画像転送速度を(少しだけ)高速化しました。

(参考)下図は前回の記事です。

前回の課題と今回の対策の概要

前回、Wi-Fi玄関カメラの製作方法について、紹介しましたが、撮影後、画像が転送されるまでの時間が長い(約5秒)という課題がありました。そこで、HTTP処理部を見直し、画像転送速度の高速化を図り、約0.4fpsの動画再生(といっても、ほとんど紙芝居)に対応しました。

動かし方

GitHubのソフトを更新しましたので、前回と同じようにダウンロードして下さい。人感センサ反応中(ずっと反応し続けている状態)に動画再生モードになります。

今回の対策内容

主にHTTP処理部の対策を行いました。以下に4月30日のコミットからの変更点を記します。

  • HTTP処理部の高速化
    • 受信バッファにRAMを使用(#define CAMERA_BUF_ENで切替可能)
    • 画像データの受信完了にHTTPヘッダ内のContent-Lengthを使用
  • 人感センサ反応中に繰り返し画像取得を実行(検知信号の受信で動画を開始、検知完了信号で動画を停止)
  • ピンポン音の追加(人感センサ検知時に「ピンポン」音)

動作確認結果

QVGA(320 x 240)の画像で、約0.4fpsの動画再生が行えるようになりました。再生中のログのようすを以下に示します。「Loading image ”」は取得データをRAMから取得したときに表示されます。

 HTTP://192.168.0.2/cam.jpg
Recieving…HTTP/1.1 200 OK
Content-Type: image/jpeg
Content-Length: 12000
Connection: close
loading…………http END
12000 Bytes, 271ms, Done
Loading image '', 12000 bytes
HTTP time :483 ms
JPEG time :1976 ms
Total time:2459 ms (0.407 f/s)

HTTP://192.168.0.2/cam.jpg
Recieving…HTTP/1.1 200 OK
Content-Type: image/jpeg
Content-Length: 12766
Connection: close
loading………….http END
12766 Bytes, 271ms, Done
Loading image '', 12766 bytes

HTTP time :482 ms
JPEG time :1979 ms
Total time:2461 ms (0.406 f/s)
HTTP://192.168.0.2/cam.jpg
Recieving…HTTP/1.1 200 OK
Content-Type: image/jpeg
Content-Length: 11010
Connection: close
loading………..http END
11010 Bytes, 270ms, Done
Loading image '', 11010 bytes

HTTP time :476 ms
JPEG time :1970 ms
Total time:2446 ms (0.409 f/s)

より滑らかな動画に(プログラム変更なし)

HTTP処理に要する時間が0.5秒程度、JPEG処理(表示を含む)が2秒程度かかっています。

撮影解像度をQQVGA(var = framesize, val = 0)に落とすことで 、HTTP処理時間とJPEG処理時間の両方を短縮くすることができます。確認したところ、現状のプログラムのままで、0.8fpsの滑らかな表示にすることが出来ました。しかし、広角レンズを使用した場合、人物の顔などが分かりにくくなってしまうので、かえって実用的ではなくなります。

さらなる高速化を目指したい方へ

HTTP処理部については、都度、TCP接続を切断しています。接続したままにする、またはUDPを使用することで、より高速化が図れるでしょう。

JPEG処理部では、デコード処理と描画処理を行っています。それぞれの時間を計測したことはありませんが、Adafruitのライブラリを使って1ドットずつ描画コマンドをコールしている点が課題だと思います。直接、LCDへコマンドを送るようにすれば、高速化することが出来るでしょう。

by ボクにもわかる電子工作
bokunimo.net

IFTTTとの連携が出来なくなるWio Node

今日、IFTTTよりWio Nodeとの連携サービスが廃止になるとの連絡がありました。

Wio Nodeとの連携サービス(5/8まで)
https://ifttt.com/seeed_wio

下記のような連携も出来なくなります。

2019年5月8日にIFTTTとの連携サービスを終了する。
Wio Link Serverは、これまでどおり存続する。
IFTTT側の新しいCEOによるビジネスモデルの変革が原因で、互換性が保てない方向に進みつつある。

他のサービスへ変更するために、サービス期間を1週間、延長したとのことですが、簡単な連携サービスが無くなることは、とても残念です。

TTGO T-Camera+M5StackでWi-Fiカメラ

中国で販売されている2000円のWi-Fiカメラで撮影した写真をM5Stackへ送信するWi-Fi玄関カメラの実験を行ってみました。

(参考)Wi-FiカメラTTGO T-Cameraの製品紹介記事はこちら:


このカメラには人感センサがついています。そこで、人感センサが人体などの動きを検知したときに、写真を撮影し、M5Stackへ送信して表示するソフトを作成しました。
また、普段はM5Stack内のMicro SDカード内の写真をフォトフレームのように表示するようにしました。

カメラ側について

カメラ側は、 TTGO T-Camera の出荷時に書き込まれていたサンプルを改造して作成しました。人感センサが反応したときに、UDPブロードキャストを送信し、M5Stackへ通知します。

Wi-Fiカメラ TTGO T-Camera側:
https://github.com/bokunimowakaru/iot-camera

  • 人感センサが反応したときにUDPでM5Stackへ通知します。
  • リセットボタン(RST)でM5StackへT-Cameraのアドレスを通知します。
  • インストール方法は、上記のGitHubのREADME.mdをご覧ください。

フォトフレーム側について

M5Stack側は、Adafruitの液晶ドライバなどを使用して作成したフォトフレームです。
Wi-Fiアクセスポイント・モードとして動かしており、デフォルトでWi-Fiカメラも同じSSIDに設定してあります。

Wi-Fiフォトフレーム M5Stack側:
https://github.com/bokunimowakaru/iot-photo

  • TTGO T-Cameraのリセット操作でアドレス登録後、T-Cameraが写真を撮影するたびに写真を表示します。
  • Micro SDカードまたはSPIFFS内の写真を表示します。 SPIFFSは遅いので、Micro SDカードの使用をお奨めします。
  • インストール方法は、上記のGitHubのREADME.mdをご覧ください。

動かし方

両方の機器の電源を入れ、M5Stackが起動してから、Wi-Fiカメラのリセットボタン(RST)を押すと、ペアリングが完了し、動作させることが出来ます。

スマホからM5Stack(http://192.168.0.1/)へアクセスすると、SPIFFSの初期化や、SPIFFSやSDカード内の写真の表示が行えます。

今日から令和になりました。
この休み中に、もう少し、機能を追加してゆこうと思います。

by ボクにもわかる電子工作
bokunimo.net