Weather Service API feeds to HA Weather platform

Development
#17

It is a very common forecast in the US to have “50% chance of rain on Tuesday” for example. For NWS, they are clear that this is the probability of rain anywhere in the forecast area times the expected percentage of area affected.

In my experience, we almost never get inches of rain forecast unless it is noteworthy, e.g. 4 inches of rain, or it is wintery precipitation like snow or sleet.

This is what those in the US are used to getting in the forecast. So seeing 0.1 inches of rain is just as hard to understand for us, or maybe just me, because it isn’t part of our normal weather experience.

#18

I think the percentage probability here in the US arose due to our size. For example, the Houston metro area covers roughly the same number of square miles/kilometers as Belgium. So to say it will rain 0.25 inches in Houston means nothing.

#19

OK I didn’t realise it was a forecast not a record. That makes more sense now :slight_smile:

#20

By the magic of copy paste, I’ve got precipitation probability working. Just need to address all the other points. I think we should request a day/night mode in the default component in addition to daily and hourly. Then, it would be as simple as setting a time of day attribute for each forecast, which is already available in the NWS data.

Screenshot_20190213-063445
Screenshot_20190213-0634451080×1920 114 KB

#21

I now have a working version for the weather card. I need to look at the more-info card to see if that needs any tweaking as well.

Besides more-info card, I think the only other big TODO on my list is to decide on how to utilize the quality control info. My suggestion is to proceed as it is now with no QC check and no fall back to retrieve data from previous time point. We can always add this more detailed functionality later. Thoughts on this approach?

image

I commented about adding features to the weather component here, although maybe I should have put it in a separate issue.

https://github.com/home-assistant/architecture/issues/75

1 Like
#22

Should have posted the update here. @txNgineer, see this link:

#23

The web page I use to find various locations is at Weather.gov/MapClick with search

This starts with our area (Houston, Tx), but you can enter any location information in the search box. The formats for searching are detailed under the “View Location Examples” link below the search box.

Have you made any progress on the other timestamps since your posting in April?

#24

Thanks. I’ll take a look.

If you mean in terms of modifying the built in weather card to show day/night, I did modify the card successfully, but then my frontend development environment broke with some version update. I can’t figure out how to get it working again to test it with the latest version.

I have a PR for a weather platform and someone else submitted a PR for a nws sensor. The other PR incorporated the metar code as a fallback, so I implemented this as well. Both PRs aren’t getting any attention however.

#25

Oops, I didn’t realize you may have meant the api location information. If so, it is a two step process:

  1. Enter an api query (I just used my browser) to your desired location with Lat/Lon coordinates in decimal degrees. Here is an example link: https://api.weather.gov/points/29.62194,-95.49278
  2. It will show several links and a grid x and grid y. In the example that will be 59,89 Put those into a second link such as https://api.weather.gov/gridpoints/HGX/59,89/stations the result will show a list of stations nearest to the desired location.

From the example the nearest station is KSGR and it shows to have the API link of https://api.weather.gov/stations/KSGR.

Note also that the results from step 1 above will return links to both a daily and hourly forecast for the grid block. It looks like you can use the same link but just replace the “stations/KSGR” with either “gridpoints/HGX/59,89/forecast” or “gridpoints/HGX/59,89/forecast/hourly” to get the 7 day and hourly forecasts.

A good programmer could probably automate the above queries, but I didn’t see a need because my desire location(s) don’t change often.

#26

Right now, it does the same process, but in a slightly different manner. You can specify no station, and it will find the closest one by lat/lon.

We need the ability to hard code a station as well, as some stations have really bad quality data, like the one by me which never has rainy days.

Since I made the PR, the NWS API changed to deprecate either the forecast or observation, I forget which now. So your method probably makes more sense as it isn’t deprecated. It just means I have to rewrite a lot of code :frowning:.

#27

I suspect it was the observation. They seem to be heading to extreme compartmentalization where NWS is the instantaneous weather only and all History (observations included) are moving to NOAA.

I am finding it miserable to get a reliable source from NWS/NOAA/NCC for something as simple as precipitation in the last 24 hrs. That used to be included with weather data, but now it is in observations and even there not totalled and averaged (at least I haven’t found it yet).

What are you using for yesterday’s precipitation totals?

#28

I have only made a weather platform which has very limited support for data types. This would fit in better with a sensor platform where any data can be used.

#29

MatthwFlamm,

Is this the same way the component in HA works for NWS? If so how did you get around the use of an API that NWS does not use anymore? I contacted them since now they are using User-Agent Script to pull weather information. I am assuming in place of the API most are just using their email to give it a authorization of some sort?  Below is what they sent me and not sure it will work with the component python script.

or cURL you would use curl -A. Looking at the curl man page you see

   -A, --user-agent <agent string>

          (HTTP) Specify the User-Agent string to send to the HTTP server. Some badly done CGIs fail if this field isn't set to  "Mozilla/4.0".

          To  encode  blanks  in  the string, surround the string with single quote marks. This can also be set with the -H, --header option of course.

I would like to use the NWS component alone with DarkSky

#30

EDIT: this was meant as a reply to @gdreelin, but it isn’t showing up as such.

I’m a bit confused in what you are asking. I hope this answers it.

The NWS weather integration is now a builtin integration in home assistant. Have you tried it? You can use it with or without DarkSky. I actually use both in case data is missing from one.

You can use any string as the userid aka user-agent string. NWS requests that this string include an email, but it isn’t a requirement. In the NWS integration, you can use any string.

The forecast API based on the lat/lon became deprecated recently, but it still works. I haven’t had any reports from anyone that it isn’t working. I have probably 95% of the work done for changing over to the non-deprecated method, but it still needs a few things before I switch over the behavior.

#31

Correct I see it under the component section of HA though it is not currently in the integration section of HA as of yet. To integrate it as shown below:

weather:
  - platform: nws
    api_key: YOUR_API_KEY  <--- Where do you get this part or just put an email there since they do not do APIs anymore?
    station: KADW   <-- Station near you

My question is if you don't have an API how do use the user-agent string in the configuration?
#32

Are you referring to the difference between configuration in a configuration.yaml file versus through the UI by using Configuration -> Integrations? If so, NWS is only available to setup in the configuration.yaml method. I’m not sure what you mean by component section. The history of HA naming is super confusing. The code exists in the folder /components/nws, but I believe it is now referred to as an integration. It is a bit baffling to me still.

Who said they don’t do API’s anymore? This API is still functional as far as I can tell and I’m getting valid data from it. See link below.

https://www.weather.gov/documentation/services-web-api

For api_key, you can put any string you want in there, but the NWS API suggests using an email. It doesn’t require an email. In addition, the integration decorates your string with an identifier to ID it as being from a home assistant instance. Do you have a recommendation for how this could be made clearer in the documentation?

#33

Here is an example configuration:

weather:
  - platform: nws
    api_key: [email protected]

And another:

weather:
  - platform: nws
    api_key: this_is_not_an_email_address_3!!!!djdh

EDIT: I’m not actually 100% sure that the !!!! will be parsed correctly in YAML into a string, since I haven’t tested it, but I think it will work.

1 Like
#34

Yes it is confusing since they switched to integration over components. And yes you nailed what I was trying to ask. For the setup the api-key is just the email that was the missing part from the page since even the NWS API page is confusing. Thanks for setting me straight and appreciate the help.

#35

If you found it confusing, I’m sure others do too in regards to the instructions for the api_key. If you have a suggestion to make it more clear, you can make the PR directly from the documentation page. Or, if you prefer, I can do it if you put it here.

#36

We on the NWS Home Assistant page it directs you the NWS’s API pages that is not clear at all. So to fix that would be to just say using your email address as the API Key in the configuration. It works I just tested it out. As long as you have the email and the station code it works. So they should change to look like this:

weather:
  - platform: nws
    api_key: [email protected]
    station: your station code (see link)

It would make it less confusing. Now just have to figure out what I can use that data in card form.