スマートコンセントをクラウドを使わずLANから制御してみた

最近のIoTブームでクラウドから制御できるコンセント(スマートプラグとかスマートコンセント)が安価に入手できるようになりました。どれもおおむね、専用のスマートフォンAppや、Amazon AlexaとかGoogle Home、IFTTTに対応しており、音声制御や自動化が可能になっています。それだけでも便利なのですが、LANに閉じて使いたいときもあるよね、ということで、クラウドに繋がらない状態でも制御できないかやってみました。
(何となく第三者のシステムから家庭内の機器を制御できる状態にしておきたくないとか、クラウドサービスが停止したら使えなくなるのがいやだという理由ですが。)

使ったもの

今回買ったのはこの二つ。Amazonのタイムセールで一番安かったので。

Wifiスマートプラグ スマートコンセント スマートソケット [2個セット]

スマートコンセント WiFiパワーストリップサージプロテクタ 電源タップ

後者の方は、USB電源2つ同時のON/OFFも制御することが可能です。

セットアップ

セットアップはSmartHomeというアプリを使って行い、Bluetooth経由で接続先のWi-Fi(2.4GHzのみ)の情報、およびクラウドやLANから制御するための暗号キーがコンセントに設定されます。

接続先を調べてみたところ、この製品は Tuya Smart というクラウドサービスを利用しているようです。また、常時クラウドにMQTTで接続しているものの、LAN内からも制御を受け付けており、スマホアプリも同一LANにある(UDPポート6666番のブロードキャストを見ることで検出可能)場合はLAN内で直接通信をしているようです。

Tuyaを利用しているデバイスは、有志が開発したNode.jsでLANから制御するためのNode.jsのライブラリがありますので、これを使ってLAN内から制御してみることにしました。この方法であれば、インターネットとの通信が遮断された環境や、MQTTがブロックされた状態であっても、制御が可能になります(ただし設定時は(少なくとも同一のSSID/パスワードで)インターネット接続可能なWi-Fiは必要ですが。)
github.com


セットアップする際、スマホから設定されるキーを取得してやる必要があります。キーはHTTPSで暗号化されてクラウドから渡されるので、少々面倒ですが、Tuyaapiのセットアップ手順通り、Charles というHTTPSプロキシを使ってスマホの通信内容を解析してキーを取り出しました。Charlesのセットアップとスマートフォンに独自CA証明書を信頼させる手順は以下が詳しく参考になります。このiPhoneAndroidの手順を踏めばOKです。

通信系のデバッグには Charles が便利

HTTPS通信の内容が取得できるようになったことを確認の上で、スマホアプリから設定操作をやり直すと、キーが取得できます。

制御してみる

あとは、tuyapi を導入し、

npm install tuyapi

単体のプラグであれば smart_plug.js として

#!/usr/bin/env node
const TuyaDevice = require('tuyapi');
setTimeout(() => { process.exit(1) }, 10000);
// 取得したID/キーを以下に設定
var tuya = new TuyaDevice({
  id: 'xxxxxxxxxxxxxxxxxxxx',
  key: "xxxxxxxxxxxxxxxx",
});
// IPアドレスを検出
tuya.resolveIds().then(() => {
  // 引数に応じてON/OFFを設定
  tuya.set({set: process.argv[2] == '1'}).then(result => {
    console.log(result ? 'OK.' : 'failed.');
  });
});

killtimer.unref();

というコードを書いて

./smart_plug.js 1    # ON
./smart_plug.js 0    # OFF

とコマンドを実行することでコンセントのON/OFFができます。

ちなみに、上記ではブロードキャストを受けてIPアドレスを探すため、若干待ちが発生しますが、IPがわかっているならば指定しておくことで tuya.resolveIds() を飛ばして高速化も可能です(以下参照)。

複数のコンセントがあるタップであれば、 smart_tap.js として

#!/usr/bin/env node
const TuyaDevice = require('tuyapi');

var t = setTimeout(() => { process.exit(1) }, 10000);

var tuya = new TuyaDevice({
  id: 'xxxxxxxxxxxxxxxxxxxx',
  key: "xxxxxxxxxxxxxxxx",
  ip: "192.168.xx.xx",  // IPを指定することで高速化
});
// 現在の設定を取得
tuya.get({schema: true}).then(result => {
  console.log(result)
});
// 引数に応じてON/OFFを設定
tuya.set({dps: process.argv[2], set: process.argv[3] == '1'}).then(result => {
  console.log(result ? 'OK.' : 'failed.');
});

