Espurna device unavailable in Homeassistant integration after restart from HS

[tripplet]

Bug description
I'm using Homeassistant with a separat mqtt broker not the embedded one in Homeassistant.
This leads to the espurna integration devices becoming unavailable when I restart Homeassistant.

From my understanding the discovery mqtt messages need to be re-send after Homeassistant restarts.
When using the embedded mqtt brocker of Homeassistant this does not generate a problem because the mqtt brocker goes offline too.

From my understanding the relevant code is this part.

espurna/code/espurna/homeassistant.ino

Lines 384 to 387 in ec4883a

	// On MQTT connect check if we have something to send
	mqttRegister([](unsigned int type, const char * topic, const char * payload) {
	if (type == MQTT_CONNECT_EVENT) _haSend();
	});

Proposed solution
A solution would be to allow the user to specify a topic and payload where espurna listens for the birth_message of Homeassistant, so that when the topic is updated e.g. with 'online' the espurna config is send again.

Example usage in the zigbee2mqtt project and relevant documentation from Homeassistant.

Steps to reproduce
Restart homeassistant while using an external mqtt broker.

Expected behavior
espurna device integration is available again.

Device information
[MAIN] ESPURNA 1.13.5 (83195fd)
The rest is not relevant (I think).

[mcspr]

Discovery is sent as retained message, so it should survive both both broker (if retained cache is configured) and HA restarts. I tried restarting HA with discovered switch and logs show that it picked up the device instantly. Could it be that the broker deletes "old" retained messages?

Another thing to note is that discovery messages are sent only on first successful MQTT client connection:

espurna/code/espurna/homeassistant.ino

Line 264 in ec4883a

if (!_haSendFlag) return;

Which can only be changed later by turning HA discovery ON to OFF or vice versa

espurna/code/espurna/homeassistant.ino

Line 289 in ec4883a

_haSendFlag = (enabled != _haEnabled);

BTW thanks for pointing out the birth message, that is something new to have in mind

[tripplet]

Interesting I'll try do debug the issue further and look where the root of the problem lies.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[tripplet]

I figured out the problem
@mcspr already said it, "on first successful MQTT client connection".
The problem is if the mqtt broker is restarted and no retained cache is configured, the integration message is gone and will not appear again until the espurna firmware is restartet or HA discovery is turned off and back on again in the ui.

I think the normal configuration of mosquitto most users use is without a retained cache, so hopefully this can be fixed by re sending the homeassistant discovery message after the mqtt connection has been reconnected.
For me the only solution is to manually go to the website of all espurna devices after a restart of mosquitto (or the raspberry) and restart click restart in the web ui to make the integration work again.

[mcspr]

Yep. That was part of the #1370, but I need to re-think that a bit to make it less tangly.
Another issue is due to discovery messages size we sometimes hit network buffer limits, so we can't just reset the haSend flag as a quick fix.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[limecat-ss]

Hi.. @mcspr
I have this same problem ("the espurna integration devices becoming unavailable when I restart Homeassistant") in version 1.15.0-dev. Was this only resolved in version 1.14.1 ?

[mcspr]

I have this same problem ("the espurna integration devices becoming unavailable when I restart Homeassistant") in version 1.15.0-dev. Was this only resolved in version 1.14.1 ?

Problem above is not HA-specific, as far as I could tell. We default to MQTT persistence, which stores both device status and HA discovery. In case persistence is disabled, or MQTT broker does not persist state between resets, not much we can do about it.

If HA would tell MQTT about reset, somehow, we handle 'birth_message' (we don't, still), it can be responded back with a discovery message repeat. Right now message is only published when

• typing 'ha.send' in terminal and thus forcing current state to be published (either empty msg or a full one)
• settings reloaded when 'haEnabled' changes OFF -> ON, ON -> OFF (terminal 'reload', or in web)
• mqtt connection restarts

[limecat-ss]

 _If_ HA would tell MQTT about reset, somehow, we handle 'birth_message' (we don't, still),
 it can be responded back with a discovery message repeat. Right now message is only published when

Forgive my ignorance @mcspr , but homeassistant doesn't publish a status in the "homeassistant/status" topic, changing it from "online" to "offline"?
Couldn't this state change be used to resend the discovery message?

[mcspr]

 _If_ HA would tell MQTT about reset, somehow, we handle 'birth_message' (we don't, still),
 it can be responded back with a discovery message repeat. Right now message is only published when

Forgive my ignorance @mcspr , but homeassistant doesn't publish a status in the "homeassistant/status" topic, changing it from "online" to "offline"?
Couldn't this state change be used to resend the discovery message?

Emphasis on IF, have to implement it first :)
I noticed that topic documentation link only after replying