ETA- 5000+ strike count/min comes from the sensor broadcasting packets in
triplicate, and every 10 seconds for lightning. So up to 18 messages in
each 1-min interval, with what was the true cumulative count of 303,
resulted in 5454 strikes "recorded".
If anyone has a way to suppress duplicate MQTT messages, I'm all ears. I
get why sensors will send a packet multiple times to maximize the chances
of reception at a station, but weewx (or, at least MQTTSubscribeDriver)
sees each one and records it as a separate datapoint to aggregate in the
archive period. Mostly harmless, but not entirely accurate.
On Tuesday, April 1, 2025 at 2:28:50 PM UTC-4 Andrew McGinnis wrote:
> I just set up an Acurite Atlas with the lightning detector sensor add-on.
> The strike_count that it outputs is cumulative (after I found I had 5000+
> lightning strikes per 1min archive interval). I have it, and the
> strike_distance outputs mapped to weewx as below. rtl_433 is converting
> strike_distance from the imperial 'miles' that is natively output, to
> metric 'km', hence the additional units switch:
>
> [[[rtl_433/pi4b8/devices/Acurite-Atlas/A/571/strike_count]]]
> name = lightning_strike_count
> contains_total = true
> [[[rtl_433/pi4b8/devices/Acurite-Atlas/A/571/strike_distance]]]
> name = lightning_distance
> units = km
>
> The sensor output always has a strike count and distance, but since the
> strike count is cumulative, there should be no recorded distance if the
> delta is 0.
>
> In StdCalibrate/Corrections, I have these:
> radiation = luminosity / 126.7 if luminosity is not None else None
> (<----this is working as expected)
> lightning_distance = lightning_distance if lightning_strike_count > 0 else
> float('nan') (<----does not work)
> lightning_distance = lightning_distance if lightning_strike_count > 0 else
> None (<----does not work)
> lightning_distance = lightning_distance if lightning_strike_count > 0 else
> Null (<----does not work)
>
> The *radiation *observation is being recorded as 0 when *luminosity *is
> recorded as 0. But, since 0 is a valid possible output, if 0 != None, then
> 0/126.7 = 0. Fair enough.
> The *lightning_distance* should be evaluating as 0 or None, but instead
> is being recorded as the sensor's output value, while
> *lightning_strike_count* is recorded as 0. I went into the db and ran the
> following, then rebuilt the affected dailies:
>
> - update archive set lightning_strike_count = 0 where
> lightning_strike_count > 5;
> - update archive set lightning_distance = 0 where
> lightning_strike_count = 0;
>
> strike_count > 5 was because I caught my contains_total omission mid day
> yesterday, and there was thunder last night. Strikes before the storm were
> largely invalid, but distance wasn't necessarily.
>
> [image: Screenshot 2025-04-01 141609.png]
> Straight away, *lightning_distance* is being recorded as the sensor's
> value, instead of 0, or ideally None/null.
> 0 is a valid possible distance, assuming I get a direct strike. Without a
> strike, it's not 0 distance- there *isn't* a distance.
>
> Rather than continue trying random changes to the Corrections logic, can
> anyone point to where the issue or mistake may lie? Is it something to do
> with the referenced *lightning_strike_count* being a cumulative number?
> Do I just need to yield and make the logic evaluate to 0?
>
--
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 visit
https://groups.google.com/d/msgid/weewx-user/18198a7b-76e8-47f2-aa13-73b2de9b7886n%40googlegroups.com.
