Experiment record
ノーリツ RC-G057MPW-2 ハイブリッド給湯器：ヒートポンプ電力・電力量のネットワーク取得経路を調査
ノーリツのハイブリッド給湯器で、リモコンには表示されるヒートポンプ瞬時電力・積算電力量を、ECHONET Lite、わかすアプリのクラウドAPI、LAN側サービスから取得できるか調べた。
概要
ノーリツのハイブリッド給湯器では、リモコン画面にヒートポンプの瞬時電力と積算電力量が表示されます。
本実験では、この表示値を既存のネットワーク経路から取得できるかを調べました。専用の電力計やCTセンサーを追加するのではなく、すでにRaspberry Piから利用していたECHONET Lite、スマートフォンの「わかすアプリ」が使うクラウドAPI、リモコンのLAN側サービスを順に確認しました。
今回確認した範囲では、リモコン表示に対応するヒートポンプ瞬時電力・積算電力量を取得できるネットワーク経路は見つかりませんでした。
一方、リモコン画面では運転中に瞬時電力が変化し、積算電力量も増えていました。したがって値自体はシステム内部に存在します。内部2線接続は、別の物理層Experimentで調べるべき有力な候補として残ります。
実験の背景
既存のRaspberry Pi収集器では、ハイブリッド給湯器からECHONET Liteを使って運転状態や残湯量などを1分間隔で取得していました。
取得経路は UDP/3610 で、収集器が送るECHONET Liteサービスは読み取り用の Get (0x62) のみです。設定変更や制御を目的としたSet系サービスは使っていません。
既に取得できていた主な情報には、ハイブリッド給湯器の運転状態、沸き上げ状態、残湯量、タンク容量、ガス積算量、水積算量、ガス直接加熱状態、給湯設定温度などがありました。
しかし、リモコンに表示されるヒートポンプの電力・電力量は既存の収集項目にはありませんでした。そこで、ネットワーク上に未確認の取得元がないかを順に調べました。
実験方法
実験対象
保存されている実験記録では、調査対象の台所リモコン型番を RC-G057MPW-2 としています。
リモコン画面では、ヒートポンプ運転中に瞬時電力が変化し、積算ヒートポンプ電力量が増加することを確認しました。この画面表示を、ネットワーク側の候補値と照合する基準にしました。
実験環境
今回のネットワーク調査には既設のRaspberry Pi収集環境を使いました。2026-08-22に、実験で使用したRaspberry Pi本体をRaspberry Pi 4 Model B / 2 GBとして確認しました。
ECHONET Lite収集は有線Ethernet接続で行い、既存収集周期は1分でした。
別経路として、以前にmitmproxyで「わかすアプリ」のHTTPS通信を観測し、複数のJSON APIを確認していました。今回の実験では、そのAPI応答もヒートポンプ電力・電力量の候補として再確認しました。
観測・比較方法
ECHONET Liteで公開されるオブジェクトとGet/INFプロパティを列挙し、メーカー独自fieldの時間変化を監視しました。あわせて、わかすアプリAPI応答、LAN側TCPサービスを確認し、ヒートポンプ運転中のリモコン表示と候補値を照合しました。
実験ログ
ECHONET LiteのGet Property Mapを確認
最初に、ハイブリッド給湯機オブジェクト 0x02A601 のGet Property Map (0x9F) を取得しました。
80 81 82 83 86 88 89 8A 8C 8D 93 9D 9E 9F
B0 B2 B8 B9 C3 E1 E2 F1
この実機では、電力関連候補として確認した 0x84 と 0x85 は 0x02A601 のGet Property Mapに含まれていませんでした。
同様に、既知のオブジェクトについてGet Property Mapを確認しました。
0x027201:
80 81 82 83 86 88 89 8A 8C 8D 93 9D 9E 9F
D0 D1 D4 D5 E1 E2 E3 E4 E5 E6 E8 EF F2 F3 F4
0x028201:
80 81 82 83 88 8A 9D 9E 9F E0
0x028101:
80 81 82 83 88 8A 9D 9E 9F E0 E1
ここでも、リモコン表示のヒートポンプ電力・電力量に対応すると判断できる標準的な取得項目は見つかりませんでした。
ノード上の全オブジェクトを列挙
ノードプロファイルのインスタンスリスト 0xD6 を取得すると、7個のオブジェクトが公開されていました。
02A601
027201
028101
028201
001601
000701
001101
追加で見つかった3オブジェクトもGet Property Mapを確認しました。
001601:
80 81 82 83 88 8A 9D 9E 9F B1
000701:
80 81 82 83 88 8A 9D 9E 9F B0 B1
001101:
80 81 82 83 88 8A 9D 9E 9F E0
この7オブジェクトの中に、独立した電力量計測オブジェクトは確認できませんでした。
001101:E0 は 0x00F0 を返し、保存記録では 24.0 ℃ 相当の温度値と解釈されています。
INF対象プロパティも確認
Get可能項目だけではなく、状態変化通知用の 0x9D も確認しました。
0x02A601 INF:
80 81 88 B0 B2 B8 B9 C3 E1
0x027201 INF:
80 81 88 D0 D1 D4 E1 E2 E3 E4 E5 E6 E8 EF F2 F4
Getでは見えず、通知側だけに存在するヒートポンプ電力・電力量候補は確認できませんでした。
メーカー独自 F1 / F3 / F4 を調査
0x02A601:F1 は50バイトのデータで、機種名やファームウェアらしき文字列を含んでいました。保存記録では、電力量ではなく識別情報として扱っています。
0x027201:F3 は100バイトの複合データでした。その中には、別オブジェクトから取得済みのガス積算値・水積算値と一致するバイト列が含まれていました。
そこで、次の2項目を1分周期で同時に監視しました。
0x02A601:B2 沸き上げ状態
0x027201:F3 100バイト複合データ
観測中、B2 は not_heating から heating に変化し、ヒートポンプ運転が継続しました。同じ時間帯にリモコンのヒートポンプ積算電力量は増加していました。
しかし、F3の100バイト全体は多数の連続サンプルで変化しませんでした。この観測から、F3をヒートポンプ電力量として利用する仮説は棄却しました。
0x027201:F4 では以前のサンプル間に1バイトの変化を確認しましたが、その後のヒートポンプ運転や積算電力量を継続的には追従しませんでした。今回の記録からは、取得元として利用できる相関を確認できませんでした。
わかすアプリのクラウドAPIを確認
mitmproxyで確認済みだった主なAPIは次のとおりです。
getData
getStructure
getLifeLogEnergy
getLifeLogEnergyMonth
getLifeLogEnergyYear
getLifeLogUsage
getHybridUsageSituation
getStructure の観測例には、
rcType = 5
eUnitFlag = 0
gthFlag = 0
が含まれていましたが、ヒートポンプ電力量に対応すると判断できるfieldは確認できませんでした。
getHybridUsageSituation の ElectricityRate と GasRate は、今回確認した応答では計測電力量ではなく料金・設定側の値でした。
getData では運転状態や浴室・給湯・貯湯関連の状態を確認できましたが、リモコン表示に対応するヒートポンプ瞬時電力・積算電力量は特定できませんでした。
pulse2 をリモコン表示と照合
getLifeLogEnergy 系の応答には、次のようなfieldが含まれていました。
hotWaterUsage
hotWaterTotalUsage
bathTemprature
bathFlag
pulse2
pulse2 は候補になりましたが、取得した日別・時間別記録では 00 のままでした。
その間もヒートポンプは運転し、リモコンのヒートポンプ積算電力量は増加していました。このシステム構成・観測条件では、pulse2 がヒートポンプ電力量であるという仮説は棄却しました。
setAppLoggingData を確認
iotapi.noritz.co.jp/dev/setAppLoggingData も確認しました。
名称から機器側のテレメトリを疑いましたが、観測したRequest BodyはApplication Boot、アプリバージョン、OS、端末モデルなど、アプリ・クライアント側のログ情報でした。
このため、ヒートポンプ電力量の取得元としては扱いませんでした。
LAN側TCPサービスを確認
リモコンは宅内LANから到達できましたが、一般的なHTTP/HTTPSポートに待受はありませんでした。
さらに所有機器に対して全TCPポートを確認したところ、65,535ポートすべてがclosed でした。
この観測では、リモコンがLAN向けにHTTP APIや独自TCPサーバーを公開している状態は確認できませんでした。既知のLAN側通信としてはECHONET Lite UDP/3610 が利用できました。
リモコン表示とネットワーク候補を比較
この実験で重要だった対照は、リモコン画面では目的の値が実際に変化していたことです。
ヒートポンプ運転中、リモコンの瞬時電力は変化し、積算電力量も増加しました。
一方で同じ調査の中では、
- ECHONET Liteの全公開オブジェクトとGet/INFプロパティ
F3/F4- わかすアプリAPIの
pulse2 - LAN側TCPサービス
のいずれからも、リモコン表示に対応する取得値を確認できませんでした。
残る物理経路を外観確認
リモコン接続を確認すると、給湯器システムとの接続は2線式に見えました。
このため、リモコン表示に使われる値が内部2線通信を通っている可能性が有力な仮説になりました。
本実験では内部2線通信の電気的計測やプロトコル解析は行っていません。内部2線接続が実際に目的の電力値を伝えているという点は、現時点では仮説です。
結論
今回確認したネットワーク公開面については、リモコン表示のヒートポンプ瞬時電力・積算電力量を取得できる経路を特定できませんでした。
特に、次の候補は実測との比較によって絞り込めました。
- ECHONET Liteの公開Get/INF項目と7個の公開オブジェクトには目的値を確認できなかった。
0x027201:F3は、リモコンの積算電力量が増えている間も変化せず、ヒートポンプ電力量候補として棄却した。0x027201:F4は継続的な相関を確認できなかった。- わかすアプリAPIの
pulse2は、目的値が増えている間も00のままで、この構成ではヒートポンプ電力量ではなかった。 - 全TCPポート確認では待受サービスを確認できなかった。
この結果は、ノーリツ製品全般にヒートポンプ電力量のネットワーク取得機能が存在しないことを意味しません。今回の実機・構成・調査対象インターフェースで取得元を確認できなかった、という範囲の結果です。
証拠区分のまとめ
このExperimentで得られた情報のEvidence Stateは次のとおりです。
| 記録内容 | Evidence State |
|---|---|
| 調べたECHONET Lite公開面から目的値を確認できなかった | OBSERVED |
F3 をヒートポンプ電力量として利用する仮説 | DISPROVEN |
F4 に継続的な相関を確認できなかった | OBSERVED |
pulse2 がこの構成のヒートポンプ電力量であるという仮説 | DISPROVEN |
| 全TCPポート確認で待受サービスが確認されなかった | OBSERVED |
| 目的値が内部2線接続を通っている可能性 | HYPOTHESIS |
各Evidence Stateの意味はEvidence State（証拠状態）を参照してください。
未解決事項
内部2線接続がどのような信号・プロトコルでリモコン表示値を伝えているか、および目的のヒートポンプ電力・電力量との対応関係は未確認です。
また、異なるリモコン、給湯器、ヒートポンプユニット、ファームウェア、システム構成では別の公開fieldや経路が存在する可能性があります。
内部2線経路を確定するには、電気的特性、波形、フレーム、データ対応関係などを直接観測する別の物理層Experimentが必要です。現在保持されているネットワーク調査のEvidenceだけでは、この点を確定できません。
運用上の示唆
ECHONET Liteから同種のデータを取得しようとする場合、まずGet Property Map、INF対象、ノードインスタンスを列挙し、対象機器が実際に公開している項目を確認する必要があります。
メーカー独自fieldに値の変化が見えた場合も、単発の変化だけで目的値と判断せず、ヒートポンプ運転状態やリモコン表示などの独立した基準と同時に追跡することが重要です。本実験では、この比較によってF3とpulse2を候補から外すことができました。
実験データについて
元の収集ログの完全な時系列ファイルは、現在確認できる記録には残っていません。保存されているのは、プロパティマップ、代表的な値、比較結果、API field、調査結果をまとめた実験記録です。
そのため、このページに記載した内容だけから当時の全サンプル時系列を再構成することはできません。
また、今回実際に使ったECHONET Lite収集コードの完全版も、公開可能な再現用ソースコードとしては残っていません。
再現に必要なもの
本実験で使用した機材・実験環境と、実験結果とは区別した現在の購入情報を次のページにまとめています。
ノーリツ ハイブリッド給湯器 / Raspberry Pi収集環境 — 使用機材・実験環境と購入情報
再現時の注意事項
本実験のECHONET Lite調査は読み取り用のGet (0x62) のみで行い、設備を操作するSet系サービスは使用していません。同じ方針で再現する場合は、読み取り調査と設備制御を明確に分け、意図しない制御コマンドを送らないようにしてください。
「わかすアプリ」やAPI通信を観測する場合は、自分が利用権限を持つ機器・アカウントを対象とし、認証情報などの機微情報をソースコードや共有ログへ残さず、適切な秘密情報ストアで管理してください。
機械可読な実験記録
このExperimentの機械可読な正本記録をJSONとして公開しています。