> > 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
This is what was happening. I followed the links and read through that thread. Maybe I took away the wrong solution, but I added the collect_observations = True and single_queue = True options. Wipe errant db records, rebuild affected daily reports, restart weewx, and boom- everything is working as intended. Lightning strikes are recording as 0, and strike distance is registering as N/A. We'll see what happens during the next expected storm this coming Monday, but this seems to be what I needed. On Tue, Apr 1, 2025 at 8:23 PM [email protected] <[email protected]> wrote: > > 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 a topic in the > Google Groups "weewx-user" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/weewx-user/b3O1IzVjiCc/unsubscribe. > To unsubscribe from this group and all its topics, 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 > <https://groups.google.com/d/msgid/weewx-user/1e68532d-4cca-487f-aefa-bcb429c9462fn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAH3iRs0J9BGTcvBzRS6n3f0iS7PRYpsYXrKpdSnw2TbGL7URQg%40mail.gmail.com.
