Setting MQTT Birth and Last will with the new MQTT Integration

I have moved from configuring the MQTT broker in the configuration.yaml file to using integrations under settings. The HA connection to the broker is working fine as is discovery. I have devices that use MQTT discovery to configure themselves with HA. They use MQTT Birth and Last will to detect HA going offline and resending the discovery messages when HA comes back online. What I can’t figure out is now to configure MQTT Birth and Last will with the MQTT integration. I’ve tried adding just the MQTT Birth and Last will configuration under mqtt: in configuration.yaml but that breaks MQTT altogether.

1 Like

I have the same question, hoping someone can answer this.

Same question here!
In the meantime, I added a small automation to deal with the “birth” message:

- alias: HomeAssistant Restart | MQTT
  trigger:
    - platform: homeassistant
      event: start
  action:
    - service: mqtt.publish
      data:
        topic: 'homeassistant/availability'
        payload: 'online'
1 Like

Any updates on this.

1 Like

Bump. Any official word on Birth and Last Will with the MQTT integration?

@thomashermine1, thanks for your automation.

Can anyone suggest an event to monitor to send an equivalent “offline” message?

Birth and last will are a function of the mqtt client not the broker.

https://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament/

Thanks. The issue here indeed concerns the HA MQTT client. In the “old way” of doing things, you could set birth and last will messages for the HA client under the mqtt: component in configuration.yaml. https://www.home-assistant.io/docs/mqtt/birth_will/

When instead setting up MQTT via Integrations in the UI, there is no obvious way to set birth and last will messages for the HA client.

I have this is my configuration.yaml

mqtt:
  discovery: true
  broker: 192.168.1.99
  birth_message:
    topic: 'hass/status'
    payload: 'online'
  will_message:
    topic: 'hass/status'
    payload: 'offline'

but still use the mqtt integration under the configuration menu, it seems to work.

Thanks @kiwijunglist. I used to have something similar in configuration.yaml, and it was imported into Integrations automatically. That worked.

However, I was having problems getting the Hassio zigbee2MQTT add on to publish messages. I finally resorted to deleting the text from configuration.yaml and also deleting the Integration. I then starting fresh by configuring MQTT solely in Integrations. After that, adding back in Birth and Last Will messages to configuration.yaml did not work.

I use docker and have ha, zigbee2mqtt, mosquito all running in separate dockers. The will is working for me when I restart h.a.

@kiwijunglist Sounds like a similar set-up but with Hassio on Ubuntu and separate dockers via add ons for everything else. Did you have MQTT configured initially in configuration.yaml, or did you initially set it up through the Integrations page?

Can’t be certain but I think I started with integrations then added mqtt to configuration afterwards.

I’ve been playing around and got the birth message working at least. Configuration:

  • Hassio on Ubuntu
  • Broker: Community Hass.io Add-on: MQTT Server & Web client
  • MQTT HA client configured initially through Integrations in the UI

I added the following to configuration.yaml after the initial configuration of MQTT:

mqtt:
  broker: 192.168.xxx.xxx:1883 # broker address a0d7b954-mqtt also works for the Hassio MQTT Server and Web client Add On
  username: !secret mqtt_username
  password: !secret mqtt_password
  birth_message:
    topic: 'hass/status'
    payload: 'online'
  will_message:
    topic: 'hass/status'
    payload: 'offline'

As mentioned above, the birth message gets sent. The last will message does not.

Can someone try this with a different broker type (not the Hassio add-on) to see if the last will message works with a different broker in order to narrow down the failure conditions? Thanks

The last will message works fine when mosquitto is installed with apt on Rassbian.

Thanks. I’ll try reporting it as an issue with the add-on.

This is an old post, but the most relevant I could find searching for the topic. I thought I would share how I solved this issue.

if you stop HA, you can edit the .storage/core.config_entries
In that file you will have an entry of "domain": "mqtt", which above it will have a "data": { entry. it is in this area you have to insert the necessary information. (this is according to my setup so YMMV.)

You can paste the following:

                    "birth_message": {
                        "topic": "hass/status",
                        "payload": "online",
                        "qos": 0,
                        "retain": false
                    },
                    "will_message": {
                        "topic": "hass/status",
                        "payload": "offline",
                        "qos": 0,
                        "retain": false
                    }

below the "username": "homeassistant",
and above the },

then save and start home assistant and it should send the birth message. Home assistant must be stopped otherwise it will overwrite your changes. If you mess anything up, HA will refuse to start, so only do this if you have an understanding of JSON and are comfortable with editing core.config_* files.

3 Likes

@xannor,

Thank you for the json and the reference to .storage/core.config_entries. I would not have figured that out. The birth_message works perfectly, however the will_message does not get sent when home assistant is restarted. This causes the hass/status to remain “online” so when it does restart, it doesn’t change state and zigbee2mqtt doesn’t know it should republish the current cached state of the world.

Any idea how to get will_message to properly publish? It mqtt broker should auto-puslish this when the mqtt client connection is closed… so it makes me wonder if mqtt broker is not getting the will_message set when the connection is established from hass.

1 Like

Update: Although will_message does not get published, I do see birth_message publishing every time when hassio is started which then triggers zigbee2mqtt to repulish its cached state. So the end result is its working for what I needed.

Would still be nice to have the correct status in mqtt when hass is down.

Update 2: Looks like will_message is only sent on ungraceful mqtt client disconnect. Since restarting hass is likely a graceful shutdown, no message is sent.

Reference:

I’ll have to research a way to post to mqtt upon hass shutdown event.

posting mqtt on shutdown is an issue, and it is unfortunate that the will is literally the last will and testament and not a good bye message. The only recommendation is to use an automation with an home assistant trigger for shutdown, but that tends to be hit or miss.

  alias: Shutdown
  description: ''
  trigger:
  - event: shutdown
    platform: homeassistant
  condition: []
  action:
  - data:
      payload: offline
      qos: 0
      retain: false
      topic: hass/status
    service: mqtt.publish