Introduce forecast providers for sensor entities

[jpbede]

Context

Today, forecast-capable integrations in Home Assistant are fragmented:

• Each integration often exposes forecast data through its own custom action shape.
• Automations and scripts need integration-specific logic.
• The frontend has no unified way to retrieve and render forecasts for sensor values.
• Custom integrations often store long forecast arrays in state attributes, which is inefficient and hard to standardize.

This leads to duplicated logic, poor interoperability, and no consistent UX for forecasted values such as energy prices, energy production, energy usage, and similar time-based data.

A first proposal, #1357, suggested adding forecast support directly to SensorEntity. That solves the case where the entity's own integration also owns the forecast data. The architecture discussion raised another use case: a forecast provider may be able to forecast input data from an arbitrary existing entity. A sensor-owned API is too rigid for that case.

This proposal introduces forecast entities. A forecast entity represents one forecast for one target entity.

Proposal

Introduce a forecast component in core.

Integrations expose forecast data by creating forecast entities through a forecast.py platform.

A forecast entity is separate from the target entity, but it has exactly one target entity:

sensor.nord_pool_se3_current_price
forecast.nord_pool_se3_current_price

The forecast entity declares which entity it forecasts through a stable target reference. The forecast component resolves that reference through the entity registry and exposes the current target_entity_id.

For example, Nord Pool can create one forecast entity for each current-price sensor. The user does not need to configure a mapping before forecasts work.

Multiple forecast entities may target the same entity. This supports advanced cases where different integrations or models can forecast the same target sensor.

Example:

sensor.energy_usage
forecast.energy_usage_utility_model
forecast.energy_usage_weather_model

For model-based or machine-learning integrations, the integration creates one forecast entity for each target entity it predicts. The model's source entities, recorder queries, training data, and feature inputs remain internal to that integration. Core only needs to know which target entity the forecast applies to and how to retrieve the forecast values.

For the first version, the forecast component should compute a primary forecast entity for each target entity. The frontend can use the primary forecast in more-info and history views.

Primary selection is deterministic:

1. If one or more forecast entities for a target are owned by the same integration/config entry as the target entity, the first one added of those forecast entities is primary.
2. Otherwise, the first one forecast entity added targeting that target is primary.

This does not require a stored primary mapping in the first version. A future UI can allow users to choose a different primary forecast.

Forecast entity model

A forecast entity exposes:

• a stable target entity reference
• async_forecast()
• optional metadata such as source, model name, or forecast type

The target entity is the entity whose future value is being forecast.

Integrations must not build or store the target entity's entity_id as the durable relationship. Entity IDs can be changed by the user.

Integrations should only provide a ForecastTargetRef. The forecast component is responsible for resolving that reference to the current target entity registry entry and current entity_id.

For integration-owned targets, the forecast entity can link to the target by stable integration data:

ForecastTargetRef(
    domain="sensor",
    platform="nordpool",
    unique_id="SE3-current_price",
)

For user-selected or third-party targets, the integration can store the target entity registry entry ID selected during configuration:

ForecastTargetRegistryRef(
    registry_entry_id="abc123",
)

The forecast component resolves either reference type and exposes target_entity_id as a runtime property and state attribute. Integrations do not need to resolve the current entity ID themselves.

The target entity reference and device relationship should be handled like helper sensors such as the derivative helper.

For the first version, valid targets are numeric sensor entities.

Forecast values use the target entity's native meaning and unit. A forecast for sensor.nord_pool_se3_current_price returns future values in that sensor's native unit. If a provider cannot produce values compatible with the target entity, it should not create a forecast entity for that target.

Forecast entity state

The forecast entity state contains the timestamp when the provider last updated its cached forecast data.

The forecast payload must not be stored in the entity state or in state attributes. Forecast values are only exposed through forecast.get_forecasts and forecast/get_forecasts.

If no forecast has been loaded yet, the state is unknown.

If the provider cannot currently operate, the entity uses the normal Home Assistant unavailable availability model.

The state should not be the current forecast value, the next forecast value, or any other forecast datapoint.

Forecast entity state attributes

