Experiment record

ノーリツ ハイブリッド給湯器：ヒートポンプ電力量をネットワークから取得できるか

ノーリツのハイブリッド給湯器で、リモコンには表示されるヒートポンプ瞬時電力・積算電力量を、ECHONET Liteまたは『わかすアプリ』のクラウドAPI経由で取得できるか実機確認した。

結論

ノーリツのハイブリッド給湯器について、リモコン画面に表示されるヒートポンプ瞬時電力と積算電力量をネットワーク経由で取得できるかを調べた。

今回確認した範囲では、目的の値を取得できるネットワークインターフェースは見つからなかった。

確認した経路は次のとおりである。

• ECHONET Liteの全Get可能プロパティ
• ECHONET Liteの状態変化通知（INF）プロパティ
• ノードが公開する全ECHONETオブジェクト
• メーカー独自に見える F1 / F3 / F4
• 「わかすアプリ」が利用するHTTPS API
• リモコンのLAN側TCP待受ポート

一方、リモコン画面ではヒートポンプの瞬時電力と積算電力量が実際に表示・更新されることを確認した。したがって値自体は機器内部に存在するが、今回調べたLAN/ECHONET/クラウドAPI層には公開されていない可能性が高い。

残る本命は、給湯器・ヒートポンプユニットとリモコン間の内部2線通信である。ただし、その先の解析にはオシロスコープや適切に保護されたロジックアナライザー等が必要になるため、今回の実験はここで終了した。

実験環境

既存のRaspberry Pi収集器は、ハイブリッド給湯器コントローラーからECHONET Lite UDP/3610を使い、1分間隔で読み取り専用データを取得している。

収集器は設定変更系サービスを使わず、Get (0x62) のみを送信する構成である。

既に収集できていた主なデータは次のとおり。

• ハイブリッド給湯器の運転状態
• 沸き上げ状態
• 残湯量
• タンク容量
• ガス積算量
• 水積算量
• ガス直接加熱状態
• 給湯設定温度

また別経路として、mitmproxyにより「わかすアプリ」のHTTPS通信を復号し、複数のJSON APIを確認済みであった。

ECHONET Liteの全Getプロパティを確認

最初に、ハイブリッド給湯機オブジェクト 0x02A601 のGet Property Map (0x9F) を取得した。

確認されたGet可能EPCは次のとおり。

80 81 82 83 86 88 89 8A 8C 8D 93 9D 9E 9F
B0 B2 B8 B9 C3 E1 E2 F1

ECHONET Liteの機器共通プロパティとして知られる、

0x84  瞬時消費電力
0x85  積算消費電力量

は、この実機の 0x02A601 には実装されていなかった。

同様に、瞬間式給湯器 0x027201、ガスメータ 0x028201、水流量メータ 0x028101 についてもGet Property Mapを確認したが、ヒートポンプ電力量に相当する標準プロパティは見つからなかった。

ノードが公開する全ECHONETオブジェクトを列挙

ノードプロファイルのインスタンスリスト 0xD6 を取得したところ、同一ノードには7個のオブジェクトが存在した。

02A601
027201
028101
028201
001601
000701
001101

既知の4オブジェクトに加えて、3個のセンサ系オブジェクトが存在したため、それぞれのGet Property Mapも調査した。

結果として、電力計測用の別オブジェクトは存在しなかった。

001101:E0 は温度センサ値で、実測時には 24.0 ℃ 相当の値を返した。

状態変化通知プロパティも確認

Get可能プロパティだけではなく、0x9D の状態変化アナウンスプロパティマップも調べた。

0x02A601 のINF対象は、

80 81 88 B0 B2 B8 B9 C3 E1

0x027201 は、

80 81 88 D0 D1 D4 E1 E2 E3 E4 E5 E6 E8 EF F2 F4

だった。

Get不可・通知専用の電力値が存在する可能性も考えたが、電力・電力量に相当する未知EPCは確認できなかった。

メーカー独自F系プロパティを調査

02A601:F1

50バイトのデータで、機種名やファームウェアらしき文字列を含んでいた。電力量ではなく識別情報と判断した。

027201:F3

100バイトの複合データを返した。

内部には、別オブジェクトから取得済みのガス積算値と水積算値と完全一致するバイト列が含まれていた。このためF3は、複数の内部状態・積算値をまとめたメーカー独自テレメトリブロックと考えられる。

そこで、

02A601:B2  沸き上げ状態
027201:F3  100バイト複合データ

を1分ごとに同時取得した。

観測中、B2 は not_heating から heating に変わり、ヒートポンプ運転が継続した。その間、リモコンのヒートポンプ電力量表示は増加したが、F3は長時間にわたり100バイトすべて同一だった。

