MQTT Sensors: Support the full MQTT QoS spectrum (QoS 0 / 1 / 2), not only QoS 2
Problem / Current Limitation:
PRTG's MQTT sensors currently hard-require QoS 2 as a fixed, non-configurable part of their implementation — none of PRTG's available MQTT sensor types offer QoS 0 or QoS 1 as an alternative. QoS 0, 1, and 2 are all standard, valid delivery levels defined by the MQTT protocol itself — a broker or service that only offers QoS 0/1 is not doing anything non-standard or unusual, it's simply choosing a different (and very common) point on the QoS spectrum. By hard-coding QoS 2 across the board, PRTG effectively excludes any MQTT broker or managed service that doesn't implement QoS 2, regardless of how widely used that service is.
Concrete example / Business case:
AWS IoT Core — one of the most widely used managed MQTT broker services worldwide — only supports QoS 0 and QoS 1, and does not support QoS 2 at all. This isn't a niche or non-compliant setup; it's a deliberate, documented design choice by AWS and affects every AWS IoT Core customer trying to monitor via PRTG's MQTT sensors. In our case, we use AWS IoT Core (mTLS, port 8883) to collect MQTT telemetry from our self-developed Ticket Vending Machines (TVMs) — status, cabinet/climate, printer, flood, POS, PC, door, VoIP intercom, UPS, etc. — across 25+ MQTT sensors per site, and AWS IoT Core is a firm architectural commitment going forward. There is currently no sensor-side flag or workaround, and no alternative PRTG sensor type, that supports this natively.
Without QoS 0/1 support, customers on any QoS-0/1-only broker are left with two unsatisfactory options: run an extra intermediary broker (e.g. Mosquitto, EMQX, HiveMQ) purely to translate QoS 2 down to QoS 1 — added infrastructure and an added point of failure for no functional benefit — or abandon PRTG for that telemetry and use other tooling instead.
Requested change:
Make the QoS level configurable (QoS 0 / 1 / 2) across PRTG's MQTT sensors, so they can negotiate whatever QoS level the target broker actually supports, instead of assuming QoS 2 is universal.
Impact if implemented:
Brings PRTG's MQTT sensors in line with the actual MQTT specification, removing an artificial compatibility gap. Benefits any customer connecting to a broker that doesn't offer QoS 2 — AWS IoT Core being the largest and most obvious example, but not the only one — without requiring extra bridging infrastructure.