Topic: Heads-up USA alerts.weather.gov is changing.. script updates are required.

[mkutche]

You can use https://alerts.weather.gov/search?zone=ssZnnn or ssCnnn to check if there's an alert posted for the specific forecast or county zone

Your Settings.php shows

$SITE['NWSalertsCodes'] = array(
"Owen Co.|INZ053|INC119|",
);

Checking both those shows the API has no current alerts for them.  Keep in mind that 'Special Weather Statement' may not appear in the api, but does show (oddly enough) in the forecast.weather.gov for your location.

ah turns out we arent in a special weather statement but hazardous outlook lmao long day.. it's working fine thanks Ken!

Mike

[Mark / Ohio]

The changes must have come to my area over the past couple of weeks.  I'm getting an error on them at the atom top warning of my personal page.  Also messed up my pulling of the alerts via IFTTT to post of Facebook and Twitter.  I have not really dug into it yet.  But wondering if this might be the end of using a service such as IFTTT to post the warnings over to social media.  I've had concerns for sometime now the way the social media handles them if people are even getting the the warning posted soon enough to their time lines to be of any good to them.

We had a tornado warning here early morning hours last week and my good ole weather radio woke me up a good 5 minutes plus of the coming storm before any alerts came to my phone by any other means.  By the time my phone went off the gust front of the storm was already here.

[saratogaWX]

atom-top-warning.php and atom-advisory.php no longer work due to changes at alerts.weather.gov.

Only the nws-alerts script set works now.

[fdrtech]

I have an advisory stuck also. It expired Friday but I can't remove it. Is it related? I updated the scripts.
I had to also change to WU forecasts since NWS won't show. I checked my logs and it's not a spamming issue.
Also, the NWS radar works on the front page but not the radar page.

weather.fdrtech.com

[saratogaWX]

So.. running check-fetch-times.php shows 403-Forbidden on all your accesses to weather.gov for data.
That's why your NWS forecast (using advforecast2.php), NWS alerts (using nws-alerts), and the wxnwsradaar.php pages are all failing.
The front-page NWS radar works because the browser (not your webserver) is accessing the animated GIF file at the NWS directly.

It seems your webserver at 198.187.29.141 has been placed by the NWS on the block list -- likely for excessive traffic/requests.
Generally, an auto-block will be removed after a few hours of 'normal' activity.  You should contact nco.ops@noaa.gov and ask them to check/address the issue.

[fdrtech]

So.. running check-fetch-times.php shows 403-Forbidden on all your accesses to weather.gov for data.
That's why your NWS forecast (using advforecast2.php), NWS alerts (using nws-alerts), and the wxnwsradaar.php pages are all failing.
The front-page NWS radar works because the browser (not your webserver) is accessing the animated GIF file at the NWS directly.

It seems your webserver at 198.187.29.141 has been placed by the NWS on the block list -- likely for excessive traffic/requests.
Generally, an auto-block will be removed after a few hours of 'normal' activity.  You should contact nco.ops@noaa.gov and ask them to check/address the issue.

That what it was. But, a perm ban for now.

[saratogaWX]

You can turn off the multiple accesses of nws-alerts (2 for each of the 2 zones) by changing to $noCron = false in nws-alerts-config.php .. that will cut out 4 accesses that fail on each page load.  Since you've already switched to WU/TWC for your forecast script (WC-forecast.php), no forecast fetches to the NWS will be done.  That just leaves the one access used by wxnwsradar.php at each page load.

I didn't find any other DNS registered sites on 198.187.29.141, but that address is likely an egress site for your hoster as your website is on weather.fdrtech.com at  198.187.29.145, so some other sites hosted by your hoster may be the root-cause of the NWS block.

Longer term, I'd suggest ditching your current hoster and getting a VPS server where bad neighbors don't cause issues.

[PSJohn]

Question about the alert update... Ever since this new script update there is a discrepancy concerning the Effective and Expires date. If you look at the photo attached the Effective date seems to be when the script first receives the alert. the alert expire date has no meaning. And in this alert when 3:30pm 3/22 comes around the script will update these dates.

The alert effective times are 3/23 from 8am to 11pm. Should the Effective & Expires labels represent this?

Is this a Script issue? Or possibly a NWS issue.

Thanks in advance,
John

 [ You are not allowed to view attachments ]

[saratogaWX]

