Andrew - I think you need to more clearly state your setup and which
problem(s) you are asking for help with because I certainly got very lost
in your posts…..
What is emitting mqtt ?
Are there actual duplicate mqtt messages with the same timestamps ?
How is your mqtt subscribe configured ?
Which mqtt subscribe variant and version are you using ?
What do a few received mqtt messages look like ?
What do a few weewx loop messages with debug=1 look like ?
What do you see ?
What do you expect/hope to see ?
On Tuesday, April 1, 2025 at 1:43:56 PM UTC-7 gjr80 wrote:
> 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/2e0d1f8c-8531-401e-9bfd-f93123d8ec79n%40googlegroups.com.
