Homeassistant 12h local weather forecast. ~94% accurate*

this homeassistant integration creates sensors to forecast local weather without the need for external services. Therefore it helps to get accurate weather data for the next 12h without the problem of changing services, API’s …
Also only a barometer as a sensor is required (can also be pulled from online). But the forecast can be made more accurate with more sensors.
.

New Ecowitt integration! Plug’n’play use!
new Ecowitt integration released! use
GitHub - HAuser1234/HA_Ecowitt_Extended: Extended Homeassistant Ecowitt Integration
to direcly integrate your Ecowitt based weatherstation with this integration!

Note: there is a chance that even if you pull data from the internet you get a much better short term local forecast!

V1.1 Released many bugfixes and better forecast. Please update to get the best experiance!

Link to repository:

Features

  • 2 Forcaster Models (zambretti + Negretti and Zambra)
    (you may have to change the card to use the other model, depending on which model is more accurate at your location)
  • rain probability
  • approximate timestamps for weather change (at reboot it can take some time for them to be accurate!)
  • text prognosis
  • simple temperature forecast
  • extract general weather conditions
  • full english an german support
    Note: It can take 3-12 h to get useful results!

Sensors

Following sensors can be used:

  • barometer (required) absolute(Temperature sensor required) or relative
  • temperature (set value to 0 is missing) (optional)
  • Wind speed (optional)
  • Wind direction (optional)

(if you have a temperature sensor it is highly recommended to use the absolute measurement of your barometer and let the integration calculate the pressure at sealevel. This then takes also temperature changes into account!!)

Card

English and german version Greek is also availlable:

grafik
grafik

Installation

please contribute ANY upgrades to the card or algorythm thia helps everybody!

  1. Add Integration: copy weather_forecast.yaml into your custom yaml integrations folder

—————-
how to make a integrations folder:
1.1 add this to your configuration.yaml:

homeassistant:
  packages: !include_dir_named integrations

1.2. create a folder named integrations in your config directory
1.3. copy weather_forecast.yaml in this folder
—————

  1. make changes for your individual setup (edit settings marked in weather_forecast.yaml
  2. copy the card as a manual yaml config into lovelace. !mushroom required, vertical-stack-in-card required!

btw. please help improve the tool by improving code!

ToDo

  • improove algorythms
  • make better temperature forecast

Versions

V0.1 fix Icons on Card
V0.2 address long periods of steady weather!
V1.0 live forecast updates, better prediction, better timestamps!
V1.1 may small tweaks
V1.2 added Greek language

sources

basic algorythm (enhanced in this integration): 
https://github.com/sassoftware/iot-zambretti-weather-forcasting
more info on the same:
https://integritext.net/DrKFS/zambretti.htm
https://www.mikrocontroller.net/topic/385242
http://www.beteljuice.co.uk/zambretti/forecast.html

.* 94% according to GitHub - sassoftware/iot-zambretti-weather-forcasting: A SAS ESP example that demonstrates the use of several ESP windows and their functions
_

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

6 Likes

Would like to try but…
YOu say it only requires a card but that one refers to a lot of sensors I donot have…how are these setup?
example:

states.sensor.local_forecast.attributes.forecast_short_term

@vingerha
edit: i misunderstood. you do need the card and the weather_forecast.yaml in your configurations!
→ I added in the post above better instructions to do so!

then they should be automatically setup. look in the developer tools. Give it some time. The algorythm relies on pressure changes ans therefore only beginns to work after some time.
Could you please supply a screenshot of your developer tools? The search query to get everything important should be „local“

Almost there…what is expected in this one? My local barometer (netartmo) logically does not show tomorrow…?

states.weather.tomorrow_io_home_daily.attributes.pressure

EDIT, I just added my netatmo and this in return… so let’s see ( abit of language tweaking still needed)

image

language can be set in the weather_forecast.yaml

set language from 0 to 1 or add a new one in which case please contribute it on github

EDIT: changed, I cannot read :frowning:
Card misses things but will check and comment back in time

there is probably something wrong! there should be a p0 attribute in local_forecast.


p0 needs to be there form the beginning.

please check your pressure entity! you may need to add a |float(0) after it.:


{% set pressure = states.weather.tomorrow_io_home_daily.attributes.pressure|float(0)%}
or another example. It depends on your sensor:
{% set pressure = states.sensor.whatever_entity.attributes.pressure|float(0)%}
or even
{% set pressure = states.sensor.whatever_entity.state|float(0)%}

the exemple service is just tomorrow.io it needs current pressure values!

this (see above) is the problem (most likely this will fix the card too)

if nothing works try to set a constant pressure like (to check if it is the pressure entity)


{% set pressure = 1010%}

please look if a p0 attribute then exists in your local_forecast entity in the developer tools
it should look like:

It is working, doing this in between 5 other things and typos are clearly easily made.
So the only ‘local’ element is the pressure if I am correct but I could also use temp wind etc. from any local station too I guess. Althoiugh local temp and wind may be ‘too’ local as depends on treelines, shadow, etc.

image

great! ist working! keep in mind it can take up to 3 h from now to get a useful forecast!

yes exactly i am still playing with how much i can pull localtalk.

btw. wind direction has a major impact. speed not as much.
temperature is only used for pressure at sealevel calculation and temperature forecast. not for the actual forecast.

if you find errors or add to the translation/documentation please commit that on github!
i found an error in the cards. I will fix that later. for now the third icon may not be correct

if you or somebody else could help improove the algorythm i would be very greatful!

After the w/e I may have more time, but for now… below the card again, bits and pieces are updating but not the time (is it now post 19:33 and 01:33 has been there from the start
Should there be a refresh, automation or something?

image

EDIT: I’d like to add that I have used 4 different weather providers so far and all have their oddities in my area: meteo-france, met.no, openweather, accuweather.
Openweather seems to be ‘best’(less wrong) on mid/long term, metea-france short term (today).
Temp differences are up to 5 degrees (in a range of 17 vs 22) And none (!) of them can predict rain.

that is per design. zambretti forecsts by changing conditions. I just have added approximate times from that forecast timestamp that approximate the weatherchanges. Zabretti will only recalculate at a weather change. Therefore the times are fixed till a change in forecast is occuring. … thats also why the temperature forecast moves to the 3. Icon after the first time has passed.
If that behaviour turns out to be wrong it is very easy to change. It is in changing conditions very reliable for me, but if the weather is very steady, it could lead to massively outdated times. Maybe I have to add a cornercase scenario after 12 h without changes of the forecast :thinking:

Do you want to observe the behaviour? here in Germany at this time of year the conditions change pretty often…
Do you want or can implement then a fix for this (if needed)(?) otherwise I will look into it when I have time.

btw. this algorythim is really good at finding oncoming heavy rain. Situations where it only rains lightly from time to time in continues to show this: partly rain/sun/cloud

Edit: i have now too a Situation with too little Changes in weather and old times. Maybe the solution is that after 6 h or so with no changes we can Update the Times(?) @vingerha

there is a new release (v0.2) which addresses this.
We will have to see how this influences that.

New update V1.0 fixes some of the issues from above in a cleaner, better way and offers more frequent updates to the prediction!

@vingerha you should update to that. this will solve the timestamps not moving issues

I will check after the weekend. Also note that I restart my instance regularly, not sure yet if this influences the sensors (are these reset?)…

That would be great!
I also pretty frequently restart my server to test different things, but haven’t noticed any problems. Only about 3 h after reboot the forecast gets sometimes a bit worng for 20 s or so, because of the missing data while restarting. Also the times reset after each reboot and therefore get more unreliable. But his doesnt matter as much, because these exact times are from the beginning never correct and have a “tolerance” to them.
Also if you haven’t already you should consider moving to a absolute barometer measurement and then use the local temperature measurements. This then takes local temperature changes in the forecast into account.

Took a bit longer as travelling but I moved to the 2nd version now.
My only pressure sensor is the netatmo and not (yet) anticpating to invest in anything else, what would you recommend here (may be a studpid question but am no specialist)?
The next steps I would like to do is to verify the forecasts, sadly HA does not store attribs in the history, Did you (and how) verify the regular ones (accu/met.no/owm) vs. yours?

I use a pretty cheap 7-1 weathersation from Sainlogic. I haven’t verified the forecast to regualr forecasters, but by looking at the results I since tweaked many things.

  • I discovered that the second algorythm plain is wrong 50% if the times (as suspected)
  • the regular algorythim is pretty good
  • Wind data (speed/direction)should probably be prerpcessed by a statistics sensor to get a more steady average value
    → fast changing windspeeds around 1 km/h cause the forecast to change often and therefore make the times useless

I will release soon some improovements to the algoryhm. (will prpbably make a post here)
if you want to further improove I am happy to get more observations!

I am thinking of redoing it in AppDeamon, if I have time. I think this allows for better forecasts, because of easy access of history data and is then installable through HACS!
What do you think?

I too was thinking about making it more integrated with selecting the various entities and language but imo … before spending any time on esthaetics, it first has to prove its added value over the regular ones.
EDIT : what do you mean by 1st and 2nd algorythms?..again, I am not too deep into the tech stuff behind this algo

yes you are right, but I think much of the input data preprocessing can be much better that way.

there is the zambretti algorythm and one called neg_zam (more in the code)
the one displayed in the card is the zambretti one. the other one ist basically only in “shadow mode”
for me since the tweaks I have done See V1.1 on Github it got pretty reliable (minus the timestamps, which need to be addressed, but in my opinion are only possible to get better by a average sensors for wind or the AppDeamon integration)

Agreed about the ease of entry and if one is confident and has the time…no issue of course, I just need to see it work for me before I (!) spend more time on it. None of the 4 local/regular ones I tested is good so I have become quite skeptical

yes for sure test it! maybe I will do that because I want the times to be more accurate.
Maybe you can just try to watch what it says and compare it to the real world.
For me the forecast text almost always matches reality. The conversion to times and so on is where the complexity beginns…
looking forward to your experiance! I think there is still a lot to tweak based on real world data.