Blueprint for Winter Credits

Home-Assistant Blueprint

A Home-Assistant blueprint that handles the Winter Credits (DCPC) schedule: fixed-time anchors and peaks, calendar-driven pre-heating for critical peaks, and a separate set of actions for regular peaks. It can be installed directly with this button:

The blueprint source is available here. To import it manually, go to Settings > Automations & scenes > Blueprints > Import blueprint and paste that URL.

How it works

The blueprint is a single automation in parallel mode (with max_exceeded: silent) that combines two kinds of triggers:

Two global conditions apply to every trigger:

• the current month must be December, or January through March, so the automation never runs outside the Winter Credits season
• calendar triggers must have an event whose summary contains pointe and whose description contains Tarif: DCPC

Critical or regular?

At every execution the blueprint reads the calendar for the current day with calendar.get_events and decides whether a critical peak exists:

- action: calendar.get_events
  target:
    entity_id: !input hydroqc_calendar
  data:
    start_date_time: "{{ now().replace(hour=0, minute=0, second=0, microsecond=0).isoformat() }}"
    end_date_time: "{{ now().replace(hour=23, minute=59, second=59, microsecond=0).isoformat() }}"
  response_variable: calendar_events

A morning peak counts as critical when an event of the day has a pointe summary, Tarif: DCPC in its description and a start time at 06:00. The evening peak is detected the same way at 16:00. This is why the automation works with time triggers alone: at 01:00, 04:00, 06:00, 10:00, 12:00, 14:00, 16:00 and 20:00 it re-reads the calendar instead of relying on a helper.

Each anchor and peak branch then picks the critical actions when a critical peak exists that day, and the regular actions otherwise. Pre-heating is driven by the calendar triggers only, so it never runs for a regular peak.

Pre-heat offsets

The two calendar triggers share the same event and are told apart by the event start hour: before 12:00 the morning pre-heat action runs, at 12:00 or later the evening one. Both offsets default to -01:45:00.

The anchor end actions fire at 04:00 and 14:00. If you set a pre-heat offset of -02:00:00 or more (for example -02:30:00), the pre-heat starts before or at the same time as the anchor end action, so plan both actions accordingly.

Prerequisites

1. Create a local calendar

1. Go to Settings > Devices & Services > Integrations
2. Click Add Integration
3. Search for “Local Calendar”
4. Create a new calendar with a name like “HydroQC Peaks” or “Winter Credits”
5. Note the calendar’s entity_id (e.g., calendar.hydroqc_peaks)

Use a dedicated calendar only for HydroQC peak events to avoid conflicts with personal events.

2. Configure the HydroQC integration

When configuring the Hydro-Québec integration, select the calendar entity you created. The integration automatically syncs critical peak events to this calendar. For DPC (Flex D) and DCPC (Winter Credits) rates, the calendar is required.

Inputs

The critical actions are enabled by default, including their notifications. Two optional collapsed sections hold the rest:

To use a disabled action, remove the enabled: false line from its sequence or replace the sequence entirely.

Peak events written by the integration

For every upcoming critical peak, the integration creates one event in the configured calendar:

• Summary: an icon followed by Pointe critique
• Location: Hydro-Québec DCPC
• Description:

Réduisez votre consommation d'électricité pendant cette période.

Début: 06:00
Fin: 10:00

--- Métadonnées ---
Ajouté le: 2026-01-15 08:12:34 EST
Tarif: DCPC
Critique: Oui
ID: hydroqc_123456789_2026-01-16T06:00:00-05:00

The Tarif metadata line is what the blueprint filters on, and the start time (06:00 or 16:00) is what marks the day as a critical peak day. Regular peaks are not added to the calendar, and events created manually with the hydroqc.create_peak_event service use the same format.

Testing calendar automations

Recommendations

• Wrap your actions in parallel: rather than a plain sequence. A failing action then does not prevent the following ones from running.
• Keep the random 30 seconds to 5 minutes delay in the end action, and spread similar delays between your own restart actions. Without it, thousands of devices restart at the same second and create a new demand peak.
• Enable the anchor actions only if you want to act on the reference consumption periods. They are optional and disabled by default.
• For complex logic, use the blueprint only as a trigger (a time trigger or a separate automation) instead of adding many conditions to it. It stays easier to maintain and debug.