Forecast entity attributes should contain only small metadata needed to understand the relationship and status of the forecast entity.

Required attribute:

• target_entity_id: the current entity ID of the entity whose future value is forecast, resolved from the stable target reference

Optional attributes:

• forecast_type: a short provider-defined type, for example price, production, consumption, or demand
• forecast_source: a short provider-defined source or model name
• native_unit_of_measurement: the native unit used by forecast values, normally matching the target entity
• first_forecast_datetime: first datetime available in the current cached forecast, if known
• last_forecast_datetime: last datetime available in the current cached forecast, if known

The following must not be state attributes:

• full forecast arrays
• nested forecast point data
• historical source data
• recorder training data
• large model metadata

Frontend and automation consumers should use forecast.get_forecasts or forecast/get_forecasts to retrieve forecast data instead of reading forecast values from attributes.

Example state:

state: "2026-07-18T09:55:00+00:00"
attributes:
  target_entity_id: sensor.nord_pool_se3_current_price
  forecast_type: price
  forecast_source: nordpool
  native_unit_of_measurement: EUR/kWh
  first_forecast_datetime: "2026-07-18T10:00:00+00:00"
  last_forecast_datetime: "2026-07-19T23:00:00+00:00"

Target lifecycle

A forecast entity must link to its target through a stable registry reference, not by storing the target entity ID.

The forecast component owns target resolution and lifecycle handling for forecast entities.

If the target entity is renamed, the forecast entity continues to work and exposes the current resolved target_entity_id.

If the target entity is temporarily unavailable, the forecast entity follows the provider's normal availability. If the provider depends on the target entity's current state or history and cannot produce a forecast while that data is unavailable, the forecast entity should become unavailable. If the provider can still produce a forecast from its own upstream data, model inputs, or cached forecast data, the forecast entity may remain available. This rule is the same for integration-owned and third-party forecast entities.

The forecast component only needs to resolve and validate the target registry entry. It does not need to interpret the target entity's runtime state when deciding forecast availability.

If the target entity registry entry no longer exists, the forecast entity should become unavailable and should not return forecasts.

If the target entity is disabled by the user, the forecast entity should not appear as an active forecast for that target and discovery should not return it for normal UI use. The forecast entity should become unavailable until the target is enabled again, or until the forecast entity is reconfigured or removed. This rule is the same for integration-owned and third-party forecast entities.

If the forecast entity and target entity are created by the same config entry, unloading or removing that config entry unloads or removes both entities together.

If a third-party forecast integration targets an entity from another config entry, removing the target should leave the forecast entity unavailable until the user reconfigures or removes it.

Forecast retrieval should return no forecast for a forecast entity whose target registry entry is missing or disabled.

Discovery

Home Assistant can discover forecasts for a target entity by finding forecast entities whose target_entity_id matches the target.

Internally, discovery should compare the resolved target registry entry. The entity_id is the user-facing lookup value, not the durable relationship between a forecast entity and its target.

A websocket API can expose this:

forecast/get_forecast_entities

Request:

target:
  entity_id:
    - sensor.nord_pool_se3_current_price

Response:

sensor.nord_pool_se3_current_price:
  forecast_entity_ids:
    - entity_id: forecast.nord_pool_se3_current_price
       primary: true

For third-party forecasting integrations, the integration creates forecast entities for the targets selected during its own configuration flow.

Forecast retrieval

Forecast data is retrieved through a shared API:

• action: forecast.get_forecasts
• websocket: forecast/get_forecasts

The request can target either:

• target entities
• forecast entities

The request can also include an optional timeframe:

• start_datetime
• end_datetime

start_datetime and end_datetime can be specified independently. A request may include either bound, both bounds, or neither.

• If neither is provided, providers return their default forecast window.
• If only start_datetime is provided, providers return forecasts from that time onward, up to their default forecast end.
• If only end_datetime is provided, providers return forecasts up to that time, including the point needed to represent the value active at now.
• If both are provided, providers return forecasts for that window.

For step-series forecasts, a timeframe query should include enough context to interpret the value at start_datetime. If the value active at start_datetime started before the requested window, the response should include that preceding forecast point. This avoids forcing consumers to make a second request to understand the first interval.

