A few comments.
I don't see multiple copies of a loop packet arriving causing a problem.
Archive record obs that are averaged (eg outTemp) will be the same
irrespective of how many time the loop packet is 'accumulated'. Per-period
obs such as rain and, in this case, lightning_strike_count will similarly
be unaffected as the difference for each such obs between successive
duplicate loop packets will be zero. Of course cumulative obs will be
nonsense, but as WeeWX does not use cumulative obs that should not be a
problem.
Also, keep in mind how the [StdCalibrate] [[Corrections]] operate. Each
[StdCalibrate]
[[Corrections]] option value is used as the argument to a python eval()
statement; if the eval() statement causes a python exception to be raised
the correction is silently ignored (and if it exists the destination obs is
left unchanged, if it does not exist it is not created). I would suggest
your main issue is your lightning_distance correction not working as
intended (are you sure lightning_strike_count is indeed 0 or is it None?).
Also, the 2nd of your three lightning_distance corrections is the one you
use; WeeWX does not use 'nan' and use of Null will raise a python exception.
I would suggest you set some appropriate debug settings (I am not familiar
with the MQTTSubscribe driver to know what debug settings are required) in
place such that loop packets emitted by the MQTTSubscribe driver are
logged. Then you will know exactly what is being fed to WeeWX and how to
ensure it is processed/recorded correctly.
Gary
On Wednesday, 2 April 2025 at 04:52:32 UTC+10 Andrew McGinnis wrote:
> 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/1e974fe0-2490-4208-a850-1891ecbe82f1n%40googlegroups.com.
