OS X はビルトインで WiFI のパケットをスニフする機能が入っているので、とりあえずキャプチャして保存するだけならとても簡単にできます。

sudo /usr/libexec/airportd en0 sniff 1

これで WiFi のチャンネル1 (2.5GHz帯) のスニフができ、/tmp 以下に適当なファイルができて保存されます。

キャプチャはこれで良いのですが、別途解析ソフトウェアが必要です。

Wireshark

https://www.wireshark.org/

airportd sniff での結果は Wireshark で解析することができます。.cap ファイルを Wireshark の File → Open… から選択するだけです。

接続先が接続元の Mac アドレスでフィルタする場合、wlan.da == ff:ff:ff:ff:ff:ff や wlan.sa == ff:ff:ff:ff:ff:ff でできます。

該当するようなパケットが見つかっているなら、右クリックでフィルタとして適用とできるようになっています。

WPA2-PSK の解析

WiFi の経路は暗号化されているので、そのままだとIEEE802.11 フレームは読めますが、イーサネットフレームは読めません。しかしこれも Wireshark に適切に設定をすることで解析可能になります。

http://jorisvr.nl/wpapsk.html ここにSSIDとPassphrase を入れてでてくる16進数文字列をコピーしておきます。

Preferences… → Protocols → IEEE802.11 → Decryption Keys

type を wpa-psk として、Key にコピーした16進数文字列を入れます。

これで OK を押すと既存の解析結果も更新され、デコード可能ならデコードされます。

  1. トップ
  2. tech
  3. OS X での WiFi スニファ

オムロン 【自動電源ON】【4秒測定】【体重50g単位表示】【PC/スマホ対応 Wi-Fi通信機能搭載】体重体組成計 カラダスキャン HBF-253W-BK - オムロン(OMRON)

オムロン(OMRON)

5.0 / 5.0

なんとなく欲しいなとは思いつつ高いから買ってませんでしたが、妻が買ってきました。とりあえず結構いい感じです。

セットアップ時にスマートフォンのオーディオ出力とマイク入力を使ってやるようになってました。どういうタイミングで音を出してるのか調べなかったのですが、ヘルプだと「ピポパと聞こえたら…」という記述があるので、DTMF でやってるのかもしれません。このオーディオ出力とマイク入力を使う方法ですが、Zenfone2 ではうまくいった一方で、HTC J One ではうまくいきませんでした (beat audio などは切ってみたんですが…)

それはともかく、WiFi 経由ということですが、実際どのような通信が行われているのか知りたくなってきました。できれば接続先サーバをうまく騙して (ないし透過プロキシを通して) データをインターネットに出る前に自分で処理したいという気持ちもあります。

そんなわけでIEEE802.11フレームのパケットスニファを行って少しだけ追跡してみました。

接続先は vdu.wellnesslink.jp

WiFi パケットの解析をしてみたところ、ちゃんと TLS を使っているようでした。なので透過プロキシやら何やらを挟むことはできません。

体重データは人によってはセンシティブな個人情報ですから、TLS を使うのは当然でしょう。

一方、サーバサイドのサービスが終了してしまったとき、このデバイスの WiFi 機能は完全にゴミになります。自分の所有するデバイスの管理を自分でできないわけですからちょっと気持ち悪いところがあります。

  1. トップ
  2. tech
  3. オムロンのWiFi対応体重計 HBF-253W の通信傍受 (失敗)

pack のテンプレート文字列から、それを使ってパックした結果のサイズを求めたいということはありませんか。つまりやりたいことは sizeof(struct x) です。

pack テンプレート文字列は割と複雑で、任意長や文字列やポインタなどがあり、全てにおいてうまく動作するものを作るのは無理ですが、だいたいうまくいくのは実装できそうです。

sizeof(template)

