Part 4 of 7 · Home Assistant Energy Build
myenergi integration: Eddi and Harvi
Bringing the myenergi Eddi hot-water diverter and its Harvi wireless CT sensor into Home Assistant via the myenergi HACS integration — the entities that matter, the Normal/boost split, and the cloud reversion trap.
With the battery under local control, the next device is hot water. The myenergi Eddi is a solar diverter: when there is surplus solar it dumps it into the immersion heater instead of exporting it. But in this system the more valuable job is the opposite — using cheap overnight grid energy to heat the tank during the Octopus cheap-rate window, which is where the automations in Part 6 come in. This part just gets the myenergi hardware visible and controllable in Home Assistant.
The kit: Hub, Eddi and Harvi
Three myenergi pieces are involved, and it helps to be clear on what each one is before integrating them:
| Device | Role |
|---|---|
| Hub | The myenergi gateway. Connects the devices to the myenergi cloud and, in turn, to Home Assistant's integration. |
Eddi (serial XXXXXXXX) | The solar diverter itself. Controls the immersion heater and is the device Home Assistant sends boost and mode commands to. |
| Harvi | A self-powered, wireless CT sensor. It clamps around the grid tail and sends current readings to the Eddi over myenergi's own radio link — no wiring or power supply of its own. |
The Harvi is worth understanding because it is sensing only. It has no controllable outputs and nothing to boost or switch. Its job is to tell the Eddi (and, through the integration, Home Assistant) how much power is flowing at the grid connection, so the diverter knows whether there is surplus to divert. In the entity list it shows up as measurement sensors, not controls.
Installing the myenergi integration
myenergi does not have a local API in the way GivTCP provides for GivEnergy, so this integration is cloud-backed: it authenticates to the myenergi cloud via the Hub and polls it. It installs from HACS.
- In HACS, add and download the myenergi integration.
- Restart Home Assistant so the component loads.
- Add it under Settings → Devices & Services → Add Integration → myenergi.
- Authenticate with the myenergi Hub serial and the API key generated in the myenergi app (Settings → Advanced → API).
Once connected, every device behind the Hub — the Eddi and the Harvi — is discovered and its entities appear automatically, all named after their serial numbers.
The entities that matter
The Eddi surfaces a long list of entities, but two do the heavy lifting in the automations later:
# The operating-mode control — driven to Normal (ready) or Stopped
select.eddi_XXXXXXXX_myenergi_eddi_XXXXXXXX_operating_mode
# The CT clamp reading used to detect when a boost has actually finished
sensor.eddi_XXXXXXXX_myenergi_eddi_XXXXXXXX_internal_load_ct1The operating_mode select is the mode control — its options are Normal, Stopped and Paused. Home Assistant drives it to Normal so the Eddi is willing to divert/boost, and to Stopped to shut it down. The internal_load_ct1 sensor is the read-back: when it drops below 100W for two minutes the boost has ended and the battery can safely resume — the trigger for the resume branch of the boost automation in Part 6.
Where the Harvi fits
Because the Harvi only measures, it doesn't add controls to automate against — but its readings underpin the whole diverter behaviour. Practically, in this build the Harvi's role is quiet: it feeds the Eddi's own diversion logic. The automation layer keys off the Eddi's operating mode and its CT reading rather than the Harvi directly. Mentioning it explicitly matters mainly so the device list makes sense: a Harvi in the integration is expected, and its lack of controllable entities is by design, not a fault.
Operating modes and the boost
There are two distinct actions involved in heating water on demand, and it is worth separating them clearly. First, the Eddi has to be in Normal mode — that is the operating_mode select. Second, the timed boost itself is fired through a dedicated Home Assistant service, myenergi.myenergi_eddi_boost, which takes a target heater and a duration in minutes. There is no operating mode literally called "Boost"; the boost is a service call layered on top of Normal.
The important design decision — detailed fully in Part 6 — is that this system does not fire-and-forget either step, because the integration is cloud-backed and both can be accepted by Home Assistant yet never applied on the device. So the boost automation first re-asserts Normal in a loop until it has held for 75 seconds (long enough to survive a myenergi cloud poll), then fires the boost service and verifies actual current draw on internal_load_ct1, re-firing up to five times before it gives up. If it can never confirm the immersion is drawing, it aborts loudly, sets the Eddi to Stopped and resumes the battery.
The one-minute reversion trap
Diagnostic tip — If the Eddi's mode flips back roughly one minute after being set, something else is actively re-asserting it — usually a myenergi app schedule being reapplied on the next cloud poll, or a competing Home Assistant automation running on a /1 time pattern. The Logbook is the fastest way to tell which: it shows whether the change came from Home Assistant or externally. Logbook is the primary diagnostic tool for every myenergi and GivTCP state question in this build.
The Eddi is now readable and controllable, and its CT reading is available to detect when heating finishes. Part 5 adds the last data source — live Octopus tariff and smart-meter data — which is what tells the automations when energy is cheap enough to charge and boost.
A personal home-energy project, shared as-is and not affiliated with myenergi or any vendor mentioned. Settings and entity names change — check current vendor docs, and treat battery charge-rate configuration as a safety matter for your own installation.