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
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
Was 100% miss here. I’m fairly certain that the first thing that happens when you hit shutdown is it stops everything, and then sends the ‘event’ to say it’s done it. This, of course, means that the automations have already stopped working so they never trigger.
I keep meaning to file a bug report, but basically I’ve never (the whole time I’ve used homeassistant, ~4 years) been able to get an automation to react to the shutdown event.
I couldn’t remember if they ever fixed the shutdown event order. It looks like the MQTT client is shutdown either before or during automation execution. The only viable solution on the issues page is to use a shell process, since those can be fired outside of the MQTT client by using the mosquitto client.
There was no follow up from the devs and it was auto-closed and locked (, which I feel is a terrible feature of github,) so most likely they don’t have a good solution for it.
Indeed - the homeassistant shutdown event is pretty pointless tbh.
So it will look like this?
{
"connection_class": "local_push",
"data": {
"broker": "core-mosquitto",
"discovery": true,
"password": "PRIVATE",
"port": 1883,
"protocol": "3.1.1",
"username": "homeassistant",
"birth_message": {
"topic": "hass/status",
"payload": "online",
"qos": 0,
"retain": false
},
"will_message": {
"topic": "hass/status",
"payload": "offline",
"qos": 0,
"retain": false
},
},
"domain": "mqtt",
"entry_id": "3c48f9e8137d4d63a80b34a670076368",
"options": {},
"source": "hassio",
"system_options": {
"disable_new_entities": false
},
"title": "Mosquitto broker",
"unique_id": null,
"version": 1
},
Technically it should be…
{
"connection_class": "local_push",
"data": {
"broker": "core-mosquitto",
"discovery": true,
"password": "PRIVATE",
"port": 1883,
"protocol": "3.1.1",
"username": "homeassistant",
"birth_message": {
"topic": "hass/status",
"payload": "online",
"qos": 0,
"retain": false
},
"will_message": {
"topic": "hass/status",
"payload": "offline",
"qos": 0,
"retain": false
}
},
"domain": "mqtt",
"entry_id": "3c48f9e8137d4d63a80b34a670076368",
"options": {},
"source": "hassio",
"system_options": {
"disable_new_entities": false
},
"title": "Mosquitto broker",
"unique_id": null,
"version": 1
},
You have a comma after the will block but no more key-value-pairs, and the JSON parser is picky about syntax. Other than that it looks correct.