MQTT Autodiscovered device now Unavailable

I have an ESP device using MQTT and is auto discovered. It works as expected. However after a few days, all the entities related to the device become unavailble; however, the device still responds to MQTT commands and gives status; but not through the dashboard or with HA interfaces; just MQTT. Looking in the history, I see the time it goes off line. 9:30:19 pm. Other MQTT devices are also timing out around the same time. Here is an excerpt from the log at that time.
2024-01-02 21:30:19: New connection from 192.168.0.152:59158 on port 1883.
2024-01-02 21:30:19: Client davidgdo already connected, closing old connection.
2024-01-02 21:30:19: New client connected from 192.168.0.152:59158 as davidgdo (p2, c1, k60, u’admin’).

Any thoughts as to the problem or how to prevent or fix it? If I restart the Mosquito Broker in HA, everything comes back to normal.

Both HASS Discovery and Tasmota Discovery are instantaneous, so this is likely to be an ESPhome issue.

MQTT devices publish their capabilities as structured topics, which are often set to “retained” so even if the device disconnects, their config is kept until the broker restarts (and even then, it can be cached). I suspect a broker restart forces a re-publish from the client device.

You could try checking the topics using https://mqtt-explorer.com/ and the links above to see if anything changes at an MQTT level, but I suspect ESPhome is doing something odd.

Did you set it up like the docs show?

The last time I used mqtt with esphome (years ago) it was auto discovered right away. Nowadays I only use the native api which is superior for me in any aspect.

I’m using MQTT Explorer and there is no update to the status, commands, or the autodiscovery JSON data. I’m not using ESPhome nor do I have it installed. If there is a relationship between ESPhome and autodiscovery, I’m not sure what it would be. Everything related to autodiscovery is retained, but not the other status. I did try to change the status of some of the entities with MQTT Explorer, but HA wasn’t listening. Thanks for your insight.

Everyone is led to believe you are because you tagged your topic with ESPHome.

Screenshot_20240104-113328~2

1 Like

Thanks for the suggestion to look into these other documents. I’m not sure yet the relevance since I don’t use ESPHome; just the Mosquito MQTT broker. But I’ll check them out. I always have the alternative to just setup my MQTT devices with the configuration.yaml…that I’ve done before and I know it works; but I kind of like this discovery approach like other integrations. Thanks again for the suggestion. The device is also my own device and is just MQTT.

Thanks. I didn’t realize I did that. Thanks for spotting that.

Is your esp device changing something? Getting a new ip address perhaps? I ask because the log mentions a new connection.

What exactly is your discovery topic?

I don’t think the ESP device is changing anything. I see a bunch of other ESP / MQTT devices making the same logs a few seconds apart. However, this device in particular, is the only one that is auto-discovered and is an Entity under the Mosquito MQTT integration. As for IP address, it is a reserved IP address, so although it will expire, DHCP will give it the same IP; but maybe you are on to something. I’ll check the address lease and see if that coincides.

As to your question about the discovery topic, one of them is homeassistant/cover/mydevice/config, and then that is a JSON string with a topic for availability, command, and status.

It isn’t critical that this doesn’t die as long as it comes back. After this event, HA reports the entity as unavailable yet MQTT Explorer shows the status perfectly. Node Red can interface to the device through MQTT so it is just HA that isn’t getting updated. If I restart the Mosquito Broker, everything comes back. I was looking for a way to do this through an automation, to reset the broker, but I don’t see that as an option. Next time it happens, I’ll try restarting the device itself and if that gets things going again, maybe there will be a way I can write a reset mechanism into the device FW.

Thanks for the help.