WeeWX and Home Assistant MQTT Device Discovery

[bell...@gmail.com]

I think I now have a handle on some Home Assistant nomenclature and have created a release of MQTTPublish with beta support for Home Assistant MQTT Device Discovery. It can be found here, https://github.com/weewx-mqtt/publish/discussions/24

This release is 1.1.0; and can installed via the weectl extension installer. It also greatly improves the reconnect logic and has some additional enhancements/fixes to 1.0.1.

Who might be interested in the Home Assistant Device Discovery?
- Someone knew to integrating Home Assistant and WeeWX. It should make it easier to get it up and running. Then you can decide to either dive deeper into MQTTPublish for more complex configuration options or switch to configuring it in Home Assistant.
- Someone who does not enjoy yaml (that would be me).
- Someone that has a robust process to build and version WeeWX configuration data and doesn't want to create something like that for configuring WeeWX sensors in Home Assistant (me again).

Enjoy

-rich

[rae...@gmail.com]

I am interested.  I'm trying to get the weewx-home-assistant extension working.  It does to some extent but I'm having issues with it not populating certain calculated values.

[bell...@gmail.com]

I’ve been working on making the ‘configuration template’ more explicit - hopefully to make it easier for people to understand how to configure.

Let me create a release with those updates. I’ll post back when it is ready to be installed. Shouldn’t take long.

rich

[rae...@gmail.com]

That's fantastic Rich, I'll gladly be the guinea pig for this.

[bell...@gmail.com]

I released 1.2.0. This has additional information in the configuration 'template' that hopefully will make it easier for people to under how to configure MQTTPublish. Hopefully after your previous struggles, this should go smoother.After installing my approach would be the following (Unfortunately I don't think running MQTTPublish standalone is ready for use):

Enable MQTTPublish and update the MQTT broker for MQTTPublish. Assuming you have a development broker that allows anonymous logins and does not require encryption, you should now be able to publish loop and archive data. Note, I'd update the topic at this time.

Restart WeeWX and see if the data is being published. If so, decide if you want to 'opt-in' or 'opt-out'. 'opt-in' means listing the fields that you want to publish. 'opt-out' means listing the fields you don't want to publish. This is your choice. I'd restart WeeWX and make sure every thing is running as expected.

Next, I'd move on to getting HA MQTT Device Discovery working. Enable the plugin, provide a device name and the topic to use (this would the one configured above). Restart WeeWX and things should start appearing in Home Assistant. Data "known" to WeeWX should flow in with 'reasonable' configurations. Some of your calculated values might need some additional configuration (https://weewx-mqtt.github.io/publish/plugins/homeassistantconfig/devices/device-id/component_data/component-id/). We can work through this.

Yes, I am slow and methodical. Obviously multiple steps can be done an once and different approaches can be used.
If you run into any problems or confusion, let me know. Documentation is far from my strength :)

Thanks in advance for your help
rich

Additional notes:
Disclaimer - I am a HA novice
If you publish the sensor state data to HA in a json formatted message, HA gets a bit upset if all of the data is not there. MQTTPublish attempts to deal with this, but that might be a problem you run into.
I am not a fan of using the retain option. I find it a bit of a pain to reset, especially as one is first getting things working. But, that too is up to you.

[rae...@gmail.com]

Quick question.  I just want weewx to dump everything into HA to create entities.  How do I enable the opt-out option with nothing opted out?  I'm a bit confused on how to do that.

[bell...@gmail.com]

Sorry. Not surprised…. That is one of the challenges when you make things highly configurable

That is the default - setting ‘ignore = false’ a the ‘topic level’.

https://weewx-mqtt.github.io/publish/common-options/topics/topic-name/#ignore

TLDR: You should not have to do anything.

[rae...@gmail.com]

I'm definitely struggling with the docs.  What do I put in here?  I'm using subscribe to populate weather data from my device which publishes to mqtt and the topic is weather/   

For this section of the config what do I put in here for the topic?


# The topics that source Home Assistant. [[[[[[topics]]]]]] [[[[[[[weather/loop3]]]]]]] # The 'type' of payload. type = individual

Am I putting my weather topic in here to input into the HA plugin?

[rae...@gmail.com]

I get a "ValueError: weather not found in topics being published.   There are so many names/fields/topics it's quite confusing what goes where.  