The response should not return past datapoints other than the most recent point needed to represent the value active at the start of the returned window. If no start_datetime is provided, this means the most recent point needed to represent the value active at now.

Example targeting the sensor:

action: forecast.get_forecasts
target:
  entity_id:
    - sensor.nord_pool_se3_current_price
data:
  start_datetime: "2026-07-18T10:00:00+00:00"
  end_datetime: "2026-07-18T13:00:00+00:00"

Example response:

sensor.nord_pool_se3_current_price:
  forecasts:
    - entity_id: forecast.nord_pool_se3_current_price
       primary: true
       forecast:
         - datetime: "2026-07-18T10:00:00+00:00"
           value: 20.0
         - datetime: "2026-07-18T11:00:00+00:00"
           value: 25.0
         - datetime: "2026-07-18T12:00:00+00:00"
           value: null

Forecast data model

async_forecast() returns:

• list[ForecastPoint]
• or None

None means no forecast is currently available.

Each ForecastPoint contains:

• datetime
• value

The first version uses step-series semantics:

• a value applies from its datetime until the next forecast point
• value: null means the value is explicitly unknown from that timestamp until the next forecast point
• finite forecasts should end with a value: null point unless the provider has a valid reason for the final value to remain valid beyond the returned forecast window
• without a terminal value: null, consumers treat the final value as valid until the provider refreshes or replaces the forecast

This allows integrations to represent known end boundaries and gaps without overlapping intervals.

Example:

- datetime: "2026-01-01T23:45:00+00:00"
  value: 10.0
- datetime: "2026-01-02T00:00:00+00:00"
  value: null
- datetime: "2026-01-02T10:00:00+00:00"
  value: 20.0
- datetime: "2026-01-02T11:00:00+00:00"
  value: null

This means the value is 10.0 from 23:45 until 00:00, unknown from 00:00 until 10:00, 20.0 from 10:00 until 11:00, and unknown after 11:00.

Core should validate and normalize forecast output:

• datetimes must be timezone-aware
• datetimes are returned in a consistent serialized format
• points must be sorted by datetime
• duplicate datetimes are invalid
• numeric values must be finite
• null is allowed only to represent an explicitly unknown forecast value
• finite step-series forecasts should include a terminal null point to mark where the known forecast ends

Caching and state history

Forecast payloads should not be stored in state attributes and should not be recorded in history.

Forecast entities may cache the latest forecast in memory. The integration controls refresh timing, similar to the weather forecast model. Calling forecast.get_forecasts should not require every provider to perform a fresh external API call.

The forecast entity state and small metadata attributes may be recorded like normal entity state. This records forecast refresh timing and metadata changes, not forecast values or the full forecast payload.

Forecast entity states should not be included in long-term statistics in the first version. Statistics for forecasted values, forecast accuracy, forecast error, and forecast-vs-actual comparisons are separate future features and should not be implied by state_class.

Entity updates

Forecast entities update like regular Home Assistant entities.

An integration can update a forecast entity by using the same patterns it already uses for other entities:

• polling with async_update()
• push updates from an upstream API
• a DataUpdateCoordinator
• another integration-specific refresh mechanism

When the integration refreshes forecast data, it updates its in-memory forecast cache, sets the entity state to the forecast update timestamp, updates the small metadata attributes, and writes the entity state.

The forecast entity does not need to update when the current forecast interval changes unless the provider refreshed or replaced the cached forecast payload.

Calling forecast.get_forecasts reads from the provider's current forecast data. It should not be the primary mechanism that updates entity state. If a provider needs fresh data before it can answer, the integration may refresh its own cache, but the regular entity update path remains responsible for keeping state and attributes current.

This keeps forecast entities consistent with the rest of Home Assistant:

• availability is reported through the normal entity availability model
• state changes are written when the integration has new data
• attributes describe the current state, not the full dataset
• the action/websocket API returns the full forecast payload on demand

Consequences

This creates one shared forecast API for frontend, scripts, automations, and future dashboards.

The model supports both simple and advanced cases:

