Home Assistant integration that prevents main power meter trips by automatically managing electrical loads based on power consumption.
When the total power consumption exceeds a configured threshold, the integration turns off loads in reverse priority order (from least important to most important), one at a time, until power usage drops back within the limit.
Once consumption stays below the threshold for a sufficient amount of time, the loads are automatically reactivated in direct priority order, ensuring that each reactivation won't trigger another overload.
| Mode | Threshold | Delay |
|---|---|---|
| Immediate | Immediate threshold (e.g., 3300 W) | Configurable in seconds |
| Delayed | Delayed threshold (e.g., 3000 W) | Configurable in minutes |
- Home Assistant 2023.6 or higher
- Devices with a controllable switch (e.g., Shelly 1PM, Shelly Plug S)
- Power sensors for the managed loads (W)
- Optional: Main grid/system power sensor (e.g., Shelly EM)
- In HACS, go to Integrations → ⋮ → Custom repositories
- Add
https://github.com/andbad/HA_PowerControlwith the category Integration - Search for "Power Control" and click install
- Restart Home Assistant
Copy the custom_components/power_control/ folder into the custom_components/ directory of your HA installation, then restart.
- Go to Settings → Devices & services → Add Integration
- Search for Power Control
- Follow the three-step setup wizard:
| Field | Description | Default |
|---|---|---|
| Instance name | Display name in HA | Power Control |
| Main power sensor | entity_id of the main total sensor (optional) | — |
| Immediate threshold | W above which loads are shed immediately | 3000 W |
| Delayed threshold | W above which loads are shed after N minutes | 2700 W |
| Immediate shedding delay | Seconds spent above threshold | 30 s |
| Delayed shedding delay | Minutes spent above threshold | 10 min |
| Wait time between sheddings | Seconds between turning off one load and the next | 10 s |
| Wait time between reactivations | Minutes between turning on one load and the next | 5 min |
| Wait time before reactivating | Minutes below threshold before starting reactivations | 5 min |
| Notification service | e.g., notify.mobile_app_phone (optional) | — |
Note: The immediate threshold must be greater than the delayed threshold.
Choose how many loads to manage (1–20). Loads are sorted by priority: Load 1 is the most important and will be the last one to be turned off.
| Field | Description |
|---|---|
| Name | Label displayed in notifications and HA |
| Power sensor | entity_id of the sensor (e.g., sensor.washing_machine_power) |
| Switch | entity_id of the switch (e.g., switch.shelly_washing_machine) |
| Auto reactivation | If disabled, the load will never be turned back on automatically |
| Min off time | Minimum seconds the load must stay off before it can be auto-restarted (0 = disabled) |
| Field | Description | Default |
|---|---|---|
| Create dashboard | Generate the Lovelace dashboard | on |
| Dashboard language | Language for labels and texts | auto-detected |
| Take control of the dashboard | If enabled, the dashboard will not be overwritten on upgrades (see below) | off |
During the installation process, the integration detects whether the previous YAML package is installed. If so, it asks if you want to import the configuration (thresholds, delays, sensors, switches, etc.). At the end of the process, it also disables the old package to avoid conflicts with the new integration. The YAML file and dashboard must be deleted manually.
All entities are grouped under a single Power Control device.
| Entity | Description |
|---|---|
sensor.power_control_current_power | Real-time measured power (W) |
sensor.power_control_suspended_power | Total power of suspended loads (W) |
sensor.power_control_immediate_threshold | Effective immediate threshold (W) — reflects runtime overrides |
sensor.power_control_delayed_threshold | Effective delayed threshold (W) — reflects runtime overrides |
sensor.power_control_<name>_suspended_power | Suspended power for each individual load (W) |
Per-load sensors also expose the following attributes:
current_power_w— instantaneous measured powerswitch_state— switch state (on/off/unavailable)auto_restart— automatic reactivation enabledkeep_off— load blocked by anti-flap or manuallyis_suspended— load currently suspendedmin_off_sec— configured per-load cooldown in seconds
The icon of each per-load sensor reflects its status at a glance:
- 🔌
mdi:power-plug— active (drawing power) - 🔌
mdi:power-plug-off— suspended (shed by the coordinator) - 🚫
mdi:cancel— blocked (keep_off = True, will not auto-restart) - 🔌
mdi:power-plug-outline— switch unavailable or not configured
| Entity | Description |
|---|---|
switch.power_control_active | Enables/disables the entire system. State persists across HA restarts. |
| Entity | Visible when | Description |
|---|---|---|
button.power_control_regenerate_dashboard | Dashboard user-controlled mode | Triggers the dashboard regeneration confirmation flow |
| Service | Parameters | Description |
|---|---|---|
power_control.enable | — | Enables load control |
power_control.disable | — | Disables control and resets all suspended powers |
power_control.reset_load | load_index (0–19) | Removes a load from the suspended list |
power_control.force_stop_load | load_index (0–19) | Immediately sheds a specific load |
power_control.force_start_load | load_index (0–19) | Immediate reactivation, ignoring timers and cooldowns |
power_control.move_load | load_index (0–19), direction (up/down) | Changes a load's priority position and rebuilds the dashboard |
power_control.set_thresholds | immediate_threshold, delayed_threshold | Runtime threshold override (see below) |
power_control.regenerate_dashboard | — | Immediately regenerates the dashboard (bypasses confirmation) |
The load_index corresponds to the position of the load in the wizard (0 = first position = highest priority). You can also find it as a load_index attribute on the load sensor.
The power_control.set_thresholds service lets you override the intervention thresholds at runtime without changing the persistent configuration. This is useful when you want to adapt thresholds dynamically based on the active power source (grid, solar, solar EPS mode, time of day, etc.).
Fields
| Field | Required | Description |
|---|---|---|
immediate_threshold | no | Immediate shedding threshold in Watts |
delayed_threshold | no | Delayed shedding threshold in Watts |
Both fields are optional. Omit one to leave that threshold unchanged. Call the service with no fields to reset both thresholds to the values set in the configuration.
Note: overrides are stored in memory only. They are lost when Home Assistant restarts.
Important —
global_power_sensormust measure total house consumption. Source-switching profiles only work correctly ifglobal_power_sensorreflects the total power drawn by the house, not just grid import/export.A common pitfall with solar/battery systems: if your meter is clamped on the grid connection point (POD) — for example a Shelly EM installed before the inverter's backup output — it will read ~0 W during a grid outage, because no power is flowing to or from the grid. Power Control will see 0 W load and never shed anything, even if the inverter's EPS/backup output is overloaded. The
set_thresholdsoverride for your backup profile is applied correctly, but the coordinator has nothing to react to.Fix: point
global_power_sensorat a meter downstream of where solar, battery, and grid combine — one that measures what the house actually consumes regardless of source. If no such sensor is available, the built-in virtual sensor (sum of per-load power sensors) is a reliable fallback for EPS/backup scenarios.
Example — switch to solar profile:
service: power_control.set_thresholdsdata:
immediate_threshold: 5000delayed_threshold: 4500Example — reset to configured values:
service: power_control.set_thresholdsdata: {}Example — full automation based on power source:
automation:
- alias: "PowerControl — adapt thresholds to power source"trigger:
- platform: stateentity_id: sensor.power_sourceaction:
- choose:
- conditions:
- condition: stateentity_id: sensor.power_sourcestate: "solar"sequence:
- service: power_control.set_thresholdsdata:
immediate_threshold: 5000delayed_threshold: 4500
- conditions:
- condition: stateentity_id: sensor.power_sourcestate: "solar_eps"sequence:
- service: power_control.set_thresholdsdata:
immediate_threshold: 2000delayed_threshold: 1800default:
- service: power_control.set_thresholdsdata: {}If a load is shed more than 5 times within a 10-minute rolling window, it is automatically blocked (keep_off = True) to prevent rapid on/off cycling. The load will no longer be auto-restarted; it can be re-enabled manually via force_start_load or by toggling the master switch off and on.
The shed counter resets automatically when:
- The load is restarted manually (watchdog detection)
force_start_loadis called on that load- The master switch is toggled off/on
Each load can be configured with a minimum off time before the coordinator attempts to restore it. For example, setting min_off_sec = 120 on a washing machine prevents it from being restarted within 2 minutes of being shed, giving the appliance time to properly power down.
Set to 0 (default) to disable the cooldown.
The integration fires Home Assistant bus events that can be used in your own automations:
| Event | Fired when | Data |
|---|---|---|
power_control_load_shed | A load is turned off (automatic or via force_stop_load) | load_name, load_index, switch, suspended_power_w |
power_control_load_restored | A load is turned on (automatic or via force_start_load) | load_name, load_index, switch, restored_power_w |
Example — send a notification when a load is shed:
automation:
- alias: "Notify on load shed"trigger:
- platform: eventevent_type: power_control_load_shedaction:
- service: notify.mobile_app_phonedata:
message: "{{ trigger.event.data.load_name }} turned off ({{ trigger.event.data.suspended_power_w }} W)"The Lovelace dashboard is automatically created at the end of the configuration wizard if the "Create dashboard" option is enabled. No manual file importing is required.
The dashboard includes:
- Main load gauge with color coding (green/yellow/red)
- Real-time status of current and suspended power
- 1-hour power history graph (current + thresholds)
- Load shed history — 3-hour history graph showing suspended power per load (highlights exactly when each load was shed and restored)
- Configuration card showing effective thresholds and timing parameters (reflects runtime overrides from
set_thresholds) - Timer card showing internal coordinator timers
- Individual cards for each configured load with power sensor, suspension state, and icon badge
The dashboard is accessible in the sidebar as Power Control and is automatically removed when the integration is deleted.
By default the dashboard is automatically regenerated on every integration upgrade, so it always reflects the latest layout and features.
If you want to customise the dashboard (add cards, change layout, modify styles) without having your changes overwritten on the next upgrade, enable "Take control of the dashboard" in the setup wizard.
How it works:
- On first install the dashboard is generated normally.
- On subsequent upgrades, if a newer dashboard version is available, a persistent notification appears in HA instead of overwriting the dashboard:
"A new version of the Power Control dashboard is available. Regenerating will overwrite all your customisations. Do you want to proceed?"
- Update dashboard — regenerates the dashboard with the latest layout (your customisations will be lost).
- Skip — dismisses the notification; it will not reappear until the next integration upgrade.
- A button entity (
button.power_control_regenerate_dashboard) is also available in the dashboard and in the device page. Pressing it shows the same confirmation notification before proceeding. - To bypass the confirmation and regenerate directly from an automation, call
power_control.regenerate_dashboard.
Note: switching user-controlled mode off and then back on requires a re-configure flow (Settings → Devices & services → Power Control → Configure).
With Main Sensor (recommended): Configure the entity_id of a sensor that measures the entire power consumption of the system (e.g., Shelly EM). The integration will use this value directly.
Without Main Sensor: The system sums up the power consumption of the individual configured loads. This works, but it cannot account for unmonitored appliances — use conservative thresholds in this case.
- The master switch state (
active/inactive) is restored. - Suspended powers are restored by reading the last state of the sensor entities.
- If a load was suspended before the restart, it remains in the queue waiting for reactivation.
Based on the original YAML package HA_PowerControl by andbad, developed with the support of the InDomus community.