Weather by Zip Code: THE MODULE

[MyKroFt]

root@pbxtcs:~ $ rpm -qa | grep pear
php-pear-db-1.7.13-2.el5.rf
php-pear-1.8.1-2.el5.centos

need to see if that is newest version

 

[MyKroFt]

i trying and contact pdaweather.org and opendns.org comes up with

root@pbxtcs:/tmp $ nslookup pdaweather.org
Server: 208.67.222.222
Address: 208.67.222.222#53

Non-authoritative answer:
Name: pdaweather.org
Address: 67.215.66.132


Hmm, 67.215.66.132 isn't loading right now.

The computers that run 67.215.66.132 are having some trouble. Usually this is just a temporary problem, so you might want to try again in a few minutes.


Nameserver trace for 67.215.66.132:

• Looking for who is responsible for root zone and followed i.root-servers.net.

Nameservers for 67.215.66.132:

• a.root-servers.net returned (NORECORDS)
• c.root-servers.net returned (NORECORDS)
• k.root-servers.net returned (NORECORDS)
• i.root-servers.net returned (NORECORDS)
• b.root-servers.net returned (NORECORDS)
• h.root-servers.net returned (NORECORDS)
• e.root-servers.net returned (NORECORDS)
• g.root-servers.net returned (NORECORDS)
• l.root-servers.net returned (NORECORDS)
• d.root-servers.net returned (NORECORDS)
• j.root-servers.net returned (NORECORDS)
• m.root-servers.net returned (NORECORDS)
• f.root-servers.net returned (NORECORDS)

so i dunno

 

[tshif]

Thats doesnt seem to be it. I have other machines that are running it just fine even while the new one fails.

The problem is happening as the dail plan hands proccessing over to the script;
exten => s,n,AGI(nvweather-zip.php|${ZIPCODE})(You can find the dail plan in custom_weatherzip.conf)
Perhaps the handoff to the agi process isnt working correctly? That or there is a php function being required by the .php script being called?

 

[MyKroFt]

i execute a

/var/lib/asterisk/agi-bin $ ./nvweather-zip.php 59937

from the command line and it just sits there until I ctrl-c out of it

so it is something in the php script

 

[tshif]

Ok - when I enable the debug in the nvweather-zip.php, no logs gets written. It sounds like that script isnt being called properly. Or, if it is, its crashing before it's ready to log anything. That script hasn't changed in a couple versions worth of the module.

 

[tshif]

Yeah the script isnt producing a wave file.

-- Executing [s@noah-flite:8] AGI("SIP/51-00000002", "nvweather-zip.php|92085") in new stack
-- Executing [s@noah-flite:9] NoOp("SIP/51-00000002", "Wave file: ") in new stack

 

[MyKroFt]

what version of asterisk are you using? at home is 1.6, here at work is 1.4.x.

Its working fine here at work on 1755/gold.....

am stumped

 

[MyKroFt]

ok, solved for asterisk 1.6.x

full log file had the answer:

59098 [2010-08-06 21:06:32] VERBOSE[3818] pbx.c:     -- Executing [s@noah-swift:8] AGI("SIP/1000-00000000","nvweather-zip.php|59427") in new stack
59099 [2010-08-06 21:06:32] WARNING[3818] pbx.c: The application delimiter is now the comma, not the pipe.  Did you forget to convert your dialplan?  (AGI(nvweather-zip.php|59427))
59100 [2010-08-06 21:06:32] WARNING[3818] res_agi.c: Failed to execute '/var/lib/asterisk/agi-bin/nvweather-zip.php|59427': File does not exist.

changed the | to a , and now everyone is happy

Myk

 

[tshif]

Fantastic. Great troubleshooting - THANK YOU.

Now - it seems the best way to fix this "out of the box" would be to make the syntax conditional based on which version of Asterisk is being used.

Do you have any wisdom you can share about writing that type of condition into the dialplans?

-tshif

 

[MyKroFt]

will see what I can find out

 

[tshif]

Please check out the Bug ticket here. I have done some research, and there is a possible workaround - but Id like your opinion also.

 

[MyKroFt]

there is a file called 'version' in /etc/asterisk - can we read this file and if the version starts with 1.6 skip over the 1.4 call to the 1.6 call

both versions in there works, just generated the error message in the log

 

[MyKroFt]

the module install script could check this version file and set the custom_weatherzip.conf to point to a 1.4 version or a 1.6 version

 

[tshif]

the module install script could check this version file and set the custom_weatherzip.conf to point to a 1.4 version or a 1.6 version

Theres a possibly good reason not to move it to the install code, and to leave it in the dial plan - please review this.

 

[tshif]

Weather by Zip Bug fix for Some Asterisk 1.6.x

Thanks to user MyKroft - There is a fix for a bug that causes this module to fail on some Asterisk 1.6.x boxes.

Right now if you need it, you can get it from the repository here. You can use the FreePBX Config Editor to edit the conf file (custom_weatherzip.conf) and replace it with the contents of the SVN file.

A maintenance release will be available shortly for this module - so if you dont mind waiting a bit - just hang in there and it will be announced here when its ready.

 

[tshif]

New Module v 1.1.7 Released!

I am pleased to announce the release and immediate availabililty of the Weather by ZIP Module v 1.1.7.

This maintenance release includes two bug fixes:

1. Ticket #314 Module fails on Asterisk 1.6.2x
The dial plan syntax has changed in Asterisk 1.6. The pipe "|" separator character must be replaced with a comma. The dial plan syntax in custom_weatherzip.conf has changed to accommodate this change. The new dial plan is "smart" and detects the version of Asterisk being run and provides the proper dial plan syntax for both Asterisk versions 1.4 and 1.6.

2. Ticket #316 Failure in cron job to remove tts files
Version release 1.1.6 was supposed to fix this, and didn't. A syntax error has been corrected to fix this issue.

Thanks to contributor MyKroft for identifying both of these issues, and providing the fixes.

As always - let us know how this version works for you!

 

[mruge]

I am trying to load the latest version (1.1.7) and the module installs correctly, but when I try to access it in FreePBX, the page comes up blank.

Any ideas?

Thank you,