A Home Assistant blueprint for automatically controlling multiple discretionary loads using solar surplus, battery SOC, load priorities, and configurable power thresholds.
The idea is simple: use as much available solar energy as possible for useful loads, while preventing the controller from adding more loads than the available surplus can support.
Features
-
Unlimited/practically arbitrary number of loads -
Priority-based load management- Loads are configured in priority order.
- First load = highest priority.
- Last load = lowest priority.
-
Sequential startup- Loads start one at a time in priority order.
- Configurable delay between starts.
-
Reverse-priority shutdown- Lowest-priority loads are shed first.
-
Per-load configured power- Each load has its own nominal wattage.
- Startup calculations account for all currently running dump loads.
-
Configurable solar safety margin -
Per-load battery SOC limits -
Per-load minimum solar-surplus thresholds -
Optional daylight-only startup -
Emergency load shedding- Automatically sheds loads during a sustained power deficit.
-
Optional high-SOC startup override -
Conditional SOC + deficit shutdown -
Configurable evaluation and settling delays
How it works
The blueprint expects a sensor representing:
PV production − house consumption
For example:
PV production 6500 W
House consumption 1800 W
---------------------------
Solar surplus 4700 W
A positive value means there is available solar power.
A negative value means the house is consuming more power than the PV system is producing.
Starting a load
The blueprint calculates the required surplus based on the loads that are already running.
For example:
Running load #1 2000 W
Running load #2 1000 W
New load 1500 W
Safety margin 300 W
--------------------------------
Required surplus 4800 W
The new load is only started if the available surplus is sufficient.
The load’s configured start_surplus threshold is also respected.
The effective requirement is the greater of:
configured start surplus
or
running loads
+ new load
+ safety margin
This prevents the controller from progressively adding loads until the system starts importing electricity.
Load priority
Priority is determined simply by the order of the loads in the blueprint configuration.
Example:
1. Water heater 2000 W
2. Pool pump 1000 W
3. Workshop heater 1500 W
4. EV charger 3000 W
The controller will attempt to start them in that order:
Water heater
↓
Pool pump
↓
Workshop heater
↓
EV charger
When power becomes insufficient, they are shed in reverse order:
EV charger
↓
Workshop heater
↓
Pool pump
↓
Water heater
This makes it possible to define which loads are considered more important.
Battery protection
Each load has its own SOC configuration.
For example:
Water heater
Start SOC: 60%
Stop SOC: 45%
Pool pump
Start SOC: 70%
Stop SOC: 55%
EV charger
Start SOC: 85%
Stop SOC: 70%
This allows different loads to have different battery-protection policies.
A load can also optionally have a conditional SOC/deficit stop.
For example:
SOC < 50%
AND
net power < 0 W
This can be useful when you don’t necessarily want to stop a load simply because the battery SOC has fallen, but you do want to stop it once the battery is being discharged.
High-SOC override
Individual loads can optionally have a high-SOC startup override.
For example:
Normal start SOC: 70%
High SOC threshold: 95%
Once the battery is above 95%, the load can use the high-SOC startup condition instead of the normal SOC requirement.
Important: the high-SOC override does not mean that the load can start with arbitrary or insufficient solar power.
The controller still requires enough positive surplus to cover:
currently running dump loads
+ new load power
+ safety margin
Emergency load shedding
The blueprint also includes an emergency mode.
Example:
Emergency deficit: -4000 W
Emergency duration: 5 minutes
If the net-power sensor remains below -4000 W for 5 minutes, emergency shedding starts.
The lowest-priority running load is switched off.
The controller then waits for the configured emergency settling delay and checks the power again.
If the deficit still exists, the next-lowest-priority load is shed.
This continues until either:
- the deficit is resolved, or
- no configured dump loads remain running.
Example configuration
A typical setup might look like:
| Priority | Load | Power | Start SOC | Stop SOC |
|---|---|---|---|---|
| 1 | Water heater | 2000 W | 60% | 45% |
| 2 | Pool pump | 1000 W | 70% | 55% |
| 3 | Workshop heater | 1500 W | 75% | 60% |
| 4 | EV charger | 3000 W | 85% | 70% |
With:
Safety margin: 300 W
Startup delay: 5 min
Shutdown delay: 15 sec
Evaluation interval: 10 min
If only the water heater is running:
Running power = 2000 W
To start the pool pump:
2000 + 1000 + 300 = 3300 W
At least 3300 W of surplus is therefore required, assuming that is greater than the pool pump’s configured start_surplus.
To subsequently start the workshop heater:
2000 + 1000 + 1500 + 300 = 4800 W
And so on.
Installation
1. Import the blueprint
In Home Assistant, go to:
Settings → Automations & scenes → Blueprints
Choose Import Blueprint and paste the blueprint URL.
Alternatively, copy the YAML into your blueprint directory:
/config/blueprints/automation/<your_directory>/solar_power_shedder.yaml
Then reload the blueprints.
2. Create the automation
Create a new automation from the Solar Power Shedder blueprint.
Select:
- your solar surplus/net-power sensor
- your battery SOC sensor
- your dump loads
- the desired priority order
- your SOC and power thresholds
3. Configure the loads
Add each controllable load in priority order.
For every load specify:
- Name
- Switch
- Nominal power
- Start SOC
- Start surplus
- Stop SOC
- Stop deficit
- Optional conditional shutdown
- Optional high-SOC override
Important: configure realistic load power
The power value should represent the expected consumption of the load.
For example:
Water heater → 2000 W
Pool pump → 750 W
Heating element → 1500 W
EV charger → 7000 W
The blueprint uses these values when determining whether another load can safely be started.
If a load’s actual consumption is significantly higher than its configured value, the controller may overestimate the available surplus.
For loads with variable consumption, use a conservative nominal value.
Known limitations
1. Nominal power is configured manually
The blueprint currently uses the configured power value rather than measuring each load’s actual consumption individually.
This is intentional because it makes the startup calculation predictable, but it means the configured value should be reasonably accurate.
2. Load state is determined from the switch entity
The blueprint assumes that:
switch = on
means the load is actually operating.
If the physical device can fail to start, disconnect, or operate at a substantially different power level, the controller cannot currently detect that independently.
3. Priority is static
Priority is determined by the order in which loads are configured.
There is currently no dynamic priority based on:
- electricity price
- time of day
- weather forecast
- expected PV production
- load runtime
- accumulated energy
- user-defined schedules
4. No minimum runtime per load
The startup delay prevents immediately starting the next load, but there is currently no independent minimum ON time for an individual load.
A load can therefore be stopped by the normal protection logic if its stop conditions are reached.
5. No maximum runtime / energy quota
The blueprint currently does not provide per-load limits such as:
Maximum runtime: 2 hours
Maximum daily energy: 5 kWh
Those could be useful for loads such as water heaters, EV charging, or pool pumps.
6. Sensor update frequency matters
The controller relies on the solar surplus/net-power sensor and battery SOC sensor.
If these sensors update slowly or have significant filtering/delay, the controller will naturally react more slowly.
This is particularly relevant for emergency shedding.
Future improvements
Some ideas for future versions:
-
Actual measured load power- Use individual power sensors instead of configured nominal values where available.
-
Minimum ON/OFF times
- Prevent short cycling of loads.
-
Daily energy quotas
- Limit individual loads to a configurable kWh/day.
-
Energy/runtime tracking- Track how long and how much energy each dump load has consumed.
-
PV forecast integration- Take expected solar production into account before starting large loads.
-
Dynamic electricity pricing- Adjust priorities based on grid import/export prices.
-
Time-of-day priorities- Allow different priorities during different periods.
-
Target battery SOC- More advanced control around a desired battery reserve.
-
Smarter load selection- Instead of strict priority, select the combination of loads that best matches the available surplus.
-
Hysteresis / anti-flapping- Separate start and stop thresholds to reduce rapid cycling around a power threshold.
Feedback
This blueprint was designed to be generic enough to work with many different solar installations and discretionary loads.
If you use it, I’d be interested in hearing what you’re controlling and what improvements would be useful.
Feedback, bug reports, and feature suggestions are welcome.
Enjoy your free solar power!