Would love to see a component built to set states for weather warnings. Potential example: A tornado warning is issued by the NWS for your house and Home Assistant sets off an alarm, changes lights, etc.
The list of feeds can be found here: https://alerts.weather.gov/
You’d just need to parse a local feed and run a point in polygon algorithm to determine if you’re in a warned area.
I suppose if you could do this with the feedreader component by selecting the feed for your county and then just using that as an event trigger. The problem is the feedreader component is so sparsely documented the only thing I can see shown as an example is a simple trigger - a new feed item appears, event is triggered. I think you’d have to write some kind of external script to actually get what that alert was and display it. The feedreader component doesn’t actually display anything.
Hello @RyanLehms @rpitera
I’ve added a PR with for Weather Underground that allows monitoring severe weather advisories.
https://github.com/home-assistant/home-assistant/pull/3505
Please let me know if that helps.
mmello
Thanks for your work on this! I’m not sure how to switch over to the dev branch to play around with it, so I might have to wait until it hits production. Seems like it should do the trick through.
Helo @RyanLehms,
Sure! It was cool working on this. I’m using the alerts here while the patch is not merged.
If you want to test it, what you can do is this (assuming you are running on Linux):
-- on the home assistant configuration directory
# mkdir -p custom_components/sensor
# cd custom_components/sensor
# wget https://raw.githubusercontent.com/tchellomello/home-assistant/wunderground_alerts/homeassistant/components/sensor/wunderground.py
Then on the wunderground sensor add the alerts and restart your home assistant.
Let me know if you need any help.
mmello
Awesome! I got it working on my install. Any tips for testing? I saw the test_wunderground.py, but I’m not sure how to implement.
@RyanLehms you don’t need to worry about the test_wunderground.py. That is just a Python unit test used for validation of the build process.
Once you placed the file under the custom_components/sensor directory all you need to do is just edit your sensors component entry and add alerts. You can refer to the documentation as explained at https://github.com/home-assistant/home-assistant.github.io/pull/981
Thanks for testing it!
Nice!
I’m still struggling to figure out how to test with fake data, but I hate to keep asking for help, so I’ll keep tinkering. I can set the state value, but struggling with setting the attributes. Once I do finally figure it out, will I be able to do a condition in an automation rule that would look something like this?
value_template: ‘{{ states.sensor.pws_alerts.attributes.description == “Severe Thunderstorm Watch” }}’
I want to move over from the original custom component to the new released version, but there are so many attributes missing. Is there any chance these will be added back?
@rpitera I’ll try to incorporate some missing attributes to this sensor on the next few days.
Before sending the PR, I’ll send you the code to get your opinion.
Thx
Thanks very much, @tchellomello. It’s probably not important to a lot of people but I actually own the weather station I am monitoring and it’s a hobby for me so having as many of the original attributes is a big deal. I appreciate you working on it. 
@tchellomello Thanks again for your work on this project! I finally got a prototype of everything working as expected.
Either it’s a bug or an issue with my setup, but I wasn’t able to modify the attribute data for testing. The best I could do was choose a lat/long combo with a current warning and add that to my configuration file. Once I got over that hurdle, I found out the hard way that pulling the attribute data is case sensitive. I’m sure there’s a better way to do this automation, but I figured I would share for anybody else that stumbles across this thread.
alias: "Weather Alert"
trigger:
- platform: numeric_state
entity_id: sensor.pws_alerts
above: 1
condition:
- condition: template
value_template: '{{ states.sensor.pws_alerts.attributes.Description == "Lake Wind Advisory" }}'
action:
service: script.weather_alert
Next on the list is figuring out what happens when more than one alert has been issued. Wish me luck!
@RyanLehms Thanks for sharing the automation rule!
Ryan, when more than 1 alert is issued, the field will be like Description_TYPE. So for example, if you get 2 alerts like this:
[.. SNIP..]
"alerts": [
{
"type": "FLO",
"description": "Areal Flood Warning",
"date": "9:36 PM CDT on September 22, 2016",
"date_epoch": "1474598160",
"expires": "10:00 AM CDT on September 23, 2016",
"expires_epoch": "1474642800",
"tz_short":"CDT",
"tz_long":"America/Chicago",
"message": "\u000AThe National Weather Service in La Crosse has extended the\u000A\u000A* Flood Warning for...\u000A Clayton County in northeastern Iowa...\u",
"phenomena": "FA",
},
{
"type": "WAT",
"description": "Flash Flood Watch",
"date": "8:25 PM CDT on September 22, 2016",
"date_epoch": "1474593900",
"expires": "1:00 PM CDT on September 23, 2016",
"expires_epoch": "1474653600",
"tz_short":"CDT",
"tz_long":"America/Chicago",
"message": "\u000A...Flash Flood Watch remains in effect through Friday afternoon...\u000A\",
},
[.. SNIP..]
It will create a structure like: {{ states.sensor.pws_alerts.attributes.Description_FLO == "Areal Flood Warning" }} and {{ states.sensor.pws_alerts.attributes.Description_WAT == "Flash Flood Watch" }}
I thought using this exactly for condition triggers then you can combine condition: or operator to monitor special alert advisories. Also based on my research on the API, a location cannot have the more than 1 advisory type of the same type.
Hope this helps.
Please let me know if you think there is a better way.
Cheers!
That’s awesome! I’ll just build out automations similar to the one below. It should definitely take care of all of my use cases.
alias: "Weather Warning Tornado"
trigger:
- platform: numeric_state
entity_id: sensor.pws_alerts
above: 1
condition:
condition: or
conditions:
- condition: template
value_template: '{{ states.sensor.pws_alerts.attributes.Description == "Tornado Warning" }}'
- condition: template
value_template: '{{ states.sensor.pws_alerts.attributes.Description_TOR == "Tornado Warning" }}'
action:
service: script.weather_warning_tornado@RyanLehms Awesome!! Yes it looks good.
You can also find the reference for the alerts types issued by WU at https://www.wunderground.com/weather/api/d/docs?d=data/alerts
type Translated
HUR Hurricane Local Statement
TOR Tornado Warning
TOW Tornado Watch
WRN Severe Thunderstorm Warning
SEW Severe Thunderstorm Watch
WIN Winter Weather Advisory
FLO Flood Warning
WAT Flood Watch / Statement
WND High Wind Advisory
SVR Severe Weather Statement
HEA Heat Advisory
FOG Dense Fog Advisory
SPE Special Weather Statement
FIR Fire Weather Advisory
VOL Volcanic Activity Statement
HWW Hurricane Wind Warning
REC Record Set
REP Public Reports
PUB Public Information Statement
This is kind of old post, but I thought if someone can rethink the way it works.
It will be nice if we can have one more attribute called “Type” which will have one of the possible value of the type documented by wunderground. This will help in filtering out important and less important alerts. Existing functionality appends type to description only if more than one alert present but if there is only one then we don’t get this Type information at all and hence I can’t figure out critical alert vs non-critical unless do a (description) string compare and which can break easily if wunderground makes any changes to the string content while Type will be more secure as it looks like coded information. If we have Type attribute always regard less of number of alerts will help even simplifying automation too.