t.unref();

というようなコードを書けば、

./smart_tap.js 1 1    # 1番のコンセントをON
./smart_tap.js 1 0    # 1番のコンセントをOFF
./smart_tap.js 5 1    # USB電源のON
./smart_tap.js 6 0    # すべての電源をOFF

などとコマンドを叩くことでLANから制御が可能です。
(IPがわからない・不定の場合は上のコードのように tuya.resolveIds().then(() => { ... }) 内で get, set を行う必要があります。)


ちなみにおまけとして、上記のコマンドを HomeBridge から実行できるようにするか、 homebridge-tuyapi(1つのコンセントのみ対応) を使えば、Siriから制御することも可能です。

ESP32で64x32 LEDマトリクスパネルを制御

ESP32を使って、Amazonで安価に売られている64x32ピクセルのLEDマトリクスに色々表示できるようにしてみました。

f:id:NeoCat:20180502031918j:plain

 
ESP32 + 64x32 RGB LED Matrix 

使ったもの

ESP32-DevKitC

P3 RGBピクセルパネルHDビデオディスプレイ64×32ドットマトリックスSMD LEDディスプレイモジュール192×96mm 

 f:id:NeoCat:20180502205034p:plain

あとは適宜ブレッドボードなど。 

配線

続きを読む

Bluetoothで値が読めるUSB電圧・電流モニター「UM24C」を使ってiPhone Xの充電状況を測ってみる

Bluetooth接続ができるUSB電圧・電流テスター「UM24C」を買ってみました。

公式のAndroid端末やWindows用のソフトを使って値を読み出すことができます。が、自作のプログラムからこれを読み出してみました。

 

f:id:NeoCat:20180414222359p:plain

カラーLCDがついていてなかなか派手ですが見やすい。上下に左右2つのボタンがついていて、これで操作します。操作HELP表示(英語)つき。これ単体で電圧や電流変化のグラフを見ることもできたりして、なかなか高機能です。

入手方法

Amazonでも購入できます

慣れてる人ならAliExpressで購入した方が安く買えます。Alibaba グループ | AliExpress.comの 電圧メートル からの UM24C 2.0カラー液晶ディスプレイusb電圧テスター電流計電圧計amperimetroバッテリー充電ケーブル抵抗30% 中の UM24C 2.0カラー液晶ディスプレイusb電圧テスター電流計電圧計amperimetroバッテリー充電ケーブル抵抗30%

↑ UM24 (Cがつかない) も選べますが、そちらはBluetooth通信機能がありませんのでご注意を。購入から1週間くらいで届きました。

※ 上位版?のUM25Cというのも出ているようですね。USB Type-Cボートがついているらしい。

早速読み出してみる

USB電源につないだ状態でBluetoothバイスを表示させてみると、普通のSPP(シリアルボートプロファイル)として見えます。

Windowsマシンでは、UM24Cを追加すると、PINを聞かれ、「1234」を入力すれば接続できます。COMボートが2つ追加され、どちらか一方に接続して利用します。公式のソフトがあり、これを導入すれば良いのですが、これがNational Instrumentsの計測プラットフォーム(NI-VISA)が丸っと入るため、かなり巨大です。

Macではペアリング自体は簡単にできるのですが、追加されるPort ( /dev/tty.Port-UM24C )に接続してもデータが読めず。(Windowsでも2つのうち1つのCOMポートは全く応答がないので、これだけが見えてしまっているのでしょうか…?)

USB-Bluetoothアダプタを接続したLinuxボード (Debianで試しました) からは以下の手順で接続できました。

$ sudo apt install bluez bluez-utils # 必要なパッケージの導入

$ sudo bluetoothctl -a

・デバイスをスキャン

[bluetooth]# scan on 

[NEW] Device 00:BA:55:XX:XX:XX UM24C

・発見されたUM24Cをペアリング

[bluetooth]# pair 00:BA:55:XX:XX:XX

Attempting to pair with 00:BA:55:XX:XX:XX

Request PIN code

