If it’s indeed not a bug then I think it’ll be time to deprecate the yaml config option (even tho I’m loathe to do it and cause breaking changes - as you know 
)
1 Like
I’ve updated the Readme on github to reflect the change.
1 Like
i have both the zone and coordinate methods setup and the zone based one just spams me all day with identical alerts. we are in a heat wave at the moment and it was literally an alert every 10 minutes, which i haven’t seen before during high alert periods. the coordinate one does max 2 a day, typically only 1 so far unless it really does change.
there’s an old open issue about the state flickering back and forth between unavailable and good state but i don’t see the error in my logs. i think my local nws just not very bright.
Are the alerts labeled as “actual” or “update”? I had multiple severe thunderstorm warnings recently but a lot of them were updates. I had to add a condition to my notification logic to only alert me on actual alerts.
The only thing I can see is if the nws alert system might be in & out for the unavailable issue.
have you looked at the actual sensor states to see if it is indeed going to unavailable and back?
also there should be an attribute that has an event_id. You can check that to see if the alert is being updated/newly added or not.
if the event_id is not changing you can filter out the old event using that event_id in an automation. You’ll need to create a new sensor to hold all of the old event_id’s to compare against tho…I think…
I think I have an example of doing that at my github repo.
Just a heads up for users of my NWS Alerts integration…
I don’t know if anyone here knows just how much I hate breaking changes (except one of you ) but at some point to improve things those breaking changes are necessary. I’ve really resisted it but I think it’s now at that point.
The alerts attributes have been a mess since the beginning of this integration. Don’t get me wrong, the integration has worked fairly well over the many years it’s been around. But I have to admit that the way the alerts are organized leave a lot to be desired.
So that will soon be changing.
The integration will substantially work exactly the same way it has been functionality-wise. All of the same data will be available but it will just be organized differently.
All of the alerts will be in a list with each alert list item containing a dictionary of all the alert data
here is an example from my test install to show you the new layout of alert attributes:
attribution: Data provided by Weather.gov
Alerts:
- Event: Excessive Heat Warning
ID: 54fe074c-e94f-1b02-44d9-420b89b4e491
URL: >-
https://api.weather.gov/alerts/urn:oid:2.49.0.1.840.0.049a16ccd015f19aff9308e2e48a1761bd1a7d1b.003.1
Headline: EXCESSIVE HEAT WARNING REMAINS IN EFFECT UNTIL 8 PM PDT FRIDAY
Type: Update
Status: Actual
Severity: Severe
Certainty: Likely
Onset: '2024-07-25T02:48:00-07:00'
Expires: '2024-07-25T15:30:00-07:00'
Description: |-
* WHAT...Dangerously hot conditions with temperatures up to 114
expected.
* WHERE...San Gorgonio Pass Near Banning.
* WHEN...Until 8 PM PDT Friday.
* IMPACTS...Heat related illnesses increase significantly during
extreme heat events.
Instruction: |-
Drink plenty of fluids, stay in an air-conditioned room, stay out of
the sun, and check up on relatives and neighbors.
- Event: Heat Advisory
ID: b4720aeb-1fbf-e089-8d29-7b5c3bb9d8ce
URL: >-
https://api.weather.gov/alerts/urn:oid:2.49.0.1.840.0.049a16ccd015f19aff9308e2e48a1761bd1a7d1b.006.1
Headline: HEAT ADVISORY REMAINS IN EFFECT UNTIL 10 PM PDT THIS EVENING
Type: Update
Status: Actual
Severity: Moderate
Certainty: Likely
Onset: '2024-07-25T02:48:00-07:00'
Expires: '2024-07-25T15:30:00-07:00'
Description: |-
* WHAT...High temperatures in the 90s to 102 below 5000 feet
expected.
* WHERE...Riverside County Mountains and San Bernardino County
Mountains.
* WHEN...Until 10 PM PDT this evening.
* IMPACTS...Hot temperatures may cause heat illnesses.
Instruction: |-
Drink plenty of fluids, stay in an air-conditioned room, stay out of
the sun, and check up on relatives and neighbors.
I think we can all agree that the new layout will be WAY more readable and all the data will be more accessible via templates than using a whole bunch of splits/etc the way it is now.
OTOH, the package (sensors, automations, scripts, etc) will need a major rewrite as well. And that’s what I want to get ironed out before releasing the updated integration into the wild.
But if anyone wants to try it out you can find it in the dev branch of my github.
Anyone that does try it out let me know if you like or dislike the new changes and if you have any suggestions either way.
And also be aware that, as can be seen in the example above, I’ve removed the “spoken_desc” data from alert attributes since all it was was just a copy of the headline anyway. And the headline data is still included.
And again thanks immensely to @firstof9 to do the heavy-lifting on finalizing the new changes. I couldn’t have done it without them.
2 Likes
Always happy to help man 
1 Like
Hi. Would like to help test but not sure how to download the dev version using HACS. Can you please point me in the right direction.
Thanks.
I don’t think you can use HACS to download it. AFAIK, I would have to draft a beta release but I’ve never done it and I’m not really sure how.
So that said I don’t plan to make the dev version downloadable via HACS so you’ll need to do it manually.
just download the zip file of the dev branch, unzip it and put the nws_alerts folder in your custom_components folder to replace the current one there. Then restart HA. It’s fairly easy.
I’ve just officially released the updated version of the integration.
I’ve also updated the example automations, etc package and the dashboard code to use the new alert attribute structure.
I’ve tested it pretty extensively and I’m fairly sure everything works but I may have missed something so of course let me know if there are issues.
As far as the automations are concerned I’m not sure why but I’ve always made the assumption in the past that any new alert would be at the top of alerts list (index 0) but during my testing I’m not 100% sure that’s correct.
So I’ve changed the automations to send notifications and announcements about all alerts. Obviously it would get annoying to hear the same alerts over and over so I’ve built-in a history of all notified & announced alerts and if any “new” alert is already in those lists the alert gets ignored in the notifications and announcements.
Hopefully it will be more reliable in sending notifications of important info without any false repeat alerts.
6 Likes
Since it’s storm season here in AZ, I’ve been able to confirm the first entry is the latest NWS alert.
The dict for Alerts does make things a bit easier to parse out too. 
1 Like
I figured as much but the issue I seemed to run into in testing is if several alerts were issued at the same time then you couldn’t always ensure the first one would be the worst one.
Example, I had for testing a zone in California that had more than one of each heat advisories, heat watches, air quality alerts, then later severe thunderstorm watches and warnings - there were 12 active alerts at one time. and in my subjective opinion the thunderstorm warnings were more important than the thunderstorm watches which were more important than the heat advisories were more important than the air quality alerts but those were all intermingled amongst each other.
So even if (as we assumed) that the newest was the first in the list if we limit the announcement to the first then we might still miss something more important that might have gotten issued essentially simultaneously with something less important and it ends up being further down.
That’s why I use the queued mode for my alerts so they all get in.
1 Like
Here is an example of the state changes over the last week.
The jumps from 2 to 3 to 4 to 5 etc might be able to be handled ok by a queued automation. The jump directly 2 to 5 or from 6 to 8 couldn’t be.
And TBH, I’m pretty sure some of those 1 step state changes were when a few old alerts expired and they were replaced en masse by their newly sent replacements. so 4 might have all expired at once then 5 might have been sent at once.
That assumption is supported by me getting multiple persistent notifications and mobile notifications all at once for based on each alerts unique ID.
Of course for a “normal” severe weather event it’s not likely to get more than one alert at a time so the queued method would be perfectly fine. But unfortunately the times we are in now are getting less “normal” all the time. 
1 Like
I know you deleted your post but just in case you still needed it there is an example of the new data structure in post 545 above.
Thanks, yeah, after I posted my question I happened to scroll up and saw it, so deleted the useless post
1 Like
I’m a bit lost with the new version and hoping some kind person can nudge me toward a working card again.
I have been using a conditional card that pops up only when there is an alert and it has been working great for a long time.
Now that I have tried to do it with the new version I can’t seem to figure it out.
card:
content: |
{% if states.sensor.nws_alert_event.attributes.features[0] is defined %}
Headline
{{states.sensor.nws_alert_event.attributes.features[0].properties.headline }}
Details
{{states.sensor.nws_alert_event.attributes.features[0].properties.description }}
Instructions
{{states.sensor.nws_alert_event.attributes.features[0].properties.instruction }}
{% else %}
{% endif %}
type: markdown
theme: AMOLED Blue
conditions:
- entity: sensor.nws_alert_event
state_not: none
type: conditional
Can anyone tell me what I’m missing?
Thanks
You’ll want to use state_attr('sensor.nws_alert_event','Alerts')[0].
Edit:
Further examples:
state_attr('sensor.nws_alerts', 'Alerts')[0].Event
state_attr('sensor.nws_alerts', 'Alerts')[0].Headline
1 Like
You can still use your current format but you’ll need to use the correct attributes.
card:
content: |
{% if states.sensor.nws_alert_event.attributes.Alerts[0] is defined %}
Headline
{{states.sensor.nws_alert_event.attributes.Alerts[0].Headline }}
Details
{{states.sensor.nws_alert_event.attributes.Alerts[0].Description }}
Instructions
{{states.sensor.nws_alert_test.attributes.Alerts[0].Instruction }}
{% else %}
{% endif %}
type: markdown
theme: AMOLED Blue
conditions:
- entity: sensor.nws_alert_event
state_not: none
type: conditional
That is all assuming your sensor is called “nws_alert_event”.
But as noted above you should probably change it to the recommended format.
Also, I don’t know if you have looked at the other folders at the github repo but there you’ll find an example markdown card for your dashboard.
Your card above will only ever show the first event in the alert list but the one at the repo will show all of the alerts.
I am replying only in hope that someone posts a good working example of a replacement for what I had before the update. I want a Lovelace card for alerts but with the new thing I have nothing.