I'm not quite following either. But as far as the corrections not working,
I think you are probably running into the fact that MQTTSubscribe creates a
packet for each topic. For 'individual' topics this works fine if
observations are not dependent on another. The correction you are writing
introduces a dependency between count and distance. Some additional
information is in this thread,
https://groups.google.com/g/weewx-user/c/NQIQ6KhG7To/m/Ke_SWuQxCwAJ
Is there an event topic? This is json message and therefore will get around
the dependency limitation of 'individual' topics.
rich
On Tuesday, 1 April 2025 at 18:14:40 UTC-4 vince wrote:
> 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/1e68532d-4cca-487f-aefa-bcb429c9462fn%40googlegroups.com.