[bell...@gmail.com]

Thanks for bearing with me. So you have something like this.

[MQTTPublish]

....

 [[topics]]
        [[[Topic you publish the data to]]]
       
       

Then further down you should have something like

[[plugins]]
        # The name of the plugin. Do not change
        [[[MQTTHomeAssistantConfig]]]
            # The module to be loaded. Do not change.
            module = user.mqtthaconfig
           
...

            [[[[devices]]]]
                # The object_id of the device.
                [[[[[Topic you publish the data to]]]]]
               
               
Can you attach the [MQTTPublish] stanza making sure to remove any sensitive data.
Also, what topic are you publishing to?

[bell...@gmail.com]

Do you need TLS? Do you need a userid password? The reason I ask, I could show you a very stripped down example.

[Rich Bell]

More of the log would be helpful when you have error messages.

--
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 weewx-user+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/b2771d70-8884-4578-83d6-e69d78f44c8an%40googlegroups.com.

[bell...@gmail.com]

Stripping out all of the comments and extra stuff (which you may or may not need). The following “SHOULD” publish the data to REPLACE_ME_TOPIC to a broker on your localhost. It should create a device named REPLACE_ME_DEVICE in HA.

BUT, I would not start with this. I would start with the template that is installed in weewx.conf

[MQTTPublish]
    host = localhost

    [[topics]]
        [[[REPLACE_ME_TOPIC]]]

    [[plugins]]
        # The name of the plugin. Do not change
        [[[MQTTHomeAssistantConfig]]]
            # The module to be loaded. Do not change.
            module = user.mqtthaconfig

            [[[[devices]]]]
                # The object_id of the device.

                [[[[[REPLACE_ME_DEVICE]]]]]

                    # The topics for this Device.
                    [[[[[[topics]]]]]]
                        # The topic name that has the data to be published to Home Assistant.
                        [[[[[[[REPLACE_ME_TOPIC]]]]]]]

On Friday, 10 July 2026 at 14:32:05 UTC-4 rae...@gmail.com wrote:

[rae...@gmail.com]

I think the confusion is, do the topics in both sections have to match? Also do I create a stanza for each value i want to create an entity in HA? That seems to not make sense as I understood that this would read every label and populate HA with entities of each measurement.  Is that correct?

[rae...@gmail.com]

 Ok, I think I'm getting it.  The main section has to have a top level topic like weewx_ha and I go the opt out route it will publish everything.  Then the HA section reads those values from that topic and formats new topics that HA will ingest automatically using its MQTT integration? Am I understanding that correctly?

[bell...@gmail.com]

The topic in the HA section has to exist in the ‘publishing’ section. 

A HA device can have multiple topics populating the sensors in the device in HA.

MQTTPublish CAN publish. to multiple devices. For example, I have a device with most of my weather sensors and a second device with sensors that monitor indoor air quality, freezer temperature, water sensors, etc. I liked breaking it down this way in HA.

No you do not have to create a stanza for each value.

[bell...@gmail.com]

Very close. The main section has a topic like weewx_ha that will publish everything.

This topic, weewx_ha, is the topic below (REPLACE_ME_TOPIC). HA will ingest from this topic

This way you can publish to topics not used by HA, HA can use multiple topics, etc. etc..

[bell...@gmail.com]

Maybe this is the missing piece….

The HA portion of MQTTPublish does publish the data, it inspects  the data being published on the specified topic to determine how to configure the sensors in HA.

This configuration data is published to a different topic with a default prefix of homeassistant.

rich

[bell...@gmail.com]

The HA portion of MQTTPublish does NOT publish the data 

sorry about that

[Rich Bell]

Again, if you want to send me what you have so far and what problems you are facing….

You can send it directly to me if you want.

--
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 weewx-user+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/618ecd68-7688-45ce-b529-365c3f1da3d2n%40googlegroups.com.

[rae...@gmail.com]

Here is the MQTTPublish stanza from my conf.  It detected the entities in Homeassistant but everything is unavailable in home assistant.  I tried using both json and individual but I don't think that matters

