AcuRite 06045M lightning detector shows constant 12 miles distance when no detected lightning

[Gene LeSage]

I several questions about data and graphing of AcuRite 06045M lightning detector.  I am using "rtl_433" and "rtl_4233 mqtt auto discover" addons in home assistant to aquire data from AcuRite 06045M and  MQTTSubscribeDriver to import data into weewx. Weewx is installed on raspberry pi.    I have set up belchertown skin for weewx, added lightning detector count and distance to database and I can graph lightning count and distance using belchertown skin.

 Looking at passing thunderstorm today, I got nice uptick in lighting counts which correlated with decreased lightning distance (fig enclosed).   But the lightning distance reading before the storm and after the storm was a steady 12.0 miles, like that is the default value when no lightning is being detected.  I would like to remove those distracting 12-mile data points, since they don't contribute to the graph.   I was wondering how I can do that and why lightning distance reading goes to exactly 12 when there is no lightning activity.   

Here is my chart entry in belchertown graphs.conf file:

     [[chart5]]

        title = Lightning data

        [[[lightning_distance]]]

           name = Lightning distance

           type = scatter

           lineWidth = 0

           yAxis = 1

           mirrored_value = true

           zIndex = 1

           aggregate_interval = 900 # 15 min

           aggregate_type = avg

           color = "#00ff00"

        [[[lightning_strike_count]]]

           name = Strike count / 15 mins

           type = column

           yAxis_label = "Strikes/15min"

           aggregate_interval = 900 # 15 min

           aggregate_type = sum

           color = "#BECC00"

           tooltip_date_format = "dddd LL"

I use "mirrored_value = true" for lightning distance rendering for two reasons, first as lightning distance decreases there is higher chance of approach thunderstorm (high ~ bad on chart) and second it minimizes the overlay of the lighting strike distance data on the lightning strike count.  

Any ideas why there is a constant 12.0 miles in distance without lightning activity and how can I remove the 12.0 mile values preferably easily.  

[Mks Mk]

I use this line in weewx.conf and it works ok with seasons skin.. you can try it

[StdCalibrate]

    [[Corrections]]

        lightning_distance = lightning_distance if lightning_strike_count > 0 else None

[Gene LeSage]

Thanks for pointing me in the right direction, unfortunately your suggestion did not fix the persisting 12mile lightning_distance output.   I tried the following 4 corrections one at a time in weewx.conf:

[[Corrections]]

lightning_distance = lightning_distance if lightning_strike_count  >  0 else None       # no change, persistent 12 mile lightning distance values in the absence of lightning strikes

lightning_distance = None if lightning_strike_count < 1 else lightning_distance    # no change, persistent 12 mile lightning distance values in the absence of lightning strikes.

lightning_distance = None       # results in NULL for all lightning distance values in database

lightning_distance = lightning_distance if lightning_strike_count > 0 else 0.0       # gives lightning distance valve of zero when there are no lightning strikes,  this is close to what I want, but I rather have NULL valves for lightning_distance when strike count is zero.

Its strange that lightening_distance can be set to NULL with the third correction, but not the first or second correction.   Yet the if, else seems to be working in the fourth correction.   

[Mks Mk]

stop weewx and restart it after you make any change to the  weewx.conf

[Gene LeSage]

restarts were done with every change of weewx.conf

[Mks Mk]

is Accumulator set in the  weewx.conf ?

 at the bottom of my  weewx.conf file is like this

[Accumulator]

    [[lightning_strike_count]]

        extractor = sum

    [[lightning_distance]]

        extractor = min

        merger = minmax

[Gene LeSage]

Yes I added accumulator set at end of weewx.conf  and still get the same result , lightning_distance = 12 for all recorded intervals

Here is my output running weewxd directly, I see three lines which show lightning_distance to be None, which is expected from corrections, but the following three lines show lightning_distance to be 11.999...  It appears the correction " lightning_distance = lightning_distance if lightning_strike_count > 0 else None" is working but being ignored in final output to graph and database.  Any additional thoughts?

LOOP:   2021-08-09 18:30:01 EDT (1628548201) dateTime: 1628548201.9, lightning_distance: None, lightning_strike_count: 0.0, maxSolarRad: None, rainRate: 0.16, usUnits: 1

LOOP:   2021-08-09 18:30:01 EDT (1628548201) dateTime: 1628548201.91, lightning_distance: None, lightning_strike_count: 0.0, maxSolarRad: None, rainRate: 0.16, usUnits: 1

LOOP:   2021-08-09 18:30:01 EDT (1628548201) dateTime: 1628548201.92, lightning_distance: None, lightning_strike_count: 0.0, maxSolarRad: None, rainRate: 0.16, usUnits: 1

LOOP:   2021-08-09 18:30:01 EDT (1628548201) dateTime: 1628548201.91, lightning_distance: 11.9999999954, maxSolarRad: None, rainRate: 0.16, usUnits: 1