• integrations can expose forecasts for their own entities without user setup
• third-party forecast integrations can create forecast entities for selected target entities
• multiple forecast entities can target the same entity
• the frontend can discover forecasts by looking up forecast entities for a target

The model avoids a separate mapping store for the first version. The relationship between a forecast and its target is part of the forecast entity.

The initial target scope is intentionally narrow. Limiting the first version to numeric sensors keeps the schema and UI use cases clear while still covering immediate energy-price, energy-usage, energy-production, and similar integrations.

Implementation outline

1. Add a forecast component.

   The component owns forecast entity registration, target reference resolution, target validation, discovery indexing, target lifecycle handling, and the shared action/websocket API.

2. Add ForecastEntity.

   Forecast entities expose a stable target reference, expose a state containing the forecast update timestamp, expose small metadata attributes, and implement async_forecast(). The forecast component resolves target_entity_id from the target reference.

3. Add forecast discovery.

   Implement forecast/get_forecast_entities so the frontend can find forecast entities for a target entity. Discovery should not return forecast entities whose target registry entry is missing or disabled for normal UI use. The response should include the computed primary forecast entity ID.

4. Add forecast retrieval.

   Implement forecast.get_forecasts and forecast/get_forecasts, returning forecasts keyed by target entity and forecast entity. The request should support optional start_datetime and end_datetime filters. The response should mark which forecast entity is primary for each target.

5. Add forecast validation and normalization.

   Validate datetimes, sorting, duplicate points, numeric values, and explicit unknown values.

6. Add frontend support.

   The frontend can automatically use the computed primary forecast entity for the target entity's more-info/history view.

7. Add an initial integration.

   Start with an integration-owned forecast entity such as Nord Pool to prove target linkage, state updates, caching, step-series semantics, and the frontend path.

8. Cover target lifecycle behavior.

   Add tests for renamed targets, target device association changes, provider-dependent and provider-independent temporarily unavailable targets, disabled targets, removed target registry entries, same-config-entry unload, and third-party target removal.

Out of scope for the first version

• automation triggers based on forecast windows
• non-numeric forecast targets
• forecasts for arbitrary domains outside sensor
• long-term statistics for forecast entities
• forecast accuracy, forecast error, and forecast-vs-actual comparison statistics
• confidence bands, quantiles, min/max values, and probabilistic forecasts
• combining multiple forecast entities into one derived forecast
• user selection of a custom primary forecast when multiple forecast entities target the same entity
• a full UI for managing multiple forecast entities per target

These are valid future use cases, but the first version should establish the forecast entity model, target linkage, state model, retrieval API, caching behavior, and forecast time semantics first.

Integrations that benefit

Immediate candidates:

• nordpool
• amberelectric
• energyzero
• easyenergy
• tibber
• pvpc_hourly_pricing

History

2026-07-21: Revised draft to be more precise and make the forecast a regular entity with a 1:1 relationship to the target entity
2026-07-21: add null termination, make primary forecast entity predictable
2026-07-21: Be more precise on the start_datetime and end_datetime filter

[MartinHjelmare]

We've discussed this proposal in the Architecture meeting.

We have these questions:

1. Should the forecast providers be entities?
2. How are the forecast providers and input data typed, so we can match input data and forecast providers? You mention async_supports_entity. Please explain more how that will work.
3. Should users configure forecasts or should we suggest forecasts based on setup integrations, together with a forecast typing system?

[jpbede]

Yes this works as well. I like this, as you said we wouldn't need to relabel all entities

[gjohansson-ST]

nordpool sensors doesn't have a device class (just to have it mentioned) that would be used (current_price)

Since integration developers anyhow needs to implement "something" to make this work (return something proper), why not use supported features as we normally do which is also used by frontend to understand there is a forecast service it can use?

If we take another possible forecast, maybe train departures, would the resulting list/dict not be the same? (maybe a bit wording but I assume value would then be some status for that particular times departure).
Or do we see forecasts that would not match and we need to differentiate?

[MartinHjelmare]

Supported features are to mark what service action features an entity supports. Here we are talking about how to identify the kind of measurement data that is represented by the entities that will be used as input to the forecast providers.