I think it's a NWS issue.  The Alert itself shows

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<alert xmlns="urn:oasis:names:tc:emergency:cap:1.2">
    <identifier>urn:oid:2.49.0.1.840.0.3a13a67ee8034637aeeeb8bd54a8ab69c4822c58.002.1</identifier>
    <sender>w-nws.webmaster@noaa.gov</sender>
    <sent>2024-03-22T02:35:00-07:00</sent>
    <status>Actual</status>
    <msgType>Alert</msgType>
    <scope>Public</scope>
    <code>IPAWSv1.0</code>
    <info>
        <language>en-US</language>
        <category>Met</category>
        <event>Wind Advisory</event>
        <responseType>Execute</responseType>
        <urgency>Expected</urgency>
        <severity>Moderate</severity>
        <certainty>Likely</certainty>
        <eventCode>
            <valueName>SAME</valueName>
            <value>NWS</value>
        </eventCode>
        <eventCode>
            <valueName>NationalWeatherService</valueName>
            <value>WIY</value>
        </eventCode>
        <effective>2024-03-22T02:35:00-07:00</effective>
        <onset>2024-03-23T08:00:00-07:00</onset>
        <expires>2024-03-22T15:30:00-07:00</expires>
        <senderName>NWS San Diego CA</senderName>
        <headline>Wind Advisory issued March 22 at 2:35AM PDT until March 24 at 11:00PM PDT by NWS San Diego CA</headline>
        <description>* WHAT...West winds 30 to 40 mph with gusts to 65 mph expected.

* WHERE...Riverside County Mountains, San Diego County
Mountains, Coachella Valley, San Diego County Deserts and San
Gorgonio Pass Near Banning.

* WHEN...From 8 AM Saturday to 11 PM PDT Sunday.

* IMPACTS...Gusty winds could blow around unsecured objects. Tree
limbs could be blown down.

* ADDITIONAL DETAILS...Areas of reduced visibility in the desert
from blowing dust.
</description>

[K6GKM]

I think it's a NWS issue.  The Alert itself shows

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<alert xmlns="urn:oasis:names:tc:emergency:cap:1.2">
    <identifier>urn:oid:2.49.0.1.840.0.3a13a67ee8034637aeeeb8bd54a8ab69c4822c58.002.1</identifier>
    <sender>w-nws.webmaster@noaa.gov</sender>
    <sent>2024-03-22T02:35:00-07:00</sent>
    <status>Actual</status>
    <msgType>Alert</msgType>
    <scope>Public</scope>
    <code>IPAWSv1.0</code>
    <info>
        <language>en-US</language>
        <category>Met</category>
        <event>Wind Advisory</event>
        <responseType>Execute</responseType>
        <urgency>Expected</urgency>
        <severity>Moderate</severity>
        <certainty>Likely</certainty>
        <eventCode>
            <valueName>SAME</valueName>
            <value>NWS</value>
        </eventCode>
        <eventCode>
            <valueName>NationalWeatherService</valueName>
            <value>WIY</value>
        </eventCode>
        <effective>2024-03-22T02:35:00-07:00</effective>
        <onset>2024-03-23T08:00:00-07:00</onset>
        <expires>2024-03-22T15:30:00-07:00</expires>
        <senderName>NWS San Diego CA</senderName>
        <headline>Wind Advisory issued March 22 at 2:35AM PDT until March 24 at 11:00PM PDT by NWS San Diego CA</headline>
        <description>* WHAT...West winds 30 to 40 mph with gusts to 65 mph expected.

* WHERE...Riverside County Mountains, San Diego County
Mountains, Coachella Valley, San Diego County Deserts and San
Gorgonio Pass Near Banning.

* WHEN...From 8 AM Saturday to 11 PM PDT Sunday.

* IMPACTS...Gusty winds could blow around unsecured objects. Tree
limbs could be blown down.

* ADDITIONAL DETAILS...Areas of reduced visibility in the desert
from blowing dust.
</description>

I believe the script might be asking for/displaying the wrong time variable.  Should it not be the "Onset" time rather than the "Effective" time?

[saratogaWX]

According to the documentation has the following meanings:

Effective

Description

The effective date and time of the information in the alert message.  In other words, the CAP message itself (i.e., the alert) is effective at the time it is sent.   

<effective> should not be confused with any use of “effect” and/or “effective” terminology in the plain language text of the alert because they may not have the same meaning.  The <effective> date and time may also not be the same as the <onset> date and time which reflects the beginning of the subject event in the alert message.   

Onset

Description

Expected time of the beginning of the subject event in the alert message.  The value for <onset> may be the same as that for <effective> when the event is already occurring or imminent.

