AIPH〇NEのプロトコルに関する追試

はじめに

家電や住宅設備についていろいろやってきました。次は何にする？インターホンを触ってみましょう。

インターホンといえば下記の記事を見た覚えがあります。

アイ〇ンのプロトコルの話 #IoT - Qiita
https://qiita.com/binzume/items/54ea81600ba8cfd4a14b

アイ○ンをハック１ - 日記
https://www.binzume.net/diary/2010-09-14:A1

著者は夢の中でアイ〇ンのプロトコルについて調査し、まとめられています。今回これを参考にして自分も似たような夢をみることができました。

そこで本稿では、この夢の中で見た内容についてまとめてみます。もちろん夢の中の話なので（表現を借りるとすると）「この内容はすべて空想であり、本文中の画像は生成AIによるものです」。

インターホンの構成

本稿で扱うのは、アイホンの集合住宅用インターホン「DASH WISMシリーズ」¹です。先行事例と同じシリーズ（ただし型番は違う）でした。

DASH WISMシリーズのインターホン

この機器をベースとして、インターホンシステムの構成について述べていきましょう。とはいえ全体的な構成としてはアイホンや、同じく集合住宅用インターホンを作っているPanasonicの製品紹介ページを見れば構成図が載っています。ここでは横着して、「もし興味があればそちらをご覧ください」です。だいたいどのシステムもこんな感じでした。

制御装置がある
- ここに集合玄関機とか、各戸室内インターホン端末が繋がる
- 共用部の各種連動機器（宅配ボックスやエレベーター制御装置など）もここに繋がる
制御装置と室内インターホン端末は幹線を介して繋がる
- 幹線にバスの構成で室内端末がぶら下がる
- 幹線には「2芯のツイストペアケーブル 1本、または複数」などが使われる
- （モニター付きでも1本の場合もある、ということは制御データ・映像・通話音声などは多重化されている）
- 状況によってはテレビ共同受信用のケーブルを使ったり²、無線で飛ばす³こともある
幹線は複数用意されることもある
- ということは、ある部屋と別の部屋でバスが分かれていることもある

室内端末についてはこんな感じです。

幹線と（必要に応じて多重化された信号をほどきながら）接続
- （少なくともアイホンだと）「『データ』と『映像・通話』」や「『データ』と『映像』と『通話』」などに分けて入力される
- 多重化をほどくときは、専用アダプタで分けたり、それ相当の機能が玄関子機内に内蔵されていたりする
- 分割されたあとの信号線もやっぱり2芯のツイストペアケーブル
部屋番号を設定する仕組みがある
- 幹線にバスでぶら下がっているので。自分宛てなのか判断する必要がある
- （少なくともDASH WISMの場合）8bit分のDIPスイッチで設定
- もし256戸より多くの住戸があったら？は不明……幹線番号みたいな情報も使ってうまく変換するのかも知れない
火災報知器やガス漏れ検知器が繋がったりする
- 火災報知器は玄関子機を通じて外部からの点検もできる（遠隔試験）
もしPanasonicだったら接点出力もある
- 来客時に作動するらしい
- アイホンには無い。補助音響用の端子はあるので頑張ればそれが使えるかも
室内端末の数は増やせる
- アイホンだと「増設親機」という呼び方をする。最大2台まで
- 増設親機と幹線は分離されている（たぶん）
最近のものだとスマホアプリと連携できる
- DASH WISMでも増設親機として「携帯電話インターフェースアダプター」（現在は入手が難しい）を繋げば連携できる
- もし室内端末がアプリと連携できる場合、後述のなんやかんやよりもアプリ側から攻めたほうが楽だろう

次からは幹線の信号線や、室内端末の内部をみていきます。

幹線の信号線

まずは幹線を見ます。

そのために室内端末のパネルを開けますが、内部に触れている間はブレーカーを落としておいたほうが良いんじゃないでしょうか⁴。うっかり非常ボタンとか触ってしまいそうだし。施工時の問題で電源接続部の根本からVVFケーブルの銅線が見えるなど、充電部が露出していることも考えられます。ただ、ブレーカーを落とすとそれが管理人室に伝わり、場合によっては警備会社に連絡が行くケースもあるようです。制御装置は各室内端末に対して死活チェックを行うようでこれを利用しているのかな……と思っています。自分の場合、少なくともいまのところは問題になっていません（そもそも管理人室に電源断の信号が届いていない or 電源断は認識しているが無視する運用となっている or 勝手に電源断してめちゃめちゃ怒っているがまだ通知前）が、この点はご留意ください。

