Just replace the current forecast tag in the ccrlocal file with the Davis forecast tag.
Durr! Why didn’t I think of that?! Must have a case of SteelSeries Guage freeze!
Thanks Mark.
EDIT: For anyone with a Davis Vantage Vue (and presumably a VP), the forecast tag in question is %vpforecasttext%, and it works a treat.
Jacco, I would like to make a point very clear - the message was not addressed to you, it was addressed to Brian - unless you have a ‘say’ into the design/modification of Weather Display, I would really appreciate you refrain from commenting. 8)
And before you put words into my mouth, I am not saying/writing that Cumulus is a better software or that Weather Display is a better software - both have their advantages and disadvantages - I still prefer Weather Display for the quality/quantity of data it produces and the many useful scripts that have been developed for the data WD produces (my Weather Display has been reliably running on a dedicated computer since 2004) - Cumulus is easy to install but it is still lacking in historical data (my Cumulus has been running on-and-off on my development computer since 2009).
The message was not a request (to Brian) for modification of Weather Display (at this time) - I was a request for some assistance in finding the as-exact-as-possible equivalent tags between both weather software - equivalent tags between those produced by Cumulus and used with the SteelSeries gauges and those produced by Weather Display - I tried to look for more exact equivalent tags in WD but it is quite difficult considering that there are in excess of 2600 identified and non-identified tags in the latest tagslist file (there are less than 500 tags for Cumulus).
For example, I could not find a WD tag that would produce the data needed to create the wind rose (ie: radar plot) - Cumulus has the ‘<#WindRoseData>’ tag which produces exactly the 16-point data needed for the wind rose.
Indeed, I cannot get the script running with the data file produce by my WD - if I replace the WD produced ‘customclientraw.txt’ with the Cumulus produced ‘realtimegauges.txt’ the script displays (runs) as expected (the two data files needed for the ‘gauges.js’ script are produced by the templates included in release 1.6.4 of the gauges-ss package). After a few hours of unsuccessful tests, I gave up and went back to the experimental gauge script I have been ‘playing’ with (linear gauges, wind rose, thermometer, etc.). 
Works perfectly! Thanks. 
Brian, how about the Sager algorithm (similar if not the same as the Zambretti algorithm) at Weather-Above…
The WXSIM forecast can also be incorporated into the ticker … but a few more modifications are required.
I have added a %WindRoseData% custom tag
there is another thread about that
re not being able to use customclientraw for steel gauges, you would need to be using the version that works for WD though I would think, yes?
Brian, in the ‘gauges-ss’ package released by Mark, there are two tag templates, the ‘realtimegaugesT.txt’ for Cumulus and the ‘customclientrawlocal.txt’ for Weather Display. Both templates are processed by their designated weather software.
The resulting data file produced by Cumulus (ie: ‘realtimegauges.txt’) is read by the ‘gauges.js’ script and the information it contains properly displayed in the gauges.
The resulting data file produced by Weather Display (ie: customclientraw.txt) cannot be read by the ‘gauges.js’ script, thus no information is displayed in the gauges.
As I have written, I have not taken the time to check what/where the error is produced. :oops:
Ray,
I’m confused. My setup - http://tiggrweather.net/wxgauges.php - reads that file just fine and the gauges show the data. Or am I misinterpreting what you wrote?
Thanks.
John do not be…
No you are not! :roll:
I am using the ‘customclientrawlocal.txt’ template found in the latest release of ‘gauges-ss_v1-6-4.zip’ - I have activated the Process in Weather Display - a file by the name ‘customclientraw.txt’ is produced.
When the ‘gauges.js’ script uses the Weather Display produced file ‘customclientraw.txt’, the gauge images are displayed, but no information is displayed within the gauges - the status (scroller) keeps displaying the ‘DOWNLOADING…’ message and the timer (counter) remains fixed at 10 seconds (that is how it has been setup in the ‘gauges.js’ script).
When the ‘gauges.js’ script uses the Cumulus produced file ‘realtimegauges.txt’, the gauge images are displayed and information is displayed within the gauges - the status (scroller) displaying the forecast message and the time (counter) counts down from 10 seconds (that is how it has been setup in the ‘gauges.js’ script).
I have just downloaded (grab) the file ‘customclientraw.txt’ from your server, overwritten the one produced by my WD and and information is displayed within the gauges! :roll:
I have worked long enough with the ‘gauges.js’ script to know that when the status (scroller) keeps displaying the ‘DOWNLOADING…’ message and the timer (counter) remains fixed there is either an error in the data file or within the ‘gauges.js’ script.
Since the ‘gauges.js’ script displays the gauges (and the information within) properly when using the Cumulus-produced data file or the data file downloaded from your server, then the error is within the data file produced by my Weather Display (v10.37R build 20 updated on 08/03/2012).
Note: Comparing my WD-produced data file with your WD-produced data file, I noticed some major differences that are probably causing the problems. Although the data produced by your WD is in imperial measurement (mine is in metric), your data does not contain any units-of-measure while mine does - that is what is causing the ‘corruption’! There has to be a setting within Weather Display to prevent the addition of the unit-of-measure to the tags, but I have not found it yet - for testing purposes, I am using a newly installed (and not fully customised) version of Weather Display on my new computer.
Go to webfiles/web page setup, custom web page setup, the include units should not be ticked.
This shouldn’t matter with later releases, I now filter out the units, though it’s hard to test properly not being a WD user.
Looking at my ‘fully functional’ Weather Display, I found the location where I can deactivate the inclusion of the unit-of-measure… :oops:
Mark, would you like me to send you my Weather Display produced data file (ie: ‘customclientraw.txt’) with the unit-of-measure included?
I really do not understand what is going on with my new installation of Weather Display - after installing (updating) all the files from the latest release (v1.6.5) of the SteelSeries, I still cannot get the information to appear within the gauges - it is getting very frustrating - changing the path of the data file to point to the one produce by Cumulus and the information appears properly within the gauges!!! :angry1:
Yes, another example of a ccr may be useful, ta.
OK, now I’ve got it. I’m using b20 from 3/8 @ 0358, although my gauges have been working since before that release.
Also, while apparently not needed in the later releases of the gauges, I still have this not ticked…
“Go to webfiles/web page setup, custom web page setup, the include units should not be ticked.”
Have you set this to 1 for Weatherdisplay in gauges.js
var g_weatherProgram = 1; //Set 0=Cumulus, 1=Weather Display
The problem Ray is having is that the %dateoflastrainalways%%timeoflastrainalways% tags are producing “-----” rather than a date/time.
that will be beause he has not had any rain since upgrading to the version of WD with those tags in use
I have updated to 1.65
Copied the customclientrawlocal.txt to my webfiles folder.
When I go over de windspeed dial it says after winddirection: %maxgstdirectiondegree%
Windy, you posted that you added %maxgstdirectiondegree% to the latest zip.
What do I do with it.
I am using build 20
you will need to wait until the max daily gust is exceded for that new value to be set
or reset the daily gust