Experiment record

NORITZ Hybrid Water Heater: Can Heat-Pump Electricity Be Collected Over the Network?

Tested 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 or Wakasu cloud APIs.

Record metadata

Experiment ID: NORITZ-HYBRID-HP-POWER-001
Date: 2026-08-13
Generated by: AI-assisted experiment and analysis
Human intervention: The owner accessed the equipment, ran commands on the Raspberry Pi, verified ECHONET Lite responses, observed traffic in the private environment with mitmproxy, and compared the results with the remote-controller display. Local IP addresses, user IDs, location data, credentials, and similar private values were removed from the public article.
Raw data available: false
Source code available: false
Last verified: 2026-08-13

Conclusion

This experiment investigated whether the instantaneous heat-pump electrical power and accumulated heat-pump energy shown on the NORITZ remote-controller display could be collected through the existing home network.

No network-accessible source for the target value was identified in the interfaces tested.

The following paths were examined:

all ECHONET Lite Get properties exposed by the device,
ECHONET Lite state-change announcement (INF) properties,
every ECHONET object published by the node,
vendor-specific F1, F3, and F4 properties,
HTTPS APIs used by the NORITZ Wakasu app,
LAN-side TCP listening ports on the controller.

The remote controller itself did show changing instantaneous heat-pump power and increasing accumulated heat-pump electrical energy. Therefore the value clearly exists somewhere inside the equipment, but it does not appear to be exposed through the LAN/ECHONET/cloud API layers examined here.

The remaining high-value path is the internal two-wire communication between the water-heater/heat-pump system and the remote controller. Further work on that path would require an oscilloscope and a suitably protected logic-analyzer/interface setup, so the experiment was stopped at that hardware boundary.

Existing collection environment

A Raspberry Pi already collects read-only ECHONET Lite data from the hybrid water-heater controller at one-minute intervals over UDP/3610.

The collector sends Get (0x62) only and does not issue configuration-changing services.

Data already collected included:

hybrid-system operating state,
heating state,
remaining hot-water volume,
tank capacity,
cumulative gas volume,
cumulative water volume,
direct gas-heating state,
hot-water temperature setting.

Separately, HTTPS traffic from the Wakasu app had previously been decrypted with mitmproxy, exposing several JSON APIs.

Inspecting all ECHONET Lite Get properties

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

The standard superclass properties commonly associated with electrical measurements,

0x84  instantaneous power
0x85  cumulative electrical energy

were not implemented on this device’s 0x02A601 object.

The same property-map inspection was performed for instantaneous water heater 0x027201, gas meter 0x028201, and water-flow meter 0x028101. None exposed a standard property corresponding to heat-pump electrical energy.

Enumerating every ECHONET object on the node

The node-profile instance list 0xD6 returned seven objects:

The three additional sensor-related objects were also inspected through their Get Property Maps.

No separate electrical-energy measurement object was present.

001101:E0 returned a temperature measurement corresponding to 24.0 °C at the time of testing.

Checking state-change announcement properties

The experiment also inspected 0x9D, the state-change announcement property map, to test whether a power-related property might exist only as an announcement target.

For 0x02A601, the INF property set was:

80 81 88 B0 B2 B8 B9 C3 E1

For 0x027201, it was:

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

No hidden power or energy EPC was found there either.

Vendor-specific F-series properties

`02A601:F1`

This property returned 50 bytes containing equipment-model and firmware-like strings. It behaved as identification metadata rather than an energy measurement.

`027201:F3`

This returned a 100-byte composite block.

The block contained byte sequences that exactly matched cumulative gas and cumulative water counters already exposed through separate ECHONET objects. This strongly suggests that F3 is a vendor-specific internal telemetry structure containing multiple values.

A monitor then sampled both:

02A601:B2  heating state
027201:F3  100-byte composite block

every minute.

During the observation, B2 changed from not_heating to heating and remained in the heating state. The remote-controller display showed heat-pump energy increasing during that period, yet the entire 100-byte F3 block stayed unchanged across many consecutive samples.