[gjohansson-ST]

Fair enough, my point was more to say that if we would use device class it's not sufficient in itself only to tell a forecast provider if data is available and what kind of data.

[MartinHjelmare]

Yeah, both sides need to have a way for data typing. The input entity needs to type its data and the forecast provider needs to type what data it can process. The benefit of using device class on the input data side is that we already have that done for a lot of input data. We'd still need to type the forecast providers so that we can match input data and forecast provider.

[rrooggiieerr]

As part of Month of "What the heck?!" 2024 I added a similar request WTH Forecasting, not only weather but also dynamic energy prices, traffic, etc

I just wanted to add to this discussion that there should also be automation triggers, like Electricity Price below X for the next 2 hours, When precipitation is 0 for the next 30 minutes and alike

[Markus98]

This is a feature I am also really hoping to see implemented soon.

However, I have some thoughts about the implementation laid out in this proposal.

1. Making mapping a mandatory step for users

First of all, I think making the mapping step mandatory for the user is a bad idea. Integrations like nordpool should definitely come with the forecast enabled and mapped out of the box. Having the ability to add forecasts for supported entities is definitely a feature we should have, but I would argue that for most users the main exposure to this feature would be from the forecast entities provided by default.

2. Ability to provide non-continuous forecasts

This proposal suggests that the forecasts are supplied as single datapoints which contain a timestamp and a value. This model might work, but I would suggest that we should support passing some sort of unknown or null value as a datapoint. For example, if we think about the electricity pricing information, we know what the price will be for each 15-minute slot. The information that the prices are in 15-minute slots does not carry over in the current data model and needs external context. Without knowing the context, the last datapoint in the forecast would just mean that the last available price continues into the future indefinitely.

Se we should support unknown or something else similar to signify that we do not know what the value is after some timestamp:

"2026-01-01T23:45:00": 10.0
"2026-01-02T00:00:00": "unknown"

This example would mean that between 23:45-00:00 the price is 10.0, but from 00:00 on the price is unknown.

With this we can also represent gaps in the forecast:

"2026-01-01T23:45:00": 10.0
"2026-01-02T00:00:00": "unknown"
"2026-01-02T10:00:00": 20.0

In this one the price is unknown between 00:00-10:00, but is known to be 20.0 from 10:00 onwards. Most likely most forecasts would always end the forecast series with the unknown datapoint so that the forecast does not continue indefinitely.

3. Forecast caching / state

This proposal does not really touch on how the forecast state and caching is handled. I suspect that we do not want to record the whole forecast into history every time it is updated like state attributes are now. This would be too expensive to do on all forecast entities and would be of dubious value anyways.

I would argue that we should have the most recent forecast stored as a state or state attributes of some sort. This would then let use forecasts in the UI without having to worry about how fetching the forecast each time could have external effects. I assume that in this proposal each forecast integration decides whether they fetch they return cached values or fetch / calculate new ones every time. I think we should have a similar approach as we do with other entities where the integration can decide how often the forecast entity is updated and the results are then stored/cached in memory in a standard way.

4. relationship between sensor and forecast entity(ies)

I am imagining from an UX perspective that when we open an entity more info panel in the UI, we should be able to see the history and the forecast in the same view. With this proposal we could have several forecast entities per sensor, which is good so we can support multiple different forecast models for example. However, it does introduce a UX question of how would we display the forecast with the main entity history.

Maybe the solution is to show the history + forecast in the forecast entity only? Or maybe we should be able to pick the main forecast entity for a target entity? I do not know and this is probably outside the scope of this proposal. Still good to think about the implications.

5. Uncertainty for values

Forecasts can be and often are non deterministic. We should not implement the feature in a way that prevents us from implementing this in the future.

For example we could have quantiles or something similar to represent the forecast confidence for certain bands of values instead of just offering a single point value.

6. How forecasts should be interpreted

The easiest way to deal with forecasts is to assume that they are just step functions. It would be possible to interpret forecasts as interpolated values between points, which would then allow us to ask for forecasts for very specific points in time. This might be nice, but I would argue that step functions are good enough if we just make sure that the forecasts have enough datapoints.