[MQTTPublish]
    # Whether the service is enabled or not.
    # Valid values: true or false
    # Default is true.
    enable = true
   
    # Controls the MQTT logging.
    # Default is false.
    log_mqtt = true
   
    # The maximum number of times to try to reconnect.
    # Default is 5.
    max_retries = 5
   
    # The clientid to connect with.
    # Default is MQTTPublish-xxxx.
    #    Where xxxx is a random number between 1000 and 9999.
    clientid = ""
   
    # The MQTT server.
    # Default is localhost.
    host = mqtt
   
    # Maximum period in seconds allowed between communications with the broker.
    # Default is 60.
    keepalive = 60
   
    # The port to connect to.
    # Default is 1883.
    port = 1883
   
    # The MQTT protocol to use
    # Valid values: MQTTv31, MQTTv311, MQTTv5
    # Default is MQTTv311,
    protocol = MQTTv311
   
    # username for broker authentication.
    # Default is None.
    username = xxxxxx
   
    # password for broker authentication.
    # Default is None.
    password = xxxxxx
   
    # The TLS options that are passed to tls_set method of the MQTT client.
    # For additional information see, https://eclipse.org/paho/clients/python/docs/strptime-format-codes
    [[tls]]
        # Turn tls on and off.
        # Default is true.
        enable = false
       
        # Path to the Certificate Authority certificate files that are to be treated as trusted by this client.
        ca_certs = ""
       
        # The PEM encoded client certificate and private keys.
        # Default is None
        certfile = None
       
        # The certificate requirements that the client imposes on the broker.
        # Valid values: none, optional, required
        # Default is required,
        certs_required = required
       
        # The encryption ciphers that are allowable for this connection. Specify None to use the defaults
        # Default is None.
        ciphers = None
       
        # The private keys.
        # Default is None
        keyfile = None
       
        # The version of the SSL/TLS protocol to be used.
        # Valid values: sslv2, sslv23, sslv3, tls, tlsv1, tlsv11, tlsv12.
        # Default is tlsv12.
        tls_version = tlsv12
   
    [[lwt]]
        # Turn lwt on and off.
        # Default is true.
        enable = false
       
        # The topic that the will message should be published on.
        # Default is 'status'.
        topic = status
       
        # Default is 'online'.
        online_payload = online
       
        # The message to send as a will.
        # Default is 'offline'.
        offline_payload = offline
       
        # he quality of service level to use for the will.
        # Default is 0
        qos = 0
       
        # If set to true, the will message will be set as the "last known good"/retained message for the topic.
        # The default is true.
        retain = true
   
    [[topics]]
        [[[weewx]]]
            # Controls if the topic is published.
            # Default is true.
            publish = true
           
            # The binding, loop or archive.
            # Default is 'archive, loop'.
            binding = archive, loop
           
            # A comma seperated list of fields that are not published.
            # This is a short hand notation for having to configure each field and setting ignore = True in its section.
            # ignore_fields =
           
            # A comma seperated list of fields that are to be published.
            # This is a short hand notation for having to configure each field and setting ignore = False in its section.
            # publish_fields =
           
            # The unit system for data published to this topic.
            # The default is US.
            unit_system = METRICWX
           
            # --------------------------------------------------------------------------------
            # The following options can be set at the [MQTTPublish] level and overridden here.
            # This has the potential to greatly reduce the verbosity of the configuration.
            # --------------------------------------------------------------------------------
           
            # The QOS level to publish to.
            # Default is 0
            qos = 0
           
            # The MQTT retain flag.
            # The default is False.
            retain = False
           
            # The format of the MQTT payload.
            # Currently support: individual, json, keyword
            # The default is 'json'
            type = json
           
            [[[[fields]]]]
                [[[[[REPLACE_ME]]]]]
                    # The WeeWX name of the data to be published.
                    # Default is the config section name.
                    # name =
                   
                    # The WeeWX unit to convert the data being published to.
                    # Default is None.
                    # unit =
                   
                    # --------------------------------------------------------------------------------
                    # The following options can be set at the [[topic-name]] level and overridden here.
                    # This has the potential to greatly reduce the verbosity of the configuration.
                    # --------------------------------------------------------------------------------
                   
                    # True if the field should not be published.
                    # Valid values: True, False.
                    # Default is  False
                    ignore = true
                   
                    # The WeeWX name of the data to be published.
                    # Default is the config section name.
                    # name =
                   
                    # The WeeWX unit to convert the data being published to.
                    # Default is None.
                    # unit =
                   
                    # Controls if data with a value of 'None' should be published.
                    # The default is false.
                    publish_none_value = false
                   
                    # Controls if the WeewX unit label should be append to the data being published.
                    # The default is true.
                    append_unit_label = true
                   
                    # The data type conversion to apply to the data being published.
                    # The default is 'string'.
                    conversion_type = string
                   
                    # The formatting to apply to the data being published.
                    # The default is '%s'.
                    format_string = %s

   
    [[plugins]]
        # The name of the plugin. Do not change
        [[[MQTTHomeAssistantConfig]]]
            # The module to be loaded. Do not change.
            module = user.mqtthaconfig
           

            # Whether the service is enabled or not.
            # Valid values: true or false
            # Default is true.
            enable = true
           
            # The MQTT qos when subscribing to the birth and lwt topics.
            # Valid values: 0, 1, 2
            # Default is 0
            qos = 0
           
            # The Home Assistant birth topic.
            # Default is homeassistant/status
            birth_topic = homeassistant/status
           
            # The Home Assistant lwt topic.
            # Default is homeassistant/status.
            lwt_topic = homeassistant/status

           
            [[[[devices]]]]
                # The object_id of the device.

                [[[[[Weather_Station]]]]]
                   
                    # The MQTT qos when publishing the device discovery message.
                    # Valid values: 0, 1, 2
                    # Default is 0.
                    qos = 0
                   
                    # The retain value when publishing the device discovery message.
                    # Valid values: true or false
                    # Default is false.
                    retain = False
                   
                    # https://www.home-assistant.io/integrations/sensor.mqtt/#device
                    [[[[[[device]]]]]]
                        # The hardware version of the device.
                        # hw_version =
                       
                        # A list of IDs that uniquely identify the device. For example a serial number.
                        # Default is the object_id of the device.
                        # identifiers =
                       
                        # The manufacturer of the device.
                        # manufacturer =
                       
                        # The model of the device.
                        # model =
                       
                        # The firmware version of the device.
                        # sw_version =
                       
                        # The serial number of the device.
                        # serial_number =
                       
                        # The name of the device.
                        name = Weather Station
                   
                    # https://www.home-assistant.io/integrations/mqtt/#name
                    [[[[[[origin]]]]]]
                        # Software version of the application that supplies the discovered MQTT item.
                        # sw_version =
                       
                        # Support URL of the application that supplies the discovered MQTT item.
                        # support_url =
                       
                        # The name of the application that is the origin of the discovered MQTT item.
                        name = WeeWX

                   
                    # The topics for this Device.
                    [[[[[[topics]]]]]]
                        # The topic name that has the data to be published to Home Assistant.

                        [[[[[[[weewx]]]]]]]
                            # The format of the MQTT payload.
                            # Currently support: individual, json
                            # The default is 'json'
                            type = json

       
        # The name of the plugin. Do not change

        [[[MQTTAggregateValues]]]

            # The module to be loaded. Do not change.

            module = user.mqttaggregatevalues
           
            # Whether the service is enabled or not.
            # Valid values: true or false
            # Default is true.
            enable = False
           
            [[[[topics]]]]
                # The name of the topic to add the aggregate values to.
                [[[[[REPLACE_ME]]]]]
                   
                    # The name of the observation in the MQTT payload.
                    # This can be any name. For example: rainSumDay, outTempMinHour, etc
                    [[[[[[REPLACE_ME]]]]]]
                        # Turn aggregates on and off.
                        # Default is true.
                        enable = false
                       
                        # The WeeWX observation to aggregate, rain, outTemp, etc,
                        observation = ""
                       
                        # The type of aggregation to perform.
                        # See, https://www.weewx.com/docs/customizing.htm#aggregation_types
                        aggregation = ""
                       
                        # The time period over which the aggregation shoulf occurr.
                        # Valid values: hour, day, week, month, year, yesterday, last24hours, last7days, last31days, last366days
                        period = ""

