MQTT devices not available after restart - workaround

So I have successfully converted some devices from api to mqtt through a free account at flespi.io (t needs to eb a cloud mqtt broker as eventually the devices will be based in other location son different networks behind mobile internet connections)

However, when I restart HA or reload the MQTT integration in HA all devices become unavailable.

The suggested trick of listening for # in QTT integration does show the devices as online again but unfortunately it doesn’t pick up ongoing sensor readings and switches although they do get relayed to devices, don’t retain state properly in HA

The workaround I have found to work reliably is:

  1. Restart HA/reload MQTT
  2. Delete each device in MQTT integration
  3. Restart each device

As they are restarted, discovery adds the devices back into MQTT integration and restores their previous history.

So I have had to add a remote restart facility in each device (they listen for a special message and when received they restart).

This seems pretty poor behaviour and I cant understand why the MQTT integration doesn’t just go and fetch the retained device config messages and restart properly

Device mqtt code:

esphome:
  name: ${esphome_name}

mqtt:
  broker: mqtt.flespi.io
  port: 1883
  username: !secret mqtt_username
  discovery: true # disable entity discovery
  discover_ip: true # enable device discovery
  discovery_retain: true #retain discovery messages
  discovery_unique_id_generator: mac #Use Mac address to generate unique entity Ids

  on_message: 
    topic: ${esphome_name}/reboot
    then:
      - button.press: restart_button

button: 
  - platform: restart
    id: restart_button
    name: Restart

You’re facing a common challenge with MQTT and Home Assistant (HA) when using retained messages and discovery. While retained messages should allow HA to restore device state after a restart, the interaction between discovery and retained messages can sometimes lead to conflicts. Your workaround, while functional, is certainly not ideal.