I can check.
I know I haven’t updated the info for the package in a while tho. But I really don’t think the basic functionality has changed much.
I’ll need to scrub my existing package of any personal info and anything that is “testing” related before I post anything new to the repo.
It shouldn’t take long so I’ll get it updated and let you know.
EDIT: the new package is up now. It was way easier than I thought. 
Shouldn’t be too hard to merge the 2 integrations with an option to use lat/lon over the stations.
Nevermind, I got it. I just needed to add an automation to turn off the boolean when sensor.nws_alerts changes. I didn’t realize that it would trigger with just an attributes change instead of requiring a state change.
I’m a little hesitant to combine the two for reasons I stated above.
I know there is always the standard disclaimer “use at your own risk” but I don’t want someone put at higher risk by them getting confused during configuration and not fully understanding (like I did TBH) that they won’t get the same alerts when using the coordinates than when using the zones.
It’s easy enough for someone to install the other integration if they really feel they need it and at that point they hopefully understand the limitations of that integration.
the zone integration should just be the default.
They could add it twice one for each configuration type, one zoned, one lat/long.
I’m all about adding options to make things more versatile for people 
I’m OK with options too.
that’s why I made the second integration in the first place. 
I really think that the first integration works fine for the vast majority of people or this would have been brought up way before now after over 4 years of this being available.
I may just be being stubborn but I think it should stay the way it is at least for now.
thank you tho.
First, thanks again, finity for the work on the second integration; it’s been working flawlessly.
I have been playing around with the differences between the two methods, and it appears to be just as responsive for severe weather alerts. Although installing the integrations separately is easy, I agree it would be nice to have them merged for simplicity. The coordinate method might also be the better way to poll for severe alerts.
I’ve been researching the general best practice approach to severe weather alerting from commercial providers, and it seems that everyone is using geocoded data for determining alert relevancy these days. The zones are a holdover from the days when weather radios and other non-geolocation-aware devices were the predominant methods for alerting. Using zones may introduce risk differently from too many false alarms or “cry wolf” scenarios resulting in lower utilization of the integrations capabilities. False alarms impacted my appetite for using the integration for weather alerting. Last year, I compared several severe weather events, and for several of them, a warning was not indicated for me (I was in the zone but not the warning polygon). For most integration users, I suspect they are not digging into the precision differences between the zone and the actual alert polygons, so there may not be awareness of the number of false alarm events that are occurring.
Just food for thought, In either case, I respect that it’s your decision on the direction you want to take the project. Here’s a reference, for consideration.
- Warnings should only be sent to users that are physically within the geographic area (polygon whenever possible) as defined by the NWS warning. Users should also have the ability to receive warnings for areas other than their own location, for which they are responsible for monitoring. Alternatively, any message sent to users outside of the NWS- defined geographic area (i.e., polygon, zone) should clearly alert the receiving party that their location is not within the warning.
Thank you for the additional info.
I’ll try to get some time to look further into it and re-evaluate my position. 
wow, i always wondered what was happening there. thanks for this info.
zones vs polygons is definitely interesting. i agree the zones are probably “good enough” and that i’d also rather get alerts of this type more often than i should rather than less often. maybe just a config option for coords, and if that is provided use coords. keep zones the default. people would have to read the docs and make a conscious decision to do it.
thanks for this, though. figured i’d have to roll my own but this looks perfect.
it looks interesting.
Could you put a description of the two methods including the possible limitations of either one?
Sure, any suggested verbiage?
in the first selection box instead of “Please select your NWS lookup method” it could be something like:
Please select your NWS lookup method.
For a brief explanation of the advantages and disadvantages of each method please see here.
If you don’t know which is better for your situation, you should probably select the Zone ID version.
I’ll put the blurb description in the github location so it doesn’t clutter the config.
Then for the selection choices rename them to:
Zone ID (more generalized location)
GPS Location (precise location)
I don’t want to label anything as old or new so it doesn’t give the impression that one will be deprecated at some point.
The above is just based on my preconceived gut feel for now since I haven’t had any time to look into the data provided by Bryan yet (dealing with some remodeling and contractors right now 
). It can easily be changed later if appropriate.
Sounds good, I’ll update the verbiage.
Thank you again for your work on this.
I took a stab a writing up the descriptions for each method: nws_alerts/lookup_options.md at 381bb3f24bb7a99e963c3cf1843a5ce368314b8c · 303Bryan/nws_alerts · GitHub
Due to the differences, you may consider breaking each method (County, Zone, GPS Location) into separate selections for clarity.
I like it.
Can I steal it and put it into the description for my integration?
I may modify it only slightly.
the zone lookup right now will return both zones and counties (at least I’m pretty sure it does) so I’ll add a note to clarify that.
I really don’t want @firstof9 to have to break the integration down any further. He’s already had to do too much work on this.
Totally- I submitted a pull request on it. Steal away.
Agree; it is probably not worth the effort to break it out. I appreciate the effort @firstof9 has put into this.
Here’s the updated verbiage:
Technically we should be sending our “API Key” as well (email address). Should I add a field for this as well?
