GivEnergy Cloud (GEC): battery control writes silently rejected with no clear status when Octopus Smart Flex owns the inverter

[springfall2008]

Describe the bug

When a GivEnergy battery is enrolled and "LIVE" under an Octopus Smart Flex battery programme (e.g. Intelligent Octopus Flux), GivEnergy's Cloud API accepts Predbat's control writes at the HTTP layer but declines to apply them, because Octopus's own automation has been granted write precedence for that inverter's charge/discharge settings. gecloud.py has no way to detect this condition, so it just keeps retrying every control loop and reports a generic, misleading warning that looks like a device/connectivity fault.

Observed behaviour:

• predbat.status shows Warn: Inverter 0 write to charge_limit failed (and the equivalent for charge_rate / discharge_rate), with error_count climbing over time.
• App logs show the same failure signature for multiple setting ids (discharge_rate, charge_rate, charge_limit) - i.e. it isn't specific to one register, any control-plane write competes with Octopus's claim on the device:

  GECloud: Setting ac_charge_upper_percent_limit to 100% for <device>, previous value was 98
  GECloud: Warn: Failed to write setting id 77, value 100
  GECloud: Warn: Failed to set ac_charge_upper_percent_limit for <device>
  

• In inverter.py, write_and_poll_value exhausts INVERTER_MAX_RETRY and logs:

  Warn: Inverter 0 Trying to write 100 to charge_limit didn't complete got 98.0
  Warn: record_status Warn: Inverter 0 write to charge_limit failed
  

• The inverter itself keeps reporting a healthy/online status throughout and telemetry keeps flowing normally - only control-plane writes are affected, which rules out a WiFi/connectivity/offline explanation.
• The failure is intermittent rather than constant - writes succeed for a while, then get stuck for an extended period. This lines up with Octopus's own device-discovery API reporting the battery as a live Smart Flex device:

  OctopusAPI: GraphQL response for get-intelligent-devices (status 200): {'data': {'devices': [{'provider': 'GIVENERGY', 'deviceType': 'BATTERIES', 'status': {'current': 'LIVE'}, '__typename': 'SmartFlexBattery'}]}}
  

Expected behaviour

Predbat already discovers Smart Flex devices for EV charging (kraken.py / octopus.py handle SmartFlexVehicle / SmartFlexChargePoint for octopus_intelligent_slot), but nothing currently checks for SmartFlexBattery. When a SmartFlexBattery is LIVE on the account, Predbat should ideally:

1. Surface a clear, distinct status (e.g. "Battery under third-party (Octopus) control") instead of the generic write to X failed warning, so this isn't mistaken for a device or connectivity fault.
2. Back off from repeatedly spending the full write-retry budget on a setting that's known to be locked while this condition holds, rather than retrying every control loop indefinitely.

Predbat version

v8.48.3 (also seen on earlier point releases)

Environment details

• GivEnergy Cloud (GEC) inverter type, ge_cloud_direct auto-discovery
• Account on an Octopus Intelligent Flux-style tariff with the battery enrolled as a Smart Flex device

Additional context

async_write_inverter_setting / async_read_inverter_setting in gecloud.py document GivEnergy's own write-acknowledgement codes (-1 timeout, -2 device offline, -5 server error, -6 no response, -7 locked/cannot be modified), but the current failure path doesn't log which of these actually came back. Today that makes it hard to tell "genuinely offline" apart from "locked because another app owns it" from Predbat's logs alone. Logging the actual code (or at least flagging a -7 lock specifically) would make this much faster to diagnose independent of the Smart Flex detection above.

[gcoan]

@springfall2008 If Predbat detects that Octopus has control of the battery, how about it sets itself to Monitor mode and writes an error as to why it has done this?

There's no point in continuing to try to control the inverter in these circumstances

[springfall2008]

Some people still want to optimise, its just they fight!