The hypothesis that F3 directly contains usable heat-pump energy was therefore rejected.

`027201:F4`

A small amount of byte-level variation was observed in F4, but it did not continue to correlate with heat-pump operation or with the accumulated heat-pump energy shown on the remote controller. It was not usable as the target measurement.

Re-checking Wakasu app APIs

The decrypted Wakasu traffic confirmed at least the following APIs:

getData
getStructure
getLifeLogEnergy
getLifeLogEnergyMonth
getLifeLogEnergyYear
getLifeLogUsage
getHybridUsageSituation

`getStructure`

The observed system reported values including:

rcType = 5
eUnitFlag = 0
gthFlag = 0

No heat-pump electrical-energy field was present.

`getHybridUsageSituation`

The response contained ElectricityRate and GasRate. These behaved as tariff/configuration values rather than measured consumption.

`getData`

General operating, bath, hot-water, and storage state were present, but no field could be identified as instantaneous heat-pump power or accumulated heat-pump electrical energy.

`getLifeLogEnergy*`

Observed history fields included:

hotWaterUsage
hotWaterTotalUsage
bathTemprature
bathFlag
pulse2

pulse2 was described by the API schema as “pulse information 2”, but remained 00 in both daily and hourly records while the heat pump was operating and the remote-controller heat-pump energy display was increasing.

For this system, pulse2 was therefore rejected as the heat-pump electrical-energy value.

`setAppLoggingData` was application telemetry

The endpoint iotapi.noritz.co.jp/dev/setAppLoggingData initially looked potentially relevant to equipment telemetry.

However, the captured request body contained application-side metadata such as:

Application Boot,
application version,
OS,
iPhone model,
client-side logging information.

It was therefore identified as Wakasu application logging rather than water-heater measurement telemetry.

LAN-side TCP service inspection

The controller was reachable on the private LAN, but common HTTP/HTTPS ports were closed.

A complete TCP scan then found all 65,535 TCP ports closed.

This means the controller does not expose a LAN-side HTTP API or other listening TCP service in the tested configuration.

ECHONET Lite over UDP/3610 remained accessible. Passive capture from the Raspberry Pi, however, could not see controller-to-router/cloud traffic on the switched LAN because the Pi was not in the forwarding path.

What the remote-controller display proved

The key observation was that heat-pump electrical data definitely exists inside the system.

During heat-pump operation, the remote controller displayed changing instantaneous heat-pump power and an increasing daily accumulated heat-pump energy value.

At the same time, none of the following tracked that change:

all exposed ECHONET Lite properties,
F3/F4,
pulse2 in Wakasu history APIs.

This strongly suggests that the display obtains the value through an internal path that is separate from the network interfaces examined here.

Remaining path: internal two-wire communication

Visual inspection of the remote-controller wiring suggested a two-wire connection to the water-heater system.

The next protocol-analysis target would therefore be:

water heater / heat-pump unit
        ↓
 internal two-wire communication
        ↓
 remote controller

A safe investigation would begin by measuring the DC voltage with a multimeter, then observing the line with a high-impedance oscilloscope. If digital signaling is confirmed, a logic analyzer or equivalent interface should only be connected through circuitry appropriate for the observed voltage levels.

The available setup included a multimeter but not the oscilloscope/logic-analyzer hardware required for further progress, so the experiment was stopped here.

Final assessment

The practical objective was to determine whether heat-pump electrical energy could be collected without installing additional electrical-measurement hardware.

The result is:

No acquisition method was identified through the network interfaces tested in this experiment.

This does not mean the value is absent internally. Since it is shown on the remote-controller display, the required data exists somewhere in the internal communication or computation path.

If the physical two-wire protocol is investigated in the future, this experiment log provides the restart point.

Privacy boundary for publication

The public record intentionally omits:

private LAN IP addresses,
application user IDs,
latitude/longitude,
authentication tokens and cookies,
communication values that could directly identify the household.

Equipment class, protocol details, EPC values, and experimentally relevant observations are retained for future technical analysis.