Expires

Description

The expiration date and time of the information in the alert message. This is the time at which the information in the message should be considered stale and no longer used.  The NWS forecaster will update or cancel the alert by the <expires> time.  <expires> should not be confused with any use of “expire” and/or “expiration” terminology in the plain language text of the alert because they may not have the same meaning.  The <expires> date and time may also not be the same as the <eventEndingTime> parameter which reflects the expected end time of the event in the alert message. 

eventEndingTime

Description

The expected end time of the subject event in the alert message. This is the time at which the hazard conditions of the subject event are no longer expected.

The issue is not all events have eventEndingTime data ..
For example, your specific alert has

<onset>2024-03-23T08:00:00-07:00</onset>

and does have

       <parameter>
            <valueName>eventEndingTime</valueName>
            <value>2024-03-24T23:00:00-07:00</value>
        </parameter>
 

but not all do.

I stuck with Curly's Onset and Expires to not second-guess the NWS as they changed to CAP 1.2 AND moved alerts.weather,gov to api.weather.gov for sourcing. 

[weatherdoc]

I think it's an issue on the NWS side. Yesterday they issued a Flood Watch for my county for today, Saturday, yet it "Expired" at 7:30PM on Friday. I've seen that issue twice in the past month or so. This morning it looks good:

Effective: Sat, 3/23 6:23am
Expires: Sat, 3/23 2:00pm

And the text of the bulletin states "* WHEN...Until 2 PM EDT this afternoon."

[tmabell]

I think my approach to begin with might be to compare the data returned by the NWS Alerts API with the VTEC coding contained in the full text message for that product.  In your case it can be found here:  https://forecast.weather.gov/product.php?site=NWS&product=NPW&issuedby=SGX 

[Jasiu]

Yesterday they issued a Flood Watch for my county for today, Saturday, yet it "Expired" at 7:30PM on Friday. I've seen that issue twice in the past month or so. This morning it looks good:

Effective: Sat, 3/23 6:23am
Expires: Sat, 3/23 2:00pm

And the text of the bulletin states "* WHEN...Until 2 PM EDT this afternoon."

Again, see what Ken included above. "Expires" just refers to the alert itself, not the event. At the expiration time, the office should issue an updated alert or cancel it entirely.

I include this sort of text in my alert displays to make it clear:

Urgency: Future
Severity: Severe
Certainty: Possible
Alert Sent: Saturday 3:48am EDT
Alert Effective: Saturday 3:48am EDT
Alert Expires: Saturday 4:45pm EDT (expect updated alert by this time)
Event Onset: Saturday 8:00am EDT
Event Ends: Sunday 8:00am EDT
Issued by: NWS Boston/Norton MA

These are the times from the JSON for that alert (also a flood watch):

Code: [Select]


        "sent": "2024-03-23T03:48:00-04:00",
        "effective": "2024-03-23T03:48:00-04:00",
        "onset": "2024-03-23T08:00:00-04:00",
        "expires": "2024-03-23T16:45:00-04:00",
        "ends": "2024-03-24T08:00:00-04:00",
When expires and ends are the same, that's just luck because it's the last alert that will be issued for the event.

[tmabell]

I'd do that comparison the next time it seems out of wack before I came to that conclusion.  Good luck!

[tmabell]

EDIT:  For now I've changed "Expires:" to "Next Update:"

I've thought more about this concern and I understand the logic but I wonder if we are not using "expired" the way it was intended.  John, your solution is to explain what "expires" means in this context.  I have taken a similar approach. In the script, I changed "Expires:" to "This Statement Expires:" but that is just as misleading. I don't think that is the best solution. I think we need to change what data we put there to reflect the actual event end time.  I feel as though the "expires" data in the API is there to define when that data becomes stale and to let the audience know that there should be something newer by that time, not to display an event end time.

Ken, I hope you'll revisit this at some point because as John pointed out, it causes confusion.

[PSJohn]

EDIT:  For now I've changed "Expires:" to "Next Update:"

I just had a visitor to my site email me and informed me of "an error" in a Wind Advisory notice. The NWS posted it today(Tuesday), Advisory: "WHEN...From 5 PM Wednesday to 11 PM PDT Friday." They assumed it was in effect now!
So there you go, funny how we spoke of this last month and how I got confirmation on the "public" getting confused about it! I understand why the NWS uses the Alert dates. But it can confuse the public"

I changed mine to This Notice Updated & Next Update.