Severe Weather Alerts from the US National Weather Service

[dhostetter]

Sorry if this is posted and I missed it.
I’m not a coder, just a tinkerer.
Can someone post the code just to display the events?

Alerts:

• Event: Red Flag Warning <<<<<< Just this Part
  ID: 3015b018-039a-308e-ecc8-4da33b6b2551
  URL: >-

I’ve played around and can’t get it to work.

This is the code I use to use:

type: markdown
content: >-
  {% set num_alerts = states('sensor.nws_alerts') | int  %} {% for alert_num in
  range(num_alerts) %} --- # NWS Alert {{ alert_num + 1 }}
    {% if state_attr('sensor.nws_alerts', 'title').split(' - ')[alert_num] is defined %}
    {{ state_attr('sensor.nws_alerts', 'display_desc').split('\n\n-\n\n')[alert_num] }}
    {% else %}
    none
    {% endif %}
  {% endfor %}type or paste code here

[finity]

this should get you close:

- type: markdown
  content: |
    {% set num_alerts = states('sensor.nws_alerts') | int  %}
    {% for alert_num in range(num_alerts) %}
    ---
    # NWS Alert {{ alert_num + 1 }}
      
    ## {{ state_attr('sensor.nws_alerts', 'Alerts')[alert_num].Event }}
    {% endfor %}

[finity]

As soon as I started trying to figure out what might be happening it stopped doing it. the only thing I saw at the time was that the state (number of active alerts) was going back and forth between 1 & 2.

But now that it’s stopped doing that I’m fairly certain that it’s the NWS feed that was the culprit.

The way the new code works is it looks at the attributes in the “from” sensor condition and compares it to the attributes in the “to” sensor condition. if the “to” ID isn’t in the “from” list it assumes it’s a new alert.

that works fine as long as any new alert is issued with a new ID. but if for some reason an active alert goes missing from the active alerts list that alert id attributes gets removed from the list. then if it later gets re-activated but with the same alert ID, the new code has no way of knowing that it’s just a reissue of an already existing alert and it’s not a “new” alert (because it’s not in the list of the “from” alerts).

you could use a hybrid of the two code schema’s and start using the event ID variable list to filter on.

But TBH it’s likely a rare occurrence for the NWS API to glitch like that so I’m not sure it’s worth the trouble.

[beyondunreal79]

Would anyone know how to make an auto dismiss for the persistent notification? Basically when the number of alerts change to 0, dismiss the notification.
Thx

[finity]

I don’t use it so I’ve never tested it but in the original “alternative automations” suggested it included a way to dismiss the persistent notifications.

it’s the first action in the below automation:

alias: NWS - Persistent Notifications
description: ""
trigger:
  - platform: state
    entity_id: sensor.nws_alerts
condition: []
action:
  - repeat:
      sequence:
        - action: persistent_notification.dismiss
          data:
            notification_id: NWS_{{ repeat.item }}
      for_each: >-
        {{ trigger.from_state.attributes.Alerts | map(attribute='ID') |
        reject('in', trigger.to_state.attributes.Alerts | map(attribute='ID')) |
        list() }}
  - repeat:
      sequence:
        - action: persistent_notification.create
          data:
            notification_id: NWS_{{ repeat.item.ID }}
            title: "NWS: {{ repeat.item.Headline }}"
            message: |
              {{ repeat.item.Description }} {{ repeat.item.Instruction or "" }}
      for_each: "{{ state_attr('sensor.nws_alerts','Alerts') }}"
mode: queued
initial_state: "on"
max: 10

[beyondunreal79]

Hmm, I tried this, but so far the automation hasn’t triggered and we have had a few alerts. Anyone use this one and got it working? Thx

[finity]

@beyondunreal79

the automation hasn’t triggered

do you know for a fact that the automation hasn’t triggered? or has it triggered and just not created the persistent notifications?

that is an important difference in where to look for troubleshooting.

since the automation above doesn’t include an “id” it’s not likely for any traces to be available. Unless you added one yourself.

if not then add one to the automation manually. it doesn’t matter where you put it as long as the indentation is correct. and it doesn’t matter what the id is as long as it’s unique in the system. I always make my id’s the entity name so I know it’s unique.

so something like this:

alias: NWS - Persistent Notifications
id: nws_persistent_notifications
description: ""
trigger:
  - platform: state
    entity_id: sensor.nws_alerts
condition: []
action:
  - repeat:
      sequence:
        - action: persistent_notification.dismiss
          data:
            notification_id: NWS_{{ repeat.item }}
      for_each: >-
        {{ trigger.from_state.attributes.Alerts | map(attribute='ID') |
        reject('in', trigger.to_state.attributes.Alerts | map(attribute='ID')) |
        list() }}
  - repeat:
      sequence:
        - action: persistent_notification.create
          data:
            notification_id: NWS_{{ repeat.item.ID }}
            title: "NWS: {{ repeat.item.Headline }}"
            message: |
              {{ repeat.item.Description }} {{ repeat.item.Instruction or "" }}
      for_each: "{{ state_attr('sensor.nws_alerts','Alerts') }}"
mode: queued
initial_state: "on"
max: 10

now all that said if your automation does have an id then you can look at the traces for it to tell you what happened if it’s not working as expected.

[sperryharris (leosperry)]

I am the developer of HaKafkaNet and I have to say THANK YOU FOR VERSION 5! It is so much easier to implement. I’ve created a pull request in the git repo to add a couple of attributes that I think will benefit many people, especially the Urgency property.

[beyondunreal79]

I did some more digging. The automation is triggering. The first half (dismiss Persistent notification works) its the creation of the new persistent notification that doesnt work.i know that the dismiss works because i still have the other create persistent notification (no dismiss) automation running. So basically, that one is creating them and the other dismisses them, but doesnt create a new one. Otherwise i’d be getting two persistent notifications. (Since i have two automations running)

This is the error i get on the trace:

Here is my entire automation yaml that i used:

EDIT: I created this automation from the HA automation section, not in the NWS yaml package. Not sure if that matters.

alias: NWS - Persistent Notifications - auto dismiss
description: ""
triggers:
  - entity_id: sensor.nws_pheasant_alerts
    trigger: state
conditions: []
actions:
  - repeat:
      sequence:
        - action: persistent_notification.dismiss
          data:
            notification_id: NWS_{{ repeat.item }}
      for_each: >-
        {{ trigger.from_state.attributes.Alerts | map(attribute='ID') |
        reject('in', trigger.to_state.attributes.Alerts | map(attribute='ID')) |
        list() }}
  - repeat:
      sequence:
        - action: persistent_notification.create
          data:
            notification_id: NWS_{{ repeat.item.ID }}
            title: "NWS: {{ repeat.item.Headline }}"
            message: |
              {{ repeat.item.Description }} {{ repeat.item.Instruction or "" }}
      for_each: "{{ state_attr('sensor.nws_alerts','Alerts') }}"
mode: queued
initial_state: "on"
max: 10

```Preformatted text

[sperryharris (leosperry)]

As mentioned before, I have created a pull request in the github repo which adds a few useful properties.
Added properties based on NWS documentation by leosperry · Pull Request #96 · finity69x2/nws_alerts
One of those properties is “Urgency” which another user has also created a PR for.

I would love to see a new version created with these changes so that I need not worry about conflicts because I have custom code running in my instance.

Again, Thank You. This really is an awesome integration!

[finity]

My problem with creating an attribute for every single available piece of data is that when multiple alerts are issued the attributes could get so long that HA might not store or report them properly.

I’ve already had this happen a few times where even with the current attributes list that HA complained that the attributes exceeded the max size limit.

prior to the last several releases there was never any limit to how big the attributes were so it was no problem adding more data there. then they added restrictions I believe to save disk space and improve system performance. Now there is a limit (16.5kb I think I saw).

I don’t really know what being over that limit causes in the system. maybe it’s no big deal but HA is complaining for a reason.

So I’m still trying to decide if I want to add one more attribute or not.

[sperryharris (leosperry)]

Interesting. I think it may be exacerbated by the fact that some properties are inherently longer, and the fact that you don’t know how many alerts will be in the collection.

Thought:
What if, for those longer properties, like description, instead of holding onto it in the state, you hold onto it in the integration and expose a service to get it by ID? That would be a breaking change, but it would go a long way to not hitting that memory cap.

As it stands now, if you’re really that worried about it, I imagine that under some crazy weather conditions, too many alerts will break it anyway, and that’s when you really want to know.

You could also think about truncating really long descriptions and providing a service to get the full value. That way you’d at least be able to calculate your breaking point.

[finity]

@sperryharris

I think it may be exacerbated by the fact that some properties are inherently longer, and the fact that you don’t know how many alerts will be in the collection.

Exactly.

@sperryharris

I imagine that under some crazy weather conditions, too many alerts will break it anyway,

correct, and every extra piece of data that is added makes it more likely that you will reach that limit quicker for less alerts so you are actually more likely to miss something important.

I’ve already added many more attributes than were there originally per other users requests. But there has to be a line somewhere.

@sperryharris

instead of holding onto it in the state,

It’s not held in the state. all of those extra data points are held in the attributes.

if they were in the states then it would really be a problem because states are limited a total of 255 characters.

@sperryharris

expose a service to get it by ID? That would be a breaking change,

I truly abhor breaking changes.

I struggled with the last breaking change even tho I knew it would end up much better afterward.

And even tho I explained all of that a couple of weeks before the release and provided updated code to deal with it in the provided package people still got pretty upset by it. To the point that someone actually tried to get the integration banned from HACS.

Also adding a service would make it more complicated to get the data than it is right now. just look at the hoops we have to jump thru now to get the weather forecasts that was easily provided by attributes before.

and again that’s assuming I could even figure out how to code that.

So since the integration works pretty darn good the way it is right now (with some known limitations for the edge cases) I really don’t think changing it like that is going to happen.

If people really want all the attributes (called “features” & “properties” in the API return data) then there is already a way for you to get everything.

just use a REST sensor calling the same API endpoint that the integration does and you will get everything completely unfiltered. Then you can parse that however you want to get any data you want out of it.

but you will still run up against the memory limit if a lot of alerts come in at once since it still puts everything into the attributes.

That’s actually the way I originally got the information before the integration was created.

here is the REST sensor if you want to play around with it (make sure you put in your own zone, etc, data):

sensor:
  - platform: rest
    resource: https://api.weather.gov/alerts/active?zone=INZ009,INC033
    name: NWS Alert Event Raw
    value_template: >
      {% if value_json.features[0] is defined %}
        {{ value_json['features'][0]['properties'].event }}
      {% else %}
        None
      {% endif %}
    json_attributes:
      - features
    headers:
      User-Agent: Homeassistant
      Accept: application/geo+json
    scan_interval: 60

[sperryharris (leosperry)]

@finity

@sperryharris

instead of holding onto it in the state,

I should have been more clear. I meant “state” as in the “state object” which has a property called “state”. HA didn’t make a very good design decision there.

@finity

To the point that someone actually tried to get the integration banned from HACS.

What the actual what?! Here you are making something AWESOME and some trolls gotta troll. I feel for you. If the breaking change is for the better of the community, so be it. They can stay on on unsupported version if they feel that strongly.

To be honest, because of the limit that HA has imposed, there’s not a lot of good choices here. While it would be clunky, the service call seems the only way to guarantee that it won’t break. While I’m not much of a python developer (C# is my bag) I might give it a go.

@finity

here is the REST sensor if you want to play around with it

I might play with that sensor. Thanks!

[finity]

@sperryharris

While I’m not much of a python developer (C# is my bag) I might give it a go.

Obviously feel free if you want but just don’t expect it to get implemented as a PR.

I’m not saying no way at all but I’m really leaning hard that direction. Unless it can be implemented and make things WAY easier then there might be a case to be made but you’ll have to make the case.

just keeping it

[Anwen]

I am horrified that someone would try to get this banned from HACS. I think you handled the breaking changes really well, and you have provided all kinds of examples which are really helpful. Just wanted to say thank you for all your hard work on this integration. I have been using it for a long time and find it really useful. I am grateful that you created it, maintain it, and are so responsive to questions. Well done

[beyondunreal79]

Did something happen to the NWS integration? Mine for the last 3 days keeps going into unavailable, then back to normal. Anyone else have this happen?

[finity]

No I haven’t seen anything like that.

I have two locations set up for the integration and neither have shown unavailable in the last three days.

it’s possible that the local weather service for your location has been having problems. But neither NE Indiana or somewhere in California are having issues.

[beyondunreal79]

This is interesting because i installed the other weatheralerts from hacs last night and its doing the exact same thing at the same time. Even tried it on my “test” HAOS box that i use for tests and experiments. Is there any way for me to the the NWS official api that these apps use?

Here is a snippet from HA logs: Any other troubleshooting advice?

The 2nd pic is the other weather alerts from hacs

[finity]

@beyondunreal79

Is there any way for me to the the NWS official api that these apps use?

I don’t know what the other integration uses but for this one if you look at the end of my last post above from 6 days ago there is a sensor you can create that polls the API directly and returns completely unfiltered results.

But I don’t think that will tell you much since two integrations are failing in the same way at the same time.

It has to be a glitch in the weather service for the zones/locations you are calling.