The current package on github has the code for the TTS announcement in it so I’ not sure what you mean there.
But again that’s for use with Alexa Media Player not Google Home.
You just target your tts service at the google home media_player and it’ll play the message.
Super easy.
So far, so good… But I haven’t had any severe weather locally to put it to the test. I did help @firstof9 with some initial testing in other areas with severe weather, and it’s worked great.
I’m doing the same.
1 Like
thanks for the update, this is perfect. i added a separate coord one to test them for a little bit.
kudos.
3 Likes
Can you edit your original post? I was about to try using the yaml you first posted in 2018, but found this comment while scrolling through the 465 comments here.
Does the HACS Weatheralerts integration supercede the yaml and other parts?
the “weatheralerts” integration isn’t mine. Mine is “nws_alerts”.
it’s similar but it doesn’t provide all of the same functionality and the usage examples at the “nws_alerts” repo won’t necessarily work for that integration.
I can. And I did. 
TBH, I didn’t think it was editable after all this time so I was surprised that it let me.
1 Like
I had a bit of an epiphany after the ability to use GPS location was added to the sensor config options…
“what if we could dynamically and automatically update those GPS coordinates as we moved around to make sure we always had alerts based on our current location?”
So I approached @firstof9 to see if he could work his magic and make that a reality and he again came thru for us.
So it’s now here. I just released a new version in HACS with that ability.
You can now select a device_tracker entity in the sensor config to use for location data.
There is only one limitation that popped up during testing. For some reason you can’t use a device_tracker entity that was configured manually in known_devices.yaml. But that is pretty rare anymore and won’t likely affect any user (except me of course since I have one that I tried to use for testing and it didn’t work 
).
try it out and let us know what you think and of course if there any issues.
3 Likes
I enjoy the challenge. Hopefully people find it useful.
2 Likes
@firstof9 curious if you can provide guidance for me. We live in AZ and many of the severe weather alerts just do not happen out here (tornados). How would I modify your scripts to take into account other severe weather like dust storms, monsoons, etc?
What do you mean? I also live in AZ.
Well that is awesome btw! So, as we have pretty much perfect weather here in AZ there is that upcoming monsoon season that we will experience where I would like to have notifications go off surrounding the high winds and gully-washer of rain. Have you done any notifications like that with your setup?
This is all I use right now:
Script:
weather_alerts:
alias: Weather Alerts
mode: queued
sequence:
- choose:
- alias: Sever Weather
conditions:
- "{{ 'Tornado' in state_attr('sensor.nws_alerts', 'title').split(' - ')[0] }}"
sequence:
- service: script.house_annoucement
data:
this_message: "The National Weather Service Has issued a {{ state_attr('sensor.nws_alerts', 'title').split(' - ')[0] }} ,, {{ state_attr('sensor.nws_alerts', 'spoken_desc').split('\n\n-\n\n')[0] }}"
volume: 0.9
priority: True
- alias: Weather Warning
conditions:
- "{{ 'Warning' in state_attr('sensor.nws_alerts', 'title').split(' - ')[0] or 'Watch' in state_attr('sensor.nws_alerts', 'title').split(' - ')[0]}}"
sequence:
- service: script.house_annoucement
data:
this_message: "The National Weather Service Has issued a {{ state_attr('sensor.nws_alerts', 'title').split(' - ')[0] }} ,, {{ state_attr('sensor.nws_alerts', 'spoken_desc').split('\n\n-\n\n')[0] }}"
volume: 0.9
Automation:
- alias: NWS Announce Weather Alert
trigger:
- platform: state
entity_id: sensor.nws_alerts
condition:
condition: and
conditions:
- condition: template
value_template: "{{states.sensor.nws_alerts.state | int(0) > 0}}"
- condition: template
value_template: "{{ trigger.to_state.state|float(0) > trigger.from_state.state|float(0) }}"
action:
- service: script.weather_alerts
mmm templates
weather_alerts:
alias: Weather Alerts
mode: queued
variables:
title: "{{ state_attr('sensor.nws_alerts', 'title').split(' - ')[0] }}"
raw_data:
this_message: The National Weather Service Has issued a {{ title }} ,, {{ state_attr('sensor.nws_alerts', 'spoken_desc').split('\n\n-\n\n')[0] }}
volume: 0.9
priority: "{{ True if 'Tornado' in title else None }}"
sequence:
- service: script.house_annoucement
data: "{{ dict.from_keys(raw_data.items() | rejectattr('1', 'none') | list) }}"
2 Likes
I updated my setup for this as it looks like it changed from when I originally installed it. I am having an issue with a new part of the setup that now has a “variable” included using a custom component. I added the custom component however the “variable.nws_alerts_event_ids” is not available. Does this variable get created on the fly when the sensor.nws_alerts is greater than 0 or do I need to create this? I guess I was expecting it to be created with this line in the package.yaml but it doesn’t seem to be there.
variable:
nws_alerts_event_ids:
value: 'none'
restore: true
What do I need to do to get this entity available?
I can’t seem to get that working - I’m trying to add it to scripts but getting extra keys not allowed - I would presume it’s my indenting?
That script only works with firstof9s script
1 Like
I am assuming your template example was a rewrite of firstof9s example. If so, what exactly does this template line do exactly?
Scott
@finity & @firstof9 - thanks for the continued work on this.
I had a perfect test today between Zone and GPS methods. A severe thunderstorm was issued that impacted my Zone, but the polygon was just outside of my physical location. The Zone triggered, but as expected, the GPS did not.
GPS:
Zone:
1 Like
I’m not sure it’s firstof9’s scripts you’re referring to.
If it’s the scripts in the packages directory on github then those are my scripts. I created those way back in the day when I first created my setup using the custom integration.
If those are what you are referring to then you can modify those to add whatever alerts you are interested in. I really only care about tornadoes and severe thunderstorms so those are the ones that trigger announcements.
You can change the announcement templates to watch for any words you want in the alert title.
Just substitute “dust” or “monsoon” for “Tornado”.
Also remember that the text has to match exactly including case. And be sure the thing you are matching on actually would exist. IOW, is “monsoon” a word that the NWS would actually put in an alert title?
Yes the examples posted in the packages directory include a custom integration called “hass-variables” maintained by Wibias. It used a custom domain called “variable” (the entity_ids would be “variable.something”). That custom integration changed recently and no longer creates a custom domain and everything is now under the sensor, binary sensor, etc domains.
You will need to either update the examples I posted to use a different method of saving the desired data or go to the custom integration repo for “hass-variables” (now it might be called “variables+history”) and use the documentation to update from the old “variable” domain to the new “sensor” domain.
I’m not updating to the new version of the integration as the old “variable” domain was useful to me in it’s functionality.
But if you still want to use my package as is then you just need to install an older version of the “variables+history” integration before it was re-written. I’m using version 2.3.6 and it still uses the “variable:” domain.
I may update at some point but for now I’m locking my version to the older one.
And the example package reflects that. But TBH, the variable used there is fairly minor and isn’t really needed for the important functionality like severe weather announcements. You can really just remove that code where it’s used and it should still work for the main functions.