[agent] Enter PIN code: 1234

[CHG] Device 00:BA:55:XX:XX:XX UUIDs: 00001101-0000-1000-8000-00805f9b34fb

[CHG] Device 00:BA:55:XX:XX:XX Paired: yes

Pairing successful

[bluetooth]# trust 00:BA:55:XX:XX:XX

[CHG] Device 00:BA:55:XX:XX:XX Trusted: yes

Changing 00:BA:55:XX:XX:XX trust succeeded

・rfcommで接続

sudo rfcomm bind 0 00:BA:55:XX:XX:XX

これで、 /dev/rfcomm0 として UM24C に接続できるようになりました。

 

あとは、適当なプログラムでこのポートを開き、「0xf0」の1バイトを送信すると、130バイトほどのレスポンスが返ってきます。なお jerm コマンドは jerminal というターミナル接続ソフトです。

$ (printf "\xf0"; sleep 2) | jerm /dev/rfcomm0 | xxd
...

00000000: 0963 0207 000a 0000 0033 0016 0048 0000  .c.......3...H..

00000010: 0000 020b 0000 09da 0000 0003 0000 000f  ................

00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................

00000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................

00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................

00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................

00000060: 0030 0030 0000 0000 0000 0000 0000 000a  .0.0............

00000070: 0000 0000 0000 0001 0002 0000 1446 0000  .............F..

00000080: fff1                                     ..

16bit Big Endian値が並んでいる感じで、最初は固定値?0x963、
電圧 0x207 = 519 ->  5.19V
電流 0x0a = 10  -> 0.010 A

他にも電流積算値や抵抗値など、画面上に出ているものは大体そのまま全て並んでいることがわかります。

ちなみに、他にも「0xf1」を送ると画面切り替え、「0xf2」を送ると画面回転、「0xf3 」「0xf4」で積算値グループの切り替えやクリアができたりします。

プログラムでロギングしてみる

Rubyでログを記録するプログラムを書いてみました。

#!/usr/bin/ruby                                                                                     

require 'serialport'

require 'timeout'

require 'json'

 

Signal.trap(:PIPE) { exit }

 

sp = SerialPort.new('/dev/rfcomm0')

sleep 2

failure = 0

loop do

  sp.write "\xf0"

  begin

    Timeout.timeout(2) do

      s = sp.read(130)

      if !s || s.length < 130

        warn 'incomplete data'

        failure += 1

        next

      end

      data = s.unpack('n*')

      # p data                                                                                      

      json = JSON.generate({

        T:   Time.now,

        V:   data[1]/100.0,

        A:   data[2]/1000.0,

        W:   data[4]/1000.0,

        C:   data[5],

        mAh: 256 * data[8] + data[9],

        mWh: 256 * data[10] + data[11],

        ohm: data[62]/10.0,

      })

      puts json

      STDOUT.flush

      failure = 0

    end

  rescue Timeout::Error

    warn 'timeout'

    failure += 1

  end

  if failure > 5

    warn 'Too many failure. quit.'

    exit 1

  end

  sleep 1

end

これを実行すると1秒ごとにJSON形式で計測値が出力されます。

{"T":"2018-04-14 23:01:48 +0900","V":5.17,"A":0.089,"W":0.46,"C":21,"mAh":6,"mWh":31,"ohm":58.0}

{"T":"2018-04-14 23:01:49 +0900","V":5.17,"A":0.089,"W":0.46,"C":21,"mAh":6,"mWh":31,"ohm":58.0}

{"T":"2018-04-14 23:01:50 +0900","V":5.17,"A":0.089,"W":0.46,"C":21,"mAh":6,"mWh":31,"ohm":58.0}
...

 

 iPhone Xの充電状況を計測してみる

これを使ってiPhone Xの充電中の電流などを計測してみました。

なお、iPhoneのバッテリー残量は、MaciPhoneを接続した状態で libimobiledevice を使って取得することができます。

$ brew install libimobiledevice  # インストール
idevice_id -l
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX  # <- IDを確認

$ ideviceinfo -u XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX -q com.apple.mobile.battery

BatteryCurrentCapacity: 96       # <- バッテリー残量

BatteryIsCharging: false

ExternalChargeCapable: false

ExternalConnected: false

FullyCharged: false

