Allow sensors to report forecast data

[jpbede]

Problem / Need

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

1. Each integration often exposes forecast data through its own custom service shape.
2. Automations and scripts must implement integration-specific logic.
3. The frontend has no unified way to retrieve and render sensor forecasts.
4. Custom integrations often stuff long forecast arrays into state attributes, which is inefficient and hard to standardize.

This leads to duplicated logic, poor interoperability, and no consistent UX for forecasted sensor values (for example energy-price curves).

Goals

1. Provide one core forecast contract for sensor entities.
2. Make forecast retrieval feature-gated and discoverable.
3. Keep forecast data out of state attributes and fetch on demand.
4. Enable frontend and automations to consume forecasts consistently.

Architecture

Use a sensor-domain native forecast API, aligned with existing Home Assistant entity-service patterns.

Sensor capability model

1. Add SensorEntityFeature.FORECAST.
2. Add optional async_forecast() on SensorEntity.
3. Return list[SensorForecast] | None where each point has:

• datetime (ISO datetime or datetime object)
• value (finite numeric, native UoM of the sensor)

Unified entity action

Add sensor.get_forecasts as entity service:

1. supports_response=SupportsResponse.ONLY
2. gated by required_features=[SensorEntityFeature.FORECAST]
3. response shape per entity:

• { "<entity_id>": { "forecast": [ ...points... ] } }

Validation and normalization

Core validates and normalizes integration output:

1. Datetime must parse and be timezone-aware.
2. value must be finite numeric.
3. Datetimes normalized to UTC ISO-8601.
4. None forecast becomes [].
5. Unsupported entities fail via standard service validation/feature gating.

Implementation Plan

Core (sensor domain)

1. Add SensorEntityFeature with initial FORECAST feature flag.
2. Add SensorForecast typed contract.
3. Add SensorEntity.async_forecast() defaulting to None.
4. Register sensor.get_forecasts in sensor component setup.
5. Implement conversion helper in sensor domain to enforce schema and normalization.
6. Add services.yaml, strings.json, and icons.json metadata entries.
7. Add tests

Frontend integration

1. Add sensor forecast client API in frontend data layer (sensor.get_forecasts).
2. Update sensor more-info history path to load forecast for forecast-capable sensors.
3. Overlay forecast points in chart as a dotted/dashed line.
4. Extend chart time range to include future forecast points.
5. Keep historical line semantics intact (solid line for history, e.g. dashed for forecast)

Integrations That Benefit

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

[MartinHjelmare]

We've discussed this proposal in the architecture meeting.

This proposal considers the application where the forecast always comes from the same provider as the data. There is another potential application where there are forecast providers that can forecast on input data from an arbitrary data provider.

The conclusion from the meeting is that although this proposal looks very solid and solves the first application in a nice way, there is worry that this proposal is too rigid considering the second application. We need to get back to this topic.

[jpbede]

For reference, I proposed a new approach which should cover this case: #1360

[Markus98]

Closing this one since the forecast conversation has moved onto a newer architecture proposal: #1360