Forecast data not currently available

Hi,

I'm assuming your site is now fetching data and that your first comment is not in need of a response.

Regarding the layout issue you mentioned in the second note. I was not able to reproduce the issue you described. Neither the code nor the html are intentionally adding extra whitespace. I would guess a .css conflict is the cause of your layout issue.

The first step to verify that my guess is correct is to enable the NWS forecast module on a page with no other content. If the problem disappears then we can assume a CSS or layout conflict exists on your intended target page.

If a conflict does exist then you may need to remove/disable other content until the conflict goes away to identify which other content is in conflict. Another option might be to use Firefox's Firebug extension (or other similar tool) to debug it in real time.

Good luck.
Dwaine

Hi, I'm wondering if I'm doing something wrong -- I can only avoid this exception if I add the "Unit" parameter ('' | 'e' | 'm') as the fifth parameter to the call to $soapclient->NDFDgenByDay() (line 345 of nws_weather.module). Nobody else seems to be having this issue...

Thanks,
Tim

Well, I'm having the same problem as on the original post here. "Forecast data not currently available" I'm using it for the following coordinates.. 33.555844, -111.548996.

I'm confirming this is definitely a bug happened recently.

I tried two different ways:

1. Tested on two different web servers: one is a PC running at home (server 1); the other one is a web server rented from an ISP (server 2).

2. One server 2, I've just deactivated all non-core modules except NWS Weather and tried by changing default location, message "Forecast data not currently available " still shown up after manually running the cron.

I'm running Drupal 7.8 and using latest NWS Weather (1.2).

http://www.weather.gov/xml/index.php#xml_changes I guess the NWS NOAA has changed their feed in some way. I thought I'd poke around and see, what its going to take to fix it, but I haven't had time. I hope we can get this resolved, because I have it on 1 live site and another site in development. I just want to add... This is a great module! Far better than any weather widget. Very flexible and professional looking.

Here is a patch for what I was describing in #4. I'm pretty sure this is not how the module author would want to do it, but it's really tiny and hopefully it'll help until a proper solution is authored. This hardcodes the response units to the default, which is English.

I had this running just fine, it stopped a few days ago and I am getting my watchdog table absolutely jammed full of the following error:

SoapFault :SERVER. format needs to be either 24 hourly or 12 hourly. triesleft = 0

NWS _did_ change the format of their SOAP function call. The new fifth 'units' parameter is required which broke this module. I've made the simple addition of 'e' to the function call. Here is the updated line of code:
$result = $soapclient->NDFDgenByDay($lat, $lon, $start, $days, 'e', $format);
I'll create a stable release as soon as I figure out how.

Newest stable release 7.x-1.3 is now available. This release fixes the issue caused by the NWS change of the SOAP function call. 6.x stable release with same fix expected tomorrow.

Still having the same issue "Forecast data not currently available" but here is what comes up in watchdog: SoapFault :WSDL. SOAP-ERROR: Parsing WSDL: Couldn't load from 'http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl' : Premature end of data in tag html line 2

The message "Forecast data not currently available" is just a generic failure message. The details are in the verbage following "SoapFault". And it appears that your site is having trouble retrieving the WSDL from NOAA as opposed to the change in SOAP function parameters the latest version of the module addresses.

Is the server in question SOAP enabled? Has it connected successfully before today? The answers to these question will help guide us in our next level of debugging. If this problem persists then it is probably appropriate to start a new issue for your unique bug.

The server appears to be SOAP enabled (see attached). It has connected prior to the NOAA changes without any issues.

I also tried this with a fresh D7 install on the same server and was able to replicate it.

On localhost it behaves as expected. Still strange this happened just recently.

Well, GarretInteractive, I don't have a great answer yet. The issue seems to be isolated to just one of your servers. So that server must interact differently with the WSDL than other servers. I've tested this code on a number of servers and am not seeing the error you are encountering. But I'm curious about the cause and have presented a few ideas based on research around this issue.

1. It is possible that a faulty version of the WSDL was cached on your server. That cached version will likely be cached for 24 hours. If that was the cause of your issue, it has since been refreshed and the code should no longer being throwing errors.

2. It is possible that NOAA made a change to the WSDL that your particular version of PHP cannot correctly parse. This is a long shot but it would explain why just one of your servers is having trouble. But you might look up your exact PHP version via phpinfo() and do a quick search to see if that version had any SOAP or XML related bugs.

3. It is possible that something has changed in the network environment that the troubled server resides in that is wrapping or otherwise modifying the retrieved WSDL document. A test for this would be to retrieve the WSDL using PHP code on the affected server and compare it with a copy of the WSDL retrieved with a browser. This is obviously going to require some PHP coding.

I'm keen on hearing any news you have on this issue since your last report. Good luck.

Here I can replicate it http://www.desertvoyagers.com/rentals.. at the bottom of the main content area there.
I had this working fine. I've got the 7.x-1.3. I've got that line patched:
$result = $soapclient->NDFDgenByDay($lat, $lon, $start, $days, 'e', $format);

Whats going on.

Oops! Sorry, false alarm. This module works right out of the gate. This was from a bad backup.

This error just started showing up on my site.

Warning: SimpleXMLElement::__construct(): Entity: line 1: parser error : Start tag expected, '<' not found in nws_weather_NDFDgenByDay() (line 371 of contrib/nws_weather/nws_weather.module).
Warning: SimpleXMLElement::__construct(): unknown: NUMBER in nws_weather_NDFDgenByDay() (line 371 of /contrib/nws_weather/nws_weather.module).
Warning: SimpleXMLElement::__construct(): ^ in nws_weather_NDFDgenByDay() (line 371 of /contrib/nws_weather/nws_weather.module).

Something must have changed with the way the data is handled?