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

[Robert Mantel]

Yep, looks like I'm all good to go...thanks for your assistance Gary.

On Monday, 23 January 2017 19:26:05 UTC-5, gjr80 wrote:
>
> Yes, in weewx rain is the total rainfall that occurred in the period 
> concerned; for a loop packet that is the period since the last loop packet 
> that contained a rain field, for an archive record it is the period since 
> the last archive record ie the archive_interval. It is not uncommon for 
> some stations to report a cumulative rain value, most (all?) weewx drivers 
> handle this by caching the last seen rain value and using the difference 
> between that and the current rain value. No matter, sounds like you are 
> on top of it!
>
> Gary
>
> On Tuesday, 24 January 2017 09:22:38 UTC+10, Robert Mantel wrote:
>>
>> I managed to iron out all my problems (at least with my weather station 
>> that is ;-)).  I experimented a great deal with weewx and measuring rain 
>> (turns out is was abnormally warm on the weekend and we had rain and not 
>> snow).  I noticed that simply readying the dailyrainin value from my phant 
>> server which is stored on the particle p1 microcontroller so it keeps track 
>> of the total rain during 24 hours.  I realized that weewx did not like me 
>> feeding this value into the rain variable (i.e. dailyrainin = rain), 
>> because weewx then thinks that 0.011" of rain is falling every 2 minutes! 
>>  So what I did was to simply record bucket tips (0.011") per 2 minute 
>> sensor cycle then purge that variable in the particle p1 once it posts to 
>> my phant server.  That seemed to do the trick and now I'm getting more 
>> believable values for rain.  I guess I'll have to wait for spring to really 
>> test it out.
>>
>>

-- 
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]

Yes, in weewx rain is the total rainfall that occurred in the period 
concerned; for a loop packet that is the period since the last loop packet 
that contained a rain field, for an archive record it is the period since 
the last archive record ie the archive_interval. It is not uncommon for 
some stations to report a cumulative rain value, most (all?) weewx drivers 
handle this by caching the last seen rain value and using the difference 
between that and the current rain value. No matter, sounds like you are on 
top of it!

Gary

On Tuesday, 24 January 2017 09:22:38 UTC+10, Robert Mantel wrote:
>
> I managed to iron out all my problems (at least with my weather station 
> that is ;-)).  I experimented a great deal with weewx and measuring rain 
> (turns out is was abnormally warm on the weekend and we had rain and not 
> snow).  I noticed that simply readying the dailyrainin value from my phant 
> server which is stored on the particle p1 microcontroller so it keeps track 
> of the total rain during 24 hours.  I realized that weewx did not like me 
> feeding this value into the rain variable (i.e. dailyrainin = rain), 
> because weewx then thinks that 0.011" of rain is falling every 2 minutes! 
>  So what I did was to simply record bucket tips (0.011") per 2 minute 
> sensor cycle then purge that variable in the particle p1 once it posts to 
> my phant server.  That seemed to do the trick and now I'm getting more 
> believable values for rain.  I guess I'll have to wait for spring to really 
> test it out.
>
>

-- 
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]

I managed to iron out all my problems (at least with my weather station 
that is ;-)).  I experimented a great deal with weewx and measuring rain 
(turns out is was abnormally warm on the weekend and we had rain and not 
snow).  I noticed that simply readying the dailyrainin value from my phant 
server which is stored on the particle p1 microcontroller so it keeps track 
of the total rain during 24 hours.  I realized that weewx did not like me 
feeding this value into the rain variable (i.e. dailyrainin = rain), 
because weewx then thinks that 0.011" of rain is falling every 2 minutes! 
 So what I did was to simply record bucket tips (0.011") per 2 minute 
sensor cycle then purge that variable in the particle p1 once it posts to 
my phant server.  That seemed to do the trick and now I'm getting more 
believable values for rain.  I guess I'll have to wait for spring to really 
test it out.

On Friday, 20 January 2017 17:20:13 UTC-5, gjr80 wrote:
>
> 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 

[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 

[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.

[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: 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 

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

[gjr80]

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 does not trigger the error) but later on that 
>> variable is used in an equation that does trigger the error. As you can see 
>> it can get complex. One technique I use is what I call the 'method of 
>> halves': 
>>
>>1. make a backup of the template as this is destructive
>>2. open the template
>>3. delete the bottom half of the template
>>4. save the template 
>>5. let weewx do a report cycle(no need to start/stop, just let weewx 
>>continue to run, you could be here a while)
>>6. did the error go away?
>>   - yes - the error is in the bottom half of the template, repeat 
>>   but this time only delete half of what you last 

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

[Robert Mantel]

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 does not trigger the error) but later on that 
> variable is used in an equation that does trigger the error. As you can see 
> it can get complex. One technique I use is what I call the 'method of 
> halves': 
>
>1. make a backup of the template as this is destructive
>2. open the template
>3. delete the bottom half of the template
>4. save the template 
>5. let weewx do a report cycle(no need to start/stop, just let weewx 
>continue to run, you could be here a while)
>6. did the error go away?
>   - yes - the error is in the bottom half of the template, repeat but 
>   this time only delete half of what you last deleted
>- no - the error is the top half of the template, delete half of what 
>   is left and repeat
>
> As I said it can be tedious, also if you have a template with lots of 
> embedded python you need to be careful where you slice. Anyway I think you 
> should get the idea.
>
> Assuming you track down the issue do let us know what the cause was, that 
> way we can harden the gauge-data.txt template.
>
> Good luck
>
> Gary
>
> On Thursday, 19 January 2017 23:44:51 UTC+10, 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 

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

[gjr80]

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 does not trigger the error) but later on that 
variable is used in an equation that does trigger the error. As you can see 
it can get complex. One technique I use is what I call the 'method of 
halves': 

   1. make a backup of the template as this is destructive
   2. open the template
   3. delete the bottom half of the template
   4. save the template 
   5. let weewx do a report cycle(no need to start/stop, just let weewx 
   continue to run, you could be here a while)
   6. did the error go away?
  - yes - the error is in the bottom half of the template, repeat but 
  this time only delete half of what you last deleted
   - no - the error is the top half of the template, delete half of what is 
  left and repeat
   
As I said it can be tedious, also if you have a template with lots of 
embedded python you need to be careful where you slice. Anyway I think you 
should get the idea.

Assuming you track down the issue do let us know what the cause was, that 
way we can harden the gauge-data.txt template.

Good luck

Gary

On Thursday, 19 January 2017 23:44:51 UTC+10, 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