v8.19.1 - Predbat changing between demand, freeze and back

[mpartington]

Describe the bug Issue raise to transfer the requested log files

1. Debug file captures an export, however as I'm on a 2 rate tariff, my settings are to export as late as possible

2. Following export, Predbat goes into 'Demand mode' and then quickly goes to 'Freeze Export '. It's possible that there is a coding issue that is driving an unnecessary interim state

Expected behaviour

1. My system is a single 3kW AC3 inverter with a 3kW String inverter. This is modelled correctly as 6kW capacity in apps.yaml and i have no export limit set. Therefore Predbat should not be discharging to prevent clipping and any discharge should be scheduled to end just before cheap rate starts. As there is no benefit, only risk, in exporting earlier

2. Go straight from exporting to Freeze export, without the interim step

Predbat version

v8.19.1

Environment details

• Inverter and battery setup
• Standard HAOS installer or Docker
• Anything else?

Screenshots plan

predbat_plan.html.txt

Log file To cover the mode changes / export

predbat.log

Predbat debug yaml file

To cover the export: predbat_debug.yaml.txt

[mpartington]

Export has finished, so one to cover the next plan (if needed)

predbat_debug2.yaml.txt

[mpartington]

Another possible bug (or maybe my settings on 8.19.1. Car was charging on an intelligent slot 22.09 until 7am. At 23.30, the battery started to export, meaning it just went into the car, rather than holding.

predbat.1.log

[springfall2008]

I'm suspecting you have a bad automation here, I'm seeing lots of these

"2025-04-28 14:10:00.499084: switch_event: switch.predbat_combine_charge_slots = False"

This causes the plan to re-computed as its made invalid and hence its not keeping the old one.

I'll maybe add some code to suppress this but I think its an issue on your side?

[mpartington]

@springfall2008 thanks for looking. This is the only automation I have for combine charge slots. Basically I combine then overnight to stop any charge/discharge behaviour.

It runs every 5 mins, I thought it wouldn't change if it's already in the required state though? I guess I could add another condition, so it doesn't try to switch if that's the issue

Also history from the 28th only records 1 state change.

[gcoan]

It may only be showing 1 state change but you are setting the state every time the automation runs.

e.g

21:00 set state to on 21:05 set state to on 21:10 set state to on ... 5:30 set state to off 5:35 set state to off

there are only 2 state CHANGES but the actual state is set every 5 minutes

is there a reason for triggering every 5 minutes, why not have a trigger at the start and end times?

[mpartington]

Thanks both, I've learnt something new today! I wasn't expecting it to set if there was no state change. I've added a couple of extra conditions now to stop it, but going to be checking the rest of my automations tomorrow.

Only reason I'm doing it every 5 mins is to act as a heartbeat, in case I missed the trigger (got a few things grouped in same automation). Agree though doesn't need to be every 5 mins

[gcoan]

If you dig into the state database table (trying to work out how the database is so big, like I've done), you discover some of HA isn't as smart as you think it should be ....