- I have a MQTT client that does not play nicely with HA
- If the MQTT broker or HA is rebooted, the switches exposed by it become “stuck” until I also reboot the client. Stuck meaning, switch is enabled, but toggles itself back when I try to flip it
- From MQTT Devices not visible as devices - #5 by 123, it seems the client is the one that must re-announce itself
- I made the client listen for
homeassistant/status = online, then immediately re-announce itself to the MQTT broker, but this only solves the problem sometimes, other times, the switch remains “stuck” - If the client must re-announce itself, how does it know when it should be performed?
- If not, what is the correct sequence of events so that the switch in HA is not stuck?
Hi,
My guess is:
- The client is publishing entities via HASS MQTT Discovery, and these appear immediately via the the MQTT integration.
- If you reboot the broker, the client does not reconnect. This means HA still shows the switch, still sends the command topic, but switches back when the state change topic is NOT sent by the (disconnected) client to change the state.
So:
- Fix the client to reconnect to the broker and retry.
- Change the client to publish a LWT topic (on a timeout) so the broker can detect when the client is NOT connected, send the LWT to clients, so HA can disable the entities.
- (Publish a LWT on behalf of the client manually, and use this in HA to detect disconnection - harder but can be made to work.)
I’d try installing a MQTT tool like https://mqtt-explorer.com/ to confirm exactly what the client does.
If you want test MQTT examples of auto-discovery, look here:
Use MQTT explorer to delete the test topics and the enetities will disappear - MQTT discovery is instantaneous.
If this helps, 
this post!
1 Like
Hi,
Thanks for getting back, I do have mqtt-explorer and will refer to point 4 of my OP:
- I made the client listen for
homeassistant/status = online, then immediately re-announce itself to the MQTT broker, but this only solves the problem sometimes, other times, the switch remains “stuck”
The client was always able to reconnect to the broker. After reconnection, it always gets homeassistant/status/online and immediately re-announce itself (publish /config). But half the time, HA does not seem to get the memo, which leads me to suspect this is a timing issue, I have not tried adding a delay yet as I prefer knowing exactly the issue instead of implementing timing hacks.
I’m using EMQX MQTT server without any change in its configuration.
My current workaround is to catch the homeassistant start event, delay 1 minute, then fire homeassistant/status/online again, this seems to make my client visible again to HA consistently.
My aim is to improve the client or at least, find out what it is doing wrongly.
Do you mean to say re-announcing /config upon homeassistant/status = online is the correct approach?
Are your config topics retained? If so, you shouldn’t have to republish them.
OTOH, non-retained state topics are volatile (unless you also retain them, but it’s not common), so your entities will likely be “unknown” until you client publishes a state update.
1 Like
Is re-announcing /config upon receiving homeassistant/status = online the correct approach?
Do you know what “retain” mean in an MQTT context?
no, but my packets are literally copied off tasmota, so I expect the same behavior.
Packets? What is that “MQTT client”?
If it’s a self made app, it’s likely a parameter of the publish function?
Detecting the on/offline status of a client is usually the purpose of a LWT…
Change the client to publish a LWT topic (on a timeout) so the broker can detect when the client is NOT connected, send the LWT to clients, so HA can disable the entities.
On client disconnection the broker spots the loss of a client, and times out the LWT, then publishes the pre-defined topic to inform all clients of the status change.
Non-retained topics get published to clients immediately and disappear. Retained stay (QoS) even if a client disconnects, another client will get that topic.
Experiment with publishing test topics (my linked post above). The HA entities should appear immediately, and only disappear when deleted (notice my example uses --retain to keep the entities active).
If your client is re-connecting, then is it sending the entity status ON/OFF immediately? (not the on/offline status of the whole device). That’s what likely drives the HA greying out (retained discovery keeps the entity, but not the status).
Again, “stuck” switches in HA are usually:
- HA keeps an auto-discovered entity as the topic is retained (until deleted manually)
- You “ask” for a state change, HA publishes a command topic to the broker
- HA expects a status change topic in response to confirm the command was acted on.
- If HA doesn’t get a status change topic back, it changes the GUI back - what you see as “stuck”
To understand this, use MQTT Explorer or mosquitto_pub to manually create a test entity, and experiment with status change topics when HA sends command topics.
If this helps, this post!
Thanks, let me re-examine my payloads in a bit.
- I built my client by sniffing Tasmota’s payload, I don’t recall them using LWT out of the box, correct?
- My (dumb) client sends the same fixed set of messages (announcement) everytime it runs, if it gets disconnected, it dies.
- Reconnecting happens because a supervisor sees that it has died and starts it again. It is a very dumb client.
- At this point in HA, sometimes the switch is stuck, sometimes it isn’t, why this happens remain unaddressed by everything I have read
- For whatever reason, if I delay sending the announcements (1 min) after receiving
homeassistant/status/online, the switch has “never” gotten stuck yet - At this point, everything works happily ever after
- I’m not concerned at all that my switch might be stuck/disabled/unavailable for a short while (1-2 minutes) as this happens only when I need to reboot HA or MQTT broker, which I think is why all the talk about LWT
- What I’m concerned with is an unreliable reboot, see point 4. Because client has connected and sent the announcements, this means it will do nothing more except respond to events, thus if the switch is stuck in HA, it is going to be stuck for a long time (forever).
That will be a yes to your question, but it is sent as part of a series of messages which I refer to as announcement.
Are you saying the client has to send different messages each time it reconnects?
Tasmota firmware >9.3 moved away from HASS Discovery to their own slimmer Tasmota Discovery (SetOption19 0).
I’ve written several client devices using HASS Discovery, added units, location, icons, etc and provided test cases for experimentation and contributed to docs.
If you’re reverse engineering Tasmota Discovery (SetOption19 1) - Good Luck!
The only docs for this I’m aware of are a GitHub commit comment from some years ago.
If this helps, this post!
Ok, is there a short and simple sensor + switch that you can share? I’m using SetOption19 0
Yes - I posted it several posts ago.
I’m not sure I see it. What language was it implemented in?