MQTT Adapter: Handling of unsupported QoS levels during subscription to control endpoint by devices

Hono Mqtt documentation states that Currently the MQTT adapter only supports publishing of command messages using QoS 0. and discards malformed messages that e.g. are published to an unsupported topic or use an unsupported QoS value.

When devices subscribe to control endpoint with QoS levels 1 and 2 (as shown in below example), there are no error messages, successfully getting subscribed and also these devices receive commands. On the other hand, validation of QoS is done when command response is being sent.

Example (With QoS 1): $ mosquitto_sub -v -h 192.168.99.100 -u ‘sensor1@DEFAULT_TENANT’ -q 1 -P hono-secret -t control/+/+/req/#

control///req/101053c7df95-213d-4b95-91af-4b803330542c/test-qos-1 test qos 1

Example (With QoS 2): $ mosquitto_sub -v -h 192.168.99.100 -u ‘sensor1@DEFAULT_TENANT’ -q 2 -P hono-secret -t control/+/+/req/#

control///req/1010d8016fad-48f0-4027-8fac-dcfcb2d3e13a/test-qos-2 test qos 2

[sophokles73]

So your point is that we should deny a request to subscribe using QoS 2, right? I can live with that. Would you mind creating a PR?

[kaniyan]

IMHO it is also important how consistently a system behaves in case of invalid inputs, which attributes to user friendliness. In case of command & control, a device can subscribe successfully with QoS 2 (system works fine) and the same device face issues when try to send a response to those command with QoS 2.

IMHO it is consistent, if hono doesn’t let devices successfully subscribe with QoS 2 to a control endpoint. It is also ok, that we (even) more explicitly update the user guide.