Maybe something like this:
--- drivers/acurite.py.orig 2021-04-02 13:15:41.000000000 -0700
+++ drivers/acurite.py 2021-09-16 10:59:45.223889264 -0700
@@ -447,6 +447,7 @@
self.r3_max_fail = 3
self.r1_next_read = 0
self.r2_next_read = 0
+ self.cached = dict()
global DEBUG_RAW
DEBUG_RAW = int(stn_dict.get('debug_raw', 0))
@@ -481,11 +482,19 @@
log.debug("R3: %s" % _fmt_bytes(row))
if raw1:
packet.update(Station.decode_R1(raw1))
+ if 'outTemp' in packet:
+ # Cache the current outside temp for barometer
calculations
+ self.cached['outTemp'] = packet['outTemp']
+ self.cached['timestamp'] = time.time()
if raw2:
Station.check_pt_constants(last_raw2, raw2)
last_raw2 = raw2
packet.update(Station.decode_R2(
raw2, self.use_constants, self.ignore_bounds))
+
+ # Make sure we have a recent outside temperature
reading to feed the barometer calculation
+ if 'outTemp' not in packet and 'outTemp' in
self.cached and 'timestamp' in self.cached and self.cached['timestamp'] >
time.time() - 60:
+ packet['outTemp'] = self.cached['outTemp']
self._augment_packet(packet)
ntries = 0
yield packet
On Thursday, September 16, 2021 at 10:26:40 AM UTC-7 Brett Warden wrote:
> This has been bugging me for a few years, but I just haven't been able to
> figure out where/how to fix it best. In the Acurite driver, there are 3
> different data packets (and two variants of one of those), each updated at
> different intervals (18, 60, and 12*60 seconds) Indoor air pressure is
> reported in R2, while outside temperature is reported in alternating R1
> variants. This means that we *often* don't have a current reading for
> outside temperature at the same time we get a pressure reading, especially
> if the USB connection is being finicky, which is common with Acurite
> hardware.
>
> As a result, there can be long intervals (I've seen 10+ minutes) between
> successful barometer calculations. When generating static webpages or
> otherwise working from archive data, this isn't a huge issue. When trying
> to do something near-real-time with loop data (for example MQTT to Home
> Assistant), though, this can be really annoying.
>
> I'm not sure the best way to fix it, but one idea I've been tossing around
> is caching *all* the readings for a period of time (say 1-2 minutes) to
> ensure we have all the R1 data (including outTemp and *both* R1 variants)
> every time we get R2 data (pressure and inTemp). This is nice because it
> only affects the Acurite driver, and as a side effect, the loop data could
> include *everything* that was received in the last minute, not just what
> was in the last packet decoded, yielding a complete snapshot of reasonably
> current data.
>
> Alternately, we could modify lower level weewx behavior, to include
> caching the temperature data used by the barometer calculation
> (weewx.wxformulas.sealevel_pressure_metric and
> weewx.wxformulas.sealevel_pressure_US). This would of course affect other
> drivers, but maybe some of them have the same issue.
>
> Anyway, just looking for thoughts about this, or better ways to solve it.
>
--
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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-user/1d6949e7-83a0-45f9-80ae-0a66b912ef02n%40googlegroups.com.