GasGaugeCapability: true

HasBattery: true

 

 

これを定期的に記録して、UM24Cで測った計測値と合わせてグラフ化してみました。
以下が残り5%の状態から100%までの、2時間半の充電中の状況です。

f:id:NeoCat:20180414230918p:plain

ちょっと単位が入り混じってしまっていますが、92-93%くらいまで充電されたところで充電電流がカクッと減る様子などがみて取れます。

なお、電流積算値はiPhoneアプリ 「Battery Care」を使って取得した最大容量 2700mAhと結構ぴったり一致しました。(iPhone Xの最大容量は2800mAhですが、使っているうちに僅かに劣化したようです。) とはいえ充電中も電源はONなので、iPhoneの消費と誤差がたまたま相殺したのでしょうかね。

 

 

赤外線アレイセンサ AMG8833 (Grid-EYE) をWebSocketで見てみる

赤外線アレイセンサ AMG8833、いわゆるGrid-EYEを使ってみました。

www.switch-science.com

 

上記の説明の通り、60度の四角錐の測定エリア(2次元)を8x8に分割した64個のピクセルについて、0〜80℃の温度が得られます。時間分解能は10fpsです。

これを、ESP8266 (ESP-WROOM-02) のI2Cで読み出してみました。上記は3.3Vで動作するモジュールになっているので、電源を含め、4本(Vcc, GND, SCL, SDA)の線で繋ぐだけで動作します。

ESP8266の場合、ArduinoWireライブラリはデフォルトでSDAにGPIO4、SCLにGPIO5を使用するため、この通りにしておくとスムーズです。(これ以外のピンでもピン番号さえ指定すれば動作します。)

 ESP8266はこちらのブレークアウトボードを使いました。

ESP-WROOM-02-搭載mikroBUS-R-対応ブレークアウトボード-Ver-2

 

基盤は以前別の目的でFusionPCBで作ったものを流用しています。GPIO13にはステータス確認用のLEDがついています。

f:id:NeoCat:20180128185609j:plain

 

AMG8833が取得した10fpsの結果をリアルタイムに手軽に可視化して見るため、WebSocketでブラウザにデータを流して表示してみることにします。ESP8266上にWebサーバ/WebSocketサーバを乗せて、そこにWebブラウザで接続すれば見られるようにしましょう。

 

AMG8833に対応したArduino用のライブラリはいくつか公開されていますが、今回はAdafruitが公開しているものを使いました。

Arduino IDEの「スケッチ → ライブラリをインクルード → ライブラリを管理…」をメニューから選び、Adafruit AMG88xx Libraryを検索してインストールします。ついでにWebSockets というライブラリも入れておきます。これは名前の通りWebSocketのサーバ/クライアント実装です。

 

あとは記事末尾のプログラムをArduino IDEで書き込みます。

AMG8833に関連するのは以下の部分です。0x68はこのセンサのI2Cアドレスです(0x68と0x69を基盤上のジャンパで選択可能。Adafruitのライブラリではデフォルトが0x69になっていました。)

#include <Wire.h>
#include <Adafruit_AMG88xx.h> Adafruit_AMG88xx amg; // setup amg.begin(0x68); // loop float pixels[AMG88xx_PIXEL_ARRAY_SIZE]; amg.readPixels(pixels);

ESP8266を起動すると、指定したWi-Fiに接続し(接続中は1秒間隔でLEDが点滅し、接続成功すると3秒間隔の点滅になります)、Webサーバが起動します。シリアル出力またはArduino IDEの「ツール → シリアルボート」でIPアドレスを確認し、そこにWebブラウザで「 http://192.168.10.xx/ 」のように接続すると、以下のように8x8のグリッドにリアルタイムの出力値が表示されます(なお自分の方に向けたときに鏡像になるよう、左右反転して表示させています)。グリッド内の各数値は℃、色は0℃〜30℃に色相を適当に割り当てています(JavaScriptの bgcolor 関数)。

 

近距離なら人の形が識別できそう。 

f:id:NeoCat:20180128210415p:plain

 

センサから2mくらい離れたところで手を振ってみたところ。10fpsだと結構動きもわかります。

f:id:NeoCat:20180128205653g:plain

 

 

