EV alike function for my swimming p0ol (heatpump

[RienduPre]

What problem does this solve?

Here's the scenario:
I want to heat my swimming only when there is surplus solar.
Functionality like the EV part, but more simple (there is no soc for instance), but I know the power usage and can switch my heatpump and and poolpump(which needs to be on when heating)

Thanks,
Rien

Proposed solution

No response

Category

None

[traktore-org]

Hi @RienduPre — good news, SEM already handles this exact pattern end-to-end. No new code needed, just a two-device setup using the existing Surplus control mode + Appliance dependencies (depends_on).

Setup for your pool

Register both devices, then link them so the heater only fires when the pump is already running:

Device	Control Mode	Priority	Min power	Requires
Pool pump	Surplus	high (e.g. 3)	~your pump rating	None
Pool heat pump	Surplus	lower than the pump (e.g. 6)	~your heat-pump rating	Pool pump

SEM will then:

1. Wait until solar surplus ≥ pool pump's min power → turn pump ON
2. Wait until additional surplus ≥ heat pump's min power → turn heat pump ON (the dependency gate only opens once the pump is already active)
3. If surplus drops below the heat pump's threshold → turn heat pump OFF; pump keeps running while surplus covers it
4. If surplus drops below the pump's threshold → cascade: pump OFF turns off heat pump too

Where to find the "Requires" dropdown

It's been on the Load Priority card all along, but the label is subtle — small font, dimmed, inline next to the Mode dropdown on each device row. Highlighted in orange below for clarity:

Control tab → Load Management card → each device row has Mode (Off / Peak Only / Surplus) and Requires (None / parent device). Set the heater's Requires to the pool pump and you're done.

Documentation

Full reference: docs/MULTI_DEVICE_GUIDE.md → Appliance Dependencies — covers chain patterns (A → B → C), sibling patterns (heat pump + circulation pump + buffer valve all under one parent), dependency modes (must_active / must_inactive), cascade behaviour, and the service-call route if you prefer YAML over the dashboard.

The pool-heater-needs-pool-pump example is literally row one of the use-case table there. We should make it more discoverable from the README and QUICK_START — landing that nudge now.

Could you confirm the configuration works for your setup? If it does, happy to close this and treat the doc-discoverability fix as the follow-up. If you hit anything specific to pool heating that doesn't fit the existing model (e.g. anti-short-cycle minimum runtime, daily-runtime budget, water-temperature target), let me know and I'll scope that as a focused feature on top of the existing controller.