This is an excellent use case for a local LLM. Even the tiniest models can produce a good sentence in a format to your liking. If you generate the text every hours, you can retrieve it instantly from a helper.
I donât mind a static, boring, nonLLM text message, but it would mean the world to me if it is in my local language 
Thanks for maintaining the integration. Feel free to update the article to best reflect the integration. I made some updates already, but itâs difficult to keep track of all the integrations.
Regarding the deviations: The point is not to criticize, but to help users find good integrations. The forecast attributes do not match the suggested attributes in de developer documentation. Iâm not sure if itâs ok to add additional attributes. I was a bit confused when comparing all the integrations, but Iâm not sure it matters for users who just want to use one or two integrations.
Thanks for the list! I got pirate weather set up in minutes.
It does makes me miss Dark Sky, but we do what we can when mega corp buy up the good stuff.
Some things you can do with the sensors from BOM Weather.
HOW TO: Full Text Weather Report, BOM Australia Integration, Extract Weather Warning Data & Other Text
1 Like
The table editor is bugged and will mess up the article.
After some discussion with the mods, the only way is to freeze the article to prevent people from breaking it by accident.
I think you tried to make some changes but they have been lost because we needed to revert to a working version. Any changes can be suggest down here in the comments. You can tag a moderator to help with edits or leave them here to be processed in batches.
I hope the issue gets fixed so we can get back to group editing soon. Until then, we have to weather the stormâŚ
2 Likes
can this guide perhaps include examples? i am wondering how to refresh the weather forecast from openweather and how to make a automation that if no rain is predicted in the next 2 hours, then trigger X.
| CURRENT WEATHER | Daily | Hourly | Con | Temp | App | Dew | Hum | Rain | Pres | Wind | Gust | Vis | Cld | O3 | UV | Other |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Bureau of Meteorology | 8 | 72 | X | X | X | X | X | X | X | X | X | X |
| FORECAST | Daily | Hourly | Con | Temp | Low | App | Hum | Wind | Gust | Rain | Rain% | Pres | Cld | Dew | UV |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Bureau of Meteorology | 8 | 72 | DH | DH | D | H | DH | H | H | DH | D | H | H |
| Integration | Entities | Description |
|---|---|---|
| Bureau of Meteorology | 163 | Will give all data for your selected weather station. 7 Days UV Fore Cast UV Start Time, UV End Time, UV Max, UV Category, UV Long Text Forecast. Sunset, Sunrise. Extended Text Forecast, Short Text Forecast. Fire Danger Rating. Icon Descriptor, MDI Icon, (3 Times A Day) Temperature Now and Later. 7 Days Rain Min, Rain Max, Rain Range, Rain Chance Of. Weather Warnings. |
1 Like
No, I understand that, Iâm also trying to find out if I did something wrong in the integration, as âDeviates from HA standardsâ seems to suggest that, or at least it doesnât sound very positive. Or does this only refer to:
The API that feeds this integration has sun_chance, solar_irradiance, and wind_speed_bft for forecasts and I assumed they could be to use by someone.
The documentation nor the code doesnât prevent extending forecasts
I agree with you that adding useful information is a good thing and the deviation from the standard weather object is not relevant.
I thought I updated the description already, but now I see itâs still the original one. We had to revert some changes because the table editor messed up the article. The article is now frozen, but it can be unfrozen upon request to allow me to make some changes.
I hope to do an update early next week.
2 Likes
Excuse me! Could anyone please explain me the meaning of the forecast result?
For example if I get below response (partially):
weather.accu:
forecast:
- datetime: "2024-08-17T05:00:00+00:00"
cloud_coverage: 53
precipitation_probability: 13
uv_index: 5
wind_bearing: 253
condition: partlycloudy
temperature: 28.3
apparent_temperature: 29
templow: 17.7
wind_gust_speed: 18.5
wind_speed: 7.4
precipitation: 0
humidity: 57
- datetime: "2024-08-18T05:00:00+00:00"
cloud_coverage: 98
precipitation_probability: 71
uv_index: 1
wind_bearing: 280
condition: rainy
temperature: 21.8
apparent_temperature: 21.4
templow: 14.1
wind_gust_speed: 31.5
wind_speed: 9.3
precipitation: 4.2
humidity: 85
I am running this forecast service at about 2024-08-17 16:00. When I get this result:
forecast[0].precipitation is 0, and I suppose the unit for precipitation is âmmâ, right? What does this 0mm mean? Does it mean starting from â2024-08-17T05:00:00+00:00â, in the next 24 hours, the total precipitation is 0mm?
Or the total precipitation on 2024-08-17 is 0mm?
Furthermore, the temperature in the forecast, is it a temperature at the time point â2024-08-17T05:00:00+00:00â? or the average temperature of 2024-08-17?
Thanks!
The definitions of the forecast attributes can be found here: Weather entity | Home Assistant Developer Docs (scroll down a bit and youâll find it).
There is still some room for interpretation. How a weather service implements the attributes exactly depends on the api and the integration. It might not even be consistent between the various integrations. Your guess is as good as mine.
I recommend to monitor the values for a while and see how it matches reality. If you find anything interesting, you can share your findings by updating the documentation of the integration.
Thanks for the answer!
I read the link, as you said, there is room for interpretation. In the doc for forecast data it says for precipitation:
native_precipitation | float | The precipitation amount in mm or in.
Still unclear. I will try to monitor it for a while.
By the way, one more question. Does this weather.get_forecasts service call make an additional API call? If I run this call hourly for OpenWeatherMap, will it cause too many API calls?
A correct implementation should cache the results locally so multiple service calls should result in a single API call (for as long as the data is considered to be valid/up-to-date).
No need to hold back on the service calls.
Thanks again!
And I just get an update about the precipitation, it is interesting.
Because the OpenWeatherMap support both daily and hourly forecasts. I did both, and I added 24 values from the hourly forecasts. It equals to the value of the daily forecasts.
So I could conclude that the daily forecast is the total precipitation amount of the day.
Further details I could verified is, the 24 hourly values start from 00:00 of local time, not the 00:00 of GMT. This is exactly what I need.
I couldnât verify AccuWeather because it doesnât support hourly forecasts.
P.S. OpenWeatherMap forecasts in hourly mode returned 48 hours forecasts. You wrote 24 in your table, maybe you could update it. 
I would like to share an interesting information I found these days. I was monitoring the output of 4 weather integrations: Accu, OpenWeatherMap, DWD Wetterdienst (fl550) and DWD Wetterdienst (hg1337).
I found that depends on different integrations, the responsed list of weather.get_forecasts action changed the forecast date at different time. Here is a picture of history chart. Iâll explain below.
The picture shows 8 sensors I create with Template. For example, the first sensor template is
- trigger:
- platform: time_pattern
hours: "/1"
action:
- action: weather.get_forecasts
data:
type: daily
target:
entity_id:
- weather.accu
- weather.openwm
- weather.dwd_hg1337
- weather.dwd_fl550
response_variable: daily_forecasts
sensor:
- name: accu_forecast_datetime
state: "{{ daily_forecasts['weather.accu'].forecast[0].datetime }}"
I used forecast[0] to show the first forecast of the list, which I supposed to be TODAY. From the first 4 rows in the picture we can see, the forecast[0] is not always changed to today at 0:00. We can see Accu is the latest one, it changes first forecast to today at 5:00. OpenWeatherMap at 1:00.
This means for example if you use forecast[0] to get a forecast value at 0:00 from Accu or OpenWeatherMap, the value you get is still for yesterday.
Then I adjust the template of sensor to always get the right value of today as below:
- name: openwm_forecast_datetime_today
state: "{{ daily_forecasts['weather.openwm']['forecast']|selectattr('datetime', 'match', states('sensor.date_time')[:10])|map(attribute='datetime')|join }}"
I use the date string splitted from sensor.date_time, filter the right forecast I need. The row 5 to 8 are new sensors. Now they are always updated at 0:00.
These datetime sensors are only used to confirm my template, based on that if we want to have a forecast precipitation value of today, we can then change the attribute in the map() filter.
- name: openwm_forecast_precipitation_today
state: "{{ daily_forecasts['weather.openwm']['forecast']|selectattr('datetime', 'match', states('sensor.date_time')[:10])|map(attribute='precipitation')|join }}"
Now we can get the right precipitation value for today, from no matter what integration.
1 Like
Sorry but canât control myself in sharing something moreâŚ
Here are the forecast precipitation values comparison from Accu, OWM, and DWD(hg1337).
First conclusion, Accu Weatherâs update frequency is too low, and value has big different from other two. I consider it is not good to use.
Second, the data value from different integration may have different meaning.
Comparing OWM and DWD value:
- at 1:00, it is the first forecast value of today, looks similar about 5mm.
- the value from DWD is getting lower and lower until 12:00 it is 0mm; the value from OWM changes also hourly, but both up and down, from 12:00 it is stable at about 14mm.
What I know is, from 12:00 on there is no more rain.
And here is my guess:
- OpenWeatherMap hourly update the precipitation value, it adds the measured value from history and the forecast value of following hours. From 12:00 on, the forecast values for the rest of hours are always 0, so the precipitation value remains unchanged for the rest of the day.
If this is true, this means if we use weather.get_forecasts to get a value at the last minute of a day, we probably get a measured precipitation value of the day. - DWD(hg1337) also update hourly, but the value show completely different. So my guess is this forecast precipitation value is the sum of the hourly forecast values of the rest hours of the day. That can explain why it is always getting reduced. From 12:00 the hourly precipitation is always 0, so the today precipitation remains at 0.
If this gues is true, people who use this integration can only get the forecast value for the whole day at the first minutes of the day.
1 Like
Is there a recommended approach to do a minutely (or at least sub-hourly) forecast? Hyperlocal forecasts like Accuweatherâs MinuteCast and OpenWeatherMapâs minute forecast can be super handy.
I tried to document the update frequency of the various weather providers, but gave up on this because itâs not compatible.
- Home assistant only supports hourly forecast. This seems to be the industry standard and is reasonably accurate for up to 1 (maybe 2) days. Looking further into the future on an hourly is not really possible.
- Some integrations provide the forecast data for the nearest weather station while others try to calculate the weather for the exact geographical location.
- Some weather services may have a 3 hour forecast and simply extrapolatie this to hourly forecast while others may have a weather model which calculates the forecast every 15 minutes.
This makes it already difficult to say something sensible about the accuracy of hourly forecast. Results can vary a lot on a case by case basis.
There are some specific weather services who predict rainfall every 10 or 15 minutes over the next 2 or 3 hours. This is useful and can be fairly accurate. It combines nicely with a weather radar. I recommend to stick to hourly forecast for all other use cases.
There are some specific weather services who predict rainfall every 10 or 15 minutes over the next 2 or 3 hours. This is useful and can be fairly accurate. It combines nicely with a weather radar.
Exactly - is there a recommended approach for this in Home Assistant?