Repository navigation
Reoccurence of #4404 - Warn: Inverter 0 REST failed to setExportTarget when exporting #4421
Description
Activity
Same here, GivEnergy setup with 3kW AC inverter and 9.5 kWh battery. Currently running Predbat
v8.47.3.predbat.log
predbat_debug.yaml2026-08-02 20:55:06.104466: Info: record_status Demand 2026-08-02 21:00:01.070081: Warn: Found 1 periods of zero load with power data, filling using power integration 2026-08-02 21:00:25.637309: Warn: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST failed got 0 2026-08-02 21:00:25.650909: Warn: record_status Warn: Inverter 0 REST failed to setExportTarget got 0 2026-08-02 21:01:12.031352: Warn: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST failed got 0 2026-08-02 21:01:12.045289: Warn: record_status Warn: Inverter 0 REST failed to setExportTarget got 0 2026-08-02 21:01:12.165383: Error: Completed run status Exporting with Errors reported (check log) 2026-08-02 21:05:00.989244: Warn: Found 1 periods of zero load with power data, filling using power integration 2026-08-02 21:05:17.250988: Warn: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST failed got 0 2026-08-02 21:05:17.264866: Warn: record_status Warn: Inverter 0 REST failed to setExportTarget got 0 2026-08-02 21:05:17.390136: Error: Completed run status Exporting with Errors reported (check log) 2026-08-02 21:10:01.220892: Warn: Found 1 periods of zero load with power data, filling using power integration 2026-08-02 21:10:02.177256: Info: HAHistory: Pruning history data started. 2026-08-02 21:10:02.178493: Info: HAHistory: Pruning history data completed. 2026-08-02 21:10:16.917629: Info: Completed run status Exporting 2026-08-02 21:10:17.168639: Info: record_status Exporting target 80%-70% 2026-08-02 21:15:01.122898: Warn: Found 1 periods of zero load with power data, filling using power integration 2026-08-02 21:15:15.448706: Warn: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST failed got 0 2026-08-02 21:15:15.461577: Warn: record_status Warn: Inverter 0 REST failed to setExportTarget got 0 2026-08-02 21:15:30.304250: Warn: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST failed got 0 2026-08-02 21:15:30.317924: Warn: record_status Warn: Inverter 0 REST failed to setExportTarget got 0 2026-08-02 21:15:30.448026: Error: Completed run status Exporting with Errors reported (check log) 2026-08-02 21:15:46.749226: Warn: Found 2 periods of zero load with power data, filling using power integration 2026-08-02 21:20:01.370737: Warn: Found 1 periods of zero load with power data, filling using power integration 2026-08-02 21:20:15.921101: Warn: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST failed got 0 2026-08-02 21:20:15.934905: Warn: record_status Warn: Inverter 0 REST failed to setExportTarget got 0 2026-08-02 21:20:18.785134: Error: Completed run status Exporting with Errors reported (check log) 2026-08-02 21:25:00.719773: Warn: Found 1 periods of zero load with power data, filling using power integration 2026-08-02 21:25:15.296093: Warn: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST failed got 0 2026-08-02 21:25:15.309072: Warn: record_status Warn: Inverter 0 REST failed to setExportTarget got 0 2026-08-02 21:25:30.135370: Warn: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST failed got 0 2026-08-02 21:25:30.149763: Warn: record_status Warn: Inverter 0 REST failed to setExportTarget got 0 2026-08-02 21:25:30.264964: Error: Completed run status Exporting with Errors reported (check log) 2026-08-02 21:30:01.132062: Warn: Found 1 periods of zero load with power data, filling using power integration 2026-08-02 21:30:26.937888: Info: Completed run status Demand 2026-08-02 21:30:27.203675: Info: record_status Demand 2026-08-02 21:35:01.037891: Warn: Found 1 periods of zero load with power data, filling using power integration 2026-08-02 21:35:25.454495: Warn: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST failed got 0 2026-08-02 21:35:25.494146: Warn: record_status Warn: Inverter 0 REST failed to setExportTarget got 0 2026-08-02 21:35:48.919668: Warn: Found 2 periods of zero load with power data, filling using power integration 2026-08-02 21:35:59.794560: Error: Completed run status Exporting with Errors reported (check log) 2026-08-02 21:40:02.077648: Warn: Found 1 periods of zero load with power data, filling using power integration 2026-08-02 21:40:19.196448: Warn: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST failed got 0 2026-08-02 21:40:19.221609: Warn: record_status Warn: Inverter 0 REST failed to setExportTarget got 0 2026-08-02 21:40:27.167531: Error: Completed run status Exporting with Errors reported (check log) 2026-08-02 21:45:01.692027: Warn: Found 1 periods of zero load with power data, filling using power integrationI'm also seeing extra inverter writes but I'm not 100% sure it is related to this. I use GiVTCP (3.5 and not changed since install) and have real time control enabled. Real Time Control (RTC) has only been recently enabled on my system
What I appear to be seeing is an extra 4 or 5 writes each time this error message is triggered - or at least around the time it is triggered. These are attempting direct writes to the inverter EEPROM (rather than to the "Safe" RAM writes which are happening as normal). Given it looks like this error is because Predbat is trying to write to something my inverter does not support, it makes sense that these try to go to the EEPROM rather than RAM based registers.
However, if this issue is causing the extra writes, then in the last 3 hours there have been over 100 as the inverter has been exporting during the peak rates.
When the inverter is in a stable status (e.g. Demand mode) for a period of time, then no extra writes happen.
The reason I can't be 100% sure of the link is because I didn't enable RTC until after I reported the original issue; however, cross-matching logs to inverter write times does make a strong case.
Also seeing the same 9.5kw battery and AC3.0 Inverter
33615 | 2026-08-04 21:29:59.842996: Error: Completed run status Exporting with Errors reported (check log) -- | -- 33608 | 2026-08-04 21:29:59.277207: Warn: record_status Warn: Inverter 0 REST failed to setExportTarget got 0 33607 | 2026-08-04 21:29:59.187515: Warn: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST failed got 0 33461 | 2026-08-04 21:29:19.956219: Warn: Cannot find battery discharge curve (settings missing), one of the required settings for soc_kwh, discharge_rate and battery_power are missing from apps.yaml 33460 | 2026-08-04 21:29:19.956040: Warn: Cannot find battery charge curve (settings missing), one of the required settings for soc_kwh, charge_rate and battery_power are missing from apps.yaml 33235 | 2026-08-04 21:28:11.681115: Warn: Web Socket closed, will try to reconnect in 5 seconds - error count 1 33231 | 2026-08-04 21:28:11.355304: Warn: Service call notify/notify failed or timed out: result {'response': None, 'success': None, 'error': None} 33210 | 2026-08-04 21:25:25.382975: Error: Completed run status Exporting with Errors reported (check log) 33202 | 2026-08-04 21:25:24.862960: Warn: record_status Warn: Inverter 0 REST failed to setExportTarget got 0 33201 | 2026-08-04 21:25:24.769785: Warn: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST failed got 0 33068 | 2026-08-04 21:21:12.910152: Error: Completed run status Exporting with Errors reported (check log) 32925 | 2026-08-04 21:20:35.507827: Warn: record_status Warn: Inverter 0 REST failed to setExportTarget got 0 32924 | 2026-08-04 21:20:35.428602: Warn: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST failed got 0 32918 | 2026-08-04 21:20:21.050757: Warn: Inverter 0 REST POST http://192.168.68.142:6345/setDischargeTarget failed: HTTPConnectionPool(host='192.168.68.142', port=6345): Read timed out. (read timeout=10) 32768 | 2026-08-04 21:15:23.646158: Error: Completed run status Exporting with Errors reported (check log)Update: with help from ChatGPT I think GivTCP confirms successful export commands but Predbat reports REST failure
I am seeing an issue where Predbat reports a failure when setting the export target, but GivTCP logs show that the inverter commands are completing successfully.
Environment:
- Predbat: v8.47.5
- GivTCP: v3.5
- Inverter: GivEnergy Gen 2 AC 3.0
- Control method: GivTCP REST (givtcp_rest enabled)
The issue appeared recently. GivTCP v3.5 has been running successfully for several months with the same configuration.
Predbat reports:
2026-08-06 19:55:34.895278: Warn: record_status Warn: Inverter 0 REST failed to setExportTarget got 0
2026-08-06 19:55:34.819348: Warn: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST failed got 0
2026-08-06 19:55:46.986320: Error: Completed run status Exporting with Errors reported (check log)At the same time, the GivTCP logs show the commands being accepted successfully:
2026-08-06 19:55:21,084 - GivTCP - write - [INFO] - Setting Discharge Target 1 was a success
2026-08-06 19:55:23,625 - GivTCP - write - [INFO] - Setting Discharge Target 1 was a success
2026-08-06 19:55:26,168 - GivTCP - write - [INFO] - Setting Discharge Target 1 was a success
2026-08-06 19:55:30,198 - GivTCP - write - [INFO] - Setting Discharge Target 1 was a success
2026-08-06 19:55:32,748 - GivTCP - write - [INFO] - Setting Discharge Target 1 was a success
2026-08-06 19:55:35,565 - GivTCP - write - [INFO] - Setting Discharge Slot 1 to: 19:55 - 20:01 was a success
2026-08-06 19:55:46,368 - GivTCP - write - [INFO] - Setting Timed Export mode was a success
2026-08-06 20:00:11,633 - GivTCP - write - [INFO] - Setting Eco mode was a successThe inverter does appear to receive and apply the commands. The issue appears to be that Predbat is interpreting the REST response as a failure (got 0) even though GivTCP completes the write successfully.
Additional observations:
- GivTCP REST endpoint is reachable and returns JSON.
- Other GivTCP entity mappings and serial-based entities are working correctly.
- No GivTCP write errors are shown.
- The issue did not occur previously with the same GivTCP version/configuration.
Could this be related to a recent change in Predbat REST response handling for GivTCP setExportTarget?
Just as an update and following others mentioning the write issue on Facebook and possible causes, I have checked out two additional things tonight:
- Turning the kernel version OFF makes no difference to the issue
- My system was in demand mode from 19:00 tonight and no additional writes happened. I've manually set it to export and back again and the write count goes up and I can see in the GivTCP log:
2026-08-07 19:00:19,709 - GivTCP - write - [INFO ] - Setting Eco mode was a success
2026-08-07 23:03:05,115 - GivTCP - write - [INFO ] - Setting Charge Slot 1 to: 23:30 - 23:55 was a success
2026-08-07 23:03:05,618 - GivTCP - write - [INFO ] - Setting Charge Schedule to enable was a success
2026-08-07 23:05:08,782 - GivTCP - write - [INFO ] - Setting Charge Schedule to disable was a success
2026-08-07 23:05:19,312 - GivTCP - write - [INFO ] - Setting Discharge Target 1 was a success
2026-08-07 23:05:21,811 - GivTCP - write - [INFO ] - Setting Discharge Target 1 was a success
2026-08-07 23:05:24,312 - GivTCP - write - [INFO ] - Setting Discharge Target 1 was a success
2026-08-07 23:05:26,812 - GivTCP - write - [INFO ] - Setting Discharge Target 1 was a success
2026-08-07 23:05:29,546 - GivTCP - write - [INFO ] - Setting Discharge Target 1 was a success
2026-08-07 23:05:30,343 - GivTCP - write - [INFO ] - Setting Discharge Slot 1 to: 23:00 - 23:31 was a success
2026-08-07 23:05:41,121 - GivTCP - write - [INFO ] - Setting Timed Export mode was a success
2026-08-07 23:10:19,547 - GivTCP - write - [INFO ] - Setting Discharge Target 1 was a success
2026-08-07 23:10:22,055 - GivTCP - write - [INFO ] - Setting Discharge Target 1 was a success
2026-08-07 23:10:24,566 - GivTCP - write - [INFO ] - Setting Discharge Target 1 was a success
2026-08-07 23:10:28,175 - GivTCP - write - [INFO ] - Setting Discharge Target 1 was a success
2026-08-07 23:10:30,687 - GivTCP - write - [INFO ] - Setting Discharge Target 1 was a success
2026-08-07 23:12:24,240 - GivTCP - write - [INFO ] - Setting Discharge Target 1 was a success
2026-08-07 23:12:26,740 - GivTCP - write - [INFO ] - Setting Discharge Target 1 was a success
2026-08-07 23:12:29,252 - GivTCP - write - [INFO ] - Setting Discharge Target 1 was a success
2026-08-07 23:12:31,763 - GivTCP - write - [INFO ] - Setting Discharge Target 1 was a success
2026-08-07 23:12:34,280 - GivTCP - write - [INFO ] - Setting Discharge Target 1 was a successEach time the "Setting Discharge Target 1 was a success" message appears in the GivTCP log, the write count increases and the following appears at the same time in the Predbat log (give or take less than a second):
2026-08-07 23:05:29.671692: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST successful after retry 4
2026-08-07 23:10:32.723256: Warn: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST failed got 0
2026-08-07 23:12:36.389288: Warn: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST failed got 0So I hope fixing the warning message REST issues might resolve the write counts.
I have today updated to the latest version, 8.47.7 and both issues are still present.
I have today updated to the latest version, 8.47.7 and both issues are still present.
thanks for keeping on raising this, I have an AC3 and have held off upgrading until its resolved
@chalfontchubby @springfall2008
could you look into this?Just to add a "me too"to this thread. v8.47.7
I first noticed this after Axle events, manually setting the battery back to Eco mode via the GivEnergy app seems to temporary resolve the issue.
I do recall that @springfall2008 was using the Cloud API not rest, so I'm considering flipping over to that to see if it helps.
34729 2026-08-12 04:25:43.919976: Warn: record_status Warn: Inverter 0 REST failed to setExportTarget got 0 34728 2026-08-12 04:25:43.915499: Warn: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST failed got 0 34443 2026-08-12 04:20:23.780261: Warn: Inverter 0 REST POST http://192.168.0.8:6345/setChargeRate failed: HTTPConnectionPool(host='192.168.0.8', port=6345): Read timed out. (read timeout=10) 34441 2026-08-12 04:20:11.762700: Warn: Inverter 0 REST POST http://192.168.0.8:6345/setChargeRate failed: HTTPConnectionPool(host='192.168.0.8', port=6345): Read timed out. (read timeout=10) 33535 2026-08-12 03:55:33.664436: Error: Completed run status Exporting with Errors reported (check log) 33364 2026-08-12 03:55:13.812143: Warn: record_status Warn: Inverter 0 REST failed to setExportTarget got 0 33363 2026-08-12 03:55:13.806989: Warn: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST failed got 0 33253 2026-08-12 03:50:13.881500: Error: Completed run status Exporting with Errors reported (check log) 33244 2026-08-12 03:50:13.848957: Warn: record_status Warn: Inverter 0 REST failed to setExportTarget got 0 33243 2026-08-12 03:50:13.843585: Warn: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST failed got 0 33137 2026-08-12 03:45:56.769231: Error: Completed run status Exporting with Errors reported (check log) 33123 2026-08-12 03:45:45.207075: Warn: record_status Warn: Inverter 0 REST failed to setExportTarget got 0 33122 2026-08-12 03:45:45.201610: Warn: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST failed got 0 32333 2026-08-12 03:25:27.005790: Error: Completed run status Exporting with Errors reported (check log) 32182 2026-08-12 03:25:18.166960: Warn: record_status Warn: Inverter 0 REST failed to setExportTarget got 0 32181 2026-08-12 03:25:18.162048: Warn: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST failed got 0 32071 2026-08-12 03:20:14.603466: Error: Completed run status Exporting with Errors reported (check log) 32062 2026-08-12 03:20:14.570626: Warn: record_status Warn: Inverter 0 REST failed to setExportTarget got 0 32061 2026-08-12 03:20:14.565906: Warn: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST failed got 0 31695 2026-08-12 03:10:14.754922: Error: Completed run status Exporting with Errors reported (check log) 31686 2026-08-12 03:10:14.719116: Warn: record_status Warn: Inverter 0 REST failed to setExportTarget got 0 31685 2026-08-12 03:10:14.711868: Warn: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST failed got 0 31579 2026-08-12 03:06:10.522732: Error: Completed run status Exporting with Errors reported (check log) 31409 2026-08-12 03:05:25.367846: Warn: record_status Warn: Inverter 0 REST failed to setExportTarget got 0 31408 2026-08-12 03:05:25.363145: Warn: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST failed got 0 31146 2026-08-12 02:55:55.101938: Error: Completed run status Exporting with Errors reported (check log) 31134 2026-08-12 02:55:44.250208: Warn: record_status Warn: Inverter 0 REST failed to setExportTarget got 0 31133 2026-08-12 02:55:44.245041: Warn: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST failed got 0 30312 2026-08-12 02:35:24.317020: Error: Completed run status Exporting with Errors reported (check log) 30304 2026-08-12 02:35:24.284159: Warn: record_status Warn: Inverter 0 REST failed to setExportTarget got 0 30303 2026-08-12 02:35:24.279536: Warn: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST failed got 0 30064 2026-08-12 02:30:14.600813: Error: Completed run status Exporting with Errors reported (check log) 30055 2026-08-12 02:30:14.567629: Warn: record_status Warn: Inverter 0 REST failed to setExportTarget got 0 30054 2026-08-12 02:30:14.562753: Warn: Inverter 0 Set export target slot 1 {'dischargeToPercent': 4, 'slot': 1} via REST failed got 0 Is anyone confident to try a local fix for this - adding a sleep between the set/get of the rest data?
I can push a patch, but if it would be possible to try this fix first it would help.
diff --git a/apps/predbat/inverter.py b/apps/predbat/inverter.py index 9806a0be..468cde36 100644 --- a/apps/predbat/inverter.py +++ b/apps/predbat/inverter.py @@ -3398,6 +3398,12 @@ class Inverter: for retry in range(INVERTER_MAX_RETRY_REST): r = self.rest_postCommand(url, json=data) + # GivTCP's runAll status is a separately-cached snapshot, refreshed on its own polling + # cycle rather than synchronously with this POST - reading it back immediately can catch + # data from before GivTCP has applied and exposed the write, reporting a spurious failure + # even though the write itself succeeded (#4421). A short settle delay gives that cache + # a chance to catch up before we check it. + self.sleep(1) self.rest_data = self.rest_runAll(self.rest_data) # GivTCP reports the raw registers as strings, so coerce before comparing or a # successful write reads back as '4' and never matches the int targetIs anyone confident to try a local fix for this - adding a sleep between the set/get of the rest data?
I can push a patch, but if it would be possible to try this fix first it would help.
is that the fix, adding a slight pause to wait for the inverter to update its registers?
I thought the problem was that Predbat was trying to set export target and on older GivEnergy inverters (specifically the AC3) that didn't exist?
Have to admit to not having upgraded to any of the latest releases as I have an AC3, and was waiting for a fix
At least one of the reports above shows the write succeeding after some attempts. The Givenergy integration has locally cached register values which it returns on the read despite the previous write apparently succeeding. The cache could/should get invalidated on a write, but that is out of our control. It only succeeds on subsequent attempts because the read cache has been updated. I think.
I can check further but can see a mechanism that explains at least some of the logs attached here.
Is anyone confident to try a local fix for this - adding a sleep between the set/get of the rest data?
I can push a patch, but if it would be possible to try this fix first it would help.
I can give it a go, do I simply edit apps/predbat/inverter.py and insert those lines?
I don't have a test system so would be going onto my live environment, so can quickly back it out.
- Yes, the one line “self.sleep(..)”added to that file is the key. # marks the rest of the line as a comment so for testing you can ignore those lines. To turn the fix off, either delete it or add a # at the start of the line. It’s python so indentation matters Sent from Yahoo Mail for iPhone On Wednesday, August 12, 2026, 10:26 am, kitenski ***@***.***> wrote: kitenski left a comment (springfall2008/batpred#4421) Is anyone confident to try a local fix for this - adding a sleep between the set/get of the rest data? I can push a patch, but if it would be possible to try this fix first it would help. I can give it a go, do I simply edit apps/predbat/inverter.py and insert those lines? I don't have a test system so would be going onto my live environment, so can quickly back it out. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>
Yes, the one line “self.sleep(..)”added to that file is the key. # marks the rest of the line as a comment so for testing you can ignore those lines. To turn the fix off, either delete it or add a # at the start of the line. It’s python so indentation matters
Hmm, so used Terminal and edited in Vi, but after saving Predbat wouldn't start! I used tab and space bar to indent, I guess that wasn't a good idea?
- Tab is probably your enemy. Sorry. I’m using the visual studio integration because I’m allergic to vi. Sent from Yahoo Mail for iPhone On Wednesday, August 12, 2026, 11:05 am, kitenski ***@***.***> wrote: kitenski left a comment (springfall2008/batpred#4421) Yes, the one line “self.sleep(..)”added to that file is the key. # marks the rest of the line as a comment so for testing you can ignore those lines. To turn the fix off, either delete it or add a # at the start of the line. It’s python so indentation matters Hmm, so used Terminal and edited in Vi, but after saving Predbat wouldn't start! I used tab and space bar to indent, I guess that wasn't a good idea? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>
5 remaining items
Traced this through the actual GivTCP integration source (britkat1980/giv_tcp) rather than guessing further from the logs alone. Summary:
There's no sign these registers don't exist.
discharge_target_soc_1is present in every reporter's raw GivTCP data, and GivTCP's own write handler (write.py'ssetDischargeTarget()) sends a real Modbus command viaset_soc_target()and only reports success if that command is accepted.The evidence that they exist and work comes straight from the logs already posted here - both reporters occasionally get a genuine successful readback, on the exact hardware in question:
- Redding43 (confirmed Gen 2 AC 3.0): 18 attempts read back
0(fail), but 3 attempts correctly read back the real target4(success after 1 and 4 retries) - FileGo (3kW AC inverter): 13 read back
0, but 2 correctly read back4(success after 0 and 4 retries)
A register that's genuinely absent or unwired would read back the same stuck value on every attempt - there'd be nothing underneath for a retry to ever catch up to. Instead it's flipping between
0and the correct target within the same continuous session, which only makes sense if a real write is landing and being read back correctly some of the time.The failure mechanism is real, and explains it precisely. GivTCP's write handler updates
Control.Discharge_Target_SOC_1in its cache synchronously the instant it accepts the write (updateControlCache(), called right after the Modbus command). But Predbat was checkingraw.invertor.discharge_target_soc_1instead - a completely different field, only refreshed by GivTCP's own background polling loop (self_run), on a timer that's configurable and can be tens of seconds (I found installs with it set to 30s). Predbat's own retry window is ~10-12 seconds total, so on many cycles it was checking a field that hadn't been due for a refresh at all yet - nothing to do with the write itself failing.One second of settle delay alone wasn't going to cut it against a poll cycle that can be 30 seconds away - so rather than just widening the delay, the fix (just pushed) switches to polling the field GivTCP actually updates synchronously (
Control.Discharge_Target_SOC_1), with the raw register kept only as a fallback. That removes the dependency on GivTCP's own poll timer entirely; the settle delay now only has to cover the much smaller gap of the physical inverter itself applying the write.PR: #4492
Reacted by Geoffrey Coan- Redding43 (confirmed Gen 2 AC 3.0): 18 attempts read back
Traced this through the actual GivTCP integration source (britkat1980/giv_tcp) rather than guessing further from the logs alone. Summary:
Great work, will backout that manual edit I made to include the sleep then.
Just wanting to check what I add, seems to be lots in "green" on two commits? commit
aad12d5and
commit
e9c9cabDo I need to add everything in green into the same file?
@kitenski It looks like the patch I asked you to test isn't strong enough. Waiting one second 5 times won't be enough to make it pass reliably if the givenergy integration is only updating the registers we read every 30 seconds.
I suggest you revert your code to the way it was and wait for the fix in pr 4492 since the changes required are a little more involved and I don't want to expose you to more risk. Thanks.
A question on the root cause for my curiosity. We know from investigations in #4402 that this started with release 8.47.1 and specifically PR #4384 (confirmed by @springfall2008). Does this proposed change of register to be read/written to link back to that?
Great investigation, thank you.
I understand the issue a lot better now, and I have seen examples of this occurring on my Gen 1 hybrids as well, e.g.
Had thought it was AC3-specific
refreshed by GivTCP's own background polling loop (self_run), on a timer that's configurable and can be tens of seconds (I found installs with it set to 30s)
For info, the default value for self_run is 30 seconds so I'd expect that the vast majority of people (myself included) are using that. You can set a lower value, I used to poll the inverters every 20 seconds, but if you set self_run to too low a value then the inverter (especially the older ones like Gen 1 hybrid and AC3) can spend all their time responding to modbus requests and none talking to the portal. So I changed mine to the default 30 seconds.
@davemilsom2
"A question on the root cause for my curiosity. We know from investigations in #4402 that this started with release 8.47.1 and specifically PR #4384 (confirmed by @springfall2008). Does this proposed change of register to be read/written to link back to that?"Good question, worth checking rather than assuming. Traced #4384's actual diff to answer it properly.
Yes, it links back directly - though not because #4384 introduced the stale-read bug itself.
raw.invertor.discharge_target_soc_1(andrest_setDischargeTarget()) is old, dating back to 2024 - the staleness this issue is about has presumably always been possible.What #4384 changed is the condition
adjust_force_export()uses to decide whether to callrest_setDischargeTarget()at all:# before #4384: if current > self.reserve_percent: self.rest_setDischargeTarget(int(self.reserve_percent)) # after #4384: if current != target_soc: self.rest_setDischargeTarget(target_soc)
Before, it only wrote when the target was too high - a coarse condition, rarely true, so the racy readback path barely got exercised. #4384 correctly fixed the bug it was targeting (a target left too low was never corrected), but its
!=check reads from the exact same staleraw.invertorfield this issue is about - so a readback that hasn't caught up yet almost always looks "different from target" even after the write already succeeded, triggering another write attempt. That turns an occasional check into one that can fire on nearly every 5-minute cycle, which matches the repeated-every-~5-minutes pattern in every log posted here.So #4384 didn't create the race, but it's very plausibly what turned a latent, rarely-triggered issue into one that fires constantly enough to notice - which lines up with the 8.47.1 timeline from #4402.
Reacted by Geoffrey Coan and davemilsom2Thanks for taking the time to investigate and explain.
- added a commit that references this issue
on Aug 12, 2026 Maybe I need to raise a new issue. The fix pushed to main has stopped the faults, however it is writing a discharge target twice every 5 mins in the GivTCP logs.
I think this is number.givtcp_ce2146g269_target_soc on my AC3, however this is NOT in the list of RTC safe registers. So burning through unnecessary writes.The number of writes during a 2 HR discharge, seems so unnecessary. I don't even see anything being changed.
Maybe I need to raise a new issue. The fix pushed to main has stopped the faults, however it is writing a discharge target twice every 5 mins in the GivTCP logs.
I'm seeing the same behaviour @mpartington
Agree, lets get this as a new issue as this one is closed
@mpartington @gcoan Agreed, this warrants its own issue since this one's closed. Opening one now and will link it here.
Reacted by Geoffrey CoanOpened #4517 to track this.
Unable to re-open #4404 but after updating to version 8.47.3 (at16:08), the same/similar issue happened again. I say "similar" as the error message now has a "got 0" at the end of it which is new, and sometimes it is showing correctly as "Exporting".
From the logs:
Issue reoccurred 16:23 - "Warn: record_status Warn: Inverter 0 REST failed to setExportTarget got 0"
Shows OK at 16:28 ("Exporting")
Reoccurred 16:34 - "Warn: record_status Warn: Inverter 0 REST failed to setExportTarget got 0"
Second message at 16:35 shows "Exporting" as I removed my manual invocation of export.
Latest YAML/Log attached
predbat_debug.yaml(Sun).txt
predbat(Sun).log