Zigbee2Mqtt device unavailable after HA restart

lucas3d · January 25, 2020, 7:52pm

Hi everyone,

End of last year, I started using HA and I’m using recently Zigbee2Mqtt 1.9.0 without any issue.
Both of them are running in Docker on my Synology NAS. Very easy to configure and use…

It looks like after 0.104 updates, my Zigbee devices are unavailable after HA restarted. I didn’t find any error in HA and Zigbee2Mqtt logs.

The only solution to get my devices available is to restart Zigbee2Mqtt.

Does someone have the same issue?
Does a better solution exist?

Thanks

francisp · January 26, 2020, 5:07am

Wait till they send their status, or force an update.

- id: '1565194745362'
  alias: Status bij opstarten HA
  trigger:
  - event: start
    platform: homeassistant
  condition: []
  action:
  - data:
      payload: 'status'
      topic: zigbee2mqtt/ikeaoutlet1/get
    service: mqtt.publish

lucas3d · January 26, 2020, 12:49pm

Hi @francisp,

Thanks for your reply.

I try this automation changing “ikeaoutlet1” with one of my Zigbee devices.
Some of my Zigbee devices are now present after restarting but the majority have the “Unknown” status.

Did I need to have this automation of each device?

francisp · January 26, 2020, 12:51pm

Unfortunately, yes. Zigbee2mqtt does not have a group topic as tasmota.

lucas3d · January 26, 2020, 1:07pm

Not user friendly if you have many devices.
Thanks for your help.

Peggy6 · January 29, 2020, 3:07pm

Hello,

I join this discussion because I got a similar behaviour. I installed HASS + zigbee2mqtt + mqtt HA module on january 18 : everything worked flawlessly and auto discovery showed up all my compatible devices : zigbee devices and tasmota devices. Everything synced perfectly until I restarted HA after having installed HACS, on january 25. From this moment all MQTT devices disappeared from the UI. In the device menu they are marked “unavailable”. If I sniff MQTT in the debug tool I can see the Zigbee MQTT messages. My tasmota MQTT devices are set to send status messages every 300s, but they still don’t appear anymore. The only two MQTT devices still working are those coming from Domoticz via MQTT. I don’t know how to solve this.

ReDaLeRt · January 29, 2020, 3:27pm

I think the only way to address this is to force the zigbee2mqtt add-on restarting automatically after X seconds the HA starts:

automation:
- alias: "Restart Z2MQTT after HA bootup"
  initial_state: true
  trigger:
    platform: homeassistant
    event: start
  action:
    - service: hassio.addon_restart
      data: 
        addon: '7ad98f9c_zigbee2mqtt'

lucas3d · January 30, 2020, 12:16pm

Thanks, @ReDaLeRt or this solution.
Unfortunately, I’m running Home Assistant inside Docker.

I don’t know why I didn’t have the issue issue before 0.104 update.

Skye · January 30, 2020, 12:18pm

I’ve also noticed that when restarting HA usually all z2m devices have their status correctly set at boot time, but there is the occasional reboot of HA that they do not restore their status and I have to wait for the sensors to send data to be updated.

lucas3d · January 31, 2020, 12:41pm

Thanks for your feedback @Skye!
I didn’t try to wait if my Zigbee devices are slowly back online.
Maybe, I’m to impatient

I will see this after the next HA auto-update.

xAPPO · January 31, 2020, 2:33pm

Apologies if this information is wrong (I don’t use zigbee2mqtt) but this sounds like a topic retention issue. If the topics are sent retained to the broker then the client (HA) can read their states immediately on connection. It doesn’t have to wait for an update. Is that an option within zigbee2mqtt ?

MQTT discovery does exactly the same but once topics are retained devices are online immediately.

francisp · January 31, 2020, 3:04pm

zigbee2mqtt does not set the retain flag (not for status, I think only for autodiscovery)

blackscreener · January 31, 2020, 8:05pm

Doesn’t work.