LOOP:   2021-08-09 18:30:01 EDT (1628548201) dateTime: 1628548201.92, lightning_distance: 11.9999999954, maxSolarRad: None, rainRate: 0.16, usUnits: 1

LOOP:   2021-08-09 18:30:01 EDT (1628548201) dateTime: 1628548201.93, lightning_distance: 11.9999999954, maxSolarRad: None, rainRate: 0.16, usUnits: 1

LOOP:   2021-08-09 18:30:02 EDT (1628548202) barometer: 30.2076711831, dateTime: 1628548202.7, maxSolarRad: None, rainRate: 0.16, usUnits: 1

LOOP:   2021-08-09 18:30:09 EDT (1628548209) dateTime: 1628548209.76, maxSolarRad: None, outTemp: 82.800014, rainRate: 0.16, usUnits: 1

LOOP:   2021-08-09 18:30:09 EDT (1628548209) dateTime: 1628548209.78, maxSolarRad: None, outTemp: 82.800014, rainRate: 0.16, usUnits: 1

LOOP:   2021-08-09 18:30:09 EDT (1628548209) dateTime: 1628548209.78, maxSolarRad: None, outTemp: 82.800014, rainRate: 0.16, usUnits: 1

LOOP:   2021-08-09 18:30:09 EDT (1628548209) dateTime: 1628548209.76, maxSolarRad: None, outHumidity: 59.0, rainRate: 0.16, usUnits: 1

LOOP:   2021-08-09 18:30:09 EDT (1628548209) dateTime: 1628548209.78, maxSolarRad: None, outHumidity: 59.0, rainRate: 0.16, usUnits: 1

LOOP:   2021-08-09 18:30:09 EDT (1628548209) dateTime: 1628548209.79, maxSolarRad: None, outHumidity: 59.0, rainRate: 0.16, usUnits: 1

LOOP:   2021-08-09 18:30:09 EDT (1628548209) dateTime: 1628548209.77, lightning_distance: None, lightning_strike_count: 0.0, maxSolarRad: None, rainRate: 0.16, usUnits: 1

LOOP:   2021-08-09 18:30:09 EDT (1628548209) dateTime: 1628548209.78, lightning_distance: None, lightning_strike_count: 0.0, maxSolarRad: None, rainRate: 0.16, usUnits: 1

LOOP:   2021-08-09 18:30:09 EDT (1628548209) dateTime: 1628548209.79, lightning_distance: None, lightning_strike_count: 0.0, maxSolarRad: None, rainRate: 0.16, usUnits: 1

LOOP:   2021-08-09 18:30:09 EDT (1628548209) dateTime: 1628548209.77, lightning_distance: 11.9999999954, maxSolarRad: None, rainRate: 0.16, usUnits: 1

LOOP:   2021-08-09 18:30:09 EDT (1628548209) dateTime: 1628548209.78, lightning_distance: 11.9999999954, maxSolarRad: None, rainRate: 0.16, usUnits: 1

LOOP:   2021-08-09 18:30:09 EDT (1628548209) dateTime: 1628548209.79, lightning_distance: 11.9999999954, maxSolarRad: None, rainRate: 0.16, usUnits: 1

[gjr80]

On Tuesday, 10 August 2021 at 08:37:42 UTC+10 gle...@gmail.com wrote:

Here is my output running weewxd directly, I see three lines which show lightning_distance to be None, which is expected from corrections, but the following three lines show lightning_distance to be 11.999...  It appears the correction " lightning_distance = lightning_distance if lightning_strike_count > 0 else None" is working but being ignored in final output to graph and database.  Any additional thoughts?

The reason you see no change to lightning_distance for some packets is that for those packets lightning_strike_count does not exist so your calibration expression fails and no change is made, in other words lightning_distance remains as it was 11.9999999954. Why does this happen, in layman's terms when lightning_strike_count is not in the loop packet the calibration expression in effect has an unknown variable (lightning_strike_count) and the calibration expression raises an error. The StdCalibrate service which handles the calibration expressions catches that error and discards that calibration expression. Given the limitations of the StdCalibrate service I am not aware of any calibration expression that would do as you want, of course a WeeWX and python wizard might come along an prove me wrong!

My thoughts on a solution, unless there is a simple solution in your WeeWX driver or elsewhere upstream of WeeWX I would be writing your own WeeWX service to look at the packet and make the necessary correction. This way you can use a bit of python code to do exactly what you want and you won't be limited by the single line expressions as used by StdCalibrate. All up it should take no more than 10 lines of code. The service could be a data_service or process_service (refer weewx.conf [Engine] [[Services]]) but would need to appear before StdArchive is called. The advantage of your own service is that there is no need to change any one else's code (eg WeeWX driver, upstream code) so you will not have your changes lost during an upgrade (WeeWX or otherwise).

Gary

[bell...@gmail.com]

I'm no python expert (probably know just enough to be dangerous), but something like this might get you want you want. 

# ligtning_strike_count must exist and have a count > 0 for lightning_distance to have a valid value

lightning_distance = lightning_distance if 'lightning_strike_count'in locals() and lightning_strike_count> 0 else None