[rae...@gmail.com]

Got it working.  What Homeassistant needed was lwt enabled and also retaining topics so I did that in both the publish and the plugin section...all working now, getting values for everything.

Thanks again for your help Rich, and if you want to try anything out, I'll be happy to assist you in the future.

[bell...@gmail.com]

Glad to hear you have something working. Thanks for letting us know.

And a huge thanks for working through this! Sorry it was so painful.

My big take away is that the documentation needs work. Here are three things that I identified
1. Explain the interaction between the topic designation between sections (probably more general about the two sections),
2. Explain that LWT needs to be set.
3. Explain about retain (I will probably need to ask some more detail about this.)
If you have other things, documentation or other, let me know.

Also, how did you figure out about LWT and retain? 

Also curious are you publishing the sensor data/state as json or individually?

Thanks again!
rich

[Greg Troxel]

"bell...@gmail.com" <bell...@gmail.com> writes:

> 2. Explain that LWT needs to be set.

This is a consequence of the choice of config data (or, if not using
that, of how one configures Home Assistant). Really, this is about an
MQTT receiver in general, not specifically HA.

As I see it, the standard approach is more or less to have a topic for a
device called "foo" as blah1/blah2/foo (henceforth just foo) -- that
does not get written to, usually, and then

foo/online

foo/temp
foo/humidity

