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 <http://weewx.com/docs/usersguide.htm#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 is used as the basis for a nubmer of derived obs so if you call it OutTempC you will have issues. The Archive Types <http://weewx.com/docs/customizing.htm#archive_types> table at appendix 1 to the Customization Guide may help. Gary -- 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.
