`find_battery_size` raises `AttributeError: 'PredBat' object has no attribute 'max_days_previous'` on every tick - reproducible on v8.42.4 and v8.42.5

[chibikibou]

Describe the bug
Every restart, timer_tick throws the following, repeating on every subsequent tick (roughly every 2 minutes in my log):

2026-06-29 20:35:44.040422: Error: Exception raised 'PredBat' object has no attribute 'max_days_previous'
2026-06-29 20:35:44.099535: Error: Traceback (most recent call last):
  File "/config/predbat.py", line 1689, in update_time_loop
    self.quick_inverter_data_update()
  File "/config/execute.py", line 883, in quick_inverter_data_update
    self.fetch_inverter_data(create=False)
  File "/config/execute.py", line 740, in fetch_inverter_data
    inverter = Inverter(self, id)
  File "/config/inverter.py", line 411, in __init__
    self.battery_size_tracking()
  File "/config/inverter.py", line 598, in battery_size_tracking
    found_size = self.find_battery_size(self.nominal_capacity)
  File "/config/inverter.py", line 722, in find_battery_size
    soc_percent_data = self.base.get_history_wrapper(entity_id=soc_percent_sensor, days=self.base.max_days_previous, required=False)
AttributeError: 'PredBat' object has no attribute 'max_days_previous'. Did you mean: 'days_previous'?
2026-06-29 20:35:44.205307: Warn: record_status Error: Exception raised 'PredBat' object has no attribute 'max_days_previous'
2026-06-29 20:35:44.205506: Error: timer_tick caught exception: 'PredBat' object has no attribute 'max_days_previous'

inverter.py line 722 (find_battery_size) reads self.base.max_days_previous, but the PredBat object only ever sets self.days_previous (the raw apps.yaml config list) — there's no derived max_days_previous attribute set anywhere on self.base, so this fails unconditionally, every time.

First seen on v8.42.4. Updated to v8.42.5 hoping it would resolve it; still present, identical traceback. Comparing the two versions, the changes between them (GE REST charge-target-enable fix, EV/EVC gateway status fix) don't touch inverter.py's battery sizing code, so this seems to be a preexisting bug rather than something either version introduced.

Expected behaviour
battery_size_tracking() / find_battery_size() should not crash timer_tick.

Predbat version: first seen on v8.42.4, confirmed still present on v8.42.5

Environment details: HAOS on Raspberry Pi 4 with SSD, installed via the standalone Predbat app. inverter_type: SIG (Sigenergy SigenStor via TypQxQ's Sigenergy-Local-Modbus HACS integration). battery_scaling: 1.0 set in apps.yaml; battery_scaling_auto is not set, so this appears to run regardless of whether automatic battery-size tracking has been opted into.

Additional context: this occurs via quick_inverter_data_update, the lightweight per-tick inverter status refresh (not the main plan calculation) which is why it fires even with Mode set to Monitor and Read Only enabled, and while template: True is still present in apps.yaml.

Full predbat.log and apps.yaml attached in case it helps. Apologies if issue exists already, searching did not turn anything up.

apps.yaml.txt

predbat.log

[chibikibou]

Sadly the issue is still occurring: reproduced across v8.42.4, v8.42.5, and v8.43.1 (identical max_days_previous AttributeError each time, at the same line in inverter.py), and a related but distinct AttributeError on inverter_clock_skew_start now appears in v8.44.0 beta at a later point in the same call chain (update_status rather than battery_size_tracking), suggesting inverter object initialisation still has unresolved gaps between what's referenced and what's populated on self.base at that point.

Commenting rather than filing a duplicate, since I assume this is the same underlying defect surfacing at a different attribute. Updated predbat.log attached covering all four versions tested, apps.yaml unchanged.

predbat.log

@springfall2008

[chibikibou]

... Further comment: out of curiosity, I commented out Template: True from apps.yaml (leaving predbat in Monitor mode) to see what would happen, and the issue instantly resolved itself. I did this in contravention of the documentation's advice to keep the template line until ready to go live, so that may be a separate issue.