Retain flag isn’t necessary. Zigbee devices after HA restart are unavailable because Mosquitto MQTT broker add-on doesn’t send birth_message. Try to add to configuration.yaml:

mqtt:
  discovery: true
  broker: 192.168.x.x
  birth_message:
    topic: 'hass/status'
    payload: 'online'
  will_message:
    topic: 'hass/status'
    payload: 'offline'

For me it works like a charm.

francisp · January 31, 2020, 8:49pm

I have this from day one in my configuration.yaml. But on my (slow) test-HA I still need to ask the state or it takes a long time before my sensors update.

lucas3d · February 1, 2020, 4:30pm

This looks working perfectly for me too!
Thanks for your help!

Trev · February 23, 2020, 2:13pm

Thanks. Great solution. Just tried it and it works for me.

saarsinai · May 22, 2020, 12:52pm

i’m having a problem where i restart the HA machine(dell t30 server) (which holds HA and mqtt broker in docker containers), when coming back online the sensors from zigbee2mqtt unavailable.

the zigbee2mqtt and the cc2531 sits on on different machine (pi4)
when i restarts only the HA container everything works. (the birth/will messages configured)

i think that when the mqtt container is restarting, the zigbee2mqtt can’t reconnect and send messages so even when my dell machine come back online with HA and mqtt, i see the unavailable message.

couldn’t find a solution so far.

saarsinai · May 22, 2020, 1:59pm

fixed it by making eclipse-moquitto container config file be persistence and has volume outside the container:

persistence true
persistence_location /mosquitto/data/
log_dest file /mosquitto/log/mosquitto.log

upwind_anderl · June 2, 2020, 3:07pm

Sorry this stupid question

If you put this in the configuration.yaml isn’t this additional mqtt plugin obsolete?

I’m on 110.4 and on a raspberry 3b+ with ssd
I use zigbee2mqtt and the officially mqtt addon
and after reboot the half of my zigbee entities is gone or unavailable in the frontend.
On the zigbee2mqtt log i see them shouting out temperetures and occupancies like before, but the entities are dead

First i tried your birth and will hint on the addon config itself.
Later the whole code snippet in the config.
Nothing happened so far (i rebootet for sure)
Do i need the localhost ip in your broker line?!

UPDATE!
DID IT
Soooo absolutely bad
After i recognized its only the sensors part i checked my config and cleaned up a bit.
My instance is there since version < 80
and obviously i had some sensor config which isn’t supported with 110

bad luck and i googled wrong

alesquire · August 19, 2020, 7:49am

I did like blackscreener said, but nothing works. After HA reboot- zigbee sensors state is unknown (not unavailable)

mqtt:
  broker: core-mosquitto 
  discovery: true
  discovery_prefix: homeassistant  
  username: mqtt
  password: !secret mqtt_password
  birth_message:
    topic: 'hass/status'
    payload: 'online'
  will_message:
    topic: 'hass/status'
    payload: 'offline'

Everything is done up to https://www.zigbee2mqtt.io/integration/home_assistant.html#mqtt-discovery
Things that I see:

online and offline messages are sent.
in mosquitto - only availability messages (like zigbee2mqtt/east_outer_th_sensor/availability) are sent with retain flag, other messages are sent without retain
all entities are autodiscovered and wasn’t renamed.
Entities aren’t lost themselves- I can query state from UI of all entities- sate will be unavailable, but history is preserved.
HomeAssistant reboot (in docker) lead to all entities become unknown before they resent their messages again.
neither mosquitto nor zigbee2mqtt reboot doesn’t lead to such behavior.
Either if after HA restart I preventively restart zigbee2mqtt- it doesn’t help.
After ~15 minutes all messages from sensors arrive, but I wan’t to implement automation on status change and these unavailability statuses will lead to unnecessary triggering
I can manually send online message to hass/status - it doesn’t help.
Very strange, but binary_sensor door open - is preserved, so it doesn’t become unavailable after reboot