foo/json

except I don't claim /json is normal. Maybe it should be.

HA then has a binary sensor from foo/online. Values might be ON and
OFF, to align with the HA MQTT default values for binary sensors, or
online and offline, to align with the default values for availability
topics. Probably online/offline is best as then the availability_topic
doesn't need value config.

The sender transmits foo/online = online at connection time. It sets a
LWT to set foo/online = offline, so that when it goes offline, the
broker sends that update, and receivers know it's gone. That's *if the
receiver is still connected to the broker*.

One also typically sets a timeout using "expire_after" so that even if
the broker goes away, the receiver will stop using the value.

See
https://www.home-assistant.io/integrations/binary_sensor.mqtt/
for more.

The binary sensor is useful for alerting, to report lack of "weewx
connected". But probably you also want (I do) a "weewx reporting"
template sensor that is true if e.g. the temperature has a valid value,
and false if it's "unavailable" or "unknwown", and to alert on that
also.

If you don't want to have an availability topic, that's ok -- this can
be done with just expire_after.

I use an archive interval of 5m (300s), send archive data via MQTT, and
have configured expire_after to 330s. So it blanks out on a missed
update with 30s grace/jitter, and I alert after 6 minutes of the sensor
(so that one missed update does not alert me, but two do). I do not use
availability topics for weemx mqtt. I'm running the older extension and
haven't mesed with it in years. That's me; not saying it's the right
approach.

So you don't need LWT, if you don't want to have an /online topic. If
you post online=true at startup, you do. If you don't have a
functioning /online topic, you can't use availability_topic.

> 3. Explain about retain (I will probably need to ask some more detail about
> this.)

My take from years of MQTT with HA and weewx (and helping with mosquitto
packaging and upstream):

Values that are semi-permanent transitions, not likely to change for
long periods, and which are not routinely retransmitted, should set
retain. Periodic measurements should not set retain.

This means that foo/online gets retain. It's written on connect and
might stay that way for weeks. When a receiver boots or reconnects, it
needs to know the last value.

State measurements -- temperature etc. -- are ephemeral. The last
reported temperature, after reports stop for some reason, isn't really
related to the current temperature and should not be used as a such. If
you don't have a current value the value is "unavailable" (a HA
codepoint).

