I know that yet another weather integration is probably the last thing that Home Assistant needs, but I’ve found Weather.com to have the most accurate weather data for my location and I’ve been slightly annoyed that I had to use other weather sources in Home Assistant. So I went ahead and fixed that by writing my own custom component for Weather.com (also known as The Weather Channel). The integration can be found here:
This integration creates two weather entities - one with a daily forecast, and one with an hourly forecast. It also creates several sensors for other pieces of weather information, such as dew point and UV index. The full list of sensors/data is available in the README in the above GitHub repo.
I’m not aware of any remaining bugs with the integration and I’ve been using it without problems for the last few days, but there’s always the chance that I missed something so let me know if you run into any problems.
Going to set this up when I get home but was curious if you’ve been able to utilize the same api key from the source during the course of your testing? Thanks in advance.
Yes, I’ve been able to use the same API key since I started working on this integration. Honestly from what I can tell, everyone who follows my instructions will get exactly the same API key - they seem to use the same key for everyone. I did a Google search for that API key and found references to it going back about 2 years, so I suspect it has been valid for a long time and will hopefully continue to be valid for years to come.
That’s the risk here though - there’s no way for normal users like us to get our own API keys, they only make keys available to enterprise customers. Because of that any API key that we use has the potential to get shut down eventually, and if we can’t find a replacement key then this integration will effectively be dead.
Thank you for this integration. I am a big fan of Weather.com’s forecasts as well and considering creating a custom integration of my own. You beat me to it!
This is excellent! I just started using it today, but it’s already so much better than any of the other Weather integrations I’ve used. Let’s hope it keeps working!!
The integration already creates a sensor for humidity, named sensor.<LOCATION_NAME>_relative_humidity. However it looks like humidity can also be added to the weather entity:
So I’ll add that soon - sometime in the next week, hopefully.
Actually I just looked at this and noticed that humidity should have been there all along, I just named the field incorrectly so it wasn’t working. I’ve fixed that and pushed a new release, so once you update it should start working.
PLEASE NOTE: The “0th index” of all the fields within the daypart object (i.e. daypart[0].{field}[0]) as well as the temperatureMax field in the top-level object will appear as null in the API after 3:00pm Local Apparent Time. The temperatureMax for the 24-hour temporal segment typically has already occurred at this point in the day and would no longer be a valid forecast.
So after 15:00 local time it’s expected that the high temperature for the day will be null. Since this integration is just returning the data from the API there isn’t much I can do about this, unfortunately.
I suggest updating your README to reflect that one must be logged in to wunderground (free account) to retrieve the API key by viewing page source.
That said, this is because it’s the API key that was allocated to wunderground by weather.com to be able to consume their APIs. I was a bit shocked, and suspect as more and more people start leveraging the key, it will be changed and no longer passed in as a URL encoded parameter.
Until then… I’m enjoying the free weather . Thanks for the integration!
**Edit: just read through the comments and realized the possibility of the key being squashed was already mentioned. Also thought it would be worth mentioning–I pay for weather.com annually ($30-40) through iOS, and have not seen any indication that client side browser exposes the API key after cursory review. Later this week I’ll probably snoop/play around with my account and postman and devtools.
@thetxpopulist@jaydeethree at work now , can’t see. by any chance do you know the limit for the calls? As @thetxpopulist said , once people started using the volume is going to increase.
I suggest updating your README to reflect that one must be logged in to wunderground (free account) to retrieve the API key by viewing page source.
Being logged in has never been necessary in my experience. I also just opened wunderground.com in a private browsing window (no cookies) and can confirm that the API key is still available in the page’s source.
suspect as more and more people start leveraging the key, it will be changed
If you search for the key on Google you’ll find GitHub projects, StackOverflow posts, etc. that have been using this key for years, so I suspect the level of use it’s getting isn’t enough to get Weather.com/IBM’s attention. However if it gets used too much then yes, I suspect it will be changed. That’s the reason I didn’t hardcode the key into the integration and I require you to obtain it yourself - this creates a small barrier that will hopefully prevent the key from being overused.
Also thought it would be worth mentioning–I pay for weather.com annually ($30-40) through iOS, and have not seen any indication that client side browser exposes the API key after cursory review. Later this week I’ll probably snoop/play around with my account and postman and devtools.
Cool, I’m interested to hear what you find! On Android the native Google Weather app uses weather.com, and one thing I’ve considered if this API key gets blocked is that I could dig around in the app to try to find Google’s API key. There’s no need for that now, but it’s something I’ve thought about for the future
by any chance do you know the limit for the calls?
I don’t think there’s a strict limit but I haven’t done any extensive testing. For now the integration updates its data every 20 minutes so it’s not generating very much traffic for their API.
Does the API that is fetched from WUnderground give you a 5-day forecast? That’s what I’m getting and wondering if it’s possible to get 7 or 10 day forecasts…
There are several different API endpoints available:
The API provides options for 3-day, 5-day, 7-day, or 10-day forecasts. Currently my integration only uses 5-day forecasts, but I just tested this and it looks like the Wunderground API key supports 10-day forecasts. So I updated the integration and pushed a new release that uses 10-day forecasts