rich

[Gene LeSage]

Initially I thought Rich's solution was going to work, adding his suggested correction <lightning_distance = lightning_distance if 'lightning_strike_count'in locals() and lightning_strike_count> 0 else None>  eliminated my fixed lightning_distance data in the absence of lightning_counts, but it created a new problem, now I don't get lightning_distance values with a lightning strike.  I triggered the lightning detector with a spark by transiently shorting a battery charger at time 14:22:16 , which produced 2 detected lightnings and 14:22:24 which produced one, but the lightning_distance remains at None.  My mqtt explorer reports the lightning detector is sending a constant 12-mile lightning distant 

LOOP:   2021-08-10 14:22:16 EDT (1628619736) dateTime: 1628619736.82, lightning_distance: None, maxSolarRad: None, outHumidity: 73.0, rainRate: 0.32, usUnits: 1

LOOP:   2021-08-10 14:22:16 EDT (1628619736) dateTime: 1628619736.81, lightning_strike_count: 2.0, maxSolarRad: None, rainRate: 0.32, usUnits: 1        <--------------------------------------------------------

LOOP:   2021-08-10 14:22:16 EDT (1628619736) dateTime: 1628619736.82, lightning_distance: None, lightning_strike_count: 0.0, maxSolarRad: None, rainRate: 0.32, usUnits: 1

LOOP:   2021-08-10 14:22:16 EDT (1628619736) dateTime: 1628619736.83, lightning_distance: None, lightning_strike_count: 0.0, maxSolarRad: None, rainRate: 0.32, usUnits: 1

LOOP:   2021-08-10 14:22:16 EDT (1628619736) dateTime: 1628619736.81, lightning_distance: None, maxSolarRad: None, rainRate: 0.32, usUnits: 1

LOOP:   2021-08-10 14:22:16 EDT (1628619736) dateTime: 1628619736.82, lightning_distance: None, maxSolarRad: None, rainRate: 0.32, usUnits: 1

LOOP:   2021-08-10 14:22:16 EDT (1628619736) dateTime: 1628619736.83, lightning_distance: None, maxSolarRad: None, rainRate: 0.32, usUnits: 1

LOOP:   2021-08-10 14:22:24 EDT (1628619744) dateTime: 1628619744.67, lightning_distance: None, maxSolarRad: None, outTemp: 82.000004, rainRate: 0.32, usUnits: 1

LOOP:   2021-08-10 14:22:24 EDT (1628619744) dateTime: 1628619744.68, lightning_distance: None, maxSolarRad: None, outTemp: 82.000004, rainRate: 0.32, usUnits: 1

LOOP:   2021-08-10 14:22:24 EDT (1628619744) dateTime: 1628619744.69, lightning_distance: None, maxSolarRad: None, outTemp: 82.000004, rainRate: 0.32, usUnits: 1

LOOP:   2021-08-10 14:22:24 EDT (1628619744) dateTime: 1628619744.67, lightning_distance: None, maxSolarRad: None, outHumidity: 73.0, rainRate: 0.32, usUnits: 1

LOOP:   2021-08-10 14:22:24 EDT (1628619744) dateTime: 1628619744.68, lightning_distance: None, maxSolarRad: None, outHumidity: 73.0, rainRate: 0.32, usUnits: 1

LOOP:   2021-08-10 14:22:24 EDT (1628619744) dateTime: 1628619744.69, lightning_distance: None, maxSolarRad: None, outHumidity: 73.0, rainRate: 0.32, usUnits: 1

LOOP:   2021-08-10 14:22:24 EDT (1628619744) dateTime: 1628619744.68, lightning_strike_count: 1.0, maxSolarRad: None, rainRate: 0.32, usUnits: 1            <-----------------------------------------------------------

LOOP:   2021-08-10 14:22:24 EDT (1628619744) dateTime: 1628619744.69, lightning_distance: None, lightning_strike_count: 0.0, maxSolarRad: None, rainRate: 0.32, usUnits: 1

LOOP:   2021-08-10 14:22:24 EDT (1628619744) dateTime: 1628619744.69, lightning_distance: None, lightning_strike_count: 0.0, maxSolarRad: None, rainRate: 0.32, usUnits: 1

[tarob...@gmail.com]

I think going back to your original issue something seems to be off. Can you post you weewx.conf for lightning data? If you're using sdr, should contain the following in each section:

[SDR]

    [[sensor_map]]

        ......

        lightning_distance = distance.XXXX.AcuriteLightningPacket

        strikes_total = strikes_total.XXXX.AcuriteLightningPacket

    [[deltas]]

        rain = rain_total

        lightning_strike_count = strikes_total

[StdCalibrate]

    

    [[Corrections]]

        lightning_distance = lightning_distance if lightning_strike_count > 0 else None

[Accumulator]

    [[lightning_strike_count]]

        extractor = sum

    [[lightning_distance]]

        extractor = min

[Gene LeSage]

