Part 3 of 7 · Home Assistant Energy Build

GivEnergy integration with GivTCP v3

8 July 2026BatteryMQTT

Taking local control of a GivEnergy dual-AIO battery system over MQTT with GivTCP v3 — so the cloud can no longer override charge rates — plus the sign-convention and charge-rate traps that cost time.

This is the part that delivers the whole point of the project: taking control of the GivEnergy battery system locally, so the cloud portal can no longer override manually set charge rates and trip the breaker. The tool for that is GivTCP.

What GivTCP does

GivTCP talks to GivEnergy inverters and batteries over the local network (Modbus over TCP) and republishes everything as MQTT — every reading and, critically, every writable control: charge rate, discharge rate, target SOC, operating mode and the timed charge/discharge slots. Because it is local and MQTT-based, Home Assistant gets full read/write control without the cloud in the loop. This is what makes deterministic, local automation possible.

Installing GivTCP v3

GivTCP v3 installs as a Home Assistant add-on. It publishes to the Mosquitto broker set up in Part 2, so the broker must already be running.

1. Add the GivTCP add-on repository under Settings → Add-ons → Add-on Store → ⋮ → Repositories.
2. Install GivTCP (v3), enable Start on boot and Watchdog, and start it.
3. Point it at the Mosquitto broker using the MQTT username and password created in Part 2.

Configure it in the Web UI — not the HA Configuration tab

Inside the GivTCP Web UI, the key settings are the inverter IP addresses on the LAN, the number of inverters/batteries, the MQTT connection details, and the publish interval. Once saved and started, GivTCP begins publishing, MQTT discovery fires, and the devices appear in Home Assistant automatically.

Three devices: the Gateway and both AIO batteries

This is a parallel dual-AIO installation with a Gateway, so GivTCP surfaces three GivEnergy devices into Home Assistant:

The Gateway presents as "Inverter 1" and is the device the control entities hang off. Every writable control entity is named after the Gateway serial, which is why that string appears throughout the automations in Part 6, for example:

select.givtcp_gwXXXXXXXX_mode
number.givtcp_gwXXXXXXXX_charge_target_soc_1

The Solis 8kW inverter and its ~10kW array feed into the GivEnergy Gateway on the DC side, so solar generation is measured and reported through GivTCP as well — there is no separate Solis integration in this build.

Power Flow Card Plus and the sign trap

To visualise generation, home load, grid and battery flows, the build uses Power Flow Card Plus, installed from HACS. It is excellent, but GivTCP's sign convention for the grid entity is the inverse of what the card expects — without correction, import and export display backwards.

The fix is a single option on the grid entity in the card config:

type: custom:power-flow-card-plus
entities:
  grid:
    entity: sensor.givtcp_gwXXXXXXXX_grid_power
    invert_state: true      # GivTCP's sign is the inverse of what the card expects
  battery:
    entity: sensor.givtcp_gwXXXXXXXX_battery_power
  solar:
    entity: sensor.givtcp_gwXXXXXXXX_pv_power

The Energy Dashboard wizard

Home Assistant's built-in Energy Dashboard is configured through its six-step wizard under Settings → Dashboards → Energy. Each step is populated with the GivTCP entities named after gwXXXXXXXX:

1. Grid consumption — the GivTCP grid import energy sensor.
2. Return to grid — the GivTCP grid export energy sensor.
3. Solar production — the GivTCP PV energy sensor.
4. Battery — the GivTCP battery charge and discharge energy sensors (as a storage source).
5. Gas / water — not used here.
6. Individual devices — optional device-level monitoring.

Once populated, the Energy Dashboard gives the standard daily/weekly generation, consumption and self-sufficiency views on top of the GivTCP data.

The gotchas that cost time

These are the GivEnergy-specific facts that are not obvious and are worth internalising before writing any automation against this system:

• battery_charge_rate_ac is a percentage, not watts. On this dual-AIO system 48% is roughly 5.7kW. This single fact drives the charge-rate automation in Part 6 — and it must never be left at 100% during grid charging, because full-rate AC charge can trip the 32A incoming breaker.
• AC and DC charge rates are firmware-linked. You cannot permanently cap the AC charge rate without also capping DC (solar) charging. That is why the cap is applied on a time schedule — clamped for the cheap-rate window, released during daylight so solar charges at full rate.
• Use the slot-specific target SOC. For a timed charge slot's SOC target the correct entity is charge_target_soc_1 (slot 1), not the global target_soc. Setting the wrong one silently does nothing useful.
• "Eco (Paused)" is the only reliable battery lock. Setting discharge rate to 0% does not reliably stop discharge under load in Eco mode. Only the Eco (Paused) operating mode is proven to actually hold the battery. This is central to the hot-water and pause logic in Part 6.
• A ~0.9 kWh solar discrepancy is normal. GivTCP-reported generation runs slightly below the Solis figure. This is expected CT-clamp measurement variance, not a fault — don't chase it.

With the battery system fully readable and writable over local MQTT, the second big device can go in. Part 4 brings the myenergi hot-water diverter — the Eddi, and its Harvi wireless sensor — into Home Assistant.

A personal home-energy project, shared as-is and not affiliated with GivEnergy 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.