What Hitachi's Tariff-Aware EcoCute Update Taught Me About Building a DIY Water Heater Dashboard

A few weeks ago I saw the news that Hitachi was rolling out a new Y-series of its EcoCute CO2 heat pump water heaters in Japan, with expanded support for daytime electricity tariffs meant to encourage households to shift hot water heating into solar hours. I read it twice, because I have an older Hitachi EcoCute unit sitting in a utility closet with a HEMS adapter bolted onto it, and about a year ago I spent a couple of weekends building a small local dashboard to actually see what that box was doing.

The vendor app that ships with these units is fine for checking tank temperature and setting a vacation mode, but it tells you almost nothing about when and why the heater decided to run. If you've got solar panels and a tariff that rewards daytime consumption, that "why" is the whole point. So I built a bridge that talks ECHONET Lite directly to the unit and pushes state to a browser tab I keep open next to my other dashboards. The Hitachi announcement didn't change my hardware, but it did make me go back and stress-test some assumptions I'd baked into that project, and one of them turned out to be flat-out wrong.

This post is about that project: how the ECHONET Lite side of these HEMS-connected water heaters actually works, the bug I hit trying to detect tariff-driven operation, and what I'd do differently if I were starting from scratch today — including what I'd treat as unknown once the Y-series units actually ship.

What Hitachi Actually Announced

Strip away the marketing framing and the announcement is fairly narrow. Hitachi Global Life Solutions introduced two new fully automatic EcoCute models, the BHP-FV37YD and BHP-FV46YD, with 370-liter and 460-liter tank capacities respectively, both using CO2 as the refrigerant and both shipping from November 2026 in Japan. Hitachi hasn't disclosed full efficiency numbers for these two models yet, and it hasn't said whether the compressor, refrigerant circuit, or heat exchanger design actually changed from the previous generation — based on what's public so far, this reads like a platform update rather than a new heat pump design.

The headline feature is expanded compatibility with Japanese daytime electricity tariffs, the kind utilities are rolling out specifically to get more solar generation absorbed locally instead of curtailed. Owners can pick a supported tariff plan directly from the water heater's remote controller, or configure other plans manually. None of that is actually new territory for Hitachi's HEMS-connected EcoCute line — the previous generation already supported ECHONET Lite and solar-linked water heating through the same HEMS connection adapter and wireless LAN adapter setup. What's new here is the breadth of tariff plans the unit understands out of the box, not the plumbing underneath it. Here's how the two new models line up against their direct predecessors, based on what Hitachi has published so far:

The five-year warranty is a real change too — it covers the heat pump unit, the storage tank, the remote controller, and notably the wireless LAN and HEMS adapters themselves, which tells you Hitachi is treating the connectivity hardware as a first-class part of the product rather than an optional dongle nobody uses.

HEMS Adapter, Wi-Fi Adapter, and ECHONET Lite Are Three Different Things

When I started this project I conflated these three pieces, and it cost me an evening of confused packet captures. The wireless LAN adapter is just the unit's link to your home network — it doesn't speak any particular energy protocol by itself. The HEMS connection adapter is what actually implements ECHONET Lite, the Japanese smart-home protocol that lets a controller (your HEMS box, or in my case a Raspberry Pi pretending to be one) discover the water heater as a device on the network and read or write its properties.

ECHONET Lite itself is protocol-agnostic about what a "property" means. A device exposes an EOJ (an object identifier — basically "which device class and instance is this"), and a list of EPCs (property codes) it supports, each with a value called EDT. Standard EPCs like operation status or measured temperature are defined in a public appendix maintained by the ECHONET Consortium, so any controller can read them without vendor documentation. Anything outside that standard set — which, as I found out, includes tariff and schedule state on my unit — is fair game for manufacturers to define however they want, and they're under no obligation to publish it.

Finding the Water Heater on the Network

Before you can read anything useful, you need to find the device and confirm which object it's exposing, because a single physical unit can present multiple logical objects (the heat pump itself, a node profile object, sometimes a separate controller object for the HEMS adapter). I ended up settling on a fairly standard discovery sequence, which most ECHONET Lite tooling follows in some form:

• Send a multicast "Get" request for the self-node instance list property (EPC 0xD6) to the Node Profile object, which every ECHONET Lite device must implement.
• Collect replies and note the source IP address and the EOJ list each device reports back.
• For the object that looks like the water heater's class code, request its property map (EPC 0x9F) to see which properties it actually supports for reading.
• Cross-reference that list against the public ECHONET Lite appendix to separate "documented, safe to rely on" properties from "undocumented, manufacturer territory."
• Only after that do you start polling or subscribing to the properties you actually care about.

That last step matters more than it sounds like it should. My first version of the bridge just guessed at property codes based on things I'd seen referenced in other people's open-source ECHONET Lite clients, and about a third of my guesses returned nothing at all, because they were valid EPCs for a different device class entirely. Reading the property map first would have saved me a fair amount of trial and error.

The Bug: Assuming Operation Status Meant Tariff Mode

Here's where the actual mistake happened. My dashboard's whole reason for existing was to answer one question: is the heater currently running because it's cheap daytime solar power, or because it's just doing its normal off-peak overnight heating cycle? I had the standard operation-status property (EPC 0x80) working within an hour — it's a documented EPC, ON is 0x30 and OFF is 0x31, and every ECHONET Lite device that can be turned on or off exposes it. So I wired that straight into the dashboard as my "is it running on solar right now" indicator. That was the bug.

