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 > <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 [email protected]. For more options, visit https://groups.google.com/d/optout.
