QOS setting seems to be ignored at MQTT Switch

[AlfaBravoX]

The problem

This is simple SONOFF plug flashed with TASMOTA:

  switch:
    - name: "SONOFF S20"
      state_topic: "demo/sonoff/tele/s20/STATE"
      state_off: "OFF"
      state_on: "ON"
      value_template: "{{ value_json.POWER }}"
      command_topic: "demo/sonoff/cmnd/s20/POWER"
      payload_on: "1"
      payload_off: "0"
      availability_topic: "demo/sonoff/tele/s20/LWT"
      payload_available: "Online"
      payload_not_available: "Offline"
      qos: 1

If state change it is triggered from UI or from Automation, QOS that is seen in MQTT Explorer and mosquitto_sub remains at 0, even it has been set to QOS 1. in YAML definition.

What version of Home Assistant Core has the issue?

2022.11.4

What was the last working version of Home Assistant Core?

It never worked since I use HA

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Automation and MQTT Switch

Link to integration documentation on our website

https://www.home-assistant.io/integrations/switch.mqtt/

Diagnostics information

mosquitto_sub -h localhost -u pi -P "passwd!" -p 1883 -t "demo/sonoff/tele/s20/STATE" -d

Client (null) received PUBLISH (d0, q0, r0, m0, 'demo/sonoff/tele/s20/STATE', ... (297 bytes)) {"Time":1670067583,"Uptime":"0T00:48:53","UptimeSec":2933,"Heap":27,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER":"OFF","Wifi":{"AP":1,"SSId":"891w","BSSId":"F4:4E:05:19:A0:C0","Channel":13,"Mode":"11n","RSSI":82,"Signal":-59,"LinkCount":1,"Downtime":"0T00:00:03"}}

Example YAML snippet

switch:
    - name: "SONOFF S20"
      state_topic: "demo/sonoff/tele/s20/STATE"
      state_off: "OFF"
      state_on: "ON"
      value_template: "{{ value_json.POWER }}"
      command_topic: "demo/sonoff/cmnd/s20/POWER"
      payload_on: "1"
      payload_off: "0"
      availability_topic: "demo/sonoff/tele/s20/LWT"
      payload_available: "Online"
      payload_not_available: "Offline"
      qos: 1

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant[bot]]

Hey there @emontnemery, @jbouwh, mind taking a look at this issue as it has been labeled with an integration (mqtt) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `mqtt` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Change the title of the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign mqtt` Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

---

mqtt documentation mqtt source _{^{(message by IssueLinks)}}

[jbouwh]

The MQTT integration is sending the correct QoS, but it indeed seems the paho MQTT client is not sending the message out as a QoS 1 message.

[AlfaBravoX]

I am sorry but cannot see what you are describing.

If mosquitto_sub is used with -q 2 parameter, then it receives correct QOS, please see:

PAHO SUB: mosquitto_sub -h localhost -u pi -P "pass" -p 1883 -t "demo/sonoff/cmnd/s20/POWER" -d -q 2 PAHO PUB: mosquitto_pub -h localhost -u pi -P "pass" -t "demo/sonoff/cmnd/s20/POWER" -m 1 -q 1 Result: Client (null) received PUBLISH (d0, >>>> we have q1 <<<<<, r0, m1, 'demo/sonoff/cmnd/s20/POWER', ... (1 bytes))

When command with payload is issued by HA MQTT integration it still has expected QOS: Client (null) received PUBLISH (d0, >>>> we DONT have expected QOS >>>q0, r0, m0, 'demo/sonoff/cmnd/s20/POWER', ... (1 bytes))

also integration shows only QOS 0 even it has been sent as QOS 1

[jbouwh]

This is not a bug in Home Assistant see also: https://github.com/home-assistant/core/issues/68318

The MQTT integration is calling the paho client with the correct parameters.

[jbouwh]

If I run: mosquitto_sub -h homeassistant -u "username" -P "sme-password" -p 1883 -t "demo/sonoff/cmnd/s20/POWER" -d -q 2

When turning on the switch I see with setting QoS to 0:

Client mosqsub|7082-docker01 received PUBLISH (d0, q0, r0, m0, 'demo/sonoff/cmnd/s20/POWER', ... (1 bytes))
1

With QoS 1:

Client mosqsub|7082-docker01 received PUBLISH (d0, q1, r0, m6, 'demo/sonoff/cmnd/s20/POWER', ... (1 bytes))
Client mosqsub|7082-docker01 sending PUBACK (Mid: 6)
1

With QoS 2:

Client mosqsub|7110-docker01 received PUBLISH (d0, q2, r0, m1, 'demo/sonoff/cmnd/s20/POWER', ... (1 bytes))
Client mosqsub|7110-docker01 sending PUBREC (Mid: 1)
Client mosqsub|7110-docker01 received PUBREL (Mid: 1)
1
Client mosqsub|7110-docker01 sending PUBCOMP (Mid: 1)

So it seems that the mosquitto broker is handling the MQTT publish commands correctly.

What I will do is open a PR to add the QoS information at the debug logging that during subscribe or publish and when receiving a message.

[jbouwh]

https://github.com/home-assistant/core/pull/83195

[AlfaBravoX]

Regarding client, what plays also role here is that Tasmota does not support other QOS then 0. I was not aware of it, so Tasmota client cannot subscribe with QOS 1 or 2, therefore it will always have QOS 0. Thansk for debug commit.

[jbouwh]

I consider this issue resolved. You could use the debugging features from the MQTT config entry page, but for now they only support QoS 0, do that fits not help. What is sure that there is nothing wrong with the MQTT integration QoS setting. To reach higher QoS , both publisher and subscriber must set the QoS. The lowest setting will be limiting the max QoS. If have opened some PR's to be able to set the QoS in the frontend at the MQTT config page, those will help to. But for now closing here