I am using weewx-MQTTSubscribe to bring data into Weewx from sensors, so i don't use SDR sensor map, see config for mqttsubscribe here https://github.com/bellrichm/WeeWX-MQTTSubscribe/wiki/Configuring  A number of unsuccessful tries to modify mqttsubscribe are commented out.  

[MQTTSubscribeDriver]

 [[topics]]

  [[[rtl_433/9b13b3f4-rtl433/devices/Acurite-6045M/C/223/strike_count]]]

            [[[[rtl_433/9b13b3f4-rtl433/devices/Acurite-6045M/C/223/strike_count]]]]

                name = lightning_strike_count    #strikes_total  #strike_count

                contains_total = true

#                conversion_type = int

#                units = count

#                expires_after = 0

        [[[rtl_433/9b13b3f4-rtl433/devices/Acurite-6045M/C/223/storm_dist]]]

            [[[[rtl_433/9b13b3f4-rtl433/devices/Acurite-6045M/C/223/storm_dist]]]]

                name = lightning_distance    #strike_dist  #LS_1_distance

#                units = mile

#                conversion_type = int

#                expires_after = 0

    [[Corrections]]

        # For each type, an arbitrary calibration expression can be given.

        # It should be in the units defined in the StdConvert section.

        # Example:

         lightning_distance = lightning_distance if lightning_strike_count > 0 else None

[Accumulator]

    [[lightning_strike_count]]

        extractor = sum 

    [[lightning_distance]]

        extractor = min

#        merger = minmax

[bell...@gmail.com]

I fear the root cause is that MQTTSubscribeDriver takes each MQTT message and creates a loop packet. This works ok for 'aggregated' messages like json or keyword (the original implementations). But for 'individual' payloads that are dependent on each other, it is problematic.I've already had to deal with this for wind data. MQTTSubscribe collects speed and direction data into a single loop packet.

Since then I've been experimenting with collecting data and creating the loop packet from the collection.  Looking at your loop packets, I think it might help you. 

The code is a pre-release which can be found here, https://github.com/bellrichm/WeeWX-MQTTSubscribe/releases/tag/v2.1.0-rc02

You will need to add two undocumented configuration options.

[MQTTSubscribeDriver]

.

.

