Steelseries Gauges for WD

Ah, thanks for clarifying that Brian.

Thanks, Brian. I think that explains it, and Mark has already confirmed it. I’m using the latest version of WD, V10.37Rb16. BTW, would you recommend using

%avdirlastimediate10%.......Average dir wind for the last immediate 10 minute period

vs.

%avdir10minute% ............average ten minute wind direction (degrees)

for the tag in customclientrawlocal.txt? Would the veer directions

%mindir10minute%............Max veer left wind direction, last 10 minute (based on 10 minute average speed)
%maxdir10minute%............Max veer right wind direction, last 10 minute (based on 10 minute average speed)

be something to look at here, or do I not understand those tags?

Thanks again for all your hard work.

Using ‘%avdirlastimediate10%…Average dir wind for the last immediate 10 minute period’ seems to have changed the range tags to much more reasonable values on my site.

I’ll see how it works out.

Thank you, thank you. I just copied and pasted your code into my page and the graphs worked.

Bill

Glad to hear it, Bill. The credit really belongs to Mark.

I don’t understand. I have ticked “Create a custom clientraw file”. But it is not being uploaded. I can watch the realtimeftp and seel clientraw.txt be uploaded.

I have tried setting the frequency to the same as clientraw.txt and also to different frequencies. I have tried the upload offset to 0 and to a few seconds.

Obviously, I have restarted WD, several times actually.

In the status bar at the bottom of the Windows screen, I see three small yellow ftp icons. Should there be three?

Occasionally, a small status window opens in the status bar and shows what filess are being uploaded.

I have one of the internet file uploads set to upload the customclientraw.txt file every minute and that is how I am getting the data now. So, the customclientrawlocal.txt file is properly formatted and being found.

Is there some other configuration that either needs to be set or not set?

Thanks.

RESOLVED: I have it working now. I was pointing to the wrong place for the data. My error. BUT, should the ftp upload window show that customclientraw.txt is being uploaded? Mine does not.

Bill

Check the location of your clientraw files on the 'Web Files/Web Page Real Time FTP/WDL menu (via the pushbutton on the upper right). That’s where your custumclientrawlocal.txt goes.

I had to ‘stop’ the uploads in the realtime uploader in order to scroll through the log and find the file.

With appreciation to some great tips from a few folks here I finally have the graphs working (along with a giant headache)…

http://tiggrweather.net/wxgauges.php

Many thanks to all!

BUT, should the ftp upload window show that customclientraw.txt is being uploaded? Mine does not.

that was an oversight this update should http://www.weather-display.com/downloadfiles/realtimeftp.zip

Thanks Brian, the ftp update now shows the upload of the customclientraw.txt.

I–and I am sure I speak for lots of people–appreciate all your support.

Bill

+1

New clientrawrealtimeftp is doing the job AND logging it.

I think I found a typo in gauges-ss.css.

There should be a . before td.

With the change there is a slight reformatting of the gauges on my page.

Bill

the graphs works great jgillett

I create my Carterlake Ajax pages uses a series of classes.

I have had a consistent non-ASCII character at the top of the html page for the gauges. I have solved the issue and post here in case others have this issue.

I think that the issue is caused by one of the files having been edited and saved as UTF-8, but that is only a guess.

Here is my function that creates the gauge portion of my page:

function makessGauges()
{

$gauges = $this->getIncludeContents("../gauges-ss/gauges-ssTO2.html");

//http://stackoverflow.com/questions/4057742/how-to-remove-efbbbf-in-php-string
/* detect the encoding, then convert from detected encoding to ASCII */
$enc = mb_detect_encoding($gauges);
$gauges = mb_convert_encoding($gauges, "ASCII", $enc);
$gauges = ltrim($gauges,"?");

$theBody = "<div id=\"main-copy\"><div align=\"center\">$gauges \n</div><!-- end align=\"left\" --></div><!-- end main-copy -->";
return $theBody;
}

So, I turn the non-ascii into ascii and it is then ? which I strip out. Seems like an ugly workaround, but hey it works!

getIncludeContents is:

function getIncludeContents($filename)
    {
        if (is_file($filename))
        {
            ob_start();
            require_once ( $filename);  // 2-25-12  changed to require_once since started getting redeclared errors  Strange!!!
            $contents = ob_get_contents();
            ob_end_clean();
            return $contents;
        }
        return false;
    }

The non-ascii characters did not appear if I just echoed out the return from the function and displayed it it fireFox with no html wrapping.

Hope this saves someone time.

Bill

Thanks, windy. As always, your help and support is most appreciated as well.

I had the same problem, but my approach was to modify the page and supporting files in order to validate as UTF-8 HTML5 compliant. It was an interesting learning experience, but right now I’m not about to subject the rest of my site to more of the same rigor.

I had seen your earlier message and it helped me identify the problem.

Bill

It is possible that I saved one or more of the files in UTF-8 with a BOM (I switched editors recently) I’ll check. The BOM is what you are seeing when the code is loaded as part of a non-UTF-8 page. The BOM should really not be required or be there.

Minor glitch with 1.6.4. Since you indicated that gauges.js was all that changed, that’s all I uploaded. However, my page is still indicating 1.6.3…

http://tiggrweather.net/wxgauges.php

…even though this is set…

var g_scriptVer = “1.6.4 - 2012-03-01”;

Tried different browsers, different OSs, and different machines. What dummy thing did I miss.

Thanks.