Hi. My inverter and batteries seem to have suddenly stopped talking to one another after I tried to set up a Home Assistant Predbat & GivTCP integration to control them. I’ve spent a couple of fruitless days trying to diagnose this myself, so I’m hoping someone here has seen this pattern before and can help me find a way through.
My setup
- Inverter: GivEnergy HY3.6 Hybrid (Gen 1), S/N prefix
SA2226(commissioned 2022), firmware D0.450 - A0.451, Modbus v1.40. - Batteries: 2 × Giv-Bat 8.2, last-known BMS firmware 3017.
- Solar PV: 16 x 385W panels
- Dongle: original Gen-1 WiFi dongle on USB/COM port.
- Stack: Home Assistant OS 17.2 with GivTCP and Predbat.
- No access to GivEnergy Cloud. I never got the account transferred to me when we bought the house last year. I’m feeling pretty silly about that now.
Symptoms
The inverter behaves as though it doesn’t have any batteries.
-
The blue cross of LEDs on the front of the inverter illuminates for grid, load and solar, but not for battery. The lightning bolt shaped fault lamp is solid green. The status LED on the batteries themselves changes from green to yellow-green shortly after boot.
-
Home Assistant / GivTCP reports consumption of solar and grid to power the house, and export of solar when there’s a surplus, but no battery activity at all. Solar power visibly clips at 3.6kW instead of charging the battery, and the battery does not discharge to provide power during dark hours.
-
Some GivTCP controls appear to work: I can set a discharge schedule or activate “force discharge” mode and those settings get persisted between updates, but they seem to have no effect on the actual behaviour of the system.
-
Other GivTCP control changes get reverted immediately in the next update: “Enable Discharge”, “Battery charge rate” and “Battery discharge rate”, for example.
Timeline
-
I set up Home Assistant and GivTCP a couple of weeks ago. That all worked fine: I could read metrics from the inverter and use the controls to alter its behaviour (force discharge, scheduled charge, etc.)
-
I installed predbat last week and got it all configured with the right metrics from GivTCP. I ran it in “Monitor” mode for a while to validate the config and gather usage history etc.
-
It seemed to be producing sensible-looking plans that incorporated all the relevant data from Octopus, Solcast, etc., so on the evening of 17th April I switched it over to “Control Charge”.
-
On 18th April it started charging the battery from the grid during the day. This made sense, as grid energy was cheap at the time.
-
In the evening, I noticed that the battery was full but we were still drawing power from the grid, even though it had become expensive. I put Predbat into “Control Charge & Discharge” mode, thinking that maybe that was necessary to get it to use the battery to provide power to the house.
-
That didn’t work, so I tried putting predbat into read-only mode and re-enabling “Enable Discharge” on the inverter myself via GivTCP. That’s when I noticed that I was no longer able to push config changes to the inverter: they just get reverted by the next GivTCP refresh. At this point I stopped the predbat app entirely and started attempts to diagnose and fix the issue.
What I’ve tried
- Migrated GivTCP v2.2.3 → v3.5 via the
britkat1980/ha-addonsrepo. Both behave identically. - Full cold boot: AC off → DC off → both batteries off → 5-min wait → reverse. No change.
- WiFi dongle reseat (unscrewed from USB/COM port, 30 s out, reinserted).
- Reseated the BMS twisted-pair cable behind the E cover at the inverter end. Cable ends and connectors look visually fine.
Diagnostic observations
GivTCP v2.2.3 logs looked like this:
RQ Dashboard version 0.6.0
* Running on 0.0.0.0:9181
* Serving Flask app 'rq_dashboard.cli'
* Debug mode: off
[2026-04-19 13:38:42 +0100] [16] [INFO] Starting gunicorn 20.1.0
[2026-04-19 13:38:42 +0100] [16] [INFO] Listening at: http://0.0.0.0:6345 (16)
[2026-04-19 13:38:42 +0100] [16] [INFO] Using worker: sync
[2026-04-19 13:38:42 +0100] [28] [INFO] Booting worker with pid: 28
[2026-04-19 13:38:42 +0100] [29] [INFO] Booting worker with pid: 29
[2026-04-19 13:38:42 +0100] [30] [INFO] Booting worker with pid: 30
2026-04-19 13:38:42,491 - Inv1 - mqtt_client - [CRITICAL] - Connecting to MQTT broker for control- core-mosquitto
UPDATE The latest version of `serve` is 14.2.6.
INFO: Accepting connections at http://localhost:3000.
2026-04-19 13:38:47,859 - Inv1 - read - [ERROR ] - "Battery SOC" reported as: 0% and no previous value so setting to 1%
2026-04-19 13:38:47,860 - Inv1 - read - [ERROR ] - Battery Object empty so skipping
2026-04-19 13:38:47,860 - Inv1 - read - [ERROR ] - Battery Object empty so skipping
2026-04-19 13:38:47,875 - Inv1 - read - [CRITICAL] - First time running so saving AC Charge status
2026-04-19 13:38:47,878 - Inv1 - read - [CRITICAL] - Publishing Home Assistant Discovery messages
2026-04-19 13:38:55,868 - Inv1 - read - [ERROR ] - "Battery SOC" reported as: 0% so using previous value
2026-04-19 13:38:55,869 - Inv1 - read - [ERROR ] - Battery Object empty so skipping
2026-04-19 13:38:55,869 - Inv1 - read - [ERROR ] - Battery Object empty so skipping
2026-04-19 13:39:32,650 - Inv1 - read - [ERROR ] - "Battery SOC" reported as: 0% so using previous value
2026-04-19 13:39:32,650 - Inv1 - read - [ERROR ] - Battery Object empty so skipping
2026-04-19 13:39:32,650 - Inv1 - read - [ERROR ] - Battery Object empty so skipping
2026-04-19 13:40:09,431 - Inv1 - read - [ERROR ] - "Battery SOC" reported as: 0% so using previous value
These “Battery Object empty” errors repeat forever.
GivTCP v3.5 logs (with serial numbers redacted) look like this:
2026-04-20 09:42:49,752 - startup - [INFO ] - ==================== STARTING GivTCP==========================
2026-04-20 09:42:51,772 - startup - [INFO ] - Scanning network for GivEnergy Devices...
2026-04-20 09:42:51,773 - startup - [INFO ] - Scanning network: 192.168.1.80/24
2026-04-20 09:42:58,773 - client - [INFO ] - Connection established to 192.168.1.207:8899
2026-04-20 09:42:58,774 - client - [INFO ] - Detecting plant
2026-04-20 09:43:17,527 - client - [INFO ] - Plant Detected
2026-04-20 09:43:59,860 - startup - [INFO ] - Inverter which is a Hybrid_gen1 with 0 batteries and 0 meters has been found at: 192.168.1.207
2026-04-20 09:43:59,894 - startup - [INFO ] - Setting up invertor: 1
2026-04-20 09:43:59,917 - startup - [INFO ] - ==============================================================
2026-04-20 09:43:59,918 - startup - [INFO ] - ==== Web Gui Config is at ====
2026-04-20 09:43:59,918 - startup - [INFO ] - ==== http://192.168.1.80:8099/config.html ====
2026-04-20 09:43:59,918 - startup - [INFO ] - ==============================================================
2026-04-20 09:43:59,918 - startup - [INFO ] - Running Invertor 1 read loop every 30/120s
2026-04-20 09:43:59,924 - startup - [INFO ] - Serving Web Dashboard from port 3000
[2026-04-20 09:44:00 +0100] [70] [INFO] Starting gunicorn 23.0.0
[2026-04-20 09:44:00 +0100] [70] [INFO] Listening at: http://0.0.0.0:6350 (70)
[2026-04-20 09:44:00 +0100] [70] [INFO] Using worker: sync
[2026-04-20 09:44:00 +0100] [86] [INFO] Booting worker with pid: 86
[2026-04-20 09:44:00 +0100] [80] [INFO] Starting gunicorn 23.0.0
[2026-04-20 09:44:00 +0100] [80] [INFO] Listening at: http://0.0.0.0:6345 (80)
[2026-04-20 09:44:00 +0100] [80] [INFO] Using worker: sync
[2026-04-20 09:44:00 +0100] [87] [INFO] Booting worker with pid: 87
[2026-04-20 09:44:00 +0100] [88] [INFO] Booting worker with pid: 88
[2026-04-20 09:44:00 +0100] [89] [INFO] Booting worker with pid: 89
2026-04-20 09:44:00,262 - GivTCP - read - [INFO ] - Starting watch_plant loop...
2026-04-20 09:44:00,263 - GivTCP - GivLUT - [CRITICAL] - Opening Modbus Connection to 192.168.1.207
2026-04-20 09:44:00,267 - GivTCP - read - [CRITICAL] - Detecting inverter characteristics...
2026-04-20 09:45:26,900 - GivTCP - read - [INFO ] - Publishing Home Assistant Discovery messages
2026-04-20 09:45:37,340 - GivTCP - read - [INFO ] - Starting data refresh cycle
2026-04-20 18:10:23,561 - GivTCP - read - [ERROR ] - 5 consecutive timeout errors in watch loop. Restarting modbus connection:
No repeating errors, but NB the line Inverter which is a Hybrid_gen1 with 0 batteries and 0 meters has been found, indicating that it’s failed to find the batteries.
I asked Claude Code to help me diagnose the modbus info directly, to cut GivTCP out of the loop. To quote Claude, it:
wrote a python script that connected to the inverter’s Modbus-TCP endpoint using th
givenergy-modbuslibrary installed on the HA host, callingGivEnergyClient.fetch_register_pages()with targetedHoldingRegisterandInputRegisterpage ranges against slave addresses 17 (inverter) and 50/51/52 (battery BMSes).Every battery-slave address (50, 51, and even non-existent 52) returned the exact same two non-zero registers —
IR:105 = 4526andIR:106 = 7668, decoding to 452.6 kWh lifetime discharge and 766.8 kWh lifetime charge — with all other 118 registers zero.Slave 17 (the inverter itself) returned roughly 100–130 non-zero registers across each probe, with all the expected values populated:
INVERTER_STATUS = 1(normal),FAULT_CODE_H/L = 0/0(no faults), real serial number, real firmware (D0.450 / A0.451), real Modbus version (1.40), real meter type (EM115), real temperature (40–44 °C range over the session), real grid voltage (~240 V), real live power flows (solar, grid, house load), realV_BATTERY = 49 Vfrom the DC-bus sensor, and successful writes to its own control registers. The inverter is entirely healthy and cooperative on its own slave; the failure is scoped to the data it’s supposed to be getting from the battery BMSes and re-publishing under slaves 50/51.Conclusions: The two non-zero registers from the battery slaves are inverter-computed lifetime energy counters (not BMS-sourced), so the inverter is still answering battery-slave queries but has no real BMS data to return for any slave address — which points to a loss of the RS485 path between the inverter and the battery BMSes (cable fault or failed RS485 driver IC on either end).
I’m less inclined to immediately accept a hardware failure as the cause, though, because the failure was preceded by me tinkering with software. A hardware failure at the same time would seem highly coincidental.
Has anyone seen this pattern before? i.e. inverter healthy and responsive on its own registers, but battery-slave block returning identical inverter-computed lifetime counters with everything else zero, across every slave address?
Does anyone have any suggestions for other diagnostics I could try, or other support channels I could ask?
Happy to share further logs or diagnostic results anyone wants to see. Thanks.