したがって、F3をヒートポンプ電力量として利用する仮説は棄却した。

027201:F4

短いメーカー独自データで、一部バイトの変化は観測した。しかしヒートポンプ運転やリモコンの積算電力量とは継続的に相関せず、取得元としては採用できなかった。

「わかすアプリ」APIを再調査

mitmproxyで復号できた通信から、少なくとも以下のAPIを確認している。

getData
getStructure
getLifeLogEnergy
getLifeLogEnergyMonth
getLifeLogEnergyYear
getLifeLogUsage
getHybridUsageSituation

getStructure

実機では、

rcType = 5
eUnitFlag = 0
gthFlag = 0

などの機器構成情報を返した。

ヒートポンプ電力量を示す項目はなかった。

getHybridUsageSituation

レスポンスは ElectricityRate と GasRate であり、計測使用量ではなく料金・設定値側の情報だった。

getData

運転状態、浴室・給湯・貯湯関連の状態は取得できたが、ヒートポンプの瞬時電力や積算電力量に相当する項目は確認できなかった。

getLifeLogEnergy*

履歴には、

hotWaterUsage
hotWaterTotalUsage
bathTemprature
bathFlag
pulse2

などが存在した。

pulse2 は「パルス情報2」と説明されるが、今回の実機では日別・時間別とも 00 のままだった。

その間もヒートポンプは運転し、リモコンのヒートポンプ電力量は増加していたため、この構成では pulse2 はヒートポンプ電力量ではないと判断した。

setAppLoggingData はアプリ側ログだった

iotapi.noritz.co.jp/dev/setAppLoggingData という名称から機器テレメトリの可能性を疑ったが、実際のRequest Bodyは、

• Application Boot
• アプリバージョン
• OS
• iPhoneモデル
• クライアントログ情報

などだった。

したがって、これは給湯器のHP電力量データではなく、わかすアプリ自身のログ送信APIと判断した。

LAN側TCPサービスを調査

リモコンは宅内LANから到達可能だったが、一般的なHTTP/HTTPSポートは開いていなかった。

さらに全TCPポートをスキャンしたところ、65535ポートすべてclosed だった。

したがって、リモコンが宅内LAN向けにHTTP APIや独自TCPサーバーを公開している構成ではない。

ECHONET Lite UDP/3610は使用できるが、Piを単純にLANへ接続しただけでは、スイッチングネットワーク上のリモコン→ルーター→クラウド通信を受動キャプチャすることもできなかった。

リモコン表示とネットワークデータの食い違い

今回の実験で重要だったのは、リモコン画面ではヒートポンプ電力が確実に存在するという点である。

ヒートポンプ運転中、リモコンでは瞬時値が変化し、日積算のヒートポンプ電力量も増加した。

しかし同じ時間帯に、

• ECHONET Liteの全公開プロパティ
• F3/F4
• わかすアプリ履歴APIの pulse2

のいずれにも対応する変化は現れなかった。

このことから、リモコン表示用のデータは、今回アクセスできたネットワーク公開層とは別の内部経路で取得されている可能性が高い。

最後に残った経路

リモコン背面を確認したところ、給湯器システムとの接続は2線式に見えた。

したがって、次に解析するなら、

給湯器 / ヒートポンプユニット
        ↓
     内部2線通信
        ↓
      リモコン

の物理層を観測する必要がある。

安全に進めるなら、まずテスターでDC電圧を確認し、高インピーダンスのオシロスコープで通信波形の有無を調べる。その後、電圧レベルに適合した保護回路を介してロジックアナライザー等でフレーム解析する流れになる。

ただし今回、テスターはあるもののオシロスコープ／ロジックアナライザー等を用意していないため、追加ハードウェアなしではこれ以上の検証は進められない。

実験終了時点の評価

今回の目的は「追加の電力計を設置せず、既存ネットワークからヒートポンプ電力量を取得できるか」だった。

結果は、今回確認できたネットワークインターフェースでは取得方法を特定できなかったとなる。

ただしこれは、機器内部に値が存在しないことを意味しない。リモコンに表示されている以上、内部通信または内部演算には必要なデータが存在する。

追加ハードウェアを用意して内部2線通信を解析する場合、この実験ログを再開地点とする。

公開時のプライバシー境界

以下は公開記録から除外した。

• 宅内LANの実IPアドレス
• アプリのユーザーID
• 緯度・経度
• 認証トークン、Cookie等
• 家庭を直接識別し得る通信情報

機種・プロトコル・EPC・観測結果など、再解析に必要な技術情報は残した。