[weewx-user] Re: WeeWx + ss gauges in us units

[gjr80]

Well, 4 different browsers across 3 different machiens and I am seeing the 
same gauge-data.txt with the same 19 January timestamp. What do you see 
when you look at gauge-data.txt in your browser?

On Saturday, 21 January 2017 13:41:20 UTC+10, Dan'l B wrote:
>
> Just deleted gauge-data.txt on the Pi and on the server and it reloads 
> with the same issue.
>
> On Friday, January 20, 2017 at 9:59:40 PM UTC-5, gjr80 wrote:
>>
>> Interesting, when I look at your gauge-data.txt at 
>> http://suiattle.net/DinkinsBayouWeather/ss/gauge-data.txt I see a file 
>> timestamped on 19 January
>>
>> Gary
>>
>> On Saturday, 21 January 2017 12:56:32 UTC+10, Dan'l B wrote:
>>>
>>> Jan 20 21:46:10 raspberrypi weewx[671]: ftpupload: Uploaded file 
>>> /gauge-data.txt
>>>
>>> 10 minutes ago.
>>>
>>> I can't see any errors related to that in the log.
>>>
>>> On Friday, January 20, 2017 at 9:36:40 PM UTC-5, gjr80 wrote:

  I look at your site it says your station has been offline for some 37 
 odd hours, in other words your gauge-data.txt is 37 odd hours old 
 ("date":"2017.01.19 07:50")

 What's in your logs? Is gauge-data.txt being generated without error 
 and if it is being generated (if applicable) is it being uploaded to your 
 web server?

 Gary

 On Saturday, 21 January 2017 12:29:14 UTC+10, Dan'l B wrote:
>
> I have the ss gauges working fine with WeeWx but they display in °C.
>
> http://suiattle.net/DinkinsBayouWeather/ss/index.html
>
> I've changed the units in /skins/ss/skin.conf to use US units but it 
> doesn't seem to effect the change. What am I missing in how to accomplish 
> this?
>
> RPi 3
> WeeWx 3.6.2
>


-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WeeWx + ss gauges in us units

