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.
Yes saw that as wel… Also read that the will not always work… Maybe a idea to make a feature request to add this hard in the mqtt broker addon of HA itself.
I have add those 2 automations:
###########################################################################################
#
# SEND A BIRTH SIGNAL MQTT OUT AND ALSO WHEN THERE IS A WILL SIGNAL WHEN OFFLINE HA
#
###########################################################################################
- alias: "System - HA Birth MQTT Signal"
trigger:
- platform: homeassistant
event: start
action:
- service: mqtt.publish
data:
topic: "hass/status"
payload: "online"
- alias: "System - HA Will MQTT Signal"
trigger:
- platform: homeassistant
event: shutdown
action:
- service: mqtt.publish
data:
topic: "hass/status"
payload: "offline"
qos: 0
retain: false
Hope this will help
Ive had no issue with the birth message, as that is a function of the MQTT client protocol, so I do not think the startup automation is necessary, the shutdown automation calling the MQTT service generally does not work because by the time the service is called the client is shutdown.
The only real option I can think of is a “Feature Request” and that is to have the HA mqtt client code support an option to publish the will on close, this wouldn’t be a protocol violation, just a custom feature for HA.
Hope my explanation is correct.
1 Like