.

    [[topics]

        # With the exception of wind data, by default a packet is created for every MQTT message received.

        # When this is true, MQTTSubscribe attempts to collect observations across messages into a packet.

        # Default is False.

        # This is experimental and may be removed.

        collect_observations = True

        # With the exception of wind data, by default a queue is created for every MQTT topic.

        # When this is true, MQTTSubsribe uses a single queue for all non wind data.

        # This is useful when 'collect_observations = True'.

        # Default is False.

        # This is experimental and may be removed.

        single_queue = True

.

.

.

With this, the incoming data should be collected and a loop packet only created when the arriving observation is already in the collection. Since, hopefully, the loop packet now has both strike and distance data, your [[Corrections]] should work.

If this doesn't work. I'll have to go back to the drawing board and look for a different solution. If it comes to this, I'd need a debug level log for at least one archive period so that I can analyze the data.

This is beta code, so the usual caveats apply. 

rich

ps.

If you are using rtl_433 to publish to MQTT, another option might be to use the 'events' topic that it publishes to. This is a json formatted message so the loop packet created for each MQTT message should have both the strike and distance data.

[Gene LeSage]

Bingo, fixed by installing v2.1.0-RC MQTTSubscribeDriver. Adding collect_observations = True and single_queue = True to   [[topics], I get desired behavior.  Null lightning distance is recorded in absence of strikes and with an test simulated lightning strike by battery charger shorting, I get lightning strike recording and a lightning distance.  Loop shows both lightning distance and strikes in same loop:

LOOP:   2021-08-11 14:56:07 EDT (1628708167) active: 1.0, cloudbase: 5636.94172822, dateTime: 1628708167.42, dewpoint: 70.6358563958, heatindex: 93.4196227576, humidex: 103.698544022, lightning_distance: None, lightning_strike_count: 0, maxSolarRad: None, outHumidity: 57.0, outTemp: 87.8, rainRate: 0, usUnits: 1

LOOP:   2021-08-11 14:56:07 EDT (1628708167) active: 1.0, cloudbase: 5636.94172822, dateTime: 1628708167.43, dewpoint: 70.6358563958, heatindex: 93.4196227576, humidex: 103.698544022, lightning_distance: None, lightning_strike_count: 0, maxSolarRad: None, outHumidity: 57.0, outTemp: 87.8, rainRate: 0, usUnits: 1

Supporting the idea that lightning strikes and distances were being interpreted at different times I caught two lightning strikes this morning (before installing v2.1.0-RC) which shows the 8 am lightning strike before lightning distance change  and the 11 am lightning strike after lightning distance change.  By not being synchronized, the correction (lightning_distance = lightning_distance if lightning_strike_count > 0 else None) would never work.  

Thanks

[Gene LeSage]

Not quite bingo, I am still getting some fixed lightning_distance integers in the absence of strikes, about 6 per hour.  Loops are produced with lightning_distance = 7.999  and no information on lightning_strike_count and other loops have with both lightning_distance = 7.999 and lightning_strike_count = 0   See below output from weewxd for 2 hours.  

I changed  [[Corrections]] to

  lightning_distance = None if lightning_strike_count == 0 or None else lightning_distance

thinking that this correction would set lightning_distance to none in the absence of a lightning strike count, but the correction had no effect.  Looking at all the loops there is no reason some loops  have lightning_distance: 7.99 while the great majority have the desired lightning_distance: None.  

I got a great improvement moving to MQTTSubscribeDriver 2.1.0rc but the problem persists to a small degree.  The problem is happening sporadically and rarely.  Any thoughts?   I really don't want to give up MQTTSubscribeDriver since it is so versatile in what data you can bring into weewx.  

pi@raspberrypi:~ $  grep "lightning_distance: 7" weewxout1

LOOP:   2021-08-12 13:58:54 EDT (1628791134) active: 1.0, cloudbase: 4673.53199141, dateTime: 1628791134.4, dewpoint: 68.5748592378, heatindex: 84.58478629, humidex: 95.6055479842, lightning_distance: 7.99999999694, lightning_strike_count: None, maxSolarRad: None, outHumidity: 65.0, outTemp: 81.5, rainRate: 0, usUnits: 1

REC:    2021-08-12 14:00:00 EDT (1628791200) active: 0.4, cloudbase: 4592.04983163, dateTime: 1628791200, dewpoint: 68.8533815408, ET: None, heatindex: 84.5975618398, humidex: 95.7627385325, interval: 5, lightning_distance: 7.99999999694, lightning_strike_count: 0.0, maxSolarRad: None, outHumidity: 65.8, outTemp: 81.4200008, rain: 0.04, rainRate: 0.0421052631579, usUnits: 1

LOOP:   2021-08-12 14:42:54 EDT (1628793774) active: 1.0, dateTime: 1628793774.25, lightning_distance: 7.99999999694, maxSolarRad: None, rainRate: 0, usUnits: 1

REC:    2021-08-12 14:45:00 EDT (1628793900) active: 1.0, altimeter: 30.3586782548, barometer: 30.2545352733, cloudbase: 4768.17055948, dateTime: 1628793900, dewpoint: 70.2239033928, ET: None, heatindex: 87.9424503611, humidex: 99.1008122419, interval: 5, lightning_distance: 7.99999999694, lightning_strike_count: 0.0, maxSolarRad: None, outHumidity: 64.3243243243, outTemp: 83.5654538545, pressure: 28.5043137197, rain: 0.0, rainRate: 0.0, usUnits: 1

LOOP:   2021-08-12 14:58:06 EDT (1628794686) active: 1.0, dateTime: 1628794686.48, lightning_distance: 7.99999999694, maxSolarRad: None, rainRate: 0, usUnits: 1

LOOP:   2021-08-12 14:58:30 EDT (1628794710) active: 1.0, dateTime: 1628794710.6, lightning_distance: 7.99999999694, maxSolarRad: None, rainRate: 0, usUnits: 1

REC:    2021-08-12 15:00:00 EDT (1628794800) active: 0.911764705882, altimeter: 30.352863321, barometer: 30.248274916, cloudbase: 4781.8918872, dateTime: 1628794800, dewpoint: 71.158468132, ET: None, heatindex: 89.7957954486, humidex: 100.932534378, interval: 5, lightning_distance: 7.99999999694, lightning_strike_count: 0.0, maxSolarRad: None, outHumidity: 64.3235294118, outTemp: 84.5603924356, pressure: 28.4987883408, rain: 0.0, rainRate: 0.0, usUnits: 1

LOOP:   2021-08-12 15:50:46 EDT (1628797846) active: 1.0, dateTime: 1628797846.38, lightning_distance: 7.99999999694, maxSolarRad: None, rainRate: 0, usUnits: 1

REC:    2021-08-12 15:55:00 EDT (1628798100) active: 1.0, altimeter: 30.3401020979, barometer: 30.2347797117, cloudbase: 4909.75354319, dateTime: 1628798100, dewpoint: 71.8556696944, ET: None, heatindex: 91.9474302989, humidex: 102.838512165, interval: 5, lightning_distance: 7.99999999694, lightning_strike_count: 0.0, maxSolarRad: None, outHumidity: 63.2432432432, outTemp: 85.8181836364, pressure: 28.4866625997, rain: 0.0, rainRate: 0.0, usUnits: 1

[gjr80]

You appear to have a logic error in your calibration expression, the hanging None has no affect at all in your expression. If you wish to check lightning_strike_count is None you need to use something like:

lightning_distance = None if lightning_strike_count == 0 or lightning_strike_count is None else lightning_distance

Gary

[bell...@gmail.com]

I am guessing that you are getting loop packets with just distance because of the order the data is arriving over MQTT. 

For example:

message with distance arrives 

  - data is saved

another message with distance arrives

  - packet with saved data is created

  - current message is saved

message with count arrives

  - count is saved

a message with either distance or count arrives

  - packet with saved data is created

  - data received is saved

A debug level log would confirm this.

If a ‘corrections’ expression won’t fix this, I will need a debug level log to get an understanding of the data being received.

If you are using rtl_433 to publish to MQTT, I’d also be interested in what is being published to the ‘events’ topic.

rich

[Gene LeSage]

Rich, I have solved problem for persisting distance values without lightning strikes,  I am now using json rather than individual message callback, this leads to both lightning_strikes and lightning_distance to be in same loop which as you predicted would solved the problem.  My  [MQTTSubscribeDriver] entry for the acurite 6054 lightning detector and acurite -rain899 rainfall gauge are included below, my example shows working for  msg_id_field for  acurite 6054  to be 233 and the  acurite -rain899 to be 1322.   Msg_id_field  may differ for other peoples devices, but I don't know.  

One question remains, as usual when you solve one problem, you create another,  I have sensors which for their mqtt output are not formatted in json, but work using "individual" callback.  Some might be convertible to json but others will not.  I see you have in configuring experimental options, the option to pick for each topic the type of format, with "name = value format" but I am not sure where that goes or if it will work with my current version  (2.1.0rc).  Thanks for the suggestions and the great work on  MQTTSubscribeDriver.    Gene

    [[message_callback]]

        # The format of the MQTT payload.

        # Currently support: individual, json, keyword

        # Must be specified.

        type = json

#        keyword_separator = ":"

#        keyword_delimiter = ","

    [[topics]]

        # Units for MQTT payloads without unit value.

        # Valid values: US, METRIC, METRICWX

        # For more information see, http://weewx.com/docs/customizing.htm#units

        # Default is US

        unit_system = METRIC

        [[[rtl_433/9b13b3f4-rtl433/events]]]

        msg_id_field = id

           [[[[time]]]]

               ignore_msg_id_field = True

               ignore = True

           [[[[model]]]]

               ignore_msg_id_field = True

               ignore = True

           [[[[id]]]]

               ignore_msg_id_field = True

               ignore = True

           [[[[channel]]]]

               ignore_msg_id_field = True

               ignore = True

           [[[[battery_ok]]]]

               ignore_msg_id_field = True

               ignore = True

           [[[[temperature_C_223]]]]

                name = outTemp

                units = degree_C

           [[[[humidity_223]]]]

                name = outHumidity

           [[[[strike_count_223]]]]

                name = lightning_strike_count

                contains_total = True

           [[[[storm_dist_223]]]]

                name = lightning_distance

                units = mile

           [[[[active]]]]

               ignore_msg_id_field = True

               ignore = True

           [[[[rfi]]]]

               ignore_msg_id_field = True

               ignore = True

           [[[[exception]]]]

               ignore_msg_id_field = True

               ignore = True

           [[[[raw_msg]]]]

               ignore_msg_id_field = True

               ignore = True

           [[[[mic]]]]

               ignore_msg_id_field = True

               ignore = True

           [[[[rain_mm_1322]]]]

                name = rain

                contains_total = true

                units = mm

[bell...@gmail.com]

Good to hear you have something working.

Here is some information on configuring the message type by payload.

https://github.com/bellrichm/WeeWX-MQTTSubscribe/issues/113#issuecomment-809655246
This exists on the version you have. If you have any feedback, let me know.

rich

[Gene LeSage]

Rich, I set up for both json and individual mqtt callback types, the beginning of my topics section in [MQTTSubscribeDriver] is shown,  the remainder of the topic section is the same as my previous post. I am unable to get the first topic (homeassistant/sensor/barometer) running as individual callback to be recorded in weewx.  I ran in logging level = DEBUG and looking grep barometer mqtt.log show at bottom, I see that the barometer topic is set up, read, with a value of 1025, but the last line shows that its value is ignored.   Any thoughts why not working?   

#    [[message_callback]]

        # The format of the MQTT payload.

        # Currently support: individual, json, keyword

        # Must be specified.

    [[topics]]

      [[[message]]]

        type = json

        keyword_separator = ":"

        keyword_delimiter = ","

        # Units for MQTT payloads without unit value.

        # Valid values: US, METRIC, METRICWX

        # For more information see, http://weewx.com/docs/customizing.htm#units

        # Default is US

#        unit_system = METRIC

      [[[homeassistant/sensor/barometer]]]

          [[[[homeassistant/sensor/barometer]]]]

             type = individual

             name = barometer

             units = mbar

      [[[rtl_433/9b13b3f4-rtl433/events]]]

        msg_id_field = id

           [[[[time]]]]

               ignore_msg_id_field = True

               ignore = True

           [[[[model]]]]

               ignore_msg_id_field = True

               ignore = True

.........

grep barometer mqtt.log

2021-08-14 11:07:51 DEBUG (Driver) MQTTSUBscriber sanitized_service_dict is {u'username': u'----', u'log': u'true', u'topics': {u'message': {u'type': u'json', u'keyword_separator': u':', u'keyword_delimiter': u','}, u'homeassistant/sensor/barometer': {u'homeassistant/sensor/barometer': {u'type': u'individual', u'name': u'barometer', u'units': u'mbar', u'ignore': u'False'}}, u'rtl_433/9b13b3f4-rtl433/events': {u'msg_id_field': u'id', u'time': {u'ignore_msg_id_field': u'True', u'ignore': u'True'}, u'model': {u'ignore_msg_id_field': u'True', u'ignore': u'True'}, u'id': {u'ignore_msg_id_field': u'True', u'ignore': u'True'}, u'channel': {u'ignore_msg_id_field': u'True', u'ignore': u'True'}, u'battery_ok': {u'ignore_msg_id_field': u'True', u'ignore': u'True'}, u'temperature_C_223': {u'name': u'outTemp', u'units': u'degree_C'}, u'humidity_223': {u'name': u'outHumidity'}, u'strike_count_223': {u'name': u'lightning_strike_count', u'contains_total': u'True'}, u'storm_dist_223': {u'name': u'lightning_distance', u'units': u'mile'}, u'active': {u'ignore_msg_id_field': u'True', u'ignore': u'True'}, u'rfi': {u'ignore_msg_id_field': u'True', u'ignore': u'True'}, u'exception': {u'ignore_msg_id_field': u'True', u'ignore': u'True'}, u'raw_msg': {u'ignore_msg_id_field': u'True', u'ignore': u'True'}, u'mic': {u'ignore_msg_id_field': u'True', u'ignore': u'True'}, u'rain_mm_1322': {u'name': u'rain', u'contains_total': u'true', u'units': u'mm'}}}, u'driver': u'user.MQTTSubscribe', u'logging_level': u'DEBUG', u'host': u'localhost', u'keepalive': u'60', u'port': u'1883', u'logging_filename': u'/home/pi/mqtt.log'}

2021-08-14 11:07:51 DEBUG (Driver) TopicManager self.subscribed_topics is {"homeassistant/sensor/barometer": {"datetime_format": null, "msg_id_field": null, "qos": 0, "filters": {}, "fields": {"homeassistant/sensor/barometer": {"name": "barometer", "contains_total": false, "conversion_error_to_none": false, "ignore": false, "conversion_func": {"source": "lambda x: to_float(x)", "compiled": "<function <lambda> at 0x761368b0>"}, "units": "mbar"}}, "message-1628953671.535918": {"type": "json", "keyword_separator": ":", "keyword_delimiter": ","}, "use_server_datetime": false, "queue": {"name": "homeassistant/sensor/barometer", "type": "normal", "adjust_start_time": 0.0, "adjust_end_time": 0.0, "ignore_start_time": false, "ignore_end_time": false, "data": "deque([])", "max_size": 2147483647}, "ignore_msg_id_field": [], "ignore": false, "subscribe": true, "conversion_func": {"source": "lambda x: to_float(x)", "compiled": "<function <lambda> at 0x76200970>"}, "unit_system": 1, "topic_tail_is_fieldname": false, "offset_format": null}, "rtl_433/9b13b3f4-rtl433/events": {"datetime_format": null, "msg_id_field": "id", "qos": 0, "filters": {}, "fields": {"exception": {"ignore": true, "conversion_func": {"source": "lambda x: to_float(x)", "compiled": "<function <lambda> at 0x7614ecb0>"}, "contains_total": false, "name": "exception", "conversion_error_to_none": false}, "temperature_C_223": {"name": "outTemp", "contains_total": false, "conversion_error_to_none": false, "ignore": false, "conversion_func": {"source": "lambda x: to_float(x)", "compiled": "<function <lambda> at 0x761366b0>"}, "units": "degree_C"}, "rain_mm_1322": {"name": "rain", "contains_total": true, "conversion_error_to_none": false, "ignore": false, "conversion_func": {"source": "lambda x: to_float(x)", "compiled": "<function <lambda> at 0x761530f0>"}, "units": "mm"}, "strike_count_223": {"ignore": false, "conversion_func": {"source": "lambda x: to_float(x)", "compiled": "<function <lambda> at 0x7614ad70>"}, "contains_total": true, "name": "lightning_strike_count", "conversion_error_to_none": false}, "battery_ok": {"ignore": true, "conversion_func": {"source": "lambda x: to_float(x)", "compiled": "<function <lambda> at 0x76136bb0>"}, "contains_total": false, "name": "battery_ok", "conversion_error_to_none": false}, "humidity_223": {"ignore": false, "conversion_func": {"source": "lambda x: to_float(x)", "compiled": "<function <lambda> at 0x7614a9b0>"}, "contains_total": false, "name": "outHumidity", "conversion_error_to_none": false}, "mic": {"ignore": true, "conversion_func": {"source": "lambda x: to_float(x)", "compiled": "<function <lambda> at 0x7614e3f0>"}, "contains_total": false, "name": "mic", "conversion_error_to_none": false}, "raw_msg": {"ignore": true, "conversion_func": {"source": "lambda x: to_float(x)", "compiled": "<function <lambda> at 0x7614ebb0>"}, "contains_total": false, "name": "raw_msg", "conversion_error_to_none": false}, "rfi": {"ignore": true, "conversion_func": {"source": "lambda x: to_float(x)", "compiled": "<function <lambda> at 0x7614eb70>"}, "contains_total": false, "name": "rfi", "conversion_error_to_none": false}, "storm_dist_223": {"name": "lightning_distance", "contains_total": false, "conversion_error_to_none": false, "ignore": false, "conversion_func": {"source": "lambda x: to_float(x)", "compiled": "<function <lambda> at 0x7614a770>"}, "units": "mile"}, "time": {"ignore": true, "conversion_func": {"source": "lambda x: to_float(x)", "compiled": "<function <lambda> at 0x761367f0>"}, "contains_total": false, "name": "time", "conversion_error_to_none": false}, "active": {"ignore": true, "conversion_func": {"source": "lambda x: to_float(x)", "compiled": "<function <lambda> at 0x7614e730>"}, "contains_total": false, "name": "active", "conversion_error_to_none": false}, "model": {"ignore": true, "conversion_func": {"source": "lambda x: to_float(x)", "compiled": "<function <lambda> at 0x761367b0>"}, "contains_total": false, "name": "model", "conversion_error_to_none": false}, "id": {"ignore": true, "conversion_func": {"source": "lambda x: to_float(x)", "compiled": "<function <lambda> at 0x76136730>"}, "contains_total": false, "name": "id", "conversion_error_to_none": false}, "channel": {"ignore": true, "conversion_func": {"source": "lambda x: to_float(x)", "compiled": "<function <lambda> at 0x76136370>"}, "contains_total": false, "name": "channel", "conversion_error_to_none": false}}, "message-1628953671.535918": {"type": "json", "keyword_separator": ":", "keyword_delimiter": ","}, "use_server_datetime": false, "queue": {"name": "rtl_433/9b13b3f4-rtl433/events", "type": "normal", "adjust_start_time": 0.0, "adjust_end_time": 0.0, "ignore_start_time": false, "ignore_end_time": false, "data": "deque([])", "max_size": 2147483647}, "ignore_msg_id_field": ["time", "model", "id", "channel", "battery_ok", "active", "rfi", "exception", "raw_msg", "mic"], "ignore": false, "subscribe": true, "conversion_func": {"source": "lambda x: to_float(x)", "compiled": "<function <lambda> at 0x761365b0>"}, "unit_system": 1, "topic_tail_is_fieldname": false, "offset_format": null}, "1628953671.557307-windGust-windGustDir-windDir-windSpeed": {"datetime_format": null, "queue": {"name": "1628953671.557307-windGust-windGustDir-windDir-windSpeed", "type": "collector", "adjust_start_time": 0.0, "adjust_end_time": 0.0, "ignore_start_time": false, "ignore_end_time": false, "data": "deque([])", "max_size": 2147483647}, "qos": 0, "message-1628953671.535918": {}, "use_server_datetime": false, "offset_format": null, "subscribe": false, "unit_system": 1, "topic_tail_is_fieldname": false}}

2021-08-14 11:07:51 DEBUG (Driver) MQTTSubscribe MQTT: Sending SUBSCRIBE (d0, m1) [('homeassistant/sensor/barometer', 0)]

2021-08-14 11:07:51 INFO (Driver) Subscribing to homeassistant/sensor/barometer has a mid 1 and rc 0

2021-08-14 11:10:02 DEBUG (Driver) MQTTSubscribe MQTT: Received PUBLISH (d0, q0, r0, m0), 'homeassistant/sensor/barometer', ...  (8 bytes)

2021-08-14 11:10:02 DEBUG (Driver) MessageCallbackProvider data-> incoming topic: homeassistant/sensor/barometer, QOS: 0, retain: 0, payload: 1025.455

2021-08-14 11:10:02 ERROR (Driver) **** MessageCallbackProvider Ignoring topic=homeassistant/sensor/barometer and payload=1025.455

[bell...@gmail.com]

In the log should be more info with the error message. I think it might be multiple lines, which is why it did not show up in the grep. 

But, I think the problem is that we don’t have the ‘type’ setting in quite the correct place.  Try something like this

  [[topics]]

      [[[message]]]

        type = json

        keyword_separator = ":"

        keyword_delimiter = ","

        # Units for MQTT payloads without unit value.

        # Valid values: US, METRIC, METRICWX

        # For more information see, http://weewx.com/docs/customizing.htm#units

        # Default is US

#        unit_system = METRIC

      [[[homeassistant/sensor/barometer]]]

          [[[[message]]]]

                type = individual

          [[[[homeassistant/sensor/barometer]]]]

             name = barometer

             units = mbar

Sorry for the tenseness of the replies, I’m away from my computer for a few days. 

rich

[Gene LeSage]

Rich with your suggestion, barometer now works, thanks,    Gene