(Yes, one could send tuples of (time, temp), and the receiver could
carry these to the db, but it should still treat them as expired as far
as the current value goes. But if you want to do database sync you
should do that, and what we're talking about is separate.)

[rae...@gmail.com]

I realized that without the retain, the HA plugin had nothing to work with because the timing on my weather data is so different depending on what it is, my wind data is every 5 seconds and my archive period is 3 minutes so all my other raw data from my weather station posts every 3 minutes as well.  Because everything is so out of sync I have to use retain or it will never get anything to work with.  Also as far as the LWT, I just AI'd it and it suggested that HA enjoys having that set.  I did set up MQTTPublish and the HA plugin with json because I had no reason to break out the topic individually.  My raw data from my weather station on the other had posts individually.

[rae...@gmail.com]

In terms of the documentation, it would be nice to have more robust explanation of what each section does.  Perhaps even a diagram that shows the flow of information within the extension.  I would say if there is a REPLACE_ME value in the extension I found myself having a hard time with "replace with what exactly".  So a bit of explanation of each level would help, maybe with an example.  Examples are extremely helpful.

[Greg Troxel]

"rae...@gmail.com" <rae...@gmail.com> writes:

> I realized that without the retain, the HA plugin had nothing to work with
> because the timing on my weather data is so different depending on what it
> is, my wind data is every 5 seconds and my archive period is 3 minutes so
> all my other raw data from my weather station posts every 3 minutes as
> well.

This doesn't make sense to me. Without retain, when weewx is connected
to the broker, and HA is connected (the normal case, should be true
almost always), then MQTT posts from weewx arrive at HA. If you are
sending data every three minutes (because your archive interval is 3
minutes and you are sending archive data), then within 3 minutes of
starting HA the data should populate, and you should probably pick 180s
or 390s for expire_after. If this doesn't work without retain, then
something is very broken and we should figure it out, not tell people to
set something which is semantically troubled.

I have retain=False using g...@github.com:matthewwall/weewx-mqtt.git and
my weather data in HA is stable, but goes to unavailable when my weewx
computer stops transmitting.

> Because everything is so out of sync I have to use retain or it will
> never get anything to work with.

This doesn't make sense to me either. There is no need for
synchronization of various entities, as long as they are all valid.

> Also as far as the LWT, I just AI'd it and it suggested that HA enjoys
> having that set.

That is incorrect; HA is not a person and does not enjoy anything! The
point of the LWT, as I said earlier, is to post offline to the online
topic on client disconnect, so that the posting of online at connection
is withdrawn and the availability topic has the right semantics. You
should look at the json config that MQTTPublish uses, or your own
config, to see if that is correct -- and see the page I referenced
previously.

> I did set up MQTTPublish and the HA plugin with json because I had no
> reason to break out the topic individually.

What "HA plugin"? HA has "integrations", and something (formerly called
"add-ons") called "apps". The MQTT integration is built in.

> My raw data from my weather station on the other had posts
> individually.

What do you mean "raw", and how is that happening -- if you aren't using
MQTTPublish?


Sending json is nice because there's one MQTT message posted. If you
are sending archive data every 3 minutes (I do, but every 5), then
there's one message, with everything, logically consistent in time.

With loop, whether things are in json or not, they aren't quite
consistent because data arrives to weewx at different times. As long as
the delays are small (sub 30s?), it's not a big deal.

If you have wind every 5s, then putting everything in json might lead to
a full json every 5s, retransmitting previous values for other things,
and ingesting them into HA again. It would be better in my view to
split out wind to not be in json (or to be in a separate higher-rate
json) to avoid transmitting data that isn't really data.


Overall it sounds like you have found a configuration by guessing at
settings but that it isn't really grounded in a plan of how things
should be. I encourage you to examine what is being sent on MQTT and to
read the HA entity configuration, in yaml if you did it yourself, or to
read the autoconfig json if you're doing it that way.

[bell...@gmail.com]

Yeah, something doesn't sound quite right. I haven't fully digested all of Greg's information. Here is what I have seen in my limited use.

I'm publishing loop topics to HA. I have 3 different loop packets. One is published very regularly ever 2 to 3 seconds (this contains the majority of my data). The other 2 publish every 15 to 20 seconds. So this is 3 messages, each with different content.

When I was publishing json, I noticed that whatever sensors weren't in the MQTT message received -  would show unavailable. I thought I worked around this.... but this might still be happening. I also got around it by publishing each sensor individually. The other option would be to use different topics for the different data sets (loop packets). But again, I thought it should work. I'll experiment more.

The only place I use retain=true is MQTTPublish's LWT (and due to current implementaion its 'birth' message). Here is why I use it.
1. WeeWX goes down. MQTTPublish 'sends' the LWT message.
2. HA receives the LWT and marks the device/sensors unavailable.
3. HA goes down
4. HA comes up.
5. HA receives the retained message that WeeWX is down.

I find that setting up HA to publish LWT and birth messages and MQTTPublish to subscribe to them to be very useful. Here is the scenario this covers.
1. HA goes down and sends the LWT message.
2 MQTTPublish receives it (currently does nothing).
3. HA comes up, sends a birth message.
4. MQTTPublish receives it and republishes the device discovery configuration.
Note, having the device discovery message published with retain=true would also work. But, I like this better. MQTTPublish supports either. Your choice.
I believe this is necessary because HA doesn't persist the device discovery configuration across an outage.

Again, I am far from an HA expert. Just my observations from my setup.
I'm off to re-read Greg's information.
rich