rainRate gets added to all LOOP packets, even those without rain (SF: #46 ) about weewx HOT 8 CLOSED

If I understand it correctly, the problem here is with hardware that occasionally emits a rainrate value when "prefer_hardware" has been selected.

When it omits one, you get the hardware value.

When it does not emit one, you get a software calculated value.

So, the algorithm effectively switches back and forth, leading to erratic rainRate values.

Sigh. The rain rate wars grind on...

from weewx.

when the hardware emits partial packets, switching between software and hardware is going to be a problem for any calculation.

one approach would be to use 'software' or 'hardware' instead of 'prefer_hardware' for any station that emits partial packets. for example, when someone selects the wmr200 station during install/config, it would set rainRate=hardware. this is analogous to fine offset stations working better with record_generation=software instead of record_generation=hardware.

another approach would be to try to detect partial packets within StdWXCalculate. for example, look at N packets to see if the requested key is in every packet, then adjust the hardware/software/prefer_hardware logic as a result.

from weewx.

I'd much prefer configuring weewx.conf properly at install time. That's something the driver installer can do.

from weewx.

Another option: the way StdWXCalculate works now, it does a calculation for every variable for every packet. So, rainRate is calculated whether or not rain is in the packet.

So, a very simple fix would be to bypass the calculation of rainRate if rain is not in the packet.

from weewx.

rainRate is handled differently than other variables. rainRate is the sum of the rain events in the last rain_period, divided by the rain_period and normalized to depth per hour. the existence of 'rain' in the current packet only affects the accumulation of rain events, not the calculation of rainRate. if there is no rain in the packet, the rainRate can still be calculated (the time window still applies).

from weewx.

The goal is to prevent the switching back and forth between using the hardware value and using a software calculated value. If the user has specified hardware or software, that's easy: just use the specified algorithm exclusively. But, what about prefer_hardware? How do we prevent it from using hardware values some of the time, and software values the rest of the time?

My thinking is that if the hardware is going to emit a rainRate value, it's also going to be in the same packet as the rain value. So, if we limit injecting a software-calculated rainRate to those packets that have rain, but not rainRate, then we will get a consistent use of an algorithm.

This is basically emulating what the hardware does. I'm not aware of any hardware that emits rainRate but not rain.

from weewx.

that solves the problem for rainRate, but only if the hardware always emits rainRate in the same partial packet as rain. however, it does not address the problem for other variables.

option 1: if the hardware emits partial packets, then the config should be either hardware or software, never prefer_hardware. still does not work when software and no caching of values.

option 2: require each driver for hardware with partial packets to cache specific variables

option 3: create a generic caching service

option 4: if hardware emits partial packets, then 'hardware' is the only option

other options?

from weewx.

decided to address this issue by configuring weewx.conf at install (or reconfigure) time.

the confeditor for wmr100, wmr200, wmr9x8, wmr300 uses modify_conf to set the calculation flag to hardware instead of prefer_hardware for rainRate, windchill, dewpoint, heatindex since these stations return partial packets.

implemented at commit 506d67e..1394474

for existing installations, solution is to use 'hardware' (or 'software') instead of 'prefer_hardware' for rainRate (and windchill, dewpoint, heatindex).

from weewx.