Experiment record
NORITZ RC-G057MPW-2 hybrid water heater: investigating network access to heat-pump power and energy
Investigated whether the heat-pump instantaneous power and accumulated electrical energy shown on a NORITZ hybrid water-heater remote controller could be obtained through ECHONET Lite, Wakasu cloud APIs, or LAN-side services.
Summary
The NORITZ hybrid water-heater remote controller used in this experiment displays both instantaneous heat-pump electrical power and accumulated heat-pump electrical energy.
This experiment asked whether those display values could be collected through network-accessible interfaces already available in the installation, without adding a dedicated power meter or CT sensor. The investigation progressed through the existing Raspberry Pi ECHONET Lite path, the cloud APIs used by the Wakasu mobile app, and LAN-side services exposed by the remote controller.
Within the interfaces tested, no network-accessible value matching the remote-controller heat-pump power or accumulated energy was identified.
The remote-controller display itself did change during heat-pump operation, so the data exists somewhere inside the system. The internal two-wire connection to the remote controller remains the leading candidate for a separate physical-layer investigation.
Background
An existing Raspberry Pi collector already retrieved read-only ECHONET Lite data from the hybrid water-heater system at one-minute intervals.
The collector used UDP/3610 and sent Get (0x62) only. It did not use Set services to change configuration or control the equipment.
Existing collected values included operating state, heating state, remaining hot-water volume, tank capacity, cumulative gas volume, cumulative water volume, direct gas-heating state, and hot-water temperature setting.
The heat-pump power and energy shown on the remote controller were not present in the existing collection, so the investigation searched for an unexamined network-accessible source.
Methods
Experimental target
The retained experiment record identifies the kitchen remote-controller model as RC-G057MPW-2.
During heat-pump operation, the display showed changing instantaneous power and increasing accumulated heat-pump electrical energy. That display was used as an independent comparison reference for candidate network values.
Experimental environment
The existing Raspberry Pi environment was used for the network investigation. On August 22, 2026, the Raspberry Pi unit used in the experiment was identified as a Raspberry Pi 4 Model B / 2 GB system.
ECHONET Lite collection used wired Ethernet, with a one-minute collection interval in the existing collector.
A separate investigation path used HTTPS traffic from the NORITZ Wakasu app that had previously been observed through mitmproxy. The captured JSON APIs were re-examined for heat-pump power or energy candidates.
Observation and comparison method
The investigation enumerated exposed ECHONET Lite objects and their Get/INF property maps, monitored selected vendor-specific fields over time, inspected Wakasu API responses, checked LAN-side TCP services, and compared candidate values against the remote-controller display while the heat pump operated.
Experiment Log
Inspecting the ECHONET Lite Get Property Map
The Get Property Map (0x9F) for hybrid-water-heater object 0x02A601 returned:
80 81 82 83 86 88 89 8A 8C 8D 93 9D 9E 9F
B0 B2 B8 B9 C3 E1 E2 F1
On this device, the electrical candidates 0x84 and 0x85 were not present in the 0x02A601 Get Property Map.
The same inspection was performed for the other known objects:
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
No standard field that could be identified as the remote-controller heat-pump power or energy was found in these maps.
Enumerating every exposed ECHONET object
The node-profile instance list at 0xD6 exposed seven objects:
02A601
027201
028101
028201
001601
000701
001101
The three additional objects were also inspected:
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
No separate electrical-energy measurement object was identified among the seven exposed objects.
0x001101:E0 returned 0x00F0, interpreted in the retained record as 24.0 °C.
Checking INF properties
The state-change announcement maps at 0x9D were also checked:
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
No heat-pump power or energy candidate appeared only in the INF surface while being absent from the Get maps.
Testing vendor-specific F1, F3, and F4
0x02A601:F1 returned a 50-byte block containing model- and firmware-like strings. The retained record treated it as identification data rather than an energy value.
0x027201:F3 returned a 100-byte composite block. It contained byte sequences identical to cumulative gas and water counters exposed elsewhere.
The following values were then monitored together at a one-minute interval:
0x02A601:B2 heating state
0x027201:F3 100-byte composite data
During the observation, B2 changed from not_heating to heating, and the heat pump continued operating. The remote-controller accumulated heat-pump energy increased during the same period.
However, the complete 100-byte F3 block remained unchanged for many consecutive samples. On that evidence, the hypothesis that F3 could be used as the heat-pump electrical-energy value was disproven for the observed condition.
0x027201:F4 showed a one-byte change between earlier samples, but it did not continue to track heat-pump operation or accumulated energy. The retained record therefore did not establish a usable correlation.
Inspecting Wakasu cloud APIs
The Wakasu APIs previously observed through mitmproxy included:
getData
getStructure
getLifeLogEnergy
getLifeLogEnergyMonth
getLifeLogEnergyYear
getLifeLogUsage
getHybridUsageSituation
An observed getStructure response included:
rcType = 5
eUnitFlag = 0
gthFlag = 0
No field was identified there as heat-pump electrical energy.
In the observed response, ElectricityRate and GasRate from getHybridUsageSituation were tariff/configuration-side values rather than measured heat-pump energy.
getData exposed general operating, bath, hot-water, and storage state, but no field could be identified as the instantaneous heat-pump power or accumulated energy shown on the remote controller.
Comparing pulse2 with the display
The getLifeLogEnergy family contained fields such as:
hotWaterUsage
hotWaterTotalUsage
bathTemprature
bathFlag
pulse2
pulse2 was a plausible candidate, but it remained "00" in the captured daily and hourly records.
During that period, the heat pump operated and the remote-controller accumulated heat-pump energy increased. For the observed system configuration, the hypothesis that pulse2 represented the heat-pump electrical-energy value was therefore disproven.
Inspecting setAppLoggingData
The endpoint iotapi.noritz.co.jp/dev/setAppLoggingData was also inspected.
Despite its name, the observed request body carried application/client telemetry such as Application Boot, app version, OS, and device-model information. It was not treated as a source of heat-pump electrical-energy telemetry.
Checking LAN-side TCP services
The remote controller was reachable on the private LAN, but common HTTP/HTTPS ports were not listening.
A full TCP-port check on the owned device then found all 65,535 TCP ports closed.
No LAN-facing HTTP API or custom TCP server was observed in that scan. ECHONET Lite UDP/3610 remained the known LAN interface.
Comparing the remote display with network candidates
The key control observation was that the target values definitely changed on the remote-controller display.
During heat-pump operation, instantaneous power changed and accumulated heat-pump electrical energy increased.
Across the same investigation, no corresponding retrievable value was identified in:
- all exposed ECHONET Lite objects and Get/INF properties,
F3orF4,- Wakasu API
pulse2, - LAN-side TCP services.
Visually inspecting the remaining physical path
The remote controller appeared to use a two-wire connection to the water-heater system.
That made the internal two-wire path the leading remaining hypothesis for how the display obtains the heat-pump power and energy values.
This experiment did not electrically measure or decode the internal two-wire communication. The two-wire path is therefore a hypothesis for a future physical-layer experiment, not a verified source of the target data.
Conclusion
No network-accessible path for the remote-controller heat-pump instantaneous power or accumulated energy was identified among the interfaces tested.
The investigation narrowed several specific candidates:
- the exposed ECHONET Lite Get/INF surfaces and seven published objects did not provide an identified target value;
0x027201:F3did not change while the remote-controller accumulated energy increased, disproving the F3 energy hypothesis for the observed condition;0x027201:F4did not show a sustained usable correlation;- Wakasu
pulse2remained"00"while the target display value increased, disproving that interpretation for this configuration; - the full TCP-port check found no listening TCP service.
This does not establish that every NORITZ model, firmware version, or system combination lacks a network-accessible heat-pump energy value. It is a result for the system and interfaces actually examined.
Evidence summary
The Evidence States for the information obtained in this Experiment are as follows.
| Recorded content | Evidence State |
|---|---|
| No target value identified in the tested ECHONET Lite surfaces | OBSERVED |
| F3 as a usable heat-pump energy value | DISPROVEN |
| No sustained usable correlation established for F4 | OBSERVED |
pulse2 as the heat-pump energy value for this configuration | DISPROVEN |
| No listening service found in the full TCP-port check | OBSERVED |
| Target data may traverse the internal two-wire connection | HYPOTHESIS |
See Evidence State for the shared definitions.
Unresolved questions
The signal/protocol used by the internal two-wire connection, and its mapping to the heat-pump power and energy shown on the remote controller, remain unresolved.
A different remote controller, water-heater unit, heat-pump unit, firmware version, or system configuration may expose different fields or interfaces.
Confirmation of the two-wire path requires a separate physical-layer experiment that directly observes the electrical characteristics, waveform, framing, or data mapping. Those facts cannot be established from the retained network-interface evidence alone.
Operational implications
For a similar ECHONET Lite investigation, the first useful step is to enumerate the actual Get Property Map, INF map, and node instances exposed by the target equipment instead of assuming that a nominally relevant property is implemented.
A single changing byte in a vendor-specific field is also not enough to identify a measurement. Candidate fields should be followed over time against an independent reference such as operating state or the remote-controller display. In this experiment, that comparison was what eliminated F3 and pulse2 as leading candidates.
Experiment data
The complete original time-series logger files are not present in the records currently available. What remains is the detailed experiment note containing property maps, representative values, API fields, comparisons, and investigation results.
The full historical sample sequence therefore cannot be reconstructed from this page alone.
The complete ECHONET Lite collector source code used during this experiment is also not retained as a public reproducible source-code artifact.
Reproduction resources
The equipment and experimental environment used in this experiment, together with current purchase information kept separate from the Experiment’s Evidence and Conclusion, are documented on NORITZ hybrid water heater / Raspberry Pi collection environment — equipment, experimental environment, and purchase information.
Reproduction considerations
The ECHONET Lite investigation in this Experiment used read-only Get (0x62) services and did not use Set services to control the equipment. When reproducing the same investigative boundary, keep read-only observation distinct from equipment control and avoid unintended control commands.
When observing Wakasu-app or API traffic, use only equipment and accounts you are authorized to access, and keep authentication material out of source code and shared logs by using an appropriate secret/configuration store.
Machine-readable experiment record
A machine-readable canonical record of this Experiment is published as JSON.