feature-requests
feature-requests copied to clipboard
esphome
Allow MQTT QOS for publish state
Describe the problem you have/What new integration you would like While MQTT features like "retain" can be configured on a component basis, it is not possible to set the QOS. Adding QOS as an option would allow this to be set to 1 or 2 so we can get more reliable state reporting. Either, we could get ESPHOME to re-report state changes when it's already in the new state (also nice as an option), or better, get more reliable state change notifications.
Please describe your use case for this integration and alternatives you've tried: During busy periods (eg all lights on) sometimes state messages can be lost, and due to the retention of old messages, the automation platform thinks the change has not happened when it has (ie, the command made it, but the state change did not). At that point, since the automation system thinks the device hasn't changed, but it has, and esphome doesn't re-report commands when the state doesn't actually change, everything becomes stuck.
Additional context From poking around in the code, it looks like MQTT state publish is at QOS 0, hardcoded.
Not being able to set QOS makes automations flakey on devices at the edge of WiFi coverage. If a device drops of the network briefly at the time it is supposed to turn on or off, the state change is missed. QOS 2 is a must in those scenarios.
For information, the MQTT client used by ESPHome (paho.mqtt.client), (now?) supports QOS, meaning that changing this to be supported by ESPHome looks like it would just involve adding the configuration option, and pulling that configuration option through to be included in the publish method in each of the different MQTT sensor components.
That said, beyond my capability to do it properly, although it no longer requires changes to 3rd party libraries.
Following up after almost 8 months. I don't currently have the know-how or time to get the know-how, but would like to use the QOS feature. Is there any update on this?
I am also wondering if there has been any movement. QoS 0 as default with no option to change seems like a missed opportunity. I'd offer to work this myself but I have no clue where to start
The question is, WHY when you implement such feature you decide to set default QOS to zero!
The mininum should be 1