[gjohansson-ST]

I think we should try to do this in a quite simple form, or it might be a bit too much as the number of use-cases are endless.

I think we should do the following (at least initially) with the inspiration from what we did in WeatherEntity:

• We add forecasting to Entity as a service (then it can be used by any sub component essentially (not only limiting ourselves to SensorEntity
• It should return future values for the same unit of measurement, device class etc. which the target entity represents (which is used for the service)
  • As example for Nord Pool, the sensor.current_price sensor having this forecast service, would return a json according to this structure: [{"datetime": "2026-07-18T10:00:00+00:00", "value": 20.0}, {"datetime": "2026-07-19T10:00:00+00:00", "value": 25.0}]
• Similar to what we did for weather, we expose this to frontend so it can present it in more-info or whatever other place we want to expose history (statistics) and/or future (service).
• I do not think we need to end the forecast with an unknown or anything as such, similar to weather, the forecast stops when it stops (which I guess has to be reasonable but controlled by the integrations, could enfore some rules)
• Storage would be in memory and also to handle caching (again, see WeatherEntity for inspiration)
• Alternatively the json could also return the information such as UoM etc. but I don't see that needed as it's already available by the target entity

Example:

action: sensor.get_forecasts
target:
  entity_id:
    - sensor.nordpool_sensor
    - sensor.my_price_sensor

sensor.nordpool_sensor:
  forecast:
    - datetime: "2026-07-18T10:00:00+00:00"
      value: 20.0
    - datetime: "2026-07-19T10:00:00+00:00"
      value: 25.0
sensor.my_price_sensor:
  forecast:
    - datetime: "2026-07-18T10:00:00+00:00"
      value: 30.0
    - datetime: "2026-07-19T10:00:00+00:00"
      value: 35.0

[jpbede]

Something similar I proposed in #1357

[gjohansson-ST]

Very similar indeed, should maybe have read that before I made almost the same proposal here 🤣

I think the main distinction between the proposals are that a new forecast component would make it much more obvious to support n:1 scenarios. A current price for your electricity could have multiple future forecasts for what the price is going to be next month. But somehow I'm doubting the usefulness of something like that.

Another comment I want to make is that again using Nord Pool current price sensor as example, it has no device class and the UoM is [currency]/kWh so depending on how the user has configured it, it's a different UoM. and given it has no device class there's no conversion in place. That would make it very tricky for other integrations to be able to provide a forecast for it (if such would exist) out of box working. I think that would have to limit it to when device class matches and the UoM can be converted (or it needs to be provided in the same integration so it's controlled together).

If we go down the path of the new forecast component, I think we need to let integrations be able to specifically say this forecast entity is for this sensor entity. But we probably need an option for the user to allow overwriting it.
Example; for Nord Pool the forecast entity directly belongs to the sensor entity on creation, but the user can open entity options on the sensor entity to add/change (it would then overwrite the default provided forecast entities).

If we use examples of electricity usage (or production) it becomes more obvious that one maybe want to use more than one forecasts and even possibly be able to combine them --> That likely would result better with a new component which could be used as well in the energy dashboard presenting future expected use (or production).

[rrooggiieerr]

Some thoughts I have, in no particular order,

Having a forecast attribute seems more sensible to me than a Forecast Entity. If the forecast attribute is missing for an Entity the Entity doesn't support forecast. An additional SensorEntityFeature.FORECAST would be smart, since some sensors might already have implemented a forecast attribute that doesn't support the agreed format.

Having a ForecastEntity seems a bit like over complicating things. I can't think of a real world use case where this would be handy.

The forecast value should be of the same type as the sensor, I don't think a forecast would have any added value if that's not the case. Conversion from ºC to º F should also be done on the forecast attribute.

Imho, a forecast doesn't need to be only numerical, a weather sensor could be Light Drizzle, Sunny etc.., a playlist could forecast which numbers are next in queue.

A Template Sensor should apply the same template to the forecast attribute values. Users could then create Template Sensor for the Nord Pool integration and calculate added taxes, and the forecast attribute of this Template Sensor would include the added taxes.

A forecast value could have a single timestamp for a single pont in time, values between 2 timestamps would then be calculated, this could work for weather forecast. Or a forecast could have a start and end time where the value is fixed between those times, This should work for NordPool prices where the price is fixed over the whole time slot.

It would be nice is a forecast could have a min and max value, for instance a Precipitation sensor which has the min, max and expected precipitation.

[Markus98]

I do not think we need to end the forecast with an unknown or anything as such, similar to weather, the forecast stops when it stops (which I guess has to be reasonable but controlled by the integrations, could enfore some rules)

The reason I suggested this is that we get the same functionality as specifying start_time and end_time for values, but without the risk of creating overlapping time intervals accidentally.

Couple of things we need value-time intervals in forecasts for:

• get_forecast_value(timestamp): what does this output when we ask for the value after the last forecast timestamp? Do we just drop the values immediately after the last timestamp, or continue the last forecast value indefinitely? With the intervals we can return unknown when the value is genuinely unknown.
• Generic cost cost optimization algorithms. The intervals for forecasts are not constant across integrations. If we do not have a standard interface for getting the values for the intervals, the algorithm implementations need to adapt to each forecast provider, which is not ideal.

Similar to what we did for weather, we expose this to frontend so it can present it in more-info or whatever other place we want to expose history (statistics) and/or future (service).

I think first party support for UI representation will be one of the most important aspects of this feature. Whatever approach we take, we should make it as usable as possible for as many users as possible, regardless of skill level.

Having a forecast attribute seems more sensible to me than a Forecast Entity. If the forecast attribute is missing for an Entity the Entity doesn't support forecast. An additional SensorEntityFeature.FORECAST would be smart, since some sensors might already have implemented a forecast attribute that doesn't support the agreed format.

Using state attributes for forecasts was a pattern that was moved away from in the weather integration, so I don't think this will be how this will get implemented. If the forecast entity idea is implemented transparently, then it should offer a similarly simple UX as attributes while unlocking many more possibilities like different kinds of forecasting integrations that could be applied to existing entities.

[jpbede]

Updated the proposal. A forecast is now represented as a regular entity with a 1:1 relationship to a target entity. Each forecast entity predicts a single target entity. For example, with Nordpool, there would be one forecast entity for the current price sensor. For future ML forecasting integrations, there could be multiple forecast entities for the same target, each representing a different ML model.

Since the integration knows the relationship between the forecast and its target entity (due to setting up and specifying a source entity to learn from or so), it provides this mapping automatically.

[gjohansson-ST]

A few small additional comments

• For user selected targeting I guess we should use entity_id instead so it can easily be used for YAML. Thinking about a future yaml based trigger template. We have helpers for updating the entity_id if needed for other purposes.
• Since we say we should have caching for the forecasts, I guess they must be finite. Should we define some limit to it?
• Should the forecast entity not also have the device class from it's target sensor?

I'd be happy with this and get it into nordpool, other questions I have is more technical and belong to a future PR

[Markus98]

This is now being actively discussed within the core team. We first need to settle the debate between this forecast entity model and other alternatives like a forecast registry. If we conclude that the entity model is the way to go, I'll update here.

[lboue]

I think Matter is an interesting reference here, especially the Device Energy Management cluster.

Matter's "forecast" is not always just a datetime → value prediction. It can also describe a future schedule, with slots and constraints such as earliest/latest start time, min/max power, or whether the operation is pausable.

             Forecast
                │
       ┌────────┴────────┐
       │                 │
  Prediction          Schedule
       │                 │
  PV / price /       EV / HVAC /
  weather / ML       appliances

I don't think HA should reproduce the Matter model, but I'd be careful not to make ForecastPoint(datetime, value) the fundamental abstraction.
The current #1360 proposal seems like a good numeric prediction implementation. I'd just keep the API extensible enough that other kinds of forecasts/schedules could be represented later.

This would also make the Matter integration a natural future consumer/provider of the same Forecast API.

[MartinHjelmare]

A forecast isn't the same as a schedule. If we try to squeeze other features into the same box built for a specific feature, the result is rarely good.