[weewx-user] Re: Rainfall totals incorrect due to Software conversion to US

Your are correct that the driver uses 0.518 mm per bucket tip. However, somewhere in the code it gets rounded up to 0.52 mm per bucket tip. This would explain my 0.0204724409. Not sure where that happens exactly in the driver. I will have to look at the driver more. Either way, the problem wit

[weewx-user] Re: Rainfall totals incorrect due to Software conversion to US

Your are correct that the driver uses 0.518 mm per bucket tip. However, somewhere in the code it gets rounded up to 0.52 mm per bucket tip. This would explain my 0.0204724409. Not sure where that happens exactly in the driver. I will have to look at the driver more to find out were that happen

[weewx-user] memory usage of forecast extension

Sort of related but for sometime I had a memory leak that causing weewx repeport generation to halt after about 3 to 4 weeks. I was using the forecast extension to produce 2 different outputs; one for my Saratoga format page and the other for my native weewx page. One of them was the culprit, my

[weewx-user] Re: Rainfall totals incorrect due to Software conversion to US

I still think there is something screwy here. The lacrosse 23xx driver uses 0.518mm per bucket tip. weewx uses 25.4mm per inch so that is 0.0203937 inches per tip. So in your database you will see multiples of this value in the rain field (assuming you are using US customary units in your databa

[weewx-user] memory usage of forecast extension

I run weewx on a 128 MB RAM system, so perhaps this is a bit unusual, but in loading the current forecast extension it 'seems' that it has really high memory usage in VSZ. I'm wondering how much this might matter (or not): Symptoms I saw: - added forecast 3.2.4 on my weewx 3.6.1 Dockstar, go

[weewx-user] Re: Rainfall totals incorrect due to Software conversion to US

Thanks Andrew. I will give that try. On Saturday, December 17, 2016 at 11:54:35 PM UTC-7, Andrew Milner wrote: > > In your example that is a correct rounding when the print format is > defined with 2 digits precision in the template - change the precision to > %.3 (or whatever is the correct fo

[weewx-user] Re: Rainfall totals incorrect due to Software conversion to US

In your example that is a correct rounding when the print format is defined with 2 digits precision in the template - change the precision to %.3 (or whatever is the correct format) in the template if you want three digits .. if you want to truncate without rounding then I think you wil

[weewx-user] Re: Rainfall totals incorrect due to Software conversion to US

I just checked over 12 months of my NOAA reports, and they were all correct, but I do my summary reports in the same way as the rest of the site - in metric - C, mm and knots - so probably not that helpful a comment!! Even without conversions though the standard weewx generates float values wi

[weewx-user] Re: Rainfall totals incorrect due to Software conversion to US

It's a Lacrosse WS-2316 and like most stations takes observations using the metric system. A conversion is done somewhere, I believe it's in WeeWx but it could be the Lacrosse software. Either way, the problem isn't where the data is converted, the conversion itself is correct. It's the calculat

[weewx-user] Re: Rainfall totals incorrect due to Software conversion to US

Yeah I realize that. The only reason I mention this was that in the Monthly NOAA Climate Summary the total rainfall doesn't match the sum of the daily rainfall. It just looks a little weird but likely no one would really notice. It doesn't happen that often either. On Saturday, December 17,

[weewx-user] Re: Rainfall totals incorrect due to Software conversion to US

. and I thought I was a pedant ! most stations with a tipping cup measuring device provide the rain measurements in metric and/or imperial as being measured in units of .3 or .2 mm or .01" per tip - which means there is probably already a rounding error before the floats even be

[weewx-user] Rainfall totals incorrect due to Software conversion to US

Hi, I am a little puzzled here. All of your figures appear to be quoted in inches, so I am assuming your database is using US customary units (ie inches for rainfall). So wondering where the mm come into it? Also, what type of station are you using? Davis? Gary -- You received this message b

[weewx-user] Rainfall totals incorrect due to Software conversion to US

Sorry if this as been discussed before but after searching through the discussions I couldn't find one that matches my issue exactly. I noticed the month rainfall total for my station was off by 0.01". After some testing, I figured out this was due to the conversion of rainfall data from mm to

Re: [weewx-user] WMR200 Extra Sensors Out of Sequence with WeeWX 3.6.2

Tried reverting the driver but it seemed to be causing problems. I've given up and changed the config on my two sensors: sensor3 is now sensor4 and sensor2 is now sensor3. Everything seems to be working after the changes. I don't have a need for additional sensors so this will work. On Satu

[weewx-user] Adding pressure sensor via I2C or SPI to existing setup?

Hi, I'm considering to buy a TFA KlimaLogg Pro to run it with WeeWX and probably upload the data to WU. According some posts here and on other places, this should work straight forward. But to complete my setup, I'd also like to add a pressure sensor directly to my Raspberry Pi where the KlimaL

[weewx-user] Re: Realtime.txt, realtime.xml and sunbird.txt

I find those two files: Realtime.xml and Sunbird.txt Can you add this to CRT extension? Usually all three files are used. -- You received this message because you are subs

[weewx-user] Re: Integration with AREDN mesh network

jerry, sounds like a lovely project! consider writing down your requirements first, then see which combination of hardware will satisfy those requirements. clarifying the requirements now will also help you manage the system as requirements and priorities change (and when you delegate the cli

Re: [weewx-user] WMR200 Extra Sensors Out of Sequence with WeeWX 3.6.2

Trying this now... On Saturday, December 17, 2016 at 5:41:44 AM UTC-8, Tom Keffer wrote: > > Yes, I see the problem. The corrections are stored in a dictionary, which > has an undefined ordering, so they do not necessarily get applied in the > order they need to be. > > How about reverting to th

Re: [weewx-user] WMR200 Extra Sensors Out of Sequence with WeeWX 3.6.2

This is the only reference to the change but isn't very explicit: *Remapped sensor identifiers in wmr200 driver so that extraTemp1 and extraHumid1 are usable.* It didn't explain the change very well and I wasn't able to determine it would break parts of my setup. On Friday, December 16, 2016 a

[weewx-user] Integration with AREDN mesh network

Hi all, I'm very very new to whew, so apologies in advance if this has been covered. I've seen some discussion but can't quite find what I want. I'm part of a team that is building a local AREDN mesh network (www.aredn.org). This network will be related to offering emergency communications to v

Re: [weewx-user] wrong rain total in the monthly and year report

Make sure you know whether your database is in METRIC or METRICWX --- the difference in rainfall is an order of magnitude! Check option target_unit in [StdConvert] Incidentally, you probably should not have changed from the default unit system if you do not know these things. -tk On Fri, Dec 16,

Re: [weewx-user] WMR200 Extra Sensors Out of Sequence with WeeWX 3.6.2

Yes, I see the problem. The corrections are stored in a dictionary, which has an undefined ordering, so they do not necessarily get applied in the order they need to be. How about reverting to the older version of the driver

Re: [weewx-user] wrong rain total in the monthly and year report

thanks for the info my highest rain rates recorded since june 2014 was 100mm/h 1.6mm/min or 8mm/5min i choose to filter 3cm /5min max because i want to avoid erratic crazy data from my weather station (like 33m the other day) but i want to stay in reasonable high limit. same thing for the wind