a few issues...
Issue #11
resolved
Team.
I am using the saragota-weather script. After your last commit aI started getting weather information and all is looking awesome so far.. There is only a few issues:
The update date is been reported as 31-Dec-1969 7:25AM The time is correct but the date is not :P The thermometer is reporting 177F so is not catching the right temps. The 24hr differences is reporting -91.8F
nincehelser was able to confirm the date issues not sure about the other 3 though.
Please see here: http://weather.digitalvoipnet.com:30303/weewx/WD/index.php
Thanks for your hard work team!
Comments (60)
-
-
Ok, temp issue is one of Celsius and Fahrenheit 81C=178 odd F. Need to workout where that is coming from. What settings do you have for $SITE['dateOnlyFormat'] and $SITE['WDdateMDY'] in Settings.php?
-
reporter
Here is what I got: $SITE['dateOnlyFormat'] = 'd-M-Y'; // for 31-Mar-2008 or 'j/n/Y' for Euro format $SITE['WDdateMDY'] = true; // for WD date format of month/day/year. =false for day/month/year
-
Think we need to change WDdateMDY. Have a look at testtags.php, I expect at about line 33 you will have $date = "19/06/13" ie D/M/Y format. I believe that the WDdateMDY setting in Settings.php tells Saratoga what format WD provides its date in and dateOnlyFormat shoudl control what format Saratoga displays dates on your site. In this case you have it in 'WD' providing D/M/Y format so WDdateMDY needs to be false.
-
reporter
Perfect. That fixed the time. Thanks!
-
Fixed for me, too.
-
Good, saw them both. I think the temperature issue is a case of all of our 'ago' (ie 5 min ago, 10 min ago through to 2 hours ago and 24 hours ago) readings that involve a temperature are being generated in F then being interpreted by the report generator as being in C and then converted again to F (or some combination there of). Those native Weewx temps eg current.outTemp are well behaved and should convert properly . Clearly we have some work to do to make our templates well behaved. Going to need to give this some thought. Suspect that when you get some rain that may be off and potentially wind as well. Again it shoudl only be the 'ago' ones that are bad.
-
reporter
Ok so clientraw.txt is what the thermometer.php is looking at... Something is not been generated right...
Can somebody pin point what is going on on my clientraw file?
12345 3 17 315 90.0 58 29.991 0.00 1.01 1.01 0.00 0.00 84.2 45 -58.0 0 0 0 0 -100 -100 -100 -100 -100 -100 -100 -100 -100 15 30 00 Spring, Texas-15:30:00 0 0 20 06 100 100 100 100 100 100 100 90.0 32.2 96.0 76.6 -0.05 5 4 2 4 2 1 3 2 2 1 0 1 3 5 4 4 5 5 6 6 17 73.2 3978 20/06/2013 35.6 24.8 96.0 76.6 0 0.2 1.1 3.0 5.3 4.0 4.2 4.7 5.2 5.7 5.8 77.0 78.1 81.5 84.5 86.9 88.4 90.3 92.8 94.8 93.3 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 104.5 76.6 98.6 3 0 --- --- 315 0 0 0 0 0 0 0 0 0 0 86.8 80.8 218.6 30.048 29.941 17 15:05 15:05 88 88 77.0 65.7 8 2013 0 0 0 0 84.4 193.1 275.6 255.0 270.0 82.5 155.6 46.9 58.1 61.9 0 0 0 0 30.05374 -95.49454 0 92 38 8 06:15 0 0 0 0 0 0 0 !!EOR!!
-
Have you tried parsing the file with this site?
-
reporter
nincehelser,
I cant because it only supports port 80 :( Can you share the change you made on the ajax script that you mentioned on weewx group?
Thanks!
-
In ajaxWDwx.js I had to change this line. Originally it was pointed to ./clientraw.txt. After that (and forcing the cache to clear with ctrl-F5) I started getting a reasonable thermometer.
var clientrawFile = '../wx/WD/clientraw.txt'; // location of clientraw.txt relative to this page on website
-
if you zip up your WD directory and send it to me, I can place it on my server so you can parse it with that tool. (george.nincehelser@gmail.com)
-
reporter
nincehelser,
I sent you the email. I hope this points to the issue.
Thanks for the help.
-
If the link below doesn't work, it's at http://nincehelser.com/fernando/WD
-
It appears that you've got a Fahrenheit value where Celsius is expected. (Field 004)
-
reporter
Maybe some of the devel guys can give me a hand here? :) I am at a lost on this one...
-
Yes a few issues there. 8am here so I will see if I can work through things today and make some progress
-
nincehelser and xcom7, this is a bit of a stab but just wondering what you have under [Units], [Groups] in your skins.conf in the WD skin folder? Do you have imperial or metric settings? If metric these should be changed to the units you use. Not sure this will help but it is easy enough to check.
-
reporter
gjroderick,
Thanks for asking. That was the first thing I changes. Mine to the US.
-
Ok, thanks, like I said it was a stab. Back to the code!
-
Mine appear to be on metric. I haven't made any changes. They're unchanged from whatever is part of the bitbucket zip download.
For every new commit, I erase the WD skin folder and replace it with whatever is in the WD folder in the zip download.
-
reporter
nincehelser,
How is that? If I change mine to default everything goes back to Celsius, etc...
-
It appears that the preferred format in clientraw.txt is metric, so changing the skin.conf file to US values seems like it would be counter-productive.
-
I think celsius is what you want in the clientraw.txt. By definition, field 004 is in Celsius.
The Saratoga template probably reads them as Metric, then converts them to US values if that's what the settings say to do.
So if you put a F value in there (when it expects C), the template will "double it and add 30" to convert C to F, resulting in an extraordinarily large temp value.
-
reporter
Mhhhhh I see. I think I figured it out. Will report back.
-
reporter
I will try out your new commit.
-
Some progress. As the majority of clientraw.txt format can be fixed easily and quickly address majority of errors in this file. Have pushed new commit with a revised clientraw.txt.tmpl. Refer commit comments for what this fixes. Note that testtags.php will still contain erroneous data. My understanding of the Saratoga templates is that testtags.php populates the initial data and those fields not contained in clientraw.txt and clientraw.txt provides the dynamic update data. So there still may be some initial display of incorrect data but the ajax updates should pick up the correct values at first refresh.
-
reporter
Awesome.
Will report back soon.
-
repo owner
In regards to Units of Measure, the Unit of Measure for the clientraw (and others) is specified on the TNET Site..
They are.. Types: K = Kts D = Degrees F = FT C = Celcius H = Baro in hpa P = Percent M = Rain in mm N = Number
It is critical that all our measurements in the templates are reflective of these otherwise we are going to have some very strange measurements being expressed..
Most likely I got a few wrong :)
-
repo owner
In regards to the Saratoga templates I believe they only use the testtags.php data..
-
reporter
Oz,
All working good so far. Things are looking better. The only things that is still wrong is the 24-hr difference that I can tell... For now :D
-
Yes but I think the Ajax updates use some JavaScript to pull in data from clientraw.txt.
-
repo owner
Yeah I noticed that was wrong.. I have been caught a few times with time (measurements) sometimes the templates measure time from current time of template creation others measure time from midnight.. WD has some inconsistencies ;)
-
Xcom7, that is good to hear. 24 hour ago temp and other 'ago' data is pulled from testtags.php and I know where the error is, just need to work out how to fix it! It will take me a little longer than clientraw.txt did. 24 hour ago temp and 'ago' data in testtags is based on hard coded queries that assume underlying data is in celsius. Other 'ago' obs are similarly hard coded and hence when the underlying database uses different units we end up with F being interpreted as C and then converted to F.
-
repo owner
Gary,
I cannot recall that being the requirements but I am a few versions behind :)
-
reporter
Guys,
How we can fix the reports page? Is that even possible? :) So you guys can see what is been going on so far... http://weather.digitalvoipnet.com:30303/beta/index.php
-
reporter
gjroderick,
Awesome! You guys are awesome!
-
repo owner
Hehe I just looked at my reporting and it looks all over the shop but I am a fair few versions behind now :)
-
Xcom7, you mean Almanac, Station Monthly Reports?
-
That is not good Greg!
-
reporter
gjroderick,
Yes.
-
xcom7, should be easy enough to fix. Two possible solutions, either get Weewx to copy over the NOAA format reports if you still have the standard skin running. If not then just need to include them in the WD skin.conf. Yearly and monthly reports in the weewx standard skin is what you want, should just be a straight copy.
-
repo owner
My 5c, we should reference the requirement to have the NOAA formatted reports rather than duplicate the functionality..
-
reporter
gjroderick,
can you give me some pointers on where to find them and where to put them? I am still running the standard skin.
-
Agree. No need to generate the same thing twice. My aim is to get down to one skin onl that generates WD files and any other eg NOAA reports, graphs etc; while we are still developing WD I am keeping my other site up with its own skin. The NOAA reports take next to no time in any case.
-
reporter
Ok I just notice that the img in top of the thermostat that displays (Mainly cloudy, Dry ) disappears when the page refreshes.... It gets replace with a ---
-
xcom7, standard skin.conf under [FileGenerator] the SummarybyMonth and SummarybyYear sections should have the necessary settings to generate the NOAA reports. I think Saratoga by default expects them in a sub folder NOAA. Not sure on this as I am not in front of my system. Think there is a setting in one of the saratoga settings files, Settings.php?
-
FYI - I'm getting errors on the latest commit and had to roll-back.
Jun 21 00:05:37 raspberrypi weewx[2893]: reportengine: Caught unrecoverable exception in generator user.wdtags.WDFileGenerator Jun 21 00:05:37 raspberrypi weewx[2893]: * unsupported operand type(s) for /: 'NoneType' and 'int' Jun 21 00:05:37 raspberrypi weewx[2893]: Traceback (most recent call last): Jun 21 00:05:37 raspberrypi weewx[2893]: File "/usr/share/weewx/weewx/reportengine.py", line 130, in run Jun 21 00:05:37 raspberrypi weewx[2893]: obj.start() Jun 21 00:05:37 raspberrypi weewx[2893]: File "/usr/share/weewx/weewx/reportengine.py", line 288, in start Jun 21 00:05:37 raspberrypi weewx[2893]: self.run() Jun 21 00:05:37 raspberrypi weewx[2893]: File "/usr/share/weewx/weewx/filegenerator.py", line 44, in run Jun 21 00:05:37 raspberrypi weewx[2893]: self.generateToDate(self.gen_ts) Jun 21 00:05:37 raspberrypi weewx[2893]: File "/usr/share/weewx/weewx/filegenerator.py", line 253, in generateToDate Jun 21 00:05:37 raspberrypi weewx[2893]: print >> _file, text Jun 21 00:05:37 raspberrypi weewx[2893]: File "/usr/lib/python2.7/dist-packages/Cheetah/Template.py", line 1005, in str Jun 21 00:05:37 raspberrypi weewx[2893]: rc = getattr(self, mainMethName)() Jun 21 00:05:37 raspberrypi weewx[2893]: File "_etc_weewx_skins_WD_clientraw_txt_tmpl.py", line 148, in respond Jun 21 00:05:37 raspberrypi weewx[2893]: TypeError: unsupported operand type(s) for /: 'NoneType' and 'int' Jun 21 00:05:37 raspberrypi weewx[2893]: *** Generator terminated...
-
Regarding the icon above the thermometer: (Mostly Cloudy, Dry) I'm suspicious that it isn't working properly. I've no idea why it says "Dry" when we've had 20-30% chance of rain all day.
Is it really working?
-
reporter
Not sure... :/
-
Am aware of the icon/forecast issue, it will be wrong. Need to work out how to fix it. George, your None/Int error will be related, I suspect, to some limitations of the Weewx simulator (if you are still using it). Will need to crank mine up and see if I can trap the error.
-
I'm still using the "simulator". Probably always will be.
-
reporter
gjroderick,
Yes I think it is working... http://nincehelser.com/peru/ <- shows the correct icon. Mine shows the Mostly Cloudy, Dry before it disappears...
-
reporter
I was able to confirm what Oz report it on the wxtrends they are all broken here with odd reporting.
-
Pushed commit for clientraw.txt.tmpl. Should fix NoneType/int errors experienced by George.
-
No joy.
Jun 21 02:49:58 raspberrypi weewx[3155]: reportengine: Caught unrecoverable exception in generator user.wdtags.WDFileGenerator Jun 21 02:49:58 raspberrypi weewx[3155]: * unsupported operand type(s) for /: 'NoneType' and 'int' Jun 21 02:49:58 raspberrypi weewx[3155]: Traceback (most recent call last): Jun 21 02:49:58 raspberrypi weewx[3155]: File "/usr/share/weewx/weewx/reportengine.py", line 130, in run Jun 21 02:49:58 raspberrypi weewx[3155]: obj.start() Jun 21 02:49:58 raspberrypi weewx[3155]: File "/usr/share/weewx/weewx/reportengine.py", line 288, in start Jun 21 02:49:58 raspberrypi weewx[3155]: self.run() Jun 21 02:49:58 raspberrypi weewx[3155]: File "/usr/share/weewx/weewx/filegenerator.py", line 44, in run Jun 21 02:49:58 raspberrypi weewx[3155]: self.generateToDate(self.gen_ts) Jun 21 02:49:58 raspberrypi weewx[3155]: File "/usr/share/weewx/weewx/filegenerator.py", line 253, in generateToDate Jun 21 02:49:58 raspberrypi weewx[3155]: print >> _file, text Jun 21 02:49:58 raspberrypi weewx[3155]: File "/usr/lib/python2.7/dist-packages/Cheetah/Template.py", line 1005, in str Jun 21 02:49:58 raspberrypi weewx[3155]: rc = getattr(self, mainMethName)() Jun 21 02:49:58 raspberrypi weewx[3155]: File "_etc_weewx_skins_WD_clientraw_txt_tmpl.py", line 154, in respond Jun 21 02:49:58 raspberrypi weewx[3155]: TypeError: unsupported operand type(s) for /: 'NoneType' and 'int' Jun 21 02:49:58 raspberrypi weewx[3155]: *** Generator terminated...
-
My apologies George, poorly implemented try..except statements around rainRate calcs in clientraw.txt.tmpl. Reproduced the error here and have corrected it.
-
Just tried it. It's running great!
Thanks!
-
For date/time format/display issues refer to issue
#22 -
repo owner
- changed status to resolved
Resolved... All should be now working..
- Log in to comment
My thermometer looks OK, but I've got a few other goofy values. Wind gust looks suspect. 24 hours temp difference is definitely loco. I'm wondering if these will settle out with time?
http://nincehelser.com/peru