HA has a solid way to store historic sensor data, using the recorder and long term statistics, but what about forecasting sensor data? I think it would be a great addition if there would be a standardised way to handle forecast throughout all of HA. Think about the UI showing graphs with forecasted energy prices, automations that can anticipate on forecasted precipitation.
This standardised way could be an addition to the API which integrations could implement if applicable.
This forecasting data should be accessible on the dashboard and in automations. For instance a graph with the energy prices for the upcoming hours could be shown or an automation could close the awning 5 minutes before it starts to rain.
I am aware some integrations already implement some kind of forecasting, like the weather platform which has the weather.get_forecasts action, the sun integration which has various solar related forecasts as separate sensors available and the Nord Pool integration which has the dynamic energy prices for the day stored in a state attribute.
This already sums up 3 different ways forecasts are currently implemented, using an action, separate sensors or as state attribute and maybe different other approaches are also in use that I havenāt seen.
This entry for WTH is to provide integrations a standardised way to deal with forecasts
There are too many factors to make a general forecast routine.
Energy prices depends on the market and the way the year is developing which can change a lot for year to year. There are probably better sources on the internet for such predictions.
Precipitation is depending on the weather, but it can slide a lot back and furth on the calendar. Forecast from weather services are better, because they have more historical data and also have access to satelite and radar images to especially improve the forecast for the next couple days.
There are nearly always better sources for forecasts than HA, because good forecasts require good historical data and many current measuring points. Something a single HA user or installation will never achieve.
Those forecasts are not made up by HA, they are coming from somewhere. Like the Nordpool integrations is getting the dynamic energy prices for the upcoming 24 hours from the Nordpool API.
If an integration canāt provide forecasts thatās totally fine, then the integration doesnāt implement that functionality. But I think those integrations that provide forecast data should and could do this in a standardised way
There is no standardised way.
Forecasting energy prices are different from forecasting heating requirement, which is different from forecasting precipitation and so on.
Historical data is not enough for a forecast.
You need a formula to make the forecast on and that formula have to take the historical data and apply some current data to account for the changes to this occurrence.
Without the formula and those current data it will just be a set of historical data and HA already provide ways to present those.
Once again, the data does not need to be made up/calculated by HA, that is not my proposal. No formulas are involved. My proposal is to provide a standardised way within HA for integrations to provide forecasting data.
I give 3 examples in my proposal where forecasting data is currently provided but all in different ways because no standardised way is currently present in HA. For all 3 examples given it is possible to retrieve the forecasting data from their respective data providers and for all 3 examples given it is possible to standardise the way the forecasting is handled within HA
Well, the sun integration is not really a forecast it is a calculation.
And it is true that the weather integration is now an action. Earlier it was a sensor.
I never really understood the reason behind that move. This part I agree with.
How the data is presented is a separate thing.
HA runs a state machine where integrations put data in and cards pull data out.
Integrations and cards are not really directly related and there can be multiple different cards that use and present the same data in different ways.
The proposal is not about how to obtain the data (from the internet, through calculations, or by entering it manuallyā¦) but about how to use it.
For example, an automation could identify the three consecutive hours with the lowest price in the next 24 hours to activate the water heater.
Another automation could decide not to water the garden if itās going to rain in the next 48 hours.
The proposal is not about how to calculate this information but about a simple and standardized way to use it across different parts of Home Assistant.
It is pretty easy to make a formula that finds the x amount of hours with the cheapest price in next 24 hours.
Yes, it might require a bit of YAML/Jinja2 coding.
The issue is that it is often not a single forecast these actions are based on.
The water heater forecast migjh have to take into account the current temperature of the water heater, the forecasted need for hot water, the forecasted electricity production from a solar cell setup and the current charge of a home battery.
The precipitation example might take into consideration the current state of moisture in the ground, the forecasted evaporation and the water prices/restrictions.
I am all for new automations, but with so many options and possible variants then standardised ones will just be a niche anyway.
It is up to the devs to decide though, so lets see.
There are a lot of things that can be done with Jinja, actually Iām doing that right now for dynamic energy proces using the Cheapest Energy Hours macro. My entry for WTH is not about keeping the status quo on the current (lack of) implementation of forecasting data. My WTH entry is for improving this and making it more user friendly and consistent throughout the system.
For instance itās not possible to show a graph with forecasted energy prices, sun irradiance levels, rain perception levels, just any simple numerical forecasting data without falling back to complicated custom APEX cards.
To give an example, this is my graph with historical energy prices:
chart_type: line
period: 5minute
type: statistics-graph
entities:
- sensor.electricity_price
stat_types:
- mean
days_to_show: 1
This is my graph with forecasted energy prices:
type: custom:apexcharts-card
header:
show: false
span:
start: day
now:
show: true
label: Now
yaxis:
- decimals: 2
min: 0
experimental:
color_threshold: true
series:
- entity: sensor.nordpool_electricity_price
name: Electricity Price
unit: ā¬/kWh
type: area
curve: stepline
extend_to: end
data_generator: |
var x = entity.attributes.raw_today
.concat(entity.attributes.raw_tomorrow)
.map((item) => {
return [item.start, item.value];
});
return x;
And then Iām not even talking about making automations based on forecasting date, thatās way more difficult than the UI examples above.
In large parts of Europe dynamic energy prices, or not being allowed to return energy to the grid during peak production, is a thing. Being able to anticipate on this, to run the washing machine/charging the EV during peak sun irradiance levels or low energy prices is something weāre moving towards. Itās the next thing in the energy transition
It is easy to make a simple card, when you control the data that are the source.
That means you decide what resolution they have and how they are formatted.
Weather forecast come in a huge number of variations where some have hourly forecasts, some have 3 hour forecast, some 4, some 6 and some daily. Then again some lack the forecast all together.
Some forecasts have precipitation values, some have not and some precipitation forecasts do not follow the sun forecasts.
I use a weather forecast that have one resolution for the first 24 hours, a lower resolution for the next 24 hours and an even lower resolution for the following 5 days, before going to a day resolution on the next 7 days.
It is extremely hard to make automations when your source data is not known and static.
Remember that the devs need to make these automations without actually knowning the services they will be used with.
I would love to see a better way to store entity values for forecasts of the future as well. It is especially hard to draw a graph of forecasted values, and often need to resort to custom cards and our own custom attributes.
The december release will add the Nord Pool integration to HA Core, but it doesnāt include the hourly forecast as far as I can tell.
The HACS integration and ApexChart card are a very popular combi for energy prices in Europe. Every energy price forecast I have seen uses the same format.
It might not be the best way to do it, but it is close to good enough. The bar charts from the energy dashboard would be perfect to show the price. I like to have the prices shown in a (stacked) bar chart, but a line can also work.
The solar forecast is already shown in the energy dashboard, so I would guess doing the same thing for price forecast would be relatively easy. Does it need to be better than the solar forecast or could this be good enough to start with?
My WTH entry is for implementing forecasting in the core of HA. System wide, not only for energy, but basically for every entity that would have the means to provide forecasting. From energy to weather, traffic, tides, maybe even playlists.
I use the HACS Nordpool and Apex cards integration, I even mention it in my examples, and itās just a workaround due to lack of a real forecasting implemented in HA.
