AlaskaDave

Thanks... I can see from your post that you now have the correct code. I would still like to figure out why you are having the problems copying the icons. Either there is still a bug somewhere in the code, or I need clearer instructions - but, either way, something should be done to correct the situation (and satisfy my own curiosity). If you are willing to take the time, I will PM you my email address so we can take this off-line for a while.

Am curious about how the scripted copying method improves the process as opposed to the "conventional" approach. Most everything in my Indigo rig involves some AS but this seems
to me a long way around the block. Thinking maybe some of my code could be improved.

Carl

berkinet,

I was using the V.3 script modified by Andrew Nairn, which has the 6 day forecast option. I just downloaded the 2.5 script and after changing all the properties to APT and ignoring the getPrecipitation properties, the script ran fine. I even changed the SetIcon procedure to try loading the day vs. night icons and they worked fine as well.

PS: on the line "if precip_1hr_in < 0 then", which is inside the SendToIndigo() function. -- I get a "Can’t make {} into type number, date or text." error message. I can live without the precipitation data and the six forecast.

AlaskaDave, can't remember if someone already suggested this test.. are you able to execute these three commands from a terminal window? This is what the setIcon function really does at the

Code: Select all

cd '/Library/Application Support/Perceptive Automation/Indigo 4/IndigoWebServer/images/controls/variables/Observation_Icons'
cp -f nt_cloudy.png ../current.png
cp -f nt_cloudy.png ../current+true.png


Good Luck.

Haseen

haseenalam wrote:...PS: on the line "if precip_1hr_in < 0 then", which is inside the SendToIndigo() function. -- I get a "Can’t make {} into type number, date or text." error message. I can live without the precipitation data and the six forecast...

I looked at the code and tried to duplicate the error you received but could not duplicate it. I believe this error could be caused by non-existant data. Check the raw XML data to see if the precip_1hr_in is available from your PWS location(s). If it is not, then change
property GetPrecip_1hr_in : "PWS"
to
property GetPrecip_1hr_in : ""

ckeyes888 wrote:Am curious about how the scripted copying method improves the process as opposed to the "conventional" approach. Most everything in my Indigo rig involves some AS but this seems to me a long way around the block. Thinking maybe some of my code could be improved.

Good question, I'll try to give you a helpful response.

The icon management section of the Wunderground script is designed to support user defined Control Pages which contain weather condition Icons. The problem in doing this is that the Control Page is static. You can place icons wherever you like. But the icon will always be the one you define in the Control Page editor. In the case of the weather icons, that file is current.png.

So, to address this problem I decided to create a sub-directory (../images/variables/Observation_Icons) and place image files for all the possible weather conditions in that directory. So, there are files named clear.png, snow.png, rain.png, etc. I then needed to find a way to replace the statically defined current.png with the image appropriate for the current conditions. So, the Wunderground script uses the current condition from the Wunderground XML file to locate the appropriate image in the Observation_Icons directory. Since the image file names are just the condition name plus the .png extension, this part is easy. Finally, to update the current.png image that will be displayed, the script copies the specific image to the file named current.png. So, when the Control Page runs, it gets the weather icon appropriate for the current condition.

BTW, Indigo supports having icons dynamically changed based on some state or variable value. But, at the time the Wunderground script was developed this capability was limited to On/Off or True/False. With the new ability to have arbitrary image files based on a variable value, I could change the script to drop the Observation_Icons directory and place all the images in the variables directory with names like:
current+clear.png, current+snow.png, current+rain.png, etc. I may get around to making this change next time I do a major update of the script.

Let me know if this explanation answered your question.

Absolutely, many thanks for taking the time to explain. Always something new to learn here.

Thanks,

Carl

Ok, after working with AlaskaDave offline I can report the Icon Display problem has been resolved. Here is what caused it, and how to fix it if you are having the same issue:

First, here is a bit of the output from ls -l -@ for one of the packages icon image files contained in the images/controls/variables/Observation_Icons directory:

Code: Select all

-rw-r--r--@  1 rdp   rdp    2362 Mar  1  2009 clear.png
   com.apple.FinderInfo     32
   com.apple.ResourceFork   40548

Now, here is the output from same command for the current.png file when an empty file was created using the touch command:

Code: Select all

-rw-r--r--   1 rdp   admin     0 Mar  9 14:03 test.png

Notice the extended attribute keys and sizes (the -@ option) are missing from the file created by using touch.

When the Wunderground script runs, it copies files like the one shown in the first listing to current.png and current+true.png in the images/controls/variables directory. For the image copy the script calls the -f option in cp. According to the man page for cp, this option means: If the destination file cannot be opened, remove it and create a new file, without prompting for confirmation regardless of its permissions.

But, it seems that there may be a bug in cp in OS X. When the source file contains extended attributes and the target file exists, the copy fails. I will report this to Apple (as if they actually cared).

Until I get around to changing the script to use dynamic image names, the fix for this problem is to simply copy any of the packaged image files to the images/controls/variables directory (use the finder or the terminal) and the rename it to current.png. Finally copy that file to the same directory and name it current+true.png. You could probably also create current+true.png as a link to current.png.

EDIT: Note that the problem with cp seems unique to calling it from within a do shell script command in an AppleScript.

I'm off and running... thanks so much for the help. Now to get designing!

AlaskaDave wrote:I'm having a hard time finding reliable stations in my area, most pull up errors indicating, "getXMLfile: xxx try number xxx: Null Station ID in XML data(1). The one station that is closest to me does work and is pulling in data but when I replace it with others the errors result.

I know this was an old post, but thought I'd comment, since I was seeing this same issue with my local station. In the AppleScript, I removed the forward slash in the ID argument of the URL string, and that fixed the station for me:

if stationType is equal to "PWS" then
set wunderURL to "http://api.wunderground.com/weatherstation/WXCurrentObXML.asp?ID=/"

Hope that helps someone.

-travis

I tried removing the trailing "/" and I'm still getting "null station ID in XML data" in my reports. I'll give it some time and try another station ID. Makes me want to get my own exterior weather station so as to get reliable weather in my area. I'm pulling in the airport but nothing closer to my house and that would be ideal.

Hmm yes, I found one in the Juneau area that seems to work without the slash (MJNEA2). Not sure if that one's close to you. The other ones around there just seem to have a lot of data missing (including the station ID) from their XML. Probably just incorrectly configured on their end.

Yes, I've been wanting to get a weather station going here too. That sounds like the best way to go.

My icon updating, which was working fine in Indigo 4, are now not working in I5. In the migration to I5 I dragged the observation icon folder to images/controls/variables. The icons appear in both Indigo Control Page Editor and Indigo Touch, they just don't update, despite that the variable list updates with the proper conditions as well as the proper day names. Both conditions and day names are updated and displayed correctly in the Browser Preview and Indigo Touch. I used Get info and the permissions seem correct on the individual current.png and current+true.png etc.

I also moved all the day icons to another folder and restarted the server. The script did not repopulate the icon list and the CP editor showed "icon not found". The event log documented that the script was looking for the icons and threw errors. I replaced the icons, restarted and the same static icons showed up.

Thoughts?

I had to edit the wunderground script. The path to current.png was pointing to Indigo 4. I changed it to Indigo 5 and everything started working fine.

That did it, thanks. Had the same problem with another script so should have thought about updating issue.

Matt and Jay, would it be worthwhile to have a thread for scripts that need minor changes to work with I5? As you know, this script http://www.perceptiveautomation.com/userforum/viewtopic.php?f=4&t=6057 also needed updating.

Works for me. That was sorta my original intention of having scripts that are put in the filelib have a corresponding thread in the User Contribution forum - so that when/if there were any updates/changes they could be discussed there where it's easy for users to find them. The scripts that are posted in random threads (rather than in the filelib) don't have that advantage...