def sizeof(template)
	x = Class.new(Numeric) do
		def to_str; ""; end
		def to_int; 0; end
		# implicit to_f is called only with Numeric subclass
		def to_f; 0.0; end
	end.new
	size = template.scan(/([a-zA-Z][_!]?[<>]?)([0-9]*)/).reduce(0) {|r,(_,n)|
		r + (n.empty?? 1 : n.to_i)
	}
	# p [template, size]
	Array.new(size) { x }.pack(template).size
end

やってることは「とりあえず pack してみる」ですが、pack するためには、まずテンプレート文字列に応じて、適当な型と適当な長さの配列が必要になります。

適当な長さという点では多い分には問題ないので、適当に数えています。

適当な型というのは、厳密にやると結局テンプレート文字列をパースするのと同じぐらい面倒なので、pack が要求するデータ型すべてに暗黙的に変換可能なオブジェクトを作っています。

pack が要求する型は整数・文字列・浮動小数点数があります。整数は to_int、文字列は to_str を実装すると、Ruby はそのオブジェクトについて整数・文字列と同等に扱う(必要なら暗黙的に変換される) ことになっています。

浮動小数点数にはそういったどんなオブジェクトも浮動小数点数として扱えるようにする、というメソッド名がないのですが、Numeric のサブクラスであって to_f が実装されている場合には暗黙的に変換されるというルールがあるので、ベースクラスを Numeric にしています。

[
	"C",
	"S",
	"L",
	"Q",

	"c",
	"s",
	"l",
	"q",

	"S_", "S!",
	"I", "I_", "I!",
	"L_", "L!",
	"Q_", "Q!",

	"s_", "s!",
	"i", "i_", "i!",
	"l_", "l!",
	"q_", "q!",

	"S>", "L>", "Q>",
	"s>", "l>", "q>",
	"S!>", "I!>",
	"L!>", "Q!>",
	"s!>", "i!>",
	"l!>", "q!>",

	"S<", "L<", "Q<",
	"s<", "l<", "q<",
	"S!<", "I!<",
	"L!<", "Q!<",
	"s!<", "i!<",
	"l!<", "q!<",

	"n",
	"N",
	"v",
	"V",

	"U",
	"w",

	"D", "d",
	"F", "f",
	"E",
	"e",
	"g",
	"G",

	"A",
	"a",
	"Z",
	"B",
	"b",
	"H",
	"h",
	"u",
	"M",
	"m",

#	"P",
#	"p",
#	"@",
#	"X",
#	"x",

	"C255",
	"i!2s!2",
	"i!i!s!s!",
].each do |tmpl|
	next if tmpl =~ /q/i
	puts "sizeof(%p) = %d" % [tmpl, sizeof(tmpl)]
end
sizeof("C") = 1
sizeof("S") = 2
sizeof("L") = 4
sizeof("c") = 1
sizeof("s") = 2
sizeof("l") = 4
sizeof("S_") = 2
sizeof("S!") = 2
sizeof("I") = 4
sizeof("I_") = 4
sizeof("I!") = 4
sizeof("L_") = 8
sizeof("L!") = 8
sizeof("s_") = 2
sizeof("s!") = 2
sizeof("i") = 4
sizeof("i_") = 4
sizeof("i!") = 4
sizeof("l_") = 8
sizeof("l!") = 8
sizeof("S>") = 2
sizeof("L>") = 4
sizeof("s>") = 2
sizeof("l>") = 4
sizeof("S!>") = 2
sizeof("I!>") = 4
sizeof("L!>") = 8
sizeof("s!>") = 2
sizeof("i!>") = 4
sizeof("l!>") = 8
sizeof("S<") = 2
sizeof("L<") = 4
sizeof("s<") = 2
sizeof("l<") = 4
sizeof("S!<") = 2
sizeof("I!<") = 4
sizeof("L!<") = 8
sizeof("s!<") = 2
sizeof("i!<") = 4
sizeof("l!<") = 8
sizeof("n") = 2
sizeof("N") = 4
sizeof("v") = 2
sizeof("V") = 4
sizeof("U") = 1
sizeof("w") = 1
sizeof("D") = 8
sizeof("d") = 8
sizeof("F") = 4
sizeof("f") = 4
sizeof("E") = 8
sizeof("e") = 4
sizeof("g") = 4
sizeof("G") = 8
sizeof("A") = 1
sizeof("a") = 1
sizeof("Z") = 1
sizeof("B") = 1
sizeof("b") = 1
sizeof("H") = 1
sizeof("h") = 1
sizeof("u") = 0
sizeof("M") = 47
sizeof("m") = 0
sizeof("C255") = 255
sizeof("i!2s!2") = 12
sizeof("i!i!s!s!") = 12
  1. トップ
  2. tech
  3. Ruby の pack テンプレート文字列からそのデータサイズを求める
  1. トップ
  2. ruby
  3. Ruby の pack テンプレート文字列からそのデータサイズを求める

Cの構造体とかだと、構造体の中に他の構造体ということは普通にあります。

こういった構造体の文字列を unpack すると、全部フラットな配列になってしまうので、Ruby レベルのオブジェクト構造として再構成しようと思うと面倒なことになります。

ということで、入れ子に対応した unpack というのを実装してみました。

概要

以下のような感じで {} (ブレース) で入れ子を表現するようにテンプレート文字列を拡張します。

struct_foo_t = %{
	I!
	I!
	Z16
}

struct_bar_t = %{
	I!
	I!
	{
		#{struct_foo_t}
	}
	I!
} #=> "I!I!{I!I!Z16}I!"

original = [
	0xffff,
	0xfeff,
	[
		0x11,
		0x22,
		"foobar"
	],
	0x10,
]

packed = original.pack_deeply(struct_bar_t)
p packed
#=> "\xFF\xFF\x00\x00\xFF\xFE\x00\x00\x11\x00\x00\x00\"\x00\x00\x00foobar\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x10\x00\x00\x00"

unpacked = packed.unpack_deeply(struct_bar_t)
p unpacked
#=> [65535, 65279, [17, 34, "foobar"], 16]

p original == unpacked
#=> true

実装

先頭から unpack して入れ子を処理していくというイメージです。処理済みのバイト長が欲しいので、クソみたいですが一旦 unpack したものをもう一度 pack しています。

pack_deeply は単にフラットにして pack するだけなので簡単です。

class String
	def unpack_deeply(template)
		ret = []
		tree = [ ret ]
		n = 0
		tmpl = ""

		# unpack partial and add to result
		unpack = lambda {
			unpacked = self.slice(n..-1).unpack(tmpl)
			# re-pack to get byte length
			size = unpacked.pack(tmpl).size
			n += size
			tmpl = ""
			tree.last.concat(unpacked)
		}

		template.each_char do |chr|
			case chr
			when "{"
				unpack.call
				ary = []
				tree.last << ary
				tree << ary
			when "}"
				unpack.call
				tree.pop
			else
				tmpl << chr
			end
		end
		unpack.call
		ret
	end
end

class Array
	def pack_deeply(template)
		flatten.pack(template.gsub(/[{}]/, ''))
	end
end
  1. トップ
  2. tech
  3. Ruby でネストした構造体文字列をネストした配列として unpack する
  1. トップ
  2. ruby
  3. Ruby でネストした構造体文字列をネストした配列として unpack する

markdown で HTML にして wkhtmltopdf で PDF 化する汎用 Makefile です。

Markdown で書いてプレビューするのはいいんですが、画像がちらばってしまって面倒です。PDF にしておけば1ファイルにまとまるのと、だいたいどこでも見ることができるので便利です。

# brew install markdown
# http://wkhtmltopdf.org/downloads.html

.SUFFIXES: .md .html
.SUFFIXES: .html .pdf

SRCS = ${wildcard *.md}
HTMLS = $(SRCS:.md=.html)
PDFS = $(SRCS:.md=.pdf)

define header
	<!DOCTYPE html>
	<meta charset="utf-8">
	<title>MD</title>
	<style>
	body { font-family: sans-serif; line-height: 1.66 }
	img { max-width: 800px }
	</style>
endef
export header

.PHONY: all
all: $(PDFS)

$(HTMLS): Makefile

.html.pdf:
	wkhtmltopdf $< $@

.md.html:
	(echo "$$header"; markdown $<) > $@
  1. トップ
  2. tech
  3. Markdown → PDF にする Makefile

ioctl に構造体のポインタを渡して値を返してもらうような場合があると思います。

このような場合、文字列つくってそのまま渡せば struct のポインタになるようでした。

つまり pack/unpack("P") を使ってこう書くのは

Termios2::FORMAT = "I!I!I!I!CC19I!I!"
Termios2::FORMAT_POINTER = "P44"

# バッファ
v = tio.values.flatten.pack(Termios2::FORMAT)

# pack("P") でポインタを取得
pointer = [v].pack(Termios2::FORMAT_POINTER)

# ポインタを数値として渡す
self.ioctl(TCGETS2, pointer.unpack("L!")[0])

# unpack("P") でポインタから値を取得し、構造体を unpack
tio = Termios2.new(*pointer.unpack(Termios2::FORMAT_POINTER)[0].unpack(Termios2::FORMAT))

単に文字列を引数に渡す方法で簡単に書ける

# バッファ
v = tio.values.flatten.pack(Termios2::FORMAT)
self.ioctl(TCGETS2, v) # v が ioctl 内で書き変わる
tio = Termios2.new(*v.unpack(Termios2::FORMAT))

v の長さが構造のサイズに足りてないと死にます

備考

リファレンスの IO#ioctl には以下のように書いてあるんだけど、意味がわからなかった……

If it is a string, it is interpreted as a binary sequence of bytes.

  1. トップ
  2. tech
  3. Ruby で IO#ioctl の引数に構造体 (struct) へのポインタを渡したいとき

グラフ化した消費電力値。5:00 ぐらいにエアコンの電源が自動的に入るようになっていて急激に消費電力が増える。起床後は食洗機や洗濯乾燥機などが稼動してさらに増えていく。40A契約だが、一瞬ピークでそこまでいってる (これは原因不明)

節電モニター

節電モニター - はやわかり

はやわかり

5.0 / 5.0

(国内だと節電モニター「はやわかり」という商品名のもの)

500 Can't connect to lowreal.net:443 (certificate verify failed) のとき買って、設置をしてはいたものの、十分に活用していたとはいえない状態でした。電気使いすぎのときにアラートを鳴らしていて、ブレーカーが落ちる1歩手前で気付けるというのが現状では最大の活用でした。

しかし、せっかく USB 端子があってデータが読み出せるのだから、自動的にグラフ化したくなってきました。ちなみにこの製品には Windows 版のかなりデキの悪いソフトウェアが付属していますが、正直常用できるようなものではありません。

製品の詳細を調べる

この製品はどうやら、以下のものと同一のようです。

USB 接続してシステムプロファイラでベンダIDなどを調べて検索すると、Silicon Labs の USB シリアル変換のチップのようでした。


実際プロトコルダンプして読みだしたりしている人がいます。

思ったより情報があったので簡単そうです。

Raspberry Pi で読みだす

ドライバの対応の関係上、Linux で読み出すのが一番簡単です。通常のドライバだと製品IDが登録されていないのですが、Linux の場合はこの製品のIDについても対応するドライバを使うようになっているので、特に苦労せずにシリアル通信ができます。

Raspberry Pi の場合、CP210x のドライバは最初から入っているようなので、特にインストールすることもなく、USB ケーブルを繋ぐだけでシリアルポートとして認識します。

シリアルフォーマット

ボーレート 250000 8bit stopbit 1 parity 0 となっており、ボーレートが特殊なので、場合によって工夫が必要です。

Ruby を使って読みだすことにしましたが、これのせいで自力で ioctl を呼ぶハメになっています。

データ形式

送られてくるのは常に、11バイト固定長で、こちらから送るのは \xA5 か \x5A だけです。解析結果のコードがあるので、その通り実装したらいいだけです。

ただ、フローコントロールをオフにせずに試していたところ、デフォルトだとソフトウェアフローコントロールが有効なようですが、データ欠けが発生して微妙に読みだせず4〜5時間ハマりました。どうやら必ずフローコントロールは完全にオフにする必要があるようです (ハードウェアフローコントロールだとデータ欠けは発生しないが、そもそも応答しなくなりました)

コード

という感じのを Ruby で実装しました。といっても、プロトコル解析はされているし、 Python 実装もあったのでたいしたコードにはなっていません。

https://github.com/cho45/CM160-rb

とにかくフローコントロールが最大のハマリどころでした。

備考

この製品は 315MHz帯の微弱電波機器 (免許・技適不要) となっていて、かなり電波が弱いです。うちはかなり狭い家(マンション)で、玄関上にある分電盤からリビングまで、10mもないと思いますが、これで電波がぎりぎり届きません。

なので、機器同士は比較的近くにおくようにして、Raspberry Pi などでネットに中継するほうが安定して便利そうです。広い家だとむしろ中継が必須な気がします。

とはいえ、そろそろスマートメータの設置もすすむので、こういうのも必要なくなるのかもしれません。

  1. トップ
  2. tech
  3. 市販の節電モニターから値を読みだしてグラフ化

分電盤にセンサーをつけて家庭内全体の消費電力を測るというのはやっていますが、実際のところ何がどう電力を食っているのは大本で計測してもわかりにくいわけです。エアコンや洗濯機などの大きなものはともかく、待機電力の支配率はコンセントごとに電力を常時測定しなければわかりません。

  • コンセントごとにセンサーをつけても十分に安い
  • データを無線で集約できる

みたいなデバイスが欲しくなります。

試作品の回路図

検討はあとに書きますがまず現段階の回路図です (といってもたいして見所はありませんが…)

ただし、

  • ブレッドボードに実装しているのは 1ch のみでアナログスイッチなし
  • 電源回路が回路図だと昇圧回路になっているが消費電力が多すぎるのでやめている

カレントセンサー

交流回路に微小抵抗を入れて直接測定するという手もありますが、これは危険が伴いますし、ちょうどいい微小抵抗の入手が難しいという問題があります。10mΩでも30A流したら抵抗だけで9W消費しますし、15Aでも2.25W消費します。

そうなると、やはりカレントトランスを使うほうが筋が良さそうです。ただカレントトランスもあまり入手性は良くないですし、価格もカットコアのものだとそれなりにします。

参考:http://akizukidenshi.com/catalog/g/gP-08960/

しかし ebay で検索してみると、ちょうど良さそうなカレントトランスが100円程度で売られています。カットコアではありませんが、実際のところカットコアのカレントランスが必要なのは分電盤のように絶対切断できない箇所かつホットとコールドが最初から分かれて配線されている部分だけなので、実質的にはあまり問題にならないでしょう。最終的にはこれを使えばよさそうです。

ただ、とりあえずは2000:1のカットコアのカレントトランスが手元にあるので、これを使います。

ADC部分

カレントセンサーが発生させる微小な電流を電圧に変換してデジタル化します。

センサーの出力電流

通常コンセントは1ポートあたり15Aまでですが、実効値で15Aだと、ピークでは21.2A流れていますし、実際の負荷によってはパルス的に倍以上の電流が流れることもあります。30Aぐらいの負荷まではいけるようにしておきたいところですが、そもそも電力契約上で40Aとか60Aが上限なので、このへんをフルスケールにして計算してもよさそうです。

分解能としては1Wあれば十分すぎるぐらいに感じます。100Vだと0.01Aです。結構なダイナミックレンジになります。

センサーの2次側の出力電流は巻線比によって決まります。1:2000 なら2次側に1次側の2000分の1の電流が流れます。すなわち 30A で 15mA、0.01A で 5uA です。

電圧変換

発生する電流は交流なので、整流する必要があります。整流した電流値を負荷抵抗で電圧に変換し、ローパスフィルタで平均化します。

負荷抵抗は10Ωぐらいにすることが多いみたいです。小さければ小さいほどリニアリティが改善します。これにより、1次側が 30A なら抵抗に最大 212mV(30 / 2000 * 10 * sqrt(2))の電圧がかかる全波整流後の波形になります。

後段にローパスフィルタをつけ、平滑します。このフィルタは整流済み信号の平滑と、ADC 入力前の折り返しノイズ防止フィルタを兼ねています。これにより電圧は元の交流電圧の平均値となります。1次側が 30A なら出力は135mV (30 / 2000 * 10 * 0.9)の直流になります。

0.01A なら45uVです。

ADC

今回は MCP3425 という8倍までのPGAがあるI2C ADCデバイスを使ってみました。16bit、LSB=62.5uV の分解能があり、8倍のPGAがついているので、8倍時にはLSB=7.8125uVとなります。16bit をしっかり生かせるなら、十分な精度となります (が実際のところこのぐらい微小な電圧を測定するのは難しい)

このADCデバイスのフルスケールは±2.048Vですので、60Aで270mVぐらいは余裕です。

本来だと微小な電流検出にはオペアンプを使ったI-V変換回路をつけるのが筋だと思われます。ただ、低オフセット入力なオペアンプが必要になります。低オフセット電圧のオペアンプは高価ですし、今回はこのように ADC デバイスの PGA で8倍までは増幅できるので、まぁなんとかなるだろうという目論みです。

入力はアナログスイッチで複数いけるようにしたい思いがあります。

MCU部分

今回は ESP8266 のみを使うことを考えました。

  • ESP8266 は500円ぐらいで激安
  • WiFi 接続できる MCU として単体でいける

というのが大きなメリットだと感じました。

コード的には MCP3425 から読みだして送信するだけです。省電力のため ESP-NOW という ESP8266 独自のAPIで通信を行っています。

ESP-NOW は受信側が別途必要なので、受信用のデバイスのコードもあります。こちらは STA+AP で起動して、ESP-NOW で受けとったデータをグラフAPIに投げなおしています。

ただ、実際 ESP-NOW を使ってみると、少し離すと、想像以上にフレームが届かないことが多いです。WiFi バンドが混んでいるせいというのもあると思いますが、なかなか厳しく、再送を実装するか、もしくは諦めて普通にWiFi接続したほうがいい気がします。電源次第です…

電源部分

ここが難しくて悩むところです。

もともとは電池駆動しようと思っていましたが、いろいろ実験した結果、電池駆動で半年程度もたせるにはかなりの低頻度のやりとりになることがわかりました。なので、この用途ではあまり筋が良くなさそうです。

一方でAC電源からとってくるのも割と面倒です。200mA 3.3V 程度だけとれる小型のAC/DCスイッチング電源なんて滅多に見ません。ACアダプタを改造するにせよ、そもそもACアダプタがそこそこ高価です。

ということで今のところ電源は保留にしています (モバイルバッテリ駆動しています)

ebay で探すと 3.3V 600mA の AC/DC 電源はすこしヒットしますので、買ってみて使えそうならこれでいい気がします。

現状

ブレッドボードで作業デスク付近のコンセントの電流を計ってみています。まぁまぁ面白いのですが、一箇所だけ計ってもあんまり面白くないです。

電源まわりをうまく解決する方法を考え中です。

その他

本来用途として WiFi は適切なプロトコルとはいえないですから、Bluetooth LE や ZigBee の安価なデバイスがあればそのほうが良いと思います。とはい現状 ZigBee 最安の TWE-Lite ですら ESP-WROOM-02 の3倍ぐらいの値段です。

  1. トップ
  2. tech
  3. コンセントごとの消費電力を知りたい人生