暖房をつけている状態で部屋全体が入るくらいの距離にしてみると、天井近くの方が床付近よりも2〜3℃くらい暖かいことがわかったりします。なおここで見ているのは空気の温度ではなく、壁の温度だと思います。 

f:id:NeoCat:20180128210420p:plain

 

プログラム

 

gist.github.com

GitHubのPull Reqest作成ページをコマンド1つで開く

何かコードを書いて、ブランチをGitHubにpushしたあと、そのブランチのプルリクエストをさくっと作りたかったので、1コマンドで現在のブランチからのPull Request作成ページを開くコマンドを作りました。(共有レポジトリを想定)

以下のコードを実行可能権限をつけてパスの通った場所に git-ghpr という名前で置き、

git ghpr

とするだけでOK(なおブラウザを開くopenコマンドはMacの前提です)。ghprは GitHub Pull Request の略のつもりです。

perl で何やらやっているのは、親の最も近いブランチ名からPull Request先のブランチを推定する処理です。常に master 等に出すと決まっている場合は、ORIGIN="master" 等として固定値を入れておくと良いでしょう。

#!/bin/bash                                                                     
set -e
ORIGIN_URL="$(git config --get remote.origin.url)"
case "$ORIGIN_URL" in
  "git@github.com:"*)
    GHPATH="${ORIGIN_URL#*:}"
    GHSRC="https://github.com/${GHPATH%.git}" ;;
  "ssh://git@github.com/"*)
    GHPATH="${ORIGIN_URL#*@}"
    GHPATH="${GHPATH#*/}"
    GHSRC="https://github.com/${GHPATH%.git}" ;;
  "https://github.com/"*)
    GHSRC="$ORIGIN_URL" ;;
  *)
    echo "origin url is not github"
    exit 1
esac
# Pull Request先を推定
ORIGIN="$(git describe --all @~ | perl -pe 's/(?:heads|remotes|origin)\/|-\d+-g[\da-f]+$//g')"
GHURL="$GHSRC/compare/$ORIGIN...$(git rev-parse --abbrev-ref @)"
echo "$GHURL"
open "$GHURL"

Qiのパケットを解析してみる

iPhoneにも 8 / X でQiが搭載されました。

Qiでは受電機器から充電器に対して通信を行うことで、充電の開始/停止や電力の調整を行いながら動作しています。これにより異常があれば即時充電を止めるようになっているわけですね。

通信速度は2kbpsで、受電側の負荷を変化させることで充電側に電力の変化として通信データを伝える後方散乱変調という仕組みが使われています。詳しくは以下のデータシートなどが参考になります。

https://toshiba.semicon-storage.com/info/docget.jsp?did=14812&prodName=TC7763WBG

 

実際にどんな通信がなされているか気になったので、この通信パケットをキャプチャしてみました。

回路

続きを読む

pryがCtrl-Yでサスペンドしてしまう

Macのターミナル上でRubyのpryを使っている際、Ctrl-Kなどでカットした文字列を貼り付けようとCtrl-Yをタイプすると、サスペンドしてしまうことがあります。ちなみにirbだと発動しません。

$ pry
[1] pry(main)> [^Yをタイプ]
[1]+  Stopped                 pry
$ 

これはDSUSPという機能によるもの。Ctrl-Z(susp)が入力されたら直ちにジョブをサスペンドさせるのに対し、Ctrl-Y(dsusp)はこのキーで入力された制御文字をプロセスがreadしたタイミングでジョブをサスペンドさせるというもので、BSD互換の環境のみで利用可能な機能だそうです。

https://www.gnu.org/software/libc/manual/html_node/Signal-Characters.html


Mac上でsttyを使ってキー割り当てを調べてみると、

$ stty -a 
speed 9600 baud; 60 rows; 80 columns;
...
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
	eol2 = <undef>; erase = ^?; intr = ^C; kill = ^U; lnext = ^V;
	min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T;
	stop = ^S; susp = ^Z; time = 0; werase = ^W;

dsusp = ^Y となっているのが分かります。


Liunx環境では発生しないこともあり、よくMacでだけハマって面倒なので、dsuspを無効化します。

無効化するには

stty dsusp undef

を実行すればOK。自動化するなら .bashrc とか .zshrc に

tty >/dev/null && stty dsusp undef

などと書いておけば良いでしょう。