Legacy Cumulus 1 release 1.9.4 (build 1099) - 28 November 2014
(a patch is available for 1.9.4 build 1099 that extends the date range of drop-down menus to 2030)
Download the Software (Cumulus MX / Cumulus 1 and other related items) from the Wiki
dygon wrote:
The file is in the folder daytime.txt Cumulus / data /
thank you
Hi,
Your file "basic.php" is looking for thr file "daytime.txt" ON THE SERVER. You MUST send the file "daytime.txt" to the server. This file is being created by Cumulus once a day (just after midnight) and located in the directory Cumulus/data. You must send it from there to the server only ONCE A DAY.
Cheers,
Piotr
The day when I have learned something is not the lost one.
Ignorance can be corrected with the help of a book. Stupidity requires a shotgun and a shovel.
dygon wrote:Thanks for your help.
But how do I send the file to the server? and in which folder of my site I have to send it?
thanks again and sorry for my lack of experience and for my English.
1. To send "Dayfile.txt" file to the server I'm using "CumulusToolbox" application (you can find it here: http://wiki.sandaysoft.com/a/Toolbox)
2. Sorry for my mistake in my previous post. In fact the main file you need to configure is "betel_ReadDayfile.php (in line 27 you have to show the place you have the "dayfile.txt" file). Your "basic.php" file is just presenting all the rcords that are defined in the "betel_ReadDayfile.php" file.
Best Regards,
Piotr
The day when I have learned something is not the lost one.
Ignorance can be corrected with the help of a book. Stupidity requires a shotgun and a shovel.
Also, you have a link at the bottom of each page saying it is 'valid XHTML 1.0', if you click it the first and only two pages I looked at on your site are not valid!
I am not the best person to ask as I have had no problems with my dayfile.txt. If I look around your site most of the other data seems to be correct for your part of the world.
The dayfile data looks fine to me, based on the NOAA report. But there's something odd about the summary page, it displays reasonable data when it first loads, but then starts going wrong when you start clicking the buttons. It looks like it's taking figures that are already in F and doing a C to F conversion on them. Misconfiguration somewhere?
The first Seasonal data display looks fine, and the first Max Temp display for 2015 looks fine then if you select another year it goes haywire, and then if you reclick on Seasonal it is also now incorrect, so I think Steve has spotted your problem i.e. not the data that is at fault but a problem in the dayfile reader in the temperature conversion.
The puzzling thing is that if you click on the temperature selection button and select C it does a conversion albeit on data that is incorrect somehow.
It doesn't seem to be 'reading' the Saratoga $SITE variables (Units Of Measure).
Have you included them on the page as described in the 'How To ....' ?
If your template DOESN'T have the Saratoga $SITE[vars] then you will need to edit..
/* Units Of Measure - *should* be able to 'read' saratogaWX templates
Your 'native' datafile units - these will also be the default display units (unless overwritten by 'cookies' OR saratogaWX)
'temp' = 'C' OR 'F'
'rain' = 'mm' OR 'in'
'wind' = 'mph' OR 'm/s' OR 'km/h' OR 'kts'
'baro' = 'hPa' OR 'mb' OR 'inHg'
Change in the array BELOW !
*/
$uom = array(
'temp' => (isset($SITE['uomTemp']) ? substr($SITE['uomTemp'], -1) : 'C'),
'rain' => (isset($SITE['uomRain']) ? substr($SITE['uomRain'], 1) : 'mm'),
'wind' => (isset($SITE['uomWind']) ? substr($SITE['uomWind'], 1) : 'km/h'),
'baro' => (isset($SITE['uomBaro']) ? substr($SITE['uomBaro'], 1) : 'hPa')
);
......................Imagine, what you will KNOW tomorrow !