TypeError: argument of type 'int' is not iterable with GS_fb00 + time entities for discharge_start_hour/discharge_end_hour

[Gammaed]

Bug Report

PredBat version: v8.37.2
Inverter type: GS_fb00 (Ginlong Solis RHI-3P-10K-HVES-5G, FB00 firmware)
Solis Modbus integration version: v4.1.2

Problem

When using time entities for discharge_start_hour and discharge_end_hour,
PredBat crashes with TypeError when trying to execute discharge plan.

Error

TypeError: argument of type 'int' is not iterable

File "/config/execute.py", line 359, in execute_plan
inverter.adjust_force_export(True, discharge_start_time, discharge_end_time)
File "/config/inverter.py", line 2172, in adjust_force_export
self.write_and_poll_option("discharge_end_hour",
self.base.get_arg("discharge_end_hour", indirect=False, index=self.id),
int(new_end[:2]))
File "/config/inverter.py", line 1775, in write_and_poll_option
if old_value and (":" in old_value) and (":" in new_value)
and (len(old_value) == 5) and (len(new_value) == 8):
TypeError: argument of type 'int' is not iterable

Cause

Solis RHI-3P with FB00 firmware uses time entities instead of separate
hour/minute number entities. The time entities return a value like "22:00:00"
but PredBat passes an int to write_and_poll_option which then fails the
string check (":" in old_value).

apps.yaml configuration

discharge_start_hour:

• time.solis_rhi_3p_grid_time_of_use_discharge_start_slot_1
  discharge_end_hour:
• time.solis_rhi_3p_grid_time_of_use_discharge_end_slot_1

Impact

PredBat crashes on every discharge execution attempt.
Charging works correctly. Export/discharge still works via
Solis own TOU settings but PredBat cannot actively control it.

Workaround

Currently running in Monitor mode to avoid crashes.

[Gammaed]

Still there the problem Still having the issue after changing inverter_type from GS_fb00 to GS.

With GS_fb00: TypeError argument of type 'int' is not iterable
on discharge_start_hour/discharge_end_hour

With GS: KeyError: 0 on alt_charge_discharge_enable ECO mode

Inverter firmware version: 1A0040-60000D
Solis RHI-3P10K-HVES-5G, Model CA

Neither GS nor GS_fb00 works correctly with time entities.
Currently running Monitor mode as workaround.

Which inverter_type should be used for firmware 1A0040-60000D?

[Gammaed]

Still having the issue after changing inverter_type from GS_fb00 to GS.

With GS_fb00: TypeError argument of type 'int' is not iterable
on discharge_start_hour/discharge_end_hour

With GS: KeyError: 0 on alt_charge_discharge_enable ECO mode

Inverter firmware version: 1A0040-60000D
Solis RHI-3P10K-HVES-5G, Model CA

Neither GS nor GS_fb00 works correctly with time entities.
Currently running Monitor mode as workaround.

Which inverter_type should be used for firmware 1A0040-60000D?

[Gammaed]

Hi @springfall2008,
​I am following up on this issue as the problem persists after the Home Assistant 2025.9.0 update. It seems Predbat is unable to fetch the necessary history data to calculate charge and discharge curves, leading to constant warnings in the logs.
​Earlier logs showed Failed to decode response <Response [404]> from the supervisor API when trying to access history. Currently, Predbat is reporting that it cannot find history for soc_percent, charge_rate, and battery_power, even though these sensors are active and recording in Home Assistant.
​My Setup:
​HA Version: 2025.9.0
​Predbat Version: v8.37.1
​Inverter: Solis RHI-3P-10K-HVES-5G
​Battery: Dyness TS17 (35kWh)
2026-04-24 09:42:40.552309: Warn: Cannot find battery charge curve (no full rate charge curve found for battery to full), one of the required settings for soc_percent, charge_rate, battery_power and predbat.status do not have history, check apps.yaml
2026-04-24 09:42:42.523972: Warn: Cannot find battery discharge curve (no full rate discharge curve found for battery to empty), one of the required settings for soc_percent, discharge_rate, battery_power and predbat.status do not have history, check apps.yaml
2026-04-24 09:42:43.274645: Info: record_status Hold for car
I have already tried restarting the add-on and verifying that the sensors have history data within the HA dashboard, which they do. It appears the communication between Predbat and the HA History API is broken in this version.
​Could you please advise if there is a workaround or if a fix is in the works?
​Thanks for the great work on Predbat!