A Home Assistant integration for GivEnergy inverters that communicates directly over local Modbus TCP — no cloud, no GivEnergy portal account required.

Uses givenergy-modbus for all inverter communication.

• A supported GivEnergy inverter connected to your local network (wifi or ethernet), with the Modbus TCP port reachable from your Home Assistant server (default port 8899)
• Home Assistant 2025.4 or later

The underlying givenergy-modbus library knows the following inverter families: Hybrid (1ph/3ph), AC, EMS, Gateway, and All-in-One. The following systems have been reported working:

• Hybrid (Gen 1)
• AC-coupled (Gen 1)

If you have a different model and would like to help validate the integration against it, please open an issue. A register dump is the most useful thing you can include — it captures every raw value the inverter exposes and lets me map new sensors without needing physical access to your hardware. To produce one, clone givenergy-cli, run uv sync, then:

uv run givenergy-cli --host <inverter-ip> export -o plant.json

This writes a portable JSON file covering all discovered registers. Attach it to the issue along with your inverter model and serial prefix.

Older Gen 2 units with the EA serial prefix are untested — any owners willing to help validate are very welcome!

Or if that doesn't work:

1. In HACS, go to Integrations → Custom repositories
2. Add https://github.com/dewet22/givenergy-hass and select category Integration
3. Install GivEnergy Local and restart Home Assistant

1. Download givenergy_local.zip from the latest release
2. Extract its contents into your Home Assistant config/custom_components/givenergy_local/ folder
3. Restart Home Assistant

Add the integration via Settings → Devices & Services → Add Integration → GivEnergy Local.

To change any of these later, open the integration's ⋮ menu in Settings → Devices & Services → GivEnergy Local and choose Reconfigure. The integration reloads automatically when you save.

When enabled, the integration connects to the inverter but does not send any Modbus read requests after the initial connection. Instead, it reads the library's register cache on each scan interval tick. This is useful when you have another client (e.g. GivTCP or a mobile app) already polling the inverter — having multiple clients requesting large register bank reads tend to get the inverter confused by stepping on each other. This is also useful if you are migrating from GivTCP and want to keep both running for the time being.

Each battery appears as a separate device linked to the inverter.

Cell-level entities are tagged as diagnostic, so they're hidden from the default device view but available for dashboards and pack-health monitoring (cell voltage spread, temperature deltas, etc.).

The upstream library makes ~180 inverter fields available; this integration intentionally exposes the subset that's useful for end users without being unsafe or noisy. Deliberately skipped for now:

• enable_* flags for low-level inverter behaviour (buzzer, RTC, BMS read, frequency derating, auto-judge battery type, …) — changing these from a UI toggle is rarely what you actually want
• Battery calibration registers, voltage-adjust trims, low-voltage force-charge timers
• Charge / discharge slots 3 - 10 and their per-slot SOC stops (slots 1 and 2 cover typical Eco/Timed usage)
• Admin / destructive actions: inverter reboot, BMS flash update, auto-test triggers, ARM-chip select, user-code register
• Raw debug fields (internal bus voltages, countdown timers, debug_inverter)
• Per-phase three-phase data beyond Grid Power Phase 1 and the three-phase balance registers

If any of these would genuinely help your setup, open an issue describing the use case — the field probably can be exposed with a single description entry, but it's nicer to have a concrete reason to do it. The same applies if a sensor we do expose looks wrong on your inverter — real-world testing on non-Hybrid Gen 1 hardware (AC, AC3, EMS, Gateway, All-in-One) is especially appreciated, and a register dump from your unit goes a long way (see Supported inverters for how to produce one).

All cumulative-energy entities (kWh) are exposed with device_class=energy and state_class=total_increasing, so Home Assistant generates long-term statistics for them automatically and they show up directly in the Energy dashboard's entity picker.

The dashboard derives household consumption automatically from the above. If you'd like to track it directly as a sanity check, Load Energy Today measures the total household demand fed by the inverter and can be added under "Individual devices".

The dashboard's live view shows current power flow between solar, grid, battery and load. Wire these in once the energy mappings above are in place:

The daily counters reset at midnight; Home Assistant's recorder detects the reset automatically thanks to the total_increasing state class, so deltas across day boundaries are accounted for correctly.

• Transient connection drops are normal. TCP-level timeouts and the occasional connection reset get logged at WARNING level and the next scan tick re-establishes the connection. The Last Successful Refresh and Consecutive Refresh Failures diagnostic sensors will tell you if something more persistent is going on.
• "Register cache unchanged" failures in passive mode mean no peer client is refreshing the inverter. Switch back to active mode, or start the other client that's supposed to be driving the bus.
• Conflicts with another Modbus client (GivTCP, the GivEnergy app, etc.) — the inverter doesn't always cope well with two clients issuing large reads concurrently. Use passive mode.

For anything else, please open an issue with the relevant HA log lines and your inverter model.

Apache License 2.0 — see LICENSE.

This project uses uv for dependency management.

uv sync --dev          # install dependencies
uv run pytest          # run tests
uv run ruff check .    # lint
uv run mypy custom_components/  # type-check