Here's roughly what that first, broken version looked like:

// BROKEN: operation status only tells you the compressor is running,
// not *why* it decided to run right now
function isRunningOnDaytimeTariff(waterHeaterProps) {
  return waterHeaterProps[0x80] === 0x30; // 0x30 = operation ON
}

This looked correct for about two days, because my old tariff plan happened to overlap almost entirely with my actual usage pattern, so the heater running and the daytime window being active were nearly always true at the same time. Then a cloudy week hit, the heater ran overnight to top up the tank on regular rates, and my dashboard cheerfully reported "running on solar tariff" the whole time. The operation status EPC tells you the compressor is on. It says nothing about which tariff logic triggered that decision — that state lives somewhere else, in a property Hitachi never documented publicly.

The fix was to stop guessing and instead diff the full set of manufacturer-range properties (EPCs in the 0xE0–0xFE range are conventionally reserved for vendor use) across a known tariff-window transition, and see which one actually changed value:

// FIXED: capture a baseline, wait for the tariff window to flip,
// capture again, and diff to find the property that actually moved
async function findTariffModeEpc(client, waterHeaterEoj) {
  const { edt: propertyMap } = await client.get(waterHeaterEoj, 0x9f);
  const candidateEpcs = propertyMap.filter((epc) => epc >= 0xe0 && epc <= 0xfe);

  const baseline = await pollAll(client, waterHeaterEoj, candidateEpcs);
  console.log("Waiting for the tariff window to change before re-polling...");
  await sleep(TARIFF_WINDOW_DELAY_MS);
  const afterShift = await pollAll(client, waterHeaterEoj, candidateEpcs);

  return candidateEpcs.filter((epc) => baseline[epc] !== afterShift[epc]);
}

On my unit, exactly one of the candidate EPCs flipped value right at the tariff boundary, and it turned out to hold a small enumerated status rather than a boolean — there were more states than just "peak" and "off-peak," including what I'm fairly sure is a forced-boost state the heater uses to top up the tank before a predicted cold snap. None of that is documented anywhere I could find, which is a genuinely annoying way to have to reverse-engineer a hot water heater, but it worked, and it's the only way I know of to get this specific answer out of the device.

Streaming State to a Dashboard Without Hammering the Heater

Once I had a reliable way to read the property, the next mistake I almost made was polling it directly from the browser. ECHONET Lite devices are not built to handle a handful of open tabs each firing UDP requests on their own schedule — the water heater's HEMS adapter is a small embedded chip, not a web server, and it noticeably slowed down responding to legitimate requests when I tested hammering it every second from two tabs at once. The fix was to centralize polling in a single small Node process on my home network — the same one doing the ECHONET Lite discovery — and have it push state changes out over a WebSocket, so the browser never talks UDP at all.

The frontend side ends up being a thin hook that just listens for pushed updates instead of pulling on any schedule of its own:

function useWaterHeaterState(deviceId: string) {
  const [state, setState] = useState(null);

  useEffect(() => {
    const socket = new WebSocket(`wss://home-bridge.local/devices/${deviceId}`);
    socket.onmessage = (event) => {
      const payload = JSON.parse(event.data) as WaterHeaterState;
      setState((prev) => (prev?.updatedAt === payload.updatedAt ? prev : payload));
    };
    socket.onclose = () => setTimeout(() => setState(null), 0);
    return () => socket.close();
  }, [deviceId]);

  return state;
}

The equality check on updatedAt is doing more work than it looks like — the bridge process re-polls the heater every thirty seconds regardless of whether anything changed, and without that guard the dashboard re-renders on every tick even when the tariff state, tank temperature, and operation status are all identical. It's a small thing, but it's the difference between a dashboard that feels calm and one that visibly flickers every time you glance at it.

What Changes, and What I'm Not Assuming, With the Y-Series

Nothing about the Y-series announcement changes the shape of this approach — it's still ECHONET Lite over a HEMS adapter, still a wireless LAN adapter for network access, and still a five-year warranty that now explicitly covers that connectivity hardware. What I'm genuinely unsure about is whether the manufacturer-specific EPCs I reverse-engineered on my older unit will carry over to the new models unchanged. Hitachi hasn't said whether the Y-series uses a new compressor or refrigerant circuit, and it also hasn't said anything about whether the internal property layout for tariff and schedule state changed alongside the expanded tariff support.

That's really the tradeoff of going this route instead of just using the vendor app: you get information the manufacturer chooses not to surface, but you're maintaining an integration against an interface nobody promised to keep stable. For a hobby dashboard on hardware you own, I think that's a fair trade. I would not build a product on top of undocumented vendor EPCs and expect it to survive a firmware update unattended.

Where I'd Draw the Line

If you already have a HEMS-connected heat pump water heater and you're the kind of person who enjoys reading UDP hex dumps for fun, this is a genuinely satisfying weekend project, and it gives you visibility the stock app simply doesn't offer. If you don't already own the hardware, I wouldn't buy a unit specifically to build this — the daytime tariff feature Hitachi is shipping in the Y-series is useful on its own even if you never touch the underlying protocol, and the remote controller's built-in tariff selection covers what most households actually need. The dashboard is for the narrower case where you want to verify, in your own terms, that the expensive box in your utility closet is actually doing what the tariff plan promised — and for that, I haven't found a substitute for going and reading the packets yourself.

Sources: Hacker News — Hitachi launches CO2 heat pump water heaters with solar-friendly tariff controls