信号線の観測

実際に幹線の信号線を見ていきましょう。 DASH WISMでは「データ」「映像・通話」の信号線が来ています。それぞれ2芯のツイストペアケーブルが使われているので、線としては合計4本です。

これらの線は壁内の端子台に接続されています。これをWAGOのワンタッチコネクタを使って分岐させて観測しました。

観測の様子

冒頭で述べた先行事例のとおり、「データ」「映像・通話」は平衡回路による差動信号が流れているようです。ひとくちに平衡回路が、差動信号が、といっても電圧駆動か？電流駆動か？いろいろあると思いますが、具体的にどれに該当するのかはよくわかりません……。わかるのは「各ペアの線で何らかの信号と思われる電位差⁵があった」「データと映像・通話でも違いがありそう」「GNDの線は来ていないと思われる」「室内端末は接地されていない（制御装置は接地されている）」くらいです。ここではペアの電位差をオシロスコープで観測し信号として扱います。

ただ、各ペアの電位差を見るといっても差動プローブのようなものは持っていません。そこでオシロのあるチャネルに信号線ペアの一方を、別のチャネルにはペアのもう一方を入力し、演算によりチャネル間の電位差を見ます。正直この方法だと、自分が持っているオシロでは演算結果に対するトリガーは設定できずやや不便でした。とはいえ、オシロのアースを浮かせて信号線ペアの一方をGNDにして……というのは避けたい。ご安全に、ゼロ災でいきましょう。この測定のためにシングルエンドの信号に変換する仕組みを用意するのも手間がかかる。まぁ信号をちょっと見るだけだったので、演算機能を使うで問題ありませんでした。

データ

オシロスコープのCh1とCh2に「データ」の信号線を繋いで見ていきます。先行事例によるとこの信号線は

UART 1200 baud
8bit (LSB First)
偶数パリティあり
50kHz/70kHzをキャリアとしてFSKで変調されている

とのことで、それっぽくサンプリングレートを設定し、各チャネルの電位差も示した結果は次のとおりです。

「データ」の信号線を観測する様子

各信号線の対地電圧が24Vほど出ている（このためにトリガーがかけられなかった）。一番下にあるオレンジ色の演算結果を見ると、一部信号っぽいのが見えます。観測したデータを保存してPCに持ってきて⁶、信号の一部を拡大するとこんな感じです。

「データ」信号の一部

ここで前方はエントランス（制御装置）側から送信されたもの、後半は室内端末側から送信されたものです。前方の信号はなぜかASKのようにも見えて⁷包絡線検波でいけそう、思いましたがそれだと後半は無理っぽい。どちらの信号も、次のようにSciPyのSTFTで周波数を確認すると各ビットので変化しており、やはりFSKとして復調する必要があります。

「データ」信号の一部に対してSTFTを適用した結果

FSKをデコードするにあたっては「Goertzelアルゴリズム」という手法がよく使われるようです。これは特定の周波数のみに絞って分析を行う手法で、計算コストがSTFT（やDFT）よりも抑えられます。が、ここではPCで、さらにオフラインで分析しているのでこのままSTFTを使ってしまいましょう。

こんな感じの信号（いままでに示した信号とは別の箇所から切り出した信号）を「50kHzくらい⁸なら0」「70kHzくらい⁹なら1」としてデコードしてみた様子は次のとおりです（部屋番号に関連する部分はマスク）。

$ python3 aiphone_fsk_decode.py ch1.csv ch2.csv
len=70 bits=11000000011011110XXXXXXXXX11110100101100111010000100011110XXXXXXXXX111

「データ」信号をデコードする様子

