[tico24]

Fixes #5807

What and why

When the shared charger control drives a charger, it also runs it in any dispatch on octopus_intelligent_slot. With octopus_intelligent_planned_slot set, the docs say planned slots on octopus_intelligent_slot are ignored for that car, and the car plan does ignore them, but the charger didn't. It now takes planned dispatches from the planned sensor and completed ones from both, as fetch.py does. With a planned sensor set it no longer falls back to the slot sensor's on/off state. Before #5791 the Hypervolt followed only the car plan, so for Hypervolt users this is a regression from the move to the shared loop.

Who this changes things for

Users with octopus_intelligent_planned_slot set whose charger Predbat drives: Octopus drives the car and octopus_intelligent_charger_follows_car is on, or Predbat can't tell and the control setting is true. Their charger now follows the planned sensor rather than the slot sensor. Nobody without a planned sensor is affected.

Deliberately not changed

• If the planned sensor is unavailable, the dispatch check finds no dispatches and doesn't fall back to the slot sensor. That's how fetch.py builds the car plan from it too, and falling back would run the charger in exactly the dispatches the user filtered out. Predbat's own plan windows still apply.
• Only the snake_case dispatch attributes are read, as the existing charger code does. fetch.py also reads the camelCase ones.
• The planned sensor rule is a copy of Fetch.car_planned_slot_entity() plus its octopus_intelligent_slot_action_config check, in the same way charger_control_dispatch_sensor() already reads octopus_intelligent_slot itself.
• Telling which device Octopus drives is left to chalfontchubby's is_charger work. Whether Predbat may stop a charger Octopus drives is a separate question, discussed in the comments.

Testing

• test_planned_slot_sensor_replaces_the_slot_sensor_plan in test_car_charger_control.py covers the planned sensor replacing the slot sensor's plan, completed dispatches from it, regex and same-sensor values, and the action config. It fails on main.
• car_charger_control, hypervolt, ohme, myenergi and ge_cloud pass. pre-commit passes on the changed files.
• Running on my own system since 28 Oct: Hypervolt Home 3 Pro (V3 API), Intelligent Octopus Go, the Octopus Energy integration, and a Home Assistant template sensor as octopus_intelligent_planned_slot.

[springfall2008]

Automated comment from the triage bot.

Clean review of PR #5808 at 3c2dac7 - 0 findings inline, 0 in the body.

What I checked: the planned-sensor rule in charger_control_dispatch_active() / charger_control_planned_sensor() side by side against Fetch.car_planned_slot_entity() and its caller (they match, including the completed-from-both reads, the single-value-is-car-0's list handling, the re: and self-reference guards, and the octopus_intelligent_slot_action_config carve-out); the new filtered arm in charger_control_drive_one() against every pre-existing leave-alone rule (the Ohme claim for car 0, never driving a sensor-said charge point, the discovery waits - all preserved, verified against main's copy of the function); charger_control_declared_device()'s arg handling against get_arg() / resolve_arg() (list wrapping, optional_entries, templating); the APPS_SCHEMA entry's allowed validation (it fires for the string type; validate_config() only enforces allowed there and in the integer branch); the new tests' claims (both fail on main - there charger_control_dispatch_active() reads the raw slot sensor and charger_control_declared_device() does not exist); the three docs files (anchors valid, the setting documented, the Hypervolt recipe covers the new combination); and each deliberate behaviour in the PR body against the code (no slot-state fallback with a planned sensor set, snake_case attributes only, the duplicated planned-sensor rule kept).

The one design change worth naming, since it is broader than the issue title: octopus_intelligent_charger_follows_car expert mode now also follows the planned sensor where one is set, rather than the raw slot sensor. That is documented in the car-charging and Hypervolt docs and reads as the coherent rule - the charger follows the same plan the car is planned on - so I see no problem with it, just flagging it in case anyone reading the issue expected the raw follow to survive there.

[springfall2008]

Not sure I want to make this mandatory to set, probably need it automatic

[tico24]

Made it automatic, and octopus_intelligent_device is gone. The Octopus Energy integration's dispatch sensor has no is_charger, but it fills in charge_point_power_in_kw only for a charger and vehicle_battery_size_in_kwh only for a car, so Predbat now reads whichever is set. Filtering an Octopus charger only needs its control setting on and octopus_intelligent_planned_slot set for that car. I've updated the description, including who this changes things for.

[chalfontchubby]

Posted by Claude on behalf of @chalfontchubby.

Short version: the planned-slot fix (part 1) is a regression fix and I think it should go in. Our Hypervolt port (#5791) introduced the regression. For the new octopus_intelligent_device setting (part 2), there's an automatic route coming, but it doesn't settle the question this PR really raises. I'd split part 2 out so part 1 can merge on its own.

Part 1: agreed. Before #5791 the Hypervolt followed only Predbat's car plan, which honours octopus_intelligent_planned_slot. The shared charger loop also lets the charger run in any dispatch on the raw octopus_intelligent_slot sensor. That check was added so octopus_intelligent_charger_follows_car reacts to a new dispatch quickly. It ignores the planned sensor, so a filtered plan is overridden, contrary to car-charging.md. Reading planned dispatches from octopus_intelligent_planned_slot when it's set fixes that for every charger on the shared loop.

Part 2: the automatic route. On "probably need it automatic": Predbat's own Octopus and Kraken components already publish is_charger on their dispatch sensors. For the Octopus Energy integration, BottlecapDave/HomeAssistant-OctopusEnergy#1917 adds a device_type attribute (ELECTRIC_VEHICLE_CHARGERS / ELECTRIC_VEHICLES) to the intelligent charge target entity. It's open and waiting for review. Once it merges, Predbat can read it from the car's octopus_charge_limit entity and tell which device Octopus drives with nothing to configure.

Detection doesn't decide the behaviour, though. Once Predbat can tell that Octopus drives this Hypervolt, today's rule leaves that charger entirely to Octopus. The filter here would then stop working. tico24's setup works today only because the integration can't say. So the real decision is whether a user-filtered octopus_intelligent_planned_slot on a charger Octopus drives should mean "Predbat may stop it outside the filtered plan". One thing to check before allowing that: I haven't verified how Octopus treats a dispatch where the charger is repeatedly stopped. It may count as a failed dispatch.

[chalfontchubby]

Posted by Claude on behalf of @chalfontchubby.

A follow-up on the automatic route. Predbat can already tell which device Octopus drives for Octopus Energy integration users, without waiting for #1917.

The integration's dispatching sensor fills in charge_point_power_in_kw when a charger is the Intelligent device, and vehicle_battery_size_in_kwh when a car is. Each is left empty for the other kind. We have this rule in an unpushed patch for #3034, where the charge target means "add X%" for a charger and "charge to X%" for a car. That patch checks, in order:

1. is_charger (Predbat's own Octopus and Kraken components)
2. device_type (Alert update to include location #1917, once merged)
3. failing both, which of those two attributes is filled in.

Shared with charger_control_dispatch_is_charger(), the same rule would make "which device does Octopus drive" automatic for the integration too, so octopus_intelligent_device wouldn't need to be set. I'll put that up as a PR together with the #3034 fix.

The caveat from my last comment still applies: once Predbat can tell that Octopus drives tico24's Hypervolt, today's rule leaves it alone and the planned-slot filter stops working. So the veto question needs settling before or alongside that change.

[tico24]

Split as you suggested. This PR is now just the planned-slot fix, and the device detection is out, so that stays with your #3034 work. I'll put the veto rule up as its own small PR on top of this one, so it can be settled before your detection lands, with what my system has shown about stopping the charger inside dispatches.