Problem statement
Someone with a dynamic electricity tariff wants the dishwasher to run during the cheapest hours tonight, and someone with a cold snap coming wants the bathroom warm before it arrives. Both are told the same thing: find a blueprint written for your specific price integration, or write a template that iterates over an attribute array and compares timestamps by hand. The data is already in their home, and acting on it is reserved for people who enjoy that work. Everyone else watches their home react to the past.
Home Assistant shows the history of everything and the future of almost nothing. Day-ahead prices, solar estimates and temperature predictions all arrive in their own shape, so any chart stops at "now" and every automation around them is rebuilt per integration. The cost lands hardest on energy optimisation, the highest-impact automation a home can run, and the same gap blocks pre-heating before a cold night, closing the awning before rain, and air-quality warnings.
Addressing this serves OpenHomeFoundation/goals#7 and OpenHomeFoundation/goals#2 by giving integrations one shape to publish forecasts in. It also advances our sustainability principle, which calls for tools to track, automate and reduce waste and emissions.
Community signals
Scope & Boundaries
In scope
- A generic forecast platform: an integration publishes a forecast for a numeric sensor it owns, in one standardised shape
- Rendering the forecast on the sensor's own more-info and history chart, with source attribution
- Target-first consumption, so a forecast is retrieved by pointing at the sensor rather than at its source
- Migrating the energy dashboard's hardcoded solar forecast onto the generic API
- A minimal/initial automation surface for the newly introduced forecast platform
- First-party providers only, one forecast per target sensor, one expected value per point
Not in scope
- User-added forecasts on arbitrary sensors (helper flow, "Add forecast" picker): follow-up, blocked on a provider/sensor matching-metadata design that must be made deliberately
- Multiple forecasts per target and primary-forecast selection: prerequisite of the above, not before it
- Further trigger and condition shapes (an offset before a predicted peak or crossing, trend deltas, gate-until-time, etc.)
- Uncertainty band rendering (the data model reserves quantiles, and the UI comes with them)
- Energy price graph in the energy dashboard
- Non-numeric forecasts (tariff schedules, binary predictions), forecast accuracy/history tracking, built-in ML forecasting, assistant intents
Foreseen solution
An integration provides a forecast for a sensor it owns as timestamped future values in that sensor's unit, held in memory rather than in state attributes or the recorder. Consumption is target-first: an action and a websocket API return the forecast for a given sensor, so casual flows never require knowing where the data comes from, while a specific forecast source stays directly addressable for custom cards, templates and advanced automations. The sensor's chart extends past "now" as a visually distinct line with its source named ("Provided by X"), so a resident sees a sensor with a future and can tell where that future came from.
The automation editor offers the shapes users already think in, without templates:
- Triggers
- When new forecast data is published (replan when day-ahead prices land)
- When the forecast first predicts a value above or below a threshold (frost tonight, price spike tomorrow)
- At the start of the lowest or highest-value window of a chosen duration (run the appliance during the best two-hour block)
- Conditions
- The forecast stays above or below X for the next duration
- The current time falls within the N lowest or highest-value hours
A forecast() template function keyed by the target sensor covers what the built-in shapes do not, including shareable blueprints.
The data model reserves extension points for quantiles and uncertainty, fact-versus-estimate firmness, and non-numeric value typing without implementing them. The first version's restrictions (first-party providers only, one forecast per sensor) are scoping chosen so that third-party providers and multiple forecasts need no breaking changes later.
Building it spans four surfaces: the forecast platform and its APIs in core, the chart overlay in the frontend, the trigger and condition shapes in the automation editor, and the energy dashboard's solar forecast migration. The technical design lives in the architecture proposal (WIP) at home-assistant/architecture#1360 and is not restated here.
Visualization mock from home-assistant/architecture#1357:
Risks & open questions
- Implementation model consensus: the underlying model is not yet settled in the core team. A decision on the architecture proposal is needed before implementation starts.
- Trigger behaviour on revising forecasts: predicted events can move or vanish between forecast revisions. The semantics need to be drafted in an architecture proposal and need to be designed so that triggers feel predictable rather than noisy.
- Automation editor framing: whether this is one forecast trigger with a shape selector or separate trigger types needs a product and design pass, solved once so it applies to everything with forecasted data.
- Frontend commitment: the chart overlay must ship in the same cycle as the platform, otherwise the feature is invisible plumbing.
- Trust: forecasts that visibly disagree with reality erode confidence. Source attribution is part of the first version, and the data model distinguishes published facts from estimates so the UI can too, even where that rendering comes later.
Appetite
Medium — 1-2 cycles. The first cycle covers the platform, target-first API, chart overlay with attribution, and the solar forecast migration. The automation surface (three trigger shapes, two conditions, template function) fits the first cycle if capacity allows and otherwise fills the second. Without it, forecasts remain template-locked or dashboard-only, which is the exact complaint in the community signals.
Execution issues
No response
Decision log
Problem statement
Someone with a dynamic electricity tariff wants the dishwasher to run during the cheapest hours tonight, and someone with a cold snap coming wants the bathroom warm before it arrives. Both are told the same thing: find a blueprint written for your specific price integration, or write a template that iterates over an attribute array and compares timestamps by hand. The data is already in their home, and acting on it is reserved for people who enjoy that work. Everyone else watches their home react to the past.
Home Assistant shows the history of everything and the future of almost nothing. Day-ahead prices, solar estimates and temperature predictions all arrive in their own shape, so any chart stops at "now" and every automation around them is rebuilt per integration. The cost lands hardest on energy optimisation, the highest-impact automation a home can run, and the same gap blocks pre-heating before a cold night, closing the awning before rain, and air-quality warnings.
Addressing this serves OpenHomeFoundation/goals#7 and OpenHomeFoundation/goals#2 by giving integrations one shape to publish forecasts in. It also advances our sustainability principle, which calls for tools to track, automate and reduce waste and emissions.
Community signals
Scope & Boundaries
In scope
Not in scope
Foreseen solution
An integration provides a forecast for a sensor it owns as timestamped future values in that sensor's unit, held in memory rather than in state attributes or the recorder. Consumption is target-first: an action and a websocket API return the forecast for a given sensor, so casual flows never require knowing where the data comes from, while a specific forecast source stays directly addressable for custom cards, templates and advanced automations. The sensor's chart extends past "now" as a visually distinct line with its source named ("Provided by X"), so a resident sees a sensor with a future and can tell where that future came from.
The automation editor offers the shapes users already think in, without templates:
A
forecast()template function keyed by the target sensor covers what the built-in shapes do not, including shareable blueprints.The data model reserves extension points for quantiles and uncertainty, fact-versus-estimate firmness, and non-numeric value typing without implementing them. The first version's restrictions (first-party providers only, one forecast per sensor) are scoping chosen so that third-party providers and multiple forecasts need no breaking changes later.
Building it spans four surfaces: the forecast platform and its APIs in core, the chart overlay in the frontend, the trigger and condition shapes in the automation editor, and the energy dashboard's solar forecast migration. The technical design lives in the architecture proposal (WIP) at home-assistant/architecture#1360 and is not restated here.
Visualization mock from home-assistant/architecture#1357:
Risks & open questions
Appetite
Medium — 1-2 cycles. The first cycle covers the platform, target-first API, chart overlay with attribution, and the solar forecast migration. The automation surface (three trigger shapes, two conditions, template function) fits the first cycle if capacity allows and otherwise fills the second. Without it, forecasts remain template-locked or dashboard-only, which is the exact complaint in the community signals.
Execution issues
No response
Decision log