Summary
Inverter.update_status() raises a bare raise ValueError (no message) when it can't determine the charge window because there's no rate/window source configured. Because the exception carries no context, it bubbles up to the main loop and surfaces to the user as the unhelpful status Error: Exception raised, with a raw traceback in the logs instead of an actionable message.
Where
apps/predbat/inverter.py ~line 1458, in update_status():
if self.rest_data:
charge_start_time = time_string_to_stamp(self.rest_data["Timeslots"]["Charge_start_time_slot_1"])
charge_end_time = time_string_to_stamp(self.rest_data["Timeslots"]["Charge_end_time_slot_1"])
elif "charge_start_time" in self.base.args:
charge_start_time = time_string_to_stamp(self.base.get_arg("charge_start_time", index=self.id))
charge_end_time = time_string_to_stamp(self.base.get_arg("charge_end_time", index=self.id))
else:
self.log("Error: Inverter {} unable to read charge window time as neither REST, charge_start_time or charge_start_hour are set".format(self.id))
self.base.record_status("Error: Inverter {} unable to read charge window time ...".format(self.id), had_errors=True)
raise ValueError # <-- bare, no message
Why it matters
- The status entity ends up as
Error: Exception raised (the outer handler's generic message), so users/support can't see why it failed without digging into the pod's traceback.
- It's inconsistent with the sibling branch just below (~1460–1466), which handles a missing/
None charge window gracefully — logs a Warn, sets safe defaults, and retries next update rather than raising:
if charge_start_time is None or charge_end_time is None:
self.log("Warn: Inverter {} unable to read charge window time ... will retry next update")
...
self.charge_enable_time = False
self.charge_start_time_minutes = self.base.forecast_minutes
...
Observed in production on multiple instances whose upstream inverter integration returned no device/registers (e.g. GivEnergy cloud "no devices", Fox returning no data): the useful Error: Inverter 0 unable to read charge window time ... message is logged, but the subsequent bare ValueError overwrites the user-visible status with Error: Exception raised.
Suggested fix (either)
- Raise with the same descriptive message already logged:
raise ValueError("Inverter {}: unable to read charge window — neither REST, charge_start_time nor charge_start_hour set".format(self.id)), or
- Follow the sibling branch's graceful-recovery pattern (safe defaults + retry next update) so a transient/absent inverter feed doesn't hard-error the whole plan.
Option 1 is minimal; option 2 is more robust for instances where the inverter feed is temporarily empty on a fresh start.
Summary
Inverter.update_status()raises a bareraise ValueError(no message) when it can't determine the charge window because there's no rate/window source configured. Because the exception carries no context, it bubbles up to the main loop and surfaces to the user as the unhelpful statusError: Exception raised, with a raw traceback in the logs instead of an actionable message.Where
apps/predbat/inverter.py~line 1458, inupdate_status():Why it matters
Error: Exception raised(the outer handler's generic message), so users/support can't see why it failed without digging into the pod's traceback.Nonecharge window gracefully — logs aWarn, sets safe defaults, and retries next update rather than raising:Observed in production on multiple instances whose upstream inverter integration returned no device/registers (e.g. GivEnergy cloud "no devices", Fox returning no data): the useful
Error: Inverter 0 unable to read charge window time ...message is logged, but the subsequent bareValueErroroverwrites the user-visible status withError: Exception raised.Suggested fix (either)
raise ValueError("Inverter {}: unable to read charge window — neither REST, charge_start_time nor charge_start_hour set".format(self.id)), orOption 1 is minimal; option 2 is more robust for instances where the inverter feed is temporarily empty on a fresh start.