[Dan'l B]

Just deleted gauge-data.txt on the Pi and on the server and it reloads with 
the same issue.

On Friday, January 20, 2017 at 9:59:40 PM UTC-5, gjr80 wrote:
>
> Interesting, when I look at your gauge-data.txt at 
> http://suiattle.net/DinkinsBayouWeather/ss/gauge-data.txt I see a file 
> timestamped on 19 January
>
> Gary
>
> On Saturday, 21 January 2017 12:56:32 UTC+10, Dan'l B wrote:
>>
>> Jan 20 21:46:10 raspberrypi weewx[671]: ftpupload: Uploaded file 
>> /gauge-data.txt
>>
>> 10 minutes ago.
>>
>> I can't see any errors related to that in the log.
>>
>> On Friday, January 20, 2017 at 9:36:40 PM UTC-5, gjr80 wrote:
>>>
>>>  I look at your site it says your station has been offline for some 37 
>>> odd hours, in other words your gauge-data.txt is 37 odd hours old 
>>> ("date":"2017.01.19 07:50")
>>>
>>> What's in your logs? Is gauge-data.txt being generated without error and 
>>> if it is being generated (if applicable) is it being uploaded to your web 
>>> server?
>>>
>>> Gary
>>>
>>> On Saturday, 21 January 2017 12:29:14 UTC+10, Dan'l B wrote:

 I have the ss gauges working fine with WeeWx but they display in °C.

 http://suiattle.net/DinkinsBayouWeather/ss/index.html

 I've changed the units in /skins/ss/skin.conf to use US units but it 
 doesn't seem to effect the change. What am I missing in how to accomplish 
 this?

 RPi 3
 WeeWx 3.6.2

>>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WeeWx + ss gauges in us units

[gjr80]

Interesting, when I look at your gauge-data.txt at 
http://suiattle.net/DinkinsBayouWeather/ss/gauge-data.txt I see a file 
timestamped on 19 January

Gary

On Saturday, 21 January 2017 12:56:32 UTC+10, Dan'l B wrote:
>
> Jan 20 21:46:10 raspberrypi weewx[671]: ftpupload: Uploaded file 
> /gauge-data.txt
>
> 10 minutes ago.
>
> I can't see any errors related to that in the log.
>
> On Friday, January 20, 2017 at 9:36:40 PM UTC-5, gjr80 wrote:
>>
>>  I look at your site it says your station has been offline for some 37 
>> odd hours, in other words your gauge-data.txt is 37 odd hours old 
>> ("date":"2017.01.19 07:50")
>>
>> What's in your logs? Is gauge-data.txt being generated without error and 
>> if it is being generated (if applicable) is it being uploaded to your web 
>> server?
>>
>> Gary
>>
>> On Saturday, 21 January 2017 12:29:14 UTC+10, Dan'l B wrote:
>>>
>>> I have the ss gauges working fine with WeeWx but they display in °C.
>>>
>>> http://suiattle.net/DinkinsBayouWeather/ss/index.html
>>>
>>> I've changed the units in /skins/ss/skin.conf to use US units but it 
>>> doesn't seem to effect the change. What am I missing in how to accomplish 
>>> this?
>>>
>>> RPi 3
>>> WeeWx 3.6.2
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WeeWx + ss gauges in us units

[Dan'l B]

Jan 20 21:46:10 raspberrypi weewx[671]: ftpupload: Uploaded file 
/gauge-data.txt

10 minutes ago.

I can't see any errors related to that in the log.

On Friday, January 20, 2017 at 9:36:40 PM UTC-5, gjr80 wrote:
>
>  I look at your site it says your station has been offline for some 37 odd 
> hours, in other words your gauge-data.txt is 37 odd hours old 
> ("date":"2017.01.19 07:50")
>
> What's in your logs? Is gauge-data.txt being generated without error and 
> if it is being generated (if applicable) is it being uploaded to your web 
> server?
>
> Gary
>
> On Saturday, 21 January 2017 12:29:14 UTC+10, Dan'l B wrote:
>>
>> I have the ss gauges working fine with WeeWx but they display in °C.
>>
>> http://suiattle.net/DinkinsBayouWeather/ss/index.html
>>
>> I've changed the units in /skins/ss/skin.conf to use US units but it 
>> doesn't seem to effect the change. What am I missing in how to accomplish 
>> this?
>>
>> RPi 3
>> WeeWx 3.6.2
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WeeWx + ss gauges in us units

[gjr80]

 I look at your site it says your station has been offline for some 37 odd 
hours, in other words your gauge-data.txt is 37 odd hours old 
("date":"2017.01.19 07:50")

What's in your logs? Is gauge-data.txt being generated without error and if 
it is being generated (if applicable) is it being uploaded to your web 
server?

Gary

On Saturday, 21 January 2017 12:29:14 UTC+10, Dan'l B wrote:
>
> I have the ss gauges working fine with WeeWx but they display in °C.
>
> http://suiattle.net/DinkinsBayouWeather/ss/index.html
>
> I've changed the units in /skins/ss/skin.conf to use US units but it 
> doesn't seem to effect the change. What am I missing in how to accomplish 
> this?
>
> RPi 3
> WeeWx 3.6.2
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] WeeWx + ss gauges in us units

[Dan'l B]

I have the ss gauges working fine with WeeWx but they display in °C.

http://suiattle.net/DinkinsBayouWeather/ss/index.html

I've changed the units in /skins/ss/skin.conf to use US units but it 
doesn't seem to effect the change. What am I missing in how to accomplish 
this?

RPi 3
WeeWx 3.6.2

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: rsync to two different servers

[gjr80]

I run mutliple RSYNC reports, albeit to the same server but different with 
different HTML_ROOT settings. Can't see why it wont work, its just another 
report with its own settings.

Gary

On Saturday, 21 January 2017 11:15:11 UTC+10, vince wrote:
>
> Would weewx support rsync to 'two' remote servers ?
>
> I'm going to be moving my site to a different ISP and have the new server 
> online but haven't repointed DNS at it yet.  If I set up multiple blocks in 
> weewx ala the [RSYNC] one, just with a different name ala [RSYNC2] with the 
> appropriate remote info in it for the new site, would weewx run the rsync 
> skin twice essentially and synchronize up to both locations ?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] rsync to two different servers

[vince]

Would weewx support rsync to 'two' remote servers ?

I'm going to be moving my site to a different ISP and have the new server 
online but haven't repointed DNS at it yet.  If I set up multiple blocks in 
weewx ala the [RSYNC] one, just with a different name ala [RSYNC2] with the 
appropriate remote info in it for the new site, would weewx run the rsync 
skin twice essentially and synchronize up to both locations ?

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: gauge-data.txt file not being generated SS gauges

[gjr80]

Ok, a few things to digest.

Ok, I found the offending line in the template and it's this one here:
>
> set $hour_rain_max = $hour.rain.max.raw * $rain_mult
>

That is interesting, $hour.rain.max.raw gives you the highest rainfall in 
an archive period over the last hour, but then the variable in which this 
is stored, $hour_rain_max is never used in the template. So on the face of 
it it appears that line is not required. As for why the TypeError with that 
statement, somehow $hour.rain.max.raw was returning None, most likely 
because you had no rain field (looking at the loop packet in your next 
post) and hence there was no underlying rain data in your archive (note no 
rain data is different to no rain, the former will return, the latter will 
return 0.0).

Tried running weewx directly and found out some interesting things:
>
> LOOP:   2017-01-20 08:53:54 EST (1484920434) altf: 797.8077, altimeter: 
> 29.865984751, altm: 243.1718, appTemp: None, barometer: 29.856421862, 
> cloudbase: 6661.05106707, dailyrainin: 0.627, dateTime: 1484920434.0, 
> dewpoint: 43.9259, dewptc: 6.6255, heatindex: 69.98, hpa: 985.31, humidex: 
> 69.98, inDewpoint: None, kilopascals: 98.532, maxSolarRad: None, 
> outHumidity: 39.0, outTemp: 69.98, pressure: 29.0965, rainmm: 0.0, 
> rainRate: 0.0, soc: 255.9961, tempc: 21.1, usUnits: 1, voltage: 5.1188, 
> windchill: None, winddir: 90.0, winddir_avg2m: 90.0, windGust: 0.0, 
> windGustDir: None, windspdmps_avg2m: 0.0, windspeedkmph: 0.0, windspeedmph: 
> 0.0, windspeedmps: 0.0
>
> So I definitely have some "None" data in there, but not sure what this 
> offending line blows up?
>

Having None is not necessarily a bad thing, for example windSpeed is 0 and 
windDir is reported as None, because there is no wind direction when wind 
speed is. Archive records will frequently have None values, loop packets 
less so. One thing I notice here is that you have no field windSpeed (more 
on that later) 

Ok, I think I solved the rain problem.  I supplied weewx with a value for 
> "rain" from my weather station.  So rather than just supplying the rainRate 
> value from my station, I'm feeding it both, and now the 
> gauges-data.txt.tmpl file is working without any edits.   Now all I have to 
> do is solve why my temperature gauge is acting so strange.  In talking to 
> another person it may be because my station does not supply the inside 
> temperature, so I disabled that function in gauges.js but that hasn't 
> changed the weird scaling issue, or why the gauge always starts from the 
> bottom, then climbs to the correct value???  The mystery continues.
>

The Steel Series gauges autoscale and they use the max min values as inputs 
to this autoscaling. So if you have old/test data in your db it is quite 
possible that the the may start off 'off the scale' but track onto the 
correct value. THe tell would be to have a look in gauge-data.txtx now that 
it is generating. Nonetheless you fixed it by clering the database which 
supports the idea of old/test data polluting gauge-data.txt. As for 
rainRate, not really related to this issue but this has been a very topical 
issue in the past. weewx has the ability to calculate rainRate from rain 
using the the StdWXCalculate 
 service. If your 
driver emits rainRate you can certainly use that or if it does not, or your 
are calculating it yourself, really a personal preference, I see you let 
weewx do it.

On Saturday, 21 January 2017 06:07:34 UTC+10, Robert Mantel wrote:
>
> Ok, just one more picky thing to work out and that is why the aparent 
> temperature isn't working (shows -20 ).  I'm wondering if there is another 
> variable I need to input into weewx to make that happen?
>

appTemp can be calculated by StdWXCalculate and weewx is set to do this by 
default. appTemp has 3 inputs, outTemp, outHumidity and windSpeed. All 3 
must exist and be non-None to get a numeric value back, if any of the 3 do 
not exist or are None you will get apptemp=None. Looking at your loop 
packet you provided above, we see appTemp is None, outTemp is 69.98, 
outHumidity is 39.0 but you have no windSpeed field. Therefore since you 
have no windSpeed (ie its missing not that it is 0) you will not anything 
other than a None for appTemp. Incidentally, I suspect the same is 
happening with windchill, no windSpeed so windchill is calculated as None.

You have a few wind speed values there, your driver needs to massage one of 
them into windSpeed. I notice you have winddir but no windDir, case matters 
with python so you should address that as well or you will have wind 
direction issues (ie a lack of stored data). Perhaps you should go back 
over your driver and carefully look at what fields it emits, there is no 
right or wrong, if your driver does not emit inHumidity that is fine, its 
your driver. But weewx has certain expectations from a driver, for example, 
weewx expects outside temperature to be outTemp and it 

Re: [weewx-user] Re: Added sensors to weewx and Pi

[Ruben Navarro Huedo]

a lot of thanks
I will do !

El 20 ene. 2017 1:25 PM, "Neville Davis" 
escribió:

> I have recently updated the weewx wiki with some mods to scripts. I am now
> using a 180 instead of the 280...it failed on me and I had a 180 lying
> around. I also now have UV operational and working on a responsive skin.
> The wiki has a link to my station
> Use any scripts as needed.
>
> Neville
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/weewx-user/SO8dGWtBaxg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> weewx-user+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: gauge-data.txt file not being generated SS gauges

[Robert Mantel]

Ok, just one more picky thing to work out and that is why the aparent 
temperature isn't working (shows -20 ).  I'm wondering if there is another 
variable I need to input into weewx to make that happen?

On Thursday, 19 January 2017 08:44:51 UTC-5, Robert Mantel wrote:
>
> I have a brand new Raspberry Pi running the latest version of weewx.  I 
> have it working with the default skin and also the Bootstrap skin with no 
> issues.  I'm using fileparse.py to grab data from a text file that gets 
> generated from a python script that does a jsonp query to my phant server 
> that is archiving the raw data from my particle photon weather hardware. 
>  Like probably everyone else I came across the SS gauges and love the look 
> and feel of them so proceeded with the install and followed the 
> instructions, modifying the gauges.js file and movnig all the appropriate 
> files into my weewx install.  The gauges are reproduced perfectly, but no 
> data is being input and I get the following error in syslog:
>
>
> Jan 19 08:27:04 raspberrypi weewx[23078]: manager: added record 2017-01-19 
> 08:26:00 EST (1484832360) to database 'weewx.sdb'
> Jan 19 08:27:04 raspberrypi weewx[23078]: manager: added record 2017-01-19 
> 08:26:00 EST (1484832360) to daily summary in 'weewx.sdb'
> Jan 19 08:27:04 raspberrypi weewx[23078]: reportengine: copied 0 files to 
> /var/www/html/weewx
> Jan 19 08:27:04 raspberrypi weewx[23078]: cheetahgenerator: Generate 
> failed with exception ''
> Jan 19 08:27:04 raspberrypi weewx[23078]: cheetahgenerator:  Ignoring 
> template /etc/weewx/skins/ss/gauge-data.txt.tmpl
> Jan 19 08:27:04 raspberrypi weewx[23078]: cheetahgenerator:  Reason: 
> unsupported operand type(s) for *: 'NoneType' and 'int'
> Jan 19 08:27:04 raspberrypi weewx[23078]:   Traceback (most recent 
> call last):
> Jan 19 08:27:04 raspberrypi weewx[23078]: File 
> "/usr/share/weewx/weewx/cheetahgenerator.py", line 315, in generate
> Jan 19 08:27:04 raspberrypi weewx[23078]:   print >> _file, text
> Jan 19 08:27:04 raspberrypi weewx[23078]: File 
> "/usr/lib/python2.7/dist-packages/Cheetah/Template.py", line 1005, in 
> __str__
> Jan 19 08:27:04 raspberrypi weewx[23078]:   rc = getattr(self, 
> mainMethName)()
> Jan 19 08:27:04 raspberrypi weewx[23078]: File 
> "cheetah__etc_weewx_skins_ss_gauge_data_txt_tmpl_1484791504_04_19193.py", 
> line 326, in respond
> Jan 19 08:27:04 raspberrypi weewx[23078]:   TypeError: unsupported 
> operand type(s) for *: 'NoneType' and 'int'
>
>
> I'm wracking my brain trying to find in the gauge-data.txt.tmpl file what 
> could be causing the operand error and obviously it's a bogus variable in 
> one of the math functions.  So I suspect that there is some missing data 
> that I'm not supplying it?  Also of note, when I set up weewx I chose 
> metricwx for the display units, but the database is using US units.  Is 
> this my problem?  Should I have stuck with US display units as well when I 
> did the initial install?
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Matching rain corrections with weewx and Weather Underground

[J]

Yes, 0.6 and 0.7 were typos, 0.06 and 0.07 are the intended values.

Thanks for the pointers -- I think I understand and am sorted now. Since 
dayRain is provided by Vantage console in the loop packet but not the 
archive packet, weewx uses the console's straight value for the former and 
generates a database-SUM-of-rain value for the latter.

Applying a matching correction to the loop packet's dayRain value wouldn't 
work out afaik for anything that depends on the value of second weather 
variable, as it'd keep applying the latest correction to the entire dayRain 
value. However with those pointers I was able to modify restx.py to 
generate dayRain from the database even for loop packets. I'm now getting 
consistent, corrected values for rapidfire (as well as archive_post, as was 
the case before) which match weewx's database.

I agree completely on corrections being no substitute for proper station 
siting or accurate, properly calibrated instruments. Alas, station siting 
in urban environments always involves some compromise. Luckily the amount 
of undercatch due to wind turbulence from increased height above ground 
level has been the subject of some study and papers over the decades and is 
relatively predictable. Much more so than the impact of heavy rain 
shadowing, my only other option. With the new rain corrections my readings 
are now in the same ballpark as my neighbor on the same block -- whose 
Vantage Vue is sited optimally for rain and temperature readings, but 
terribly for wind readings. 

Thanks again for the guidance and excellent software!

On Friday, January 20, 2017 at 4:38:36 AM UTC-8, Tom Keffer wrote:
>
> The URLs you have posted show values of 0.06 or 0.07, but your narrative 
> talks about 0.6 and 0.7. I assume the former is correct and the latter is 
> just a typo?
>
> The value for dailyrainin comes from field dayRain in the current record, 
> which, in turn, is pulled off the Vantage weather station. This is why it 
> matches what you see in the console.
>
> If you want the dayRain to match the sum of 'rain' since midnight, it 
> would have to be "corrected" by the same factor.
>
> Frankly, correcting for the effects of high winds by boosting rain is no 
> substitute for correct placement of your ISS. I also live in a high wind 
> area (the Columbia River Gorge) and don't have any problems with rain. I 
> would leave it alone.
>
> -tk
>
>
>
> On Thu, Jan 19, 2017 at 7:42 PM, J  
> wrote:
>
>> Thanks for your responses and please pardon my late reply -- I wanted to 
>> wait until some more rain fell to confirm observations and gather more 
>> detailed logs.
>>
>> It appears that the standard Wunderground-PWS archive method posts the 
>> corrected values, but Wunderground-RF rapid fire submits a combination of 
>> corrected and uncorrected values. I'm unclear on where the uncorrected 
>> value is being pulled from.
>>
>> For reference, the uncorrected value (as displayed by Davis console) at 
>> the time of the below logs is 0.6 inches. With the weewx corrections it's 
>> (rounded up to) 0.7. The discrepancy has persisted and widened as more rain 
>> has fallen throughout the day.
>>
>> Wunderground-PWS:  both dailyrainin and rainin show the corrected 0.7:
>>
>> Jan 19 04:47:16 weewx[2009]: restx: Ambient: url: 
>> http://weatherstation.wunderground.com/weatherstation/updateweatherstation.php?action=updateraw=YYY=XXX=weewx-3.5.0=3.0=095;
>> *dailyrainin=0.07*=270=50.8=1.0&*rainin=0.07*
>> =29.805=49.4=2017-01-19%2012%3A47%3A00
>> Jan 19 04:47:16 weewx[2009]: restx: Wunderground-PWS: Published record 
>> 2017-01-19 04:47:00 PST (1484830020)
>>
>> Wunderground-RF rapid fire:  dailyrainin has the uncorrected value (0.6), 
>> but rainin uses the corrected one (0.7).  WU appears to use the dailyrainin 
>> value for it's displayed precipitation totals. Log:
>>
>> Jan 19 04:47:16 weewx[2009]: restx: Ambient: url: 
>> http://weatherstation.wunderground.com/weatherstation/updateweatherstation.php?action=updateraw=YYY=XXX=weewx-3.5.0=5.0=095;
>> *dailyrainin=0.06*=247=50.8=5.0=2.5&
>> *rainin=0.07*
>> =29.807=49.4=2017-01-19%2012%3A47%3A16=1
>>
>> If I enable both methods, I can see the displayed value on WU bounce down 
>> to 0.6 after the Wundergrond-PWS submission, then back to 0.7 with the next 
>> Wunderground-RF submission.  This bouncing back and forth is also reflected 
>> occasionally in the WU graphs.
>>
>>
>> mwall wrote:
>>
>>> jesse, you can use conditionals in corrections:  [...]  each correction 
>>> must be a single line of python
>>
>>
>> Awesome, thank you!
>>
>> - jesse
>>
>>
>> On Friday, January 13, 2017 at 6:40:17 PM UTC-8, Tom Keffer wrote:
>>
>>
>> The value sent to wunderground is calculated directly from the database. 
>>> It's the sum of all rain that fell during the last 60 minutes. So, if 
>>> you're happy with the values of 'rain' in the database, then you should 
>>> be getting the same at wunderground. 
>>>
>>> -tk
>>>
>>> On Fri, Jan 

[weewx-user] Re: gauge-data.txt file not being generated SS gauges

[Robert Mantel]

Ok, I think I solved the rain problem.  I supplied weewx with a value for 
"rain" from my weather station.  So rather than just supplying the rainRate 
value from my station, I'm feeding it both, and now the 
gauges-data.txt.tmpl file is working without any edits.   Now all I have to 
do is solve why my temperature gauge is acting so strange.  In talking to 
another person it may be because my station does not supply the inside 
temperature, so I disabled that function in gauges.js but that hasn't 
changed the weird scaling issue, or why the gauge always starts from the 
bottom, then climbs to the correct value???  The mystery continues.

On Thursday, 19 January 2017 08:44:51 UTC-5, Robert Mantel wrote:
>
> I have a brand new Raspberry Pi running the latest version of weewx.  I 
> have it working with the default skin and also the Bootstrap skin with no 
> issues.  I'm using fileparse.py to grab data from a text file that gets 
> generated from a python script that does a jsonp query to my phant server 
> that is archiving the raw data from my particle photon weather hardware. 
>  Like probably everyone else I came across the SS gauges and love the look 
> and feel of them so proceeded with the install and followed the 
> instructions, modifying the gauges.js file and movnig all the appropriate 
> files into my weewx install.  The gauges are reproduced perfectly, but no 
> data is being input and I get the following error in syslog:
>
>
> Jan 19 08:27:04 raspberrypi weewx[23078]: manager: added record 2017-01-19 
> 08:26:00 EST (1484832360) to database 'weewx.sdb'
> Jan 19 08:27:04 raspberrypi weewx[23078]: manager: added record 2017-01-19 
> 08:26:00 EST (1484832360) to daily summary in 'weewx.sdb'
> Jan 19 08:27:04 raspberrypi weewx[23078]: reportengine: copied 0 files to 
> /var/www/html/weewx
> Jan 19 08:27:04 raspberrypi weewx[23078]: cheetahgenerator: Generate 
> failed with exception ''
> Jan 19 08:27:04 raspberrypi weewx[23078]: cheetahgenerator:  Ignoring 
> template /etc/weewx/skins/ss/gauge-data.txt.tmpl
> Jan 19 08:27:04 raspberrypi weewx[23078]: cheetahgenerator:  Reason: 
> unsupported operand type(s) for *: 'NoneType' and 'int'
> Jan 19 08:27:04 raspberrypi weewx[23078]:   Traceback (most recent 
> call last):
> Jan 19 08:27:04 raspberrypi weewx[23078]: File 
> "/usr/share/weewx/weewx/cheetahgenerator.py", line 315, in generate
> Jan 19 08:27:04 raspberrypi weewx[23078]:   print >> _file, text
> Jan 19 08:27:04 raspberrypi weewx[23078]: File 
> "/usr/lib/python2.7/dist-packages/Cheetah/Template.py", line 1005, in 
> __str__
> Jan 19 08:27:04 raspberrypi weewx[23078]:   rc = getattr(self, 
> mainMethName)()
> Jan 19 08:27:04 raspberrypi weewx[23078]: File 
> "cheetah__etc_weewx_skins_ss_gauge_data_txt_tmpl_1484791504_04_19193.py", 
> line 326, in respond
> Jan 19 08:27:04 raspberrypi weewx[23078]:   TypeError: unsupported 
> operand type(s) for *: 'NoneType' and 'int'
>
>
> I'm wracking my brain trying to find in the gauge-data.txt.tmpl file what 
> could be causing the operand error and obviously it's a bogus variable in 
> one of the math functions.  So I suspect that there is some missing data 
> that I'm not supplying it?  Also of note, when I set up weewx I chose 
> metricwx for the display units, but the database is using US units.  Is 
> this my problem?  Should I have stuck with US display units as well when I 
> did the initial install?
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Acurite 5n1 sdr rain issue

[Andy]

Using the latest rtl_433 and the latest sdr.py my rain totals match the 
console.  And yes the 5n1 is ouput from rtl_433 is now json

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: gauge-data.txt file not being generated SS gauges

[Robert Mantel]

Tried running weewx directly and found out some interesting things:

LOOP:   2017-01-20 08:53:54 EST (1484920434) altf: 797.8077, altimeter: 
29.865984751, altm: 243.1718, appTemp: None, barometer: 29.856421862, 
cloudbase: 6661.05106707, dailyrainin: 0.627, dateTime: 1484920434.0, 
dewpoint: 43.9259, dewptc: 6.6255, heatindex: 69.98, hpa: 985.31, humidex: 
69.98, inDewpoint: None, kilopascals: 98.532, maxSolarRad: None, 
outHumidity: 39.0, outTemp: 69.98, pressure: 29.0965, rainmm: 0.0, 
rainRate: 0.0, soc: 255.9961, tempc: 21.1, usUnits: 1, voltage: 5.1188, 
windchill: None, winddir: 90.0, winddir_avg2m: 90.0, windGust: 0.0, 
windGustDir: None, windspdmps_avg2m: 0.0, windspeedkmph: 0.0, windspeedmph: 
0.0, windspeedmps: 0.0

So I definitely have some "None" data in there, but not sure what this 
offending line blows up?

On Friday, 20 January 2017 08:48:24 UTC-5, Robert Mantel wrote:
>
> Ok, I found the offending line in the template and it's this one here:
>
> set $hour_rain_max = $hour.rain.max.raw * $rain_mult
>
> It's now populating the gauges with data, but for some strange reason the 
> temperature and aparent temp gauges are cycling from some -5000 number up 
> to the correct number once a second or so.  Odd.  So, maybe what I'm 
> missing in weewx is the rain rate over one hour, so perhaps I have miss 
> directed that info from the weather station to the wrong label in weewx?
>
> On Thursday, 19 January 2017 18:17:13 UTC-5, gjr80 wrote:
>>
>> Ok, some more thoughts. Delete the content between the {}, no * 
>> opertaions in there so the error is not in there. Then work through the 
>> 'chunks' of  python in the template commenting out/deleting (keeping the 
>> template open in an editor and using control-Z/undo is a great timesaver) 
>> each one in turn until you find the culprit, eg; comment/delete the 
>> appttemp calculations, then the humidex. 
>>
>> Another thought, run weewx directly 
>>  and have a look 
>> at what is coming out for each obs in the archive record (archive records 
>> are identified with a REC and appear each archive interval). Look for any 
>> obs used in the template that have None values. That might give you a clue.
>>
>> windDir (and the gust equivalent) are often a source of 'Nones' but in 
>> this case I don't think any are used in a multiplication operation. But 
>> that is the sort of thinking you need.
>>
>> I note your list has no Nones, but that is not what is used in the 
>> template; the template uses the data in weewx, there is a subtle 
>> difference. that is why we need to focus on what weewx 'sees' or 'has'.
>>
>> Gary
>>
>> On Friday, 20 January 2017 08:41:33 UTC+10, Robert Mantel wrote:
>>>
>>> Hey Gary, thanks for the reply.  Yes I tried doing some troubleshooting 
>>> by commenting out specific lines, especially the math.exp ones, but when I 
>>> do cheetah just complains it can't find variable "x" whatever one I have 
>>> commented out.  But maybe your technique will yield more info.  Here is the 
>>> label map I'm using in fileparse:
>>>
>>> tempf = outTemp
>>> humidity = outHumidity
>>> inches = pressure
>>> dewptf = dewpoint
>>> windspdavg = windSpeed
>>> winddiravg = windDir
>>> rainin = rainRate
>>> timestamp = dateTime
>>> windgustmph = windGust
>>> windgustdir = windGustDir
>>>
>>> The values on the left come from a cron job I run every minute that does 
>>> a jsonp query to my phant server which acts as my weather station data 
>>> dump.  The timestamp comes from the phant server and my cron job code 
>>> converts it to epoch and the query itself grabs the EST version of the 
>>> timestamp.  While writing this I'm wondering if I should be using UTC? 
>>>  Anyways, my station is inside right now so no wind is being produced but I 
>>> anticipated that the gauges would be able to deal with this condition, 
>>> otherwise it would be complaining all the time about wind and rain and 
>>> such.  Here is a dump of my fileparse data file (the one that weewx 
>>> imports), As you can see there are no null values:
>>>
>>> soc=255.9961
>>> rainin=0.1100
>>> voltage=5.1188
>>> humidity=35.
>>> windspeedmph=0.
>>> kilopascals=98.6170
>>> winddir_avg2m=90
>>> rainmm=2.7940
>>> windspeedmps=0.
>>> hpa=986.1700
>>> tempc=21.6800
>>> windgustmph=0.
>>> tempf=71.0240
>>> inches=29.1216
>>> timestamp=1484865589
>>> windspdmps_avg2m=0.
>>> windspeedkmph=0.
>>> winddir=90
>>> dewptf=42.0318
>>> dewptc=5.5732
>>> altm=235.6895
>>> altf=773.2595
>>> dailyrainin=0.6160
>>> windgustdir=0
>>>
>>> Obviously I'm not mapping all these to weewx as of yet.  I'm hoping you 
>>> can shed some light on this one.  
>>>
>>> On Thursday, 19 January 2017 16:44:52 UTC-5, gjr80 wrote:

 Hi,

 Welcome to the joys of troubleshooting a Cheetah template! The best 
 Cheetah errors to have are those that crash in your 

[weewx-user] Re: gauge-data.txt file not being generated SS gauges

[Robert Mantel]

Ok, I found the offending line in the template and it's this one here:

set $hour_rain_max = $hour.rain.max.raw * $rain_mult

It's now populating the gauges with data, but for some strange reason the 
temperature and aparent temp gauges are cycling from some -5000 number up 
to the correct number once a second or so.  Odd.  So, maybe what I'm 
missing in weewx is the rain rate over one hour, so perhaps I have miss 
directed that info from the weather station to the wrong label in weewx?

On Thursday, 19 January 2017 18:17:13 UTC-5, gjr80 wrote:
>
> Ok, some more thoughts. Delete the content between the {}, no * opertaions 
> in there so the error is not in there. Then work through the 'chunks' of  
> python in the template commenting out/deleting (keeping the template open 
> in an editor and using control-Z/undo is a great timesaver) each one in 
> turn until you find the culprit, eg; comment/delete the appttemp 
> calculations, then the humidex. 
>
> Another thought, run weewx directly 
>  and have a look 
> at what is coming out for each obs in the archive record (archive records 
> are identified with a REC and appear each archive interval). Look for any 
> obs used in the template that have None values. That might give you a clue.
>
> windDir (and the gust equivalent) are often a source of 'Nones' but in 
> this case I don't think any are used in a multiplication operation. But 
> that is the sort of thinking you need.
>
> I note your list has no Nones, but that is not what is used in the 
> template; the template uses the data in weewx, there is a subtle 
> difference. that is why we need to focus on what weewx 'sees' or 'has'.
>
> Gary
>
> On Friday, 20 January 2017 08:41:33 UTC+10, Robert Mantel wrote:
>>
>> Hey Gary, thanks for the reply.  Yes I tried doing some troubleshooting 
>> by commenting out specific lines, especially the math.exp ones, but when I 
>> do cheetah just complains it can't find variable "x" whatever one I have 
>> commented out.  But maybe your technique will yield more info.  Here is the 
>> label map I'm using in fileparse:
>>
>> tempf = outTemp
>> humidity = outHumidity
>> inches = pressure
>> dewptf = dewpoint
>> windspdavg = windSpeed
>> winddiravg = windDir
>> rainin = rainRate
>> timestamp = dateTime
>> windgustmph = windGust
>> windgustdir = windGustDir
>>
>> The values on the left come from a cron job I run every minute that does 
>> a jsonp query to my phant server which acts as my weather station data 
>> dump.  The timestamp comes from the phant server and my cron job code 
>> converts it to epoch and the query itself grabs the EST version of the 
>> timestamp.  While writing this I'm wondering if I should be using UTC? 
>>  Anyways, my station is inside right now so no wind is being produced but I 
>> anticipated that the gauges would be able to deal with this condition, 
>> otherwise it would be complaining all the time about wind and rain and 
>> such.  Here is a dump of my fileparse data file (the one that weewx 
>> imports), As you can see there are no null values:
>>
>> soc=255.9961
>> rainin=0.1100
>> voltage=5.1188
>> humidity=35.
>> windspeedmph=0.
>> kilopascals=98.6170
>> winddir_avg2m=90
>> rainmm=2.7940
>> windspeedmps=0.
>> hpa=986.1700
>> tempc=21.6800
>> windgustmph=0.
>> tempf=71.0240
>> inches=29.1216
>> timestamp=1484865589
>> windspdmps_avg2m=0.
>> windspeedkmph=0.
>> winddir=90
>> dewptf=42.0318
>> dewptc=5.5732
>> altm=235.6895
>> altf=773.2595
>> dailyrainin=0.6160
>> windgustdir=0
>>
>> Obviously I'm not mapping all these to weewx as of yet.  I'm hoping you 
>> can shed some light on this one.  
>>
>> On Thursday, 19 January 2017 16:44:52 UTC-5, gjr80 wrote:
>>>
>>> Hi,
>>>
>>> Welcome to the joys of troubleshooting a Cheetah template! The best 
>>> Cheetah errors to have are those that crash in your non-template python 
>>> code as that way you tend to get a meaningfull error trace, if the crash 
>>> occurs in the in-template python code they can be very hard (well tedious) 
>>> to track down. As you have no doubt found out the line number quoted in the 
>>> error trace is usesless, it refers to a temporary file we have no access 
>>> to. The best clue is the actual error message itself. in this case there is 
>>> a multiplication operation occuring that is using an integer and the value 
>>> None which gives the TypeError. What you need to do is carefully look at 
>>> each multiplication operation in the template (there are 33 but some can be 
>>> ruled out depending on your settings) and see if any of them could possibly 
>>> be using a variable that is None. You have what sounds like a unique setup, 
>>> I would look at what obs your setup is providing weewx and through omission 
>>> could any of the common obs be None? This could cause some variable in the 
>>> template to be None (which 

Re: [weewx-user] Matching rain corrections with weewx and Weather Underground

[Thomas Keffer]

The URLs you have posted show values of 0.06 or 0.07, but your narrative
talks about 0.6 and 0.7. I assume the former is correct and the latter is
just a typo?

The value for dailyrainin comes from field dayRain in the current record,
which, in turn, is pulled off the Vantage weather station. This is why it
matches what you see in the console.

If you want the dayRain to match the sum of 'rain' since midnight, it would
have to be "corrected" by the same factor.

Frankly, correcting for the effects of high winds by boosting rain is no
substitute for correct placement of your ISS. I also live in a high wind
area (the Columbia River Gorge) and don't have any problems with rain. I
would leave it alone.

-tk



On Thu, Jan 19, 2017 at 7:42 PM, J  wrote:

> Thanks for your responses and please pardon my late reply -- I wanted to
> wait until some more rain fell to confirm observations and gather more
> detailed logs.
>
> It appears that the standard Wunderground-PWS archive method posts the
> corrected values, but Wunderground-RF rapid fire submits a combination of
> corrected and uncorrected values. I'm unclear on where the uncorrected
> value is being pulled from.
>
> For reference, the uncorrected value (as displayed by Davis console) at
> the time of the below logs is 0.6 inches. With the weewx corrections it's
> (rounded up to) 0.7. The discrepancy has persisted and widened as more rain
> has fallen throughout the day.
>
> Wunderground-PWS:  both dailyrainin and rainin show the corrected 0.7:
>
> Jan 19 04:47:16 weewx[2009]: restx: Ambient: url: http://weatherstation.
> wunderground.com/weatherstation/updateweatherstation.php?
> action=updateraw=YYY=XXX=
> weewx-3.5.0=3.0=095&*dailyrainin=0.07*&
> winddir=270=50.8=1.0&*rainin=0.07*&
> baromin=29.805=49.4=2017-01-19%2012%3A47%3A00
> Jan 19 04:47:16 weewx[2009]: restx: Wunderground-PWS: Published record
> 2017-01-19 04:47:00 PST (1484830020)
>
> Wunderground-RF rapid fire:  dailyrainin has the uncorrected value (0.6),
> but rainin uses the corrected one (0.7).  WU appears to use the dailyrainin
> value for it's displayed precipitation totals. Log:
>
> Jan 19 04:47:16 weewx[2009]: restx: Ambient: url: http://weatherstation.
> wunderground.com/weatherstation/updateweatherstation.php?
> action=updateraw=YYY=XXX=
> weewx-3.5.0=5.0=095&*dailyrainin=0.06*&
> winddir=247=50.8=5.0=2.5&*rainin=0.07*
> =29.807=49.4=2017-01-19%2012%3A47%3A16=1
>
> If I enable both methods, I can see the displayed value on WU bounce down
> to 0.6 after the Wundergrond-PWS submission, then back to 0.7 with the next
> Wunderground-RF submission.  This bouncing back and forth is also reflected
> occasionally in the WU graphs.
>
>
> mwall wrote:
>
>> jesse, you can use conditionals in corrections:  [...]  each correction
>> must be a single line of python
>
>
> Awesome, thank you!
>
> - jesse
>
>
> On Friday, January 13, 2017 at 6:40:17 PM UTC-8, Tom Keffer wrote:
>
>
> The value sent to wunderground is calculated directly from the database.
>> It's the sum of all rain that fell during the last 60 minutes. So, if
>> you're happy with the values of 'rain' in the database, then you should
>> be getting the same at wunderground.
>>
>> -tk
>>
>> On Fri, Jan 13, 2017 at 6:21 PM, J  wrote:
>>
>>> Hi,
>>>
>>> I'm trying to apply some corrections to my rain data but am running into
>>> an issue with getting Wunderground data to match.
>>>
>>> I want to adjust my rain corrections based on wind data -- I'm
>>> compensating for undercatch during high winds due to my rain bucket's
>>> higher than typical elevation above ground. I'm using a Davis VantagePro2.
>>>
>>> Making corrections to rain and rainRate using windGust works great in
>>> weewx. Each 0.01" tip is adjusted by current wind conditions. However,
>>> Wunderground values are uncorrected. From some reading of past threads, it
>>> sounds like Wunderground data may instead use dayRain and hourRain values
>>> directly from archive records, instead of simply pushing up the weewx
>>> values. I run into the issue that if I try to adjust dayRain and/or
>>> hourRain based on wind from the archive records, not only will the totals
>>> differ because of wind values from different periods, but it seems like the
>>> entire day total would be repeatedly scaled up and down based on whatever
>>> the last wind reading was.
>>>
>>> Is there a way to have the data sent to Wunderground based on the totals
>>> stored by weewx? Or otherwise keep them synced in a sane manner?
>>>
>>> Thanks!
>>> Jesse
>>>
>>> P.S. I'd also love to be able to use windDirection and rainRate as
>>> factors in the corrections, but that's probably overly ambitious without
>>> support for conditionals in corrections.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to weewx-user+...@googlegroups.com.