画像における赤い点のところは「データを読み出したタイミング（横軸）」「そのタイミングでのピーク周波数（縦軸）」を示しています。 STFT自体はうまくいっていそうなものの、読み出しのタイミングが結構危ういです。たまにミスもします……まぁ重要そうなデータは人間が確認すれば良いんじゃないですか？データのはじまりから調歩同期の開始とみなしていますがこれは正確ではないので修正¹⁰したり、また調歩同期に加えエッジを見てタイミングのズレを適応的に修正するなどで精度は上げられると思います。

さて、データを見ると1から始まり、たまに10だか110だかが挟まって、1で終わる感じでした。おそらくこれはUARTの信号を一部切り取ってアイドル状態も含めてFSKで送っていると思われます。どういうことかというと、こういうことです。

変調の様子（推測）

アイドルの時間は一定とは限らないので、やっぱり本来であれば各スタートビットを見て同期を取らないと正確ではない。でも試した限りだとそうでなくてもまぁまぁうまくいっているので、この辺もしかしたら考慮されていて少し細工されているかも知れません。

これを受理するには ^(?:1*0(?P<bits>[01]{8})(?P<parity>[01])1*)+$ のような形式でやると良いんじゃないでしょうか。必要に応じてパリティの検証を行いつつ、LSB Firstなので各バイトのbitsを逆転させればそれらしいバイト列が出てきます。バイト列の構造は、先行事例のとおり「メッセージ種別 (1 byte)」「部屋番号 (1 byte)」「データ (n byte)」「チェックサム (1 byte)」となっているようです。 ACKやNACKを返すこともあり、その場合データは無し。この構造にしたがってダンプするとこんな感じに（部屋番号はマスク）。

# エントランスから呼出 + 取消
data0 t=0.000556000556000556 len=62 valid
  40 parity:valid [Msg Ent->Room Res/Req]
  xx parity:valid [Room XXXX]
  05 parity:valid [Data length:1 cmd:Call]
  c0 parity:valid
  xx parity:valid [CheckSum valid]
  ==> Call
data1 t=0.06199406199406199 len=43 valid
  d0 parity:valid [Msg Room->Ent ACK]
  xx parity:valid [Room XXXX]
  xx parity:valid [CheckSum valid]
data2 t=5.918069918069918 len=50 valid
  40 parity:valid [Msg Ent->Room Res/Req]
  xx parity:valid [Room XXXX]
  00 parity:valid [Data length:0 cmd:Terminate]
  xx parity:valid [CheckSum valid]
  ==> Terminate
data3 t=5.969360969360969 len=43 valid
  d0 parity:valid [Msg Room->Ent ACK]
  xx parity:valid [Room XXXX]
  xx parity:valid [CheckSum valid]

# 死活チェックっぽいもの
data0 t=0.000556000556000556 len=50 valid
  40 parity:valid [Msg Ent->Room Res/Req]
  xx parity:valid [Room XXXX]
  68 parity:valid [Data length:0 cmd:Ping]
  xx parity:valid [CheckSum valid]
  ==> Ping
data1 t=0.05156905156905157 len=43 valid
  d0 parity:valid [Msg Room->Ent ACK]
  xx parity:valid [Room XXXX]
  xx parity:valid [CheckSum valid]
data2 t=0.16263016263016264 len=70 valid
  c0 parity:valid [Msg Room->Ent Res/Req]
  xx parity:valid [Room XXXX]
  69 parity:valid [Data length:1 cmd:Pong]
  21 parity:valid
  xx parity:valid [CheckSum valid]
  ==> Pong
data3 t=0.2324082324082324 len=38 valid
  50 parity:valid [Msg Ent->Room ACK]
  xx parity:valid [Room XXXX]
  xx parity:valid [CheckSum valid]

先行事例のほうがより多くの調査結果が載っています。一応c3やc7、ce、cf（何からのカウンタが上がっている？）、また93からはじまるデータが流れてきたのは確認しましたが、内容が謎なので割愛。

ちなみに、ここで扱っているインターホンにはエントランスのオートロックに「非接触キー」をかざすと室内端末で帰宅通知が出るという機能があります。でも自分の環境では施工設定で無効とされているようでこの機能は使えません。え、「非接触キー」？ノンタッチキーでも良いんですか？それならせっかくあるのに¹¹……いやでも実は連携しているのでは！？！？ということで試してみましたが、特にそれらしいデータは得られませんでした。おわり。

映像

次は「映像・通話」の信号線（の映像部分のみ扱う）についてです。

この線では待機時だと無信号のようでした。おそらくオートロックに来客があったとき（または監視カメラがある環境だとそれを見ているとき？）しか流れないような……。もしかすると映像を出させるコマンドがあるかも知れませんが、よくわかりません。バスには他の部屋の室内端末もぶら下がっているので、誰かの部屋に来客があるまで待つ？いえ、もし画像が取れても他人が写ったものは扱いにくいのでやめておきましょう。

でも検証するとしたら、自分でオシロスコープを操作しつつエントランスに行ってインターホンを押して、またオシロスコープを操作して……とかで忙しすぎる。オシロスコープに慣れていない人に操作は頼めない、なら誰かにインターホンを押してもらうか、いやそれだとやっぱり扱いにくい画像になってしまう。と思ったら、このオシロスコープはnoVNCやSCPIにより遠隔で操作できる¹²んでした。 SCPIでやろうと思いましたが、普通にnoVNCがスマホの携帯電話回線からVPN経由（紛らわしい）でも繋がったのでそれで事なきを取得です。（実は「データ」信号線のときもこの方法を使ってバイト列を集めていました。）

こうして映像が出ているときの信号線を観測するとこうなりました。

「映像・通話」の信号線を観測する様子

差分を取った結果であるオレンジ色のところを見ると……う～ん、50Hzの波ですか？拡大してもよくわかりません。 Ch1とCh2で時間差が出来てしまったかなと思い、ちょっとズラして差分を取るもそういう話ではないようです。でもなんか線が太いような……なんらかの信号が含まれているのでは？

ここでアイホンの特許公報を見ると気になる記述を見つけました。その部分を引用します。

アイホン株式会社．集合住宅インターホンシステム．特開2007-053632

また、複数の共用部カメラ５の撮像映像は、カメラコントローラ６の制御により所定時間間隔で切り替えて制御機２に撮像映像を出力される。この映像はカメラコントローラ６からＮＴＳＣで出力され、制御機２にてＦＭ変調されて専用の映像信号線２５ｄにより各居室親機３へ送信されている。

なんか「集合住宅インターホンシステム」においてNTSCの出力がFM変調されることがあるらしいです。とはいえこれがDASH WISMで使われているか、もっといえば実際の製品に使われているかはわかりません。

そして、NTSCのFM変調について調べるとこんな記事を見つけました。

三洋半導体、無調整化を実現したテレビドアホン用FM変復調ICを発表 | TECH+（テックプラス）
https://news.mynavi.jp/techplus/article/20091021-sanyo_fmmodic/

「テレビドアホン用FM変復調IC」。ニッチすぎる。映像部分に注目すると搬送周波数12.5MHzくらいのFM波に変調するとのこと。でも特にアイホンで採用されたような資料は見当たらず、（後述する）基板を見てもこのICはたぶんありません。

まぁ期待は薄いですが、謎データの全時間に対してFFTくらいはしてみますか。これです。

「映像・通話」の信号線に対するFFTの結果

ちょうど12.5MHzあたりに山が見えます。怪しい。そこで、見よう見まねでFM復調を試します。復調したデータを見ると……

「映像・通話」復調後のデータ

ちょっと荒いですが、NTSCの垂直同期信号っぽいものが見えます。周辺を見ると一応水平同期信号っぽいものも。実は先行事例でもこの信号はNTSCであることが示唆されていましたが、復調後の話だったようです。

これをCVBSのデコードと同様にNTSCとしてデコードしてみると……こうなりました（-40IREを黒として設定）。

著者近影

（ほとんどぼかしてしまいましたが）各フレームが画像としてデコードできています。上部に映っているのがエントランスのドアです。

次はカラー画像としてデコードしたいところですが……それは叶いませんでした。プロービングの不備か、FM復調の品質が良くないせいか、色を取得できるまできれいな波形にはなっておらずモノクロが限界です。この辺は今後似たような夢を見る方に託したいと思います。今回「通話」についても触りませんでしたが、この辺も託したい。あとこの信号線でもASKで何らかの制御データを送っているのではないか（「テレビドアホン用FM変復調IC」の例とここには載せていない観測結果より）という気もしますが、これも託します。

なお、このインターホン（というかカメラ？）の画素数は約11万です。だからNTSCでも伝送できたんですね。でも最近のだと約115万画素らしいです。これだとNTSCは無理なんじゃ……。おそらくそちらだとAHDやHD-TVIやHDCVIなどが使われているんじゃないでしょうか。この辺も自分の環境だと検証できないので本当のところは謎です。

機器内部

ここからは機器内部を見ていきます。

基板全体について

基板は多層基板のようです。いくつかのボードに分かれています。さらに部品も高密度に実装されており、あんまりパターンは追えていません。

それでも主に「データ」と「映像・通話」の信号線がどう入ってくるかを見ようとしてはいました。パターンとしては別に等長配線というわけではなかったです。この辺はもしかしたら壁内の端子台側で吸収しているのかも知れないですし、そもそも施工時に人間が単線を剥いて端子台に差す¹³ことから、配線長の差についてはあまりシビアではないのかも知れません。

あとテストポイントとかいろいろ出ていますが、シングルエンドの信号が出てくるところは不明。

ほか、“AIPHONE”とマーキングされたICが2つありました。カスタムASICなのか？何かのICをリマークしたのか？は不明。機能も不明。もしかしたらこれらのどれかが「テレビドアホン用FM変復調IC」なのかも……。

基板対基板コネクタ

基板同士を繋ぐコネクタがあります。これについては先行事例の方がピンアサインを調べられているようでした。

https://github.com/binzume/door-keeper/blob/master/AiphoneCtrl/memo.md

壁内端子台との接続

端子台とはJST CZコネクタで接続されているようです。

インターホン側は4Pin、17Pin、20Pinという3つのコネクタがあり、うち17Pinのコネクタには下記のピンに「データ」と「映像・通話」の信号線があります。

Pin11 (TP289) … R1
Pin12 (TP291) … R2
Pin13 (TP292) … RA1
Pin14 (TP293) … RA2

ただ、CZコネクタの入手は難しかったです。それもあって「信号線の観測」ではWAGOのコネクタで分岐させていました。

増設親機との接続

増設親機との接続にはJST PHコネクタが使われています。

おそらくPin4 (B4)がGND……だと思いますが、これ以上はわかりませんでした。他のピンの電圧を測ってみてもよくわかりません。インターホンを押してみましたが特に変化が見えず。

もしかしたら何かのピンを短絡させたり、親機と増設親機間でPING,PONGのようなデータを送らないとダメなのかも知れません。親機と増設親機間で通話ができる機能があるらしく、それなら親機は何らかの方法で増設親機が接続されたことを検知していそうです。実際に増設親機を繋いだときの信号が見えれば一番良いですが、増設親機は受注生産でこの定価も高い。たまにヤフオクなどで中古品が出ますがそれでも高く、検証するにはためらいます。なので未検証です。

LCD担当基板

LCDまわりを担当する基板があります。

LCD担当基板

ここには “3.579” と書かれた水晶があり、それが繋がるのはSHARP IR3Y29BというICです。このICにはNTSCなどの信号をLCDに映す機能があるようでした。

であればどこかからその信号が渡されるはず。おそらく下側のJST ZHコネクタから入力されるんでしょう。実際にピンアサインを調べてみる¹⁴と……

左Pin7 (TP705) … 不明
左Pin8 (TP717) … 不明。2.5Vくらいかかっている。電源？
左Pin9 (TP702) … 不明。1MHzくらいの信号が流れている
右Pin1 (TP708) … 不明。5.2MHzくらいの信号が流れている
右Pin2 … GND。増設親機用コネクタのGNDとは別
右Pin3 … GND。右Pin2と同じ
右Pin4 (TP707) … LCD上に表示するNTSCの信号

でした。ほぼ「不明」¹⁵ですが……NTSCの信号はわかったので良いです。そのNTSCの信号を観測するとこうなります。

LCD担当基板に入力されるNTSC信号

きれいな信号ですね。まさに顧客が本当に必要だったもの。こういうのでいいんだよ、こういうので。

設定画面を表示しているときに信号を観測し、デコードするとこうなります。

NTSC信号（設定画面）のデコード結果

きれいな信号なので色付き（Y/C分離はBPF）で。まぁまぁ良い画面ですね。

同様に、インターホンで呼び出したときのNTSC信号をデコードするとこうなります。

著者近影その2

ちょっと暗い。でも（ぼかしたので伝わりにくいかもですが）鮮明でちゃんと色も出ています。本当は幹線の信号線でもこのぐらいきれいにデコードできたら良かったんですけどね。

おわりに

先行事例をもとにAIPH〇NEのプロトコルに関して追試を行いました。「データ」については先行事例の情報が正しいことを確認、「映像・通話」では映像部分のデコードもできて満足です。

実は先行事例の著者が寄稿した下記の同人誌（ななかInside PRESS vol.8）も見ており、これはいつか触ってみたいテーマでした。

ななかInside PRESS vol.8（vol.2か3ぐらいの頃からコミケに行きはじめたのでvol.1はなし）

それがようやく実現できました。先行事例があるとはいえ自分にとっては難しく、取り組み始めてから何度か投げ出したりしましたが最終的になんとか形になって良かったです。

以前に住んでいたところではPanasonicのインターホンが使われていたりして、そっちの仕様はどんな感じか……気にはなりますがもう検証できません。でも、もし今後見かけたことがあれば検証したいですね。なら次はPanasonicのインターホンが付いているところに住むか、いや次は戸建ての住宅を建てたい……。ここへ無駄に集合住宅用インターホンを（保守なしのどこから出たのかわからないような中古端末をセルフビルドで）導入したくて検証していたところもある。

まぁマンションの一室をオフィスとして貸し出しているところもある。そしてそうしたオフィスを借りることもあるかも知れない。そこにPanasonicのインターホンがあったら検証してみましょう。

おわり。

結構古い（参考: お使いのインターホンを確認しましょう（アイホン株式会社）。早くリプレースしてくれ。 ↩
アイホンとマスプロ電工がリニューアル向けに集合住宅用テレビ共同受信インターホンシステムを共同開発｜新着情報｜アイホン株式会社。ただし2004年に開発されたシステム。現行製品でも採用されることがあるかは不明。 ↩
ワイヤレスインターホン AirEZ（エアイーズ） | マンションインターホン | Panasonic ↩
以前住んでいたところでたまたまインターホンのリプレースがあり、その際は活線で作業されていましたが……。 ↩
電圧駆動のためか、それとも電流駆動によって生じた電位差かはわかりません。 ↩
当初は演算結果だけ持ってきていましたがこれだとサンプリングレートが落ちる仕様のようで……Ch1とCh2のデータを持ってきて自前で演算すると元のサンプリングレートのまま処理できました。 ↩
電圧駆動で意図的に振幅を変えているのか、それとも電流駆動で特定の周波数により電流値が異なった結果として電圧が変化しているのかはわかりません。 ↩
実際のピークを見ると約50.5kHzくらいが多い。 ↩
これも実際のピークを見ると約68.6kHzくらいが多い。 ↩
本来であれば各スタートビットのタイミングで同期を取るべき。 ↩
ノンタッチキーのデータを読む ↩
オシロスコープ購入 ↩
思えばLANケーブルもときには人間が手作りし、意図的に斜めカットしたりするような。差動といっても意外と雑でもいけるのかも知れません。 ↩
本体基板側のテストポイントから調査。でも当初はZHコネクタ側から調べようとしていました。既存ケーブルを別のケーブルに置き換え、その被覆をちょっと剥いて横取りするような構成。ZHのコンタクト圧着くらい自分でできるわ、と試みたものの用意した線が合っていないし、そもそもコンタクト小さすぎて難しいしで心が折れました。今後はどうしようもないとき以外は自分で圧着しない。でも圧着済みのやつは数千本単位で買わないと割高……。こういうのどうすれば良いんでしょうね。 ↩
このLCDはタッチで操作するため、それに関する信号もありそうですが……。 ↩