fix(car): default car_charging_plan_smart to on (#5237)

[chalfontchubby]

Written by Claude Code on behalf of @chalfontchubby.

Addresses #5237 (does not close it - see "Relation to #5163").

Why

With car_charging_plan_smart off (the current default), plan_car_charging() fills every slot in low_rates in time order from plug-in, whatever the price. "Low rate" means "below the automatic import threshold", which is rate_max - 0.5. So anything that lifts rate_max for a while admits the ordinary peak as a "low-rate" slot, and a default install charges the car at peak.

The #5237 log shows this happening. The user was on default settings, Octopus Go, with a saving session joined for 18:00-19:00:

time	import threshold	car plan
16:15-18:55 (session ahead)	43.48p (rate_max 43.98p = 34.6p + 9.375p reward)	34.6p peak slots from plug-in
19:00 (session over)	34.1p	00:30 at 9.5p

That is roughly 10 kWh × 25p ≈ £2.50 on the car. It also caused a knock-on: with car_charging_from_battery on and a best_soc_keep of 5 kWh, the optimiser topped the house battery up to 85% at 34.6p to feed the car. That top-up disappeared in the same cycle that the car plan moved.

The battery optimiser rejects an uneconomic charge window. The non-smart car planner does not: admission to low_rates is its approval. So the default setting should not be the one that trusts the threshold blindly.

Change

• car_charging_plan_smart default False → True in CONFIG_ITEMS, and the matching get_arg fallback in fetch.py
• Docs: car-charging.md and customisation.md state the new default and what turning it off does
• Test: smart_default in test_car_charging_smart.py pins the default

Who is affected

Existing installs keep their current value. The switch is restored from predbat_config.json or HA history before the default is consulted. Only new installs, or users whose switch has never been created (no car configured until now), get the new default.

Users who want the old behaviour can turn the switch off; the docs now say what that does.

Relation to #5163

#5163 fixes the underlying threshold distortion: it takes saving/Axle minutes out of the min/max/average that set_rate_thresholds() uses, which would have kept the threshold at 34.1p here. That is a code-reading claim - the attached debug.yaml is from 20:00, after the session ended, so it cannot replay the 17:45 state. This PR is independent of #5163 and still worth having: the automatic threshold is a blunt min/max rule, and any other one-off import spike would have the same effect on a price-blind car planner.

Testing

• ./run_all --quick: all passed (includes debug_cases)
• ./run_pre_commit: all hooks passed

🤖 Generated with Claude Code