I just released the latest version of the integration (v6.0) based on the conversation above.
it contains a very minor breaking change but it is a breaking change nonetheless.
I put the instructions for the change mitigation in the release notes but I’ll copy them here as well for completeness.
Minor Breaking Change
After installing this update your sensor Unique ID and Entity ID will likely change.
The integration will likely create a new sensor entity that will have “_alerts” appended to the new entity ID. If you used the default naming for the original sensor the new sensor will be called “sensor.nws_alerts_alerts”.
You can either choose to fix the new sensor entity_id to match the old one or update all of the locations in which you use the sensor to the newly updated entity_id. Either way you will need to delete the old unavailable entity_id. Fixing the new entity_id is the easiest in my opinion.
To fix the entity_id simply open the integration and navigate to the entities list.
You should now see that there are three entities associated with the updated integration - if there are only two then this likely doesn’t apply to you. As you can see I’ve already fixed one of my test integration instances so it only has two entities now.
Select the old sensor entity. It will be the one without the “_alerts” added to the end and it will have a red circle icon at the right (indicating it is now “unavailable”).
You can now go back to the prior entities list (there should now be only two entities listed) and edit the entity_id of the newly created sensor and just remove the “_alerts” from the end.
The changes should stop those annoying “re-alerts” when the API becomes available once more. Although few and far between for myself, I’m sure others have had more unstable API calls where it would re-trigger their automations and fire off the alerts again and again.
I successfully renamed my alerts sensor, and have two entities showing for the integration. But if I look at Dev Tools - States, I have sensor.nws_alerts_last_updated which is unknown, and sensor.nws_alerts_last_updated_2, which has today’s date. I cannot delete the unknown sensor. There is also an update sensor, but there is only one of those. I tried restarting HA, but it didn’t change. I am on HA 2024.12.5.
Thanks for continuing improvement on the integration, much appreciated.
If you can’t delete it the usual way you could try deleting the configured instance of the integration (i.e. don’t remove the integration completely just the configured entry), restart and then re-add your configuration via the UI.
Then hopefully it will be all resolved and you can edit the sensor as necessary.
Sorry for the hassle.
Which is why I abhor breaking changes. Even minor ones like this cause troubles.
Thanks for the help. Just to follow up: I removed the config entry, and that removed the integration (maybe because I only had one?) Restarted HA and all the entities still showed in Dev Tools. Added the integration back, now had 3 update entities. Added a second config entry, deleted the first one. Restarted. Now I have 2 update entities: sensor.nws_alerts_last_updated_3 which is currently unknown and associated with the integration, and sensor.nws_alerts_last_updated which is unavailable. When I try to delete that last one, I can’t, because “This entity (‘sensor.nws_alerts_last_updated’) does not have a unique ID, therefore its settings cannot be managed from the UI.” Tried another restart, no change.
I’m not fussed about this, I will just ignore the unavailable entity. Maybe it will magically correct itself I have no active alerts at the moment…I will see what happens next time there is one.
Sometimes with HA that’s the best and only hope that we have.
I have no idea why or how it could work for me and many others 100% and not work at all for you and a few others.
unknown I think makes sense if the first update hasn’t happened. Mine was that way at first then it suddenly populated.
something else you might try is to add a second instance and name it something else in the config UI (maybe “NWS Alerts Duplicate”) and then delete the first one.
after a restart hopefully the old one is gone then you can rename the new one to match the old one.
Problem solved - it was my fault I woke to an alert this morning, and saw that the date formats were different for the two different update entities. It turns out I had created a template sensor called sensor.nws_alerts_last_updated to use in the markdown card I used before the NWS integration had the big update in August. I’ve redone my weather dashboard in the interim, and forgot about having created that sensor. I deleted the template sensor, renamed sensor.nws_alerts_last_updated_3, and all is well.
I’m very sorry to have bothered you. Thanks again for a great integration and your responsiveness and help!
It would really nice to be able to get the code to parse out separate items as separate entities, and then generate a category for each of those with structured information. I.e. category would be “Wind Warning” etc of a limited list.
What I’m trying to do is make an automation that when there are any alerts and those alerts are watch or warning for things that might take out power, set my inverters (EG4) to go on grid, and charge my batteries up to 100% if it can, so that if the grid goes down, I don’t need to use my generator (which more expensive than grid) if it’s dark for a few days and the solar won’t power the home.
I guess I could parse the above from attributes and get nasty with this info, but it would be nice to do this in the python where you have way more power to do the work. (sad that NWS doesn’t provide a category of alert by default…)
I mean if we just had 10 alerts that should be more than enough, and then put all of the values into those, and assign a category entity for each along with the other values.
In the mean time, anyone have any suggestions on how to setup those types of conditions so that my automation executes only on things like tornado, wind, blizaard, hail, etc?
Have you looked at the package files in the github repo? there are examples there that you should be able to use as a basis for what you want to do.
as far as splitting up the sensor into different entities per alert that’s not going to happen.
it would be a bear to program keeping track of creating and removing the sensor entities for each alert as they come and go. Then I also think actually acting on those sensors being created and/or removed would be impossible since most times you need to provide an entity_id to act in response to or upon in an automation. You have to provide a specific entity to watch for state changes. unless the integration provides an event to act on. But that would get hairy to program as well.
the bottom line is that I think the way it’s set up now is the easiest to work with on both ends.
Just as an FYI for everyone, this user was the OG NWS Alerts custom integration developer before I took it over and modified it based on their initial framework. This project was originally based on a REST API call but they converted that functionality into a proper integration.
So everyone should thank them for their initial work since without that work this integration wouldn’t exist and we would still be using a REST sensor to interact with the API.
The alerts have been working great for me so I haven’t felt the need to be active.
Thanks for all the work you’ve done and continue to do on this project!
I just added this service to my setup but I am having an issue getting the Persistent Notification automation to work. I am receiving this error message → Error: UndefinedError: ‘dict object’ has no attribute ‘to_state’ and I haven’t been able to figure why or how to get past it. Any ideas on what I might try?
Even minor ones like this cause troubles.
I have no active alerts at the moment…I will see what happens next time there is one.
I woke to an alert this morning, and saw that the date formats were different for the two different update entities. It turns out I had created a template sensor called 
