MQTT

MQTT(Message Queuing Telemetry Transport) ist ein leichtes und weit verbreitetes Messaging-Protokoll, das für eingeschränkte Geräte entwickelt wurde.AWS IoT CoreDie Unterstützung für MQTT basiert aufMQTT v3.1.1-Spezifikationund derMQTT v5.0-Spezifikation, mit einigen Unterschieden, wie dokumentiert inAWS IoTUnterschiede zu den MQTT-Spezifikationen. Als neueste Version des Standards führt MQTT 5 mehrere wichtige Funktionen ein, die ein MQTT-basiertes System robuster machen, darunter neue Skalierbarkeitserweiterungen, verbesserte Fehlerberichte mit Antworten auf Ursachencodes, Timer für Nachrichten und Sitzungen sowie benutzerdefinierte Nachrichtenkopfzeilen. Weitere Informationen zu den Funktionen von MQTT 5 finden Sie unterAWS IoT Coreunterstützt, sieheUnterstützte Funktionen von MQTT 5.AWS IoT Coreunterstützt auch die Kommunikation zwischen den MQTT-Versionen (MQTT 3 und MQTT 5). Ein MQTT 3-Herausgeber kann eine MQTT 3-Nachricht an einen MQTT 5-Abonnenten senden, der eine MQTT 5-Veröffentlichungsnachricht erhält, und umgekehrt.

AWS IoT Coreunterstützt Geräteverbindungen, die das MQTT-Protokoll und das MQTT-overWSS-Protokoll verwenden und die durch eineClient-ID. DerAWS IoTGeräte-SDKsunterstützen beide Protokolle und sind die empfohlenen Methoden, um Geräte anAWS IoT Core. DerAWS IoTGeräte-SDKs unterstützen die Funktionen, die Geräte und Clients benötigen, um eine Verbindung herzustellen und darauf zuzugreifenAWS IoTdienstleistungen. Die Geräte-SDKs unterstützen die Authentifizierungsprotokolle, die dieAWS IoTDienste erfordern und die Verbindungs-ID-Anforderungen, die das MQTT-Protokoll und MQTT über WSS-Protokolle erfordern. Für Informationen darüber, wie Sie eine Verbindung herstellen könnenAWS IoTunter Verwendung derAWSGeräte-SDKs und Links zu Beispielen fürAWS IoTin den unterstützten Sprachen finden Sie unterHerstellen einer Verbindung mit MQTT mithilfe desAWS IoTGeräte-SDKs. Weitere Hinweise zu Authentifizierungsmethoden und den Portzuordnungen für MQTT-Nachrichten finden Sie unterProtokolle, Port-Zuweisungen und Authentifizierung.

Wir empfehlen zwar die Verwendung desAWS IoTGeräte-SDKs zum Herstellen einer VerbindungAWS IoT, sie sind nicht erforderlich. Wenn Sie das nicht verwendenAWS IoTGeräte-SDKs müssen Sie jedoch für die erforderliche Verbindungs- und Kommunikationssicherheit sorgen. Kunden müssen die sendenTLS-Erweiterung zur Servernamenangabe (SNI)in der Verbindungsanfrage. Verbindungsversuche, die das SNI nicht beinhalten, werden abgelehnt. Weitere Informationen finden Sie unter Transportsicherheit in AWS IoT. Kunden, die IAM-Benutzer verwenden undAWSAnmeldeinformationen zur Authentifizierung von Clients müssen die richtigen Angaben enthaltenSignatur Version 4Authentifizierung.

Herstellen einer Verbindung mit MQTT mithilfe desAWS IoTGeräte-SDKs

Dieser Abschnitt enthält Links zuAWS IoTGeräte-SDKs und zum Quellcode von Beispielprogrammen, die veranschaulichen, wie ein Gerät angeschlossen wirdAWS IoT. Die hier verlinkten Beispiel-Apps zeigen, wie Sie eine Verbindung herstellenAWS IoTunter Verwendung des MQTT-Protokolls und MQTT über WSS.

Anmerkung

DerAWS IoTGeräte-SDKs haben einen MQTT 5-Client in der Entwicklervorschau veröffentlicht. Während des Vorschauzeitraums nehmen wir möglicherweise abwärtsinkompatible Änderungen an den öffentlichen APIs und den Service-Clients in derAWS IoTGeräte-SDKs verwenden weiterhin den MQTT 3.1.1-Client.

C++

Mit demAWS IoTC++ Device SDK zum Verbinden von Geräten

• Quellcode einer Beispiel-App, die ein Beispiel für eine MQTT-Verbindung in C++ zeigt

• AWS IoTC++-Geräte-SDK v2 aktiviertGitHub

Python

Mit demAWS IoTGeräte-SDK für Python zum Verbinden von Geräten

• Quellcode einer Beispiel-App, die ein Beispiel für eine MQTT-Verbindung in Python zeigt

• AWS IoTGeräte-SDK für Python v2 aktiviertGitHub

JavaScript

Mit demAWS IoTGeräte-SDK fürJavaScriptum Geräte zu verbinden

• Quellcode einer Beispiel-App, die ein Beispiel für eine MQTT-Verbindung in zeigtJavaScript

• AWS IoTGeräte-SDK fürJavaScriptv2 anGitHub

Java

Mit demAWS IoTGeräte-SDK für Java zum Verbinden von Geräten

• Quellcode einer Beispiel-App, die ein Beispiel für eine MQTT-Verbindung in Java zeigt

• AWS IoTGeräte-SDK für Java v2 aktiviertGitHub

Embedded C

Mit demAWS IoTGeräte-SDK für Embedded C zum Verbinden von Geräten

Wichtig

Dieses SDK ist für die Verwendung durch erfahrene Entwickler eingebetteter Software vorgesehen.

• Quellcode einer Beispiel-App, die ein Beispiel für eine MQTT-Verbindung in Embedded C zeigt

• AWS IoTGeräte-SDK für Embedded C onGitHub

MQTT-Optionen für die Servicequalität (QoS)

AWS IoTund derAWS IoTGeräte-SDKs unterstützen dieMQTT-Niveaus für die Servicequalität (QoS)0und1. Das MQTT-Protokoll definiert eine dritte Ebene von QoS, Ebene2, aberAWS IoTunterstützt es nicht. Nur das MQTT-Protokoll unterstützt die QoS-Funktion. HTTPS unterstützt QoS, indem es einen Abfragezeichenfolgenparameter übergibt.?qos=qoswobei der Wert 0 oder 1 sein kann.

In dieser Tabelle wird beschrieben, wie sich jede QoS-Stufe auf Nachrichten auswirkt, die im und vom Message Broker veröffentlicht werden.

Mit einem QoS-Level von...	Die Botschaft ist...	Kommentare
QoS-Stufe 0	Null oder öfter gesendet	Diese Stufe sollte für Nachrichten verwendet werden, die über zuverlässige Kommunikationsverbindungen gesendet werden oder die problemlos übersehen werden können.
QoS Stufe 1	Mindestens einmal gesendet und dann wiederholt, bis einPUBACKAntwort ist eingegangen	Die Nachricht gilt erst als abgeschlossen, wenn der Absender einePUBACKAntwort, um eine erfolgreiche Lieferung anzuzeigen.

Persistente MQTT-Sitzungen

Dauerhafte Sitzungen speichern die Abonnements und Nachrichten eines Kunden mit einer Servicequalität (QoS) von 1, die vom Client nicht bestätigt wurden. Wenn das Gerät erneut eine Verbindung zu einer persistenten Sitzung herstellt, wird die Sitzung wieder aufgenommen, Abonnements werden wiederhergestellt und unbestätigte abonnierte Nachrichten, die vor der Wiederverbindung empfangen und gespeichert wurden, werden an den Client gesendet.

Die Verarbeitung der gespeicherten Nachrichten wird aufgezeichnet inCloudWatchundCloudWatchLogs. Für Informationen zu den Einträgen, die geschrieben wurden anCloudWatchundCloudWatchProtokolle, sieheMessage Broker-MetrikenundProtokolleintrag.

Eine persistente Sitzung erstellen

In MQTT 3 erstellen Sie eine persistente MQTT-Sitzung, indem Sie eineCONNECTNachricht und Einstellung dercleanSessionFlagge bis0. Wenn für den Client, der die sendet, keine Sitzung existiertCONNECTNachricht, eine neue persistente Sitzung wird erstellt. Wenn für den Client bereits eine Sitzung existiert, nimmt der Client die bestehende Sitzung wieder auf. Um eine saubere Sitzung zu erstellen, senden Sie eineCONNECTNachricht senden und einstellencleanSessionFlagge bis1, und der Broker speichert keinen Sitzungsstatus, wenn der Client die Verbindung trennt.

In MQTT 5 behandeln Sie persistente Sitzungen, indem Sie dieClean StartFlagge undSession Expiry Interval. Clean Start steuert den Beginn der Verbindungssitzung und das Ende der vorherigen Sitzung. Wenn du einstellstClean Start=1, wird eine neue Sitzung erstellt und eine vorherige Sitzung wird beendet, falls sie existiert. Wenn du einstellstClean Start=0, die Verbindungssitzung setzt eine vorherige Sitzung fort, falls sie existiert. Das Sitzungsablaufintervall bestimmt das Ende der Verbindungssitzung. Das Sitzungsablaufintervall gibt die Zeit in Sekunden (4-Byte-Ganzzahl) an, während der eine Sitzung nach der Trennung fortbesteht. EinstellungSession Expiry interval=0bewirkt, dass die Sitzung sofort beendet wird, wenn die Verbindung unterbrochen wird. Wenn das Sitzungsablaufintervall in der CONNECT-Nachricht nicht angegeben ist, ist der Standardwert 0.

MQTT 5 Clean Start und Ablauf der Sitzung
Eigenschaftenwert	Beschreibung
Clean Start= 1	Erzeugt eine neue Sitzung und beendet eine vorherige Sitzung, falls eine existiert.
Clean Start= 0	Setzt eine Sitzung fort, wenn eine vorherige Sitzung existiert.
Session Expiry Interval> 0	Hält eine Sitzung aufrecht.
Session Expiry interval= 0	Hält eine Sitzung nicht aufrecht.

In MQTT 5, wenn SieClean Start=1undSession Expiry Interval=0, das entspricht einer MQTT 3-Clean-Sitzung. Wenn du einstellstClean Start=0undSession Expiry Interval>0, dies entspricht einer persistenten MQTT-3-Sitzung.

Anmerkung

Persistente Sitzungen der Cross-MQTT-Version (MQTT 3 und MQTT 5) werden nicht unterstützt. Eine persistente MQTT 3-Sitzung kann nicht als MQTT 5-Sitzung wieder aufgenommen werden und umgekehrt.

Operationen während einer persistenten Sitzung

Kunden nutzen diesessionPresentAttribut in der Verbindung bestätigt (CONNACK) Nachricht, um festzustellen, ob eine persistente Sitzung vorhanden ist. WennsessionPresentist1, es liegt eine persistente Sitzung vor und alle gespeicherten Nachrichten für den Client werden an den Client übermittelt, nachdem der Client dieCONNACK, wie beschrieben inNachrichtenverkehr nach Wiederverbindung zu einer persistenten Sitzung. WennsessionPresentist1, der Kunde muss sich nicht erneut anmelden. Wenn jedochsessionPresentist0, ist keine persistente Sitzung vorhanden und der Client muss seine Themenfilter erneut abonnieren.

Nachdem der Client einer persistenten Sitzung beigetreten ist, kann er Nachrichten veröffentlichen und Themenfilter abonnieren, ohne dass bei jedem Vorgang zusätzliche Flags erforderlich sind.

Nachrichtenverkehr nach Wiederverbindung zu einer persistenten Sitzung

Eine persistente Sitzung stellt eine fortlaufende Verbindung zwischen einem Client und einem MQTT-Nachrichtenbroker dar. Wenn ein Client über eine persistente Sitzung eine Verbindung zum Nachrichtenbroker herstellt, speichert der Nachrichtenbroker alle Abonnements, die der Client während der Verbindung abschließt. Wenn der Client getrennt wird, speichert der Message Broker unbestätigte QoS 1-Nachrichten und neue QoS 1-Nachrichten, die zu Themen veröffentlicht wurden, die der Client abonniert hat. Nachrichten werden gemäß dem Kontolimit gespeichert. Nachrichten, die das Limit überschreiten, werden gelöscht. Weitere Hinweise zu Beschränkungen für persistente Nachrichten finden Sie unterAWS IoT CoreEndpunkte und Kontingente. Wenn der Client wieder eine Verbindung zu seiner persistenten Sitzung herstellt, werden alle Abonnements wieder aktiviert und alle gespeicherten Nachrichten werden mit einer maximalen Geschwindigkeit von 10 Nachrichten pro Sekunde an den Client gesendet. Wenn in MQTT 5 ein ausgehender QoS1 mit dem Nachrichtenablaufintervall abläuft, wenn ein Client offline ist, erhält der Client nach Wiederaufnahme der Verbindung die abgelaufene Nachricht nicht.

Nach der Wiederverbindung werden die gespeicherten Nachrichten an den Client gesendet, und zwar mit einer Geschwindigkeit, die auf 10 gespeicherte Nachrichten pro Sekunde begrenzt ist, zusammen mit dem aktuellen Nachrichtenverkehr, bisPublish requests per second per connectionLimit ist erreicht. Da die Übertragungsrate der gespeicherten Nachrichten begrenzt ist, dauert es mehrere Sekunden, bis alle gespeicherten Nachrichten zugestellt sind, wenn in einer Sitzung nach der Wiederverbindung mehr als 10 gespeicherte Nachrichten zugestellt werden müssen.

Beenden einer persistenten Sitzung

Dauerhafte Sitzungen können auf folgende Weise enden:

• Die Ablaufzeit der persistenten Sitzung ist abgelaufen. Der Timer für den Ablauf einer persistenten Sitzung wird gestartet, wenn der Message Broker feststellt, dass ein Client die Verbindung getrennt hat, entweder weil der Client die Verbindung getrennt hat oder weil die Verbindung aufgrund eines Timeouts unterbrochen wurde.

• Der Kunde sendet eineCONNECTNachricht, die dencleanSessionFlagge bis1.

In MQTT 3 ist der Standardwert für die Ablaufzeit persistenter Sitzungen eine Stunde, und dies gilt für alle Sitzungen im Konto.

In MQTT 5 können Sie das Sitzungsablaufintervall für jede Sitzung auf den CONNECT- und DISCONNECT-Paketen festlegen.

Für das Sitzungsablaufintervall für das DISCONNECT-Paket:

• Wenn die aktuelle Sitzung ein Sitzungsablaufintervall von 0 hat, können Sie das Sitzungsablaufintervall für das DISCONNECT-Paket nicht auf mehr als 0 setzen.

• Wenn die aktuelle Sitzung ein Sitzungsablaufintervall von mehr als 0 hat und Sie das Sitzungsablaufintervall im DISCONNECT-Paket auf 0 setzen, wird die Sitzung bei DISCONNECT beendet.

• Andernfalls aktualisiert das Sitzungsablaufintervall im DISCONNECT-Paket das Sitzungsablaufintervall der aktuellen Sitzung.

Anmerkung

Die gespeicherten Nachrichten, die darauf warten, an den Client gesendet zu werden, wenn eine Sitzung endet, werden verworfen. Sie werden jedoch weiterhin zum Standardtarif für Nachrichten abgerechnet, obwohl sie nicht gesendet werden konnten. Weitere Informationen zu den Preisen für Nachrichten finden Sie unterAWS IoT CorePreisgestaltung. Sie können das Ablaufzeitintervall konfigurieren.

Wiederverbindung nach Ablauf einer persistenten Sitzung

Wenn ein Client vor Ablauf nicht erneut eine Verbindung zu seiner persistenten Sitzung herstellt, wird die Sitzung beendet und die gespeicherten Nachrichten werden verworfen. Wenn ein Client nach Ablauf der Sitzung erneut eine Verbindung herstellt mit einemcleanSessionFlagge bis0erstellt der Dienst eine neue persistente Sitzung. Abonnements oder Nachrichten aus der vorherigen Sitzung sind für diese Sitzung nicht verfügbar, da sie nach Ablauf der vorherigen Sitzung verworfen wurden.

Gebühren für persistente Sitzungsnachrichten

Nachrichten werden zu Ihren Lasten berechnetAWS-Kontowenn der Message Broker eine Nachricht an einen Client oder eine persistente Offline-Sitzung sendet. Wenn ein Offline-Gerät mit einer dauerhaften Sitzung die Verbindung wiederherstellt und seine Sitzung wieder aufnimmt, werden die gespeicherten Nachrichten an das Gerät übermittelt und Ihrem Konto erneut belastet. Weitere Informationen zu den Preisen für Nachrichten finden Sie unterAWS IoT CorePreisgestaltung - Messaging.

Die standardmäßige Ablaufzeit für persistente Sitzungen von einer Stunde kann mithilfe des Standardverfahrens zur Erhöhung des Limits erhöht werden. Beachten Sie, dass eine Verlängerung der Sitzungsablaufzeit Ihre Nachrichtengebühren erhöhen kann, da durch die zusätzliche Zeit mehr Nachrichten für das Offline-Gerät gespeichert werden könnten und diese zusätzlichen Nachrichten Ihrem Konto zum Standardtarif für Nachrichten in Rechnung gestellt würden. Die Sitzungsablaufzeit ist ungefähre Angaben und eine Sitzung kann bis zu 30 Minuten länger als das Kontolimit andauern. Eine Sitzung wird jedoch nicht kürzer als das Kontolimit sein. Weitere Hinweise zu Sitzungslimits finden Sie unterAWSServicekontingente.

MQTT behielt Nachrichten

AWS IoT Coreunterstützt das im MQTT-Protokoll beschriebene RETAIN-Flag. Wenn ein Client das RETAIN-Flag für eine MQTT-Nachricht setzt, die er veröffentlicht,AWS IoT Corespeichert die Nachricht. Es kann dann an neue Abonnenten gesendet und abgerufen werden, indem Sie denGetRetainedMessageBedienung, und angesehen in derAWS IoTKonsole.

Beispiele für die Verwendung von gespeicherten MQTT-Nachrichten

• Als erste Konfigurationsnachricht

  Bei MQTT gespeicherte Nachrichten werden an einen Client gesendet, nachdem der Kunde ein Thema abonniert hat. Wenn Sie möchten, dass alle Kunden, die ein Thema abonnieren, die MQTT-Nachricht erhalten, die von MQTT beibehaltene Nachricht sofort nach ihrem Abonnement erhalten, können Sie eine Konfigurationsnachricht veröffentlichen, bei der das RETAIN-Flag gesetzt ist. Abonnierende Clients erhalten außerdem Updates für diese Konfiguration, sobald eine neue Konfigurationsnachricht veröffentlicht wird.

• Als letzte bekannte Zustandsmeldung

  Geräte können das RETAIN-Flag für Nachrichten mit aktuellem Status setzen, sodassAWS IoT Corewird sie retten. Wenn Anwendungen eine Verbindung herstellen oder erneut eine Verbindung herstellen, können sie dieses Thema abonnieren und sofort nach dem Abonnieren des beibehaltenen Nachrichtenthemas den zuletzt gemeldeten Status abrufen. Auf diese Weise können sie vermeiden, auf die nächste Nachricht vom Gerät warten zu müssen, um den aktuellen Status zu sehen.

In diesem Abschnitt:

• Häufige Aufgaben mit gespeicherten MQTT-Nachrichten inAWS IoT Core
• Fakturierung und gespeicherte Nachrichten
• Vergleich von gespeicherten MQTT-Nachrichten und persistenten MQTT-Sitzungen
• MQTT behielt Nachrichten undAWS IoTGeräteschatten

Häufige Aufgaben mit gespeicherten MQTT-Nachrichten inAWS IoT Core

AWS IoT Corespeichert MQTT-Nachrichten, wobei das RETAIN-Flag gesetzt ist. Diesegespeicherte Nachrichtenwerden als normale MQTT-Nachricht an alle Kunden gesendet, die das Thema abonniert haben, und sie werden auch gespeichert, um an neue Abonnenten des Themas gesendet zu werden.

Bei MQTT gespeicherte Nachrichten erfordern spezifische Richtlinienmaßnahmen, um den Clients den Zugriff auf sie zu ermöglichen. Beispiele für die Verwendung von Richtlinien zur Aufbewahrung von Nachrichten finden Sie unterBeispiele für Richtlinien für beibehaltene Nachrichten.

In diesem Abschnitt werden allgemeine Vorgänge beschrieben, bei denen Nachrichten aufbewahrt werden.

• Eine beibehaltene Nachricht erstellen

  Der Client bestimmt, ob eine Nachricht beibehalten wird, wenn er eine MQTT-Nachricht veröffentlicht. Kunden können das RETAIN-Flag setzen, wenn sie eine Nachricht veröffentlichen, indem sie eineGeräte-SDK. Anwendungen und Dienste können das RETAIN-Flag setzen, wenn sie dasPublishAktionum eine MQTT-Nachricht zu veröffentlichen.

  Pro Themenname wird nur eine Nachricht beibehalten. Eine neue Nachricht mit dem RETAIN-Flag, die zu einem Thema veröffentlicht wurde, ersetzt jede bestehende beibehaltene Nachricht, die zuvor zu dem Thema gesendet wurde.

  HINWEIS:Sie können nicht auf einem veröffentlichenreserviertes Themamit gesetzter RETAIN-Flagge.

• Thema einer beibehaltenen Nachricht abonnieren

  Kunden abonnieren beibehaltene Nachrichtenthemen wie jedes andere MQTT-Nachrichtenthema. Bei zurückgehaltenen Nachrichten, die durch das Abonnieren eines beibehaltenen Nachrichtenthemas empfangen wurden, ist das RETAIN-Flag gesetzt.

  Archivierte Nachrichten werden gelöscht vonAWS IoT Corewenn ein Client eine beibehaltene Nachricht mit einer 0-Byte-Nachrichten-Payload für das beibehaltene Nachrichtenthema veröffentlicht. Kunden, die das Thema der beibehaltenen Nachricht abonniert haben, erhalten ebenfalls die 0-Byte-Nachricht.

  Wenn Sie einen Wildcard-Themenfilter abonnieren, der ein beibehaltenes Nachrichtenthema enthält, kann der Kunde nachfolgende Nachrichten erhalten, die zum Thema der beibehaltenen Nachricht veröffentlicht wurden, aber die beibehaltene Nachricht wird nicht zugestellt, wenn das Abonnement abgeschlossen ist.

  HINWEIS:Um eine beibehaltene Nachricht nach dem Abonnement zu erhalten, muss der Themenfilter in der Abonnementanfrage genau dem Thema der beibehaltenen Nachricht entsprechen.

  Bei zurückgehaltenen Nachrichten, die nach dem Abonnieren eines beibehaltenen Nachrichtenthemas empfangen wurden, ist das RETAIN-Flag gesetzt. Eingeschränkte Nachrichten, die von einem abonnierenden Kunden nach dem Abonnement empfangen werden, tun dies nicht.

• Eine gespeicherte Nachricht wird abgerufen

  Archivierte Nachrichten werden automatisch an Kunden zugestellt, wenn sie das Thema mit der gespeicherten Nachricht abonnieren. Damit ein Kunde die beibehaltene Nachricht im Rahmen des Abonnements erhalten kann, muss er den genauen Themennamen der zurückgehaltenen Nachricht abonnieren. Wenn Sie einen Wildcard-Themenfilter abonnieren, der ein beibehaltenes Nachrichtenthema enthält, kann der Kunde nachfolgende Nachrichten erhalten, die zum Thema der beibehaltenen Nachricht veröffentlicht wurden, aber die beibehaltene Nachricht wird nicht zugestellt, wenn das Abonnement abgeschlossen ist.

  Dienste und Apps können gespeicherte Nachrichten auflisten und abrufen, indem sie anrufenListRetainedMessagesundGetRetainedMessage.

  Ein Client wird nicht daran gehindert, Nachrichten zu einem beibehaltenen Nachrichtenthema zu veröffentlichenohnedas RETAIN-Flag setzen. Dies kann zu unerwarteten Ergebnissen führen, z. B. wenn die beibehaltene Nachricht nicht mit der Nachricht übereinstimmt, die Sie beim Abonnieren des Themas erhalten haben.

  Wenn bei MQTT 5 für eine beibehaltene Nachricht das Nachrichtenablaufintervall festgelegt ist und die beibehaltene Nachricht abläuft, erhält ein neuer Abonnent, der dieses Thema abonniert, die beibehaltene Nachricht nach erfolgreichem Abonnement nicht.

• Themen der beibehaltenen Nachrichten auflisten

  Sie können gespeicherte Nachrichten auflisten, indem Sie anrufenListRetainedMessagesund die gespeicherten Nachrichten können in derAWS IoTKonsole.

• Abrufen von gespeicherten Nachrichtendetails

  Sie können die gespeicherten Nachrichtendetails erhalten, indem Sie anrufenGetRetainedMessageund sie können in der eingesehen werdenAWS IoTKonsole.

• Beibehaltung einer Testamtsnachricht

  MQTTWillNachrichtendie erstellt werden, wenn ein Gerät eine Verbindung herstellt, können beibehalten werden, indem dasWill RetainFlagge in derConnect Flag bitsFeld.

• Löschen einer gespeicherten Nachricht

  Geräte, Anwendungen und Dienste können eine beibehaltene Nachricht löschen, indem sie eine Nachricht mit dem RETAIN-Flag und einer leeren Nachrichten-Payload (0 Byte) unter dem Themennamen der zu löschenden beibehaltenen Nachricht veröffentlichen. Solche Nachrichten löschen die beibehaltene Nachricht vonAWS IoT Core, werden an Kunden mit einem Abonnement für das Thema gesendet, aber sie sind nicht im Besitz vonAWS IoT Core.

  Archivierte Nachrichten können auch interaktiv gelöscht werden, indem Sie auf die gespeicherte Nachricht in derAWS IoTKonsole. Eingeschlossene Nachrichten, die mithilfe desAWS IoTKonsolesendet außerdem eine 0-Byte-Nachricht an Kunden, die das Thema der beibehaltenen Nachricht abonniert haben.

  Archivierte Nachrichten können nicht wiederhergestellt werden, nachdem sie gelöscht wurden. Ein Kunde müsste eine neue beibehaltene Nachricht veröffentlichen, um die gelöschte Nachricht zu ersetzen.

• Debuggen und Problembehandlung bei zurückgehaltenen Nachrichten

  DerAWS IoTKonsolestellt mehrere Tools zur Verfügung, mit denen Sie Probleme mit gespeicherten Nachrichten beheben können:

  • DerEingeschränkte NachrichtenSeite

    DerEingeschränkte NachrichtenSeite in derAWS IoTDie Konsole bietet eine paginierte Liste der gespeicherten Nachrichten, die von Ihrem Konto in der aktuellen Region gespeichert wurden. Von dieser Seite aus können Sie:

    • Sehen Sie sich die Details jeder gespeicherten Nachricht an, z. B. die Nachrichten-Payload, QoS und die Uhrzeit des Empfangs.

    • Aktualisieren Sie den Inhalt einer gespeicherten Nachricht.

    • Löscht eine beibehaltene Nachricht.

  • DerMQTT-Testclient

    DerMQTT-TestclientSeite in derAWS IoTDie Konsole kann MQTT-Themen abonnieren und veröffentlichen. Mit der Option Veröffentlichen können Sie das RETAIN-Flag für die von Ihnen veröffentlichten Nachrichten setzen, um zu simulieren, wie sich Ihre Geräte möglicherweise verhalten.

  Einige unerwartete Ergebnisse könnten auf diese Aspekte der Implementierung von zurückgehaltenen Nachrichten in zurückzuführen seinAWS IoT Core.

  • Beschränkungen für beibehaltene Nachrichten

    Wenn ein Konto die maximale Anzahl an gespeicherten Nachrichten gespeichert hat,AWS IoT Coregibt eine gedrosselte Antwort auf Nachrichten zurück, die mit dem RETAIN-Set veröffentlicht wurden, und Nutzlasten von mehr als 0 Byte, bis einige der gespeicherten Nachrichten gelöscht werden und die Anzahl der zurückgehaltenen Nachrichten unter den Grenzwert fällt.

  • Reihenfolge der Nachrichtenzustellung beibehalten

    Die Reihenfolge der Zustellung von gespeicherten Nachrichten und abonnierten Nachrichten kann nicht garantiert werden.

Fakturierung und gespeicherte Nachrichten

Veröffentlichen von Nachrichten, bei denen das RETAIN-Flag von einem Client aus gesetzt ist, indemAWS IoTKonsole oder per AnrufPublishfallen zusätzliche Messaging-Gebühren an, die unter beschrieben sindAWS IoT CorePreisgestaltung - Messaging.

Abrufen von gespeicherten Nachrichten durch einen Client mithilfe vonAWS IoTKonsole oder per AnrufGetRetainedMessagefallen zusätzlich zu den normalen Gebühren für die API-Nutzung Messaging-Gebühren an. Die zusätzlichen Gebühren sind beschrieben inAWS IoT CorePreisgestaltung - Messaging.

MQTTWillNachrichtendie veröffentlicht werden, wenn die Verbindung eines Geräts unerwartet unterbrochen wird, fallen Nachrichtengebühren an, wie unterAWS IoT CorePreisgestaltung - Messaging.

Weitere Informationen zu den Kosten für Nachrichten finden Sie unterAWS IoT CorePreisgestaltung - Messaging.

Vergleich von gespeicherten MQTT-Nachrichten und persistenten MQTT-Sitzungen

Beibehaltene Nachrichten und persistente Sitzungen sind Standardfunktionen von MQTT, die es Geräten ermöglichen, Nachrichten zu empfangen, die veröffentlicht wurden, während sie offline waren. Archivierte Nachrichten können aus persistenten Sitzungen veröffentlicht werden. In diesem Abschnitt werden die wichtigsten Aspekte dieser Funktionen und ihr Zusammenspiel beschrieben.

	Eingeschränkte Nachrichten	Dauerhafte Sitzungen
Schlüsselfunktionen	Gespeicherte Nachrichten können verwendet werden, um große Gruppen von Geräten zu konfigurieren oder zu benachrichtigen, nachdem sie eine Verbindung hergestellt haben. Gespeicherte Nachrichten können auch verwendet werden, wenn Geräte nach einer erneuten Verbindung nur die letzte zu einem Thema veröffentlichte Nachricht empfangen sollen.	Dauerhafte Sitzungen sind nützlich für Geräte, die über eine unterbrochene Konnektivität verfügen und auf denen mehrere wichtige Nachrichten übersehen werden können. Geräte können sich mit einer persistenten Sitzung verbinden, um Nachrichten zu empfangen, die gesendet werden, während sie offline sind.
Beispiele	Bei gespeicherten Nachrichten können Geräte Konfigurationsinformationen über ihre Umgebung erhalten, wenn sie online gehen. Die Erstkonfiguration könnte eine Liste anderer Nachrichtenthemen enthalten, die das Unternehmen abonnieren sollte, oder Informationen darüber, wie es seine lokale Zeitzone konfigurieren sollte.	Geräte, die über ein Mobilfunknetz mit intermittierender Konnektivität eine Verbindung herstellen, können persistente Sitzungen verwenden, um zu verhindern, dass wichtige Nachrichten übersehen werden, die gesendet werden, wenn ein Gerät keine Netzabdeckung hat oder sein Mobilfunknetz ausschalten muss.
Nachrichten, die beim ersten Abonnement eines Themas eingegangen sind	Nachdem Sie ein Thema mit einer gespeicherten Nachricht abonniert haben, wird die zuletzt beibehaltene Nachricht empfangen.	Nach dem Abonnieren eines Themas ohne eine beibehaltene Nachricht wird keine Nachricht empfangen, bis eine Nachricht zu dem Thema veröffentlicht wird.
Abonnierte Themen nach der Wiederherstellung der Verbindung	Ohne eine persistente Sitzung muss der Client nach der Wiederverbindung Themen abonnieren.	Abonnierte Themen werden nach der Wiederherstellung der Verbindung wiederhergestellt.
Nach der Wiederverbindung empfangene Nachrichten	Nachdem Sie ein Thema mit einer gespeicherten Nachricht abonniert haben, wird die zuletzt beibehaltene Nachricht empfangen.	Alle Nachrichten, die mit einem QOS = 1 veröffentlicht und mit einem QOS =1 abonniert wurden, während das Gerät getrennt war, werden gesendet, nachdem das Gerät wieder verbunden ist.
Ablauf der Daten/Sitzung	In MQTT 3 laufen gespeicherte Nachrichten nicht ab. Sie werden gespeichert, bis sie ersetzt oder gelöscht werden. In MQTT 5 laufen gespeicherte Nachrichten nach dem von Ihnen festgelegten Nachrichtenablaufintervall ab. Weitere Informationen finden Sie unterAblauf der Nachricht.	Dauerhafte Sitzungen laufen ab, wenn der Client innerhalb des Timeouts keine erneute Verbindung herstellt. Nach Ablauf einer persistenten Sitzung werden die Abonnements und gespeicherten Nachrichten des Clients, die mit einem QOS = 1 veröffentlicht und mit einem QOS =1 abonniert wurden, während das Gerät getrennt war, gelöscht. Abgelaufene Nachrichten werden nicht zugestellt. Weitere Hinweise zu Sitzungsabläufen bei persistenten Sitzungen finden Sie unterPersistente MQTT-Sitzungen.

Hinweise zu persistenten Sitzungen finden Sie unterPersistente MQTT-Sitzungen.

Bei Retained Messages bestimmt der Publishing Client, ob eine Nachricht aufbewahrt und an ein Gerät übermittelt werden soll, nachdem eine Verbindung hergestellt wurde, unabhängig davon, ob es eine vorherige Sitzung hatte oder nicht. Die Entscheidung, eine Nachricht zu speichern, wird vom Herausgeber getroffen, und die gespeicherte Nachricht wird an alle aktuellen und zukünftigen Kunden übermittelt, die ein QoS 0- oder QoS 1-Abonnement abonnieren. Bei gespeicherten Nachrichten wird jeweils nur eine Nachricht zu einem bestimmten Thema gespeichert.

Wenn ein Konto die maximale Anzahl an gespeicherten Nachrichten gespeichert hat,AWS IoT Coregibt eine gedrosselte Antwort auf Nachrichten zurück, die mit dem RETAIN-Set veröffentlicht wurden, und Nutzlasten von mehr als 0 Byte, bis einige der gespeicherten Nachrichten gelöscht werden und die Anzahl der zurückgehaltenen Nachrichten unter den Grenzwert fällt.

MQTT behielt Nachrichten undAWS IoTGeräteschatten

Beibehaltene Nachrichten und Device Shadows speichern beide Daten von einem Gerät, verhalten sich jedoch unterschiedlich und dienen unterschiedlichen Zwecken. In diesem Abschnitt werden ihre Gemeinsamkeiten und Unterschiede beschrieben.

	Eingeschränkte Nachrichten	Device Shadows
Nachrichten-Payload hat eine vordefinierte Struktur oder ein vordefiniertes Schema	Wie in der Implementierung definiert. MQTT spezifiziert keine Struktur oder kein Schema für seine Nachrichten-Payload.	AWS IoTunterstützt eine bestimmte Datenstruktur.
Durch das Aktualisieren der Nachrichten-Payload werden Ereignismeldungen generiert.	Wenn Sie eine beibehaltene Nachricht veröffentlichen, wird die Nachricht an abonnierte Kunden gesendet, es werden jedoch keine zusätzlichen Aktualisierungsnachrichten generiert.	Das Aktualisieren eines Geräts erzeugt ShadowNachrichten aktualisieren, die die Änderung beschreiben.
Nachrichtenaktualisierungen sind nummeriert	Archivierte Nachrichten werden nicht automatisch nummeriert.	Device Shadow-Dokumente haben automatische Versionsnummern und Zeitstempel.
Die Nachrichten-Payload ist an eine Dingressource angehängt	Archivierte Nachrichten werden nicht an eine Dingressource angehängt.	Geräteschatten sind an eine Dingressource angehängt.
Aktualisierung einzelner Elemente der Nachrichten-Payload	Einzelne Elemente der Nachricht können nicht geändert werden, ohne die gesamte Nachrichten-Payload zu aktualisieren.	Einzelne Elemente eines Device Shadow-Dokuments können aktualisiert werden, ohne dass das gesamte Device Shadow-Dokument aktualisiert werden muss.
Der Kunde erhält Nachrichtendaten nach dem Abonnement	Der Kunde erhält automatisch eine beibehaltene Nachricht, nachdem er ein Thema mit einer gespeicherten Nachricht abonniert hat.	Kunden können Device Shadow-Updates abonnieren, müssen jedoch bewusst den aktuellen Status abfragen.
Indexierung und Durchsuchbarkeit	Archivierte Nachrichten werden nicht für die Suche indexiert.	Fleet Indexing indexiert Device Shadow-Daten für die Suche und Aggregation.

MQTT-Nachrichten über den letzten Willen und das Testament (LWT)

Last Will and Testament (LWT) ist ein Feature in MQTT. Mit LWT können Clients eine Nachricht angeben, die der Broker zu einem vom Kunden definierten Thema veröffentlicht und an alle Clients sendet, die das Thema abonniert haben, wenn eine uninitiierte Verbindungsunterbrechung auftritt. Die von den Kunden angegebene Nachricht wird als LWT-Nachricht oder Willensmeldung bezeichnet, und das von den Kunden definierte Thema wird als Willensthema bezeichnet. Sie können eine LWT-Nachricht angeben, wenn ein Gerät eine Verbindung zum Broker herstellt. Diese Nachrichten können beibehalten werden, indem Sie dieWill RetainFlagge in derConnect Flag bitsFeld während der Verbindung. Zum Beispiel, wenn derWill RetainFlagge ist gesetzt auf1, eine Testamtsnachricht wird im Broker im zugehörigen Testamtsthema gespeichert. Weitere Informationen finden Sie unterWill Nachrichten.

Der Broker speichert die Willensmeldungen, bis eine uninitiierte Verbindungsunterbrechung eintritt. In diesem Fall veröffentlicht der Broker die Nachrichten an alle Kunden, die das Will Topic abonniert haben, um die Unterbrechung der Verbindung zu benachrichtigen. Wenn der Client die Verbindung zum Broker aufgrund einer vom Client initiierten Trennung mithilfe der MQTT DISCONNECT-Nachricht trennt, veröffentlicht der Broker die gespeicherten LWT-Nachrichten nicht. In allen anderen Fällen werden die LWT-Nachrichten versendet. Eine vollständige Liste der Trennungsszenarien, in denen der Broker die LWT-Nachrichten sendet, finden Sie unterEreignisse verbinden/trennen.

Connect-Attribute verwenden

ConnectAttributesermöglichen es Ihnen, in Ihren IAM-Richtlinien anzugeben, welche Attribute Sie in Ihrer Connect-Nachricht verwenden möchten, wie z. B.PersistentConnectundLastWill. MitConnectAttributeskönnen Sie Richtlinien erstellen, die Geräten standardmäßig keinen Zugriff auf neue Funktionen gewähren. Dies kann hilfreich sein, wenn ein Gerät kompromittiert wird.

connectAttributes unterstützt die folgenden Funktionen:

PersistentConnect

Benutze diePersistentConnectFunktion zum Speichern aller Abonnements, die der Kunde während der Verbindung abschließt, wenn die Verbindung zwischen dem Client und dem Broker unterbrochen wird.

LastWill

Benutze dieLastWillFunktion zum Veröffentlichen einer Nachricht auf derLastWillTopicwenn ein Client unerwartet die Verbindung trennt.

Standardmäßig hat Ihre Richtlinie eine nicht persistente Verbindung, und für diese Verbindung werden keine Attribute übergeben. Sie müssen in Ihrer IAM-Richtlinie eine persistente Verbindung angeben, wenn Sie eine haben möchten.

FürConnectAttributesBeispiele finden Sie unterBeispiele für Connect-Richtlinien.

Unterstützte Funktionen von MQTT 5

AWS IoT CoreDie Unterstützung für MQTT 5 basiert auf demMQTT v5.0-Spezifikationmit einigen Unterschieden, wie dokumentiert inAWS IoTUnterschiede zu den MQTT-Spezifikationen.

AWS IoT Coreunterstützt die folgenden MQTT 5-Funktionen:

• Geteilte Abonnements
• Clean Start und Ablauf der Sitzung
• Reason-Code auf allen ACKs
• Aliase für Themen
• Ablauf der Nachricht
• Weitere Funktionen von MQTT 5

Geteilte Abonnements

AWS IoT Coreunterstützt Shared Subscriptions für MQTT 3 und MQTT 5. Geteilte Abonnements ermöglichen es mehreren Kunden, sich ein Abonnement für ein Thema zu teilen, und nur ein Kunde erhält Nachrichten, die nach dem Zufallsprinzip zu diesem Thema veröffentlicht wurden. Shared Subscriptions können MQTT-Nachrichten effektiv auf mehrere Abonnenten verteilen. Angenommen, Sie haben 1.000 Geräte, die zum gleichen Thema veröffentlichen, und 10 Backend-Anwendungen, die diese Nachrichten verarbeiten. In diesem Fall können die Backend-Anwendungen dasselbe Thema abonnieren und jede würde nach dem Zufallsprinzip Nachrichten erhalten, die von den Geräten zum gemeinsamen Thema veröffentlicht wurden. Dadurch wird die Last dieser Nachrichten quasi „aufgeteilt“. Gemeinsame Abonnements ermöglichen auch eine bessere Stabilität. Wenn eine Backend-Anwendung die Verbindung trennt, verteilt der Broker die Last auf die verbleibenden Abonnenten in der Gruppe.

Um gemeinsame Abonnements zu nutzen, abonnieren Kunden ein gemeinsames AbonnementThemenfilterwie folgt:

$share/{ShareName}/{TopicFilter}

• $shareist eine wörtliche Zeichenfolge, die den Themenfilter eines gemeinsamen Abonnements angibt, der beginnen muss mit$share.

• {ShareName}ist eine Zeichenfolge, um den gemeinsamen Namen anzugeben, der von einer Gruppe von Abonnenten verwendet wird. Der Themenfilter eines gemeinsamen Abonnements muss eine enthaltenShareNameund gefolgt von der/Charakter. Der{ShareName}darf die folgenden Zeichen nicht enthalten:/,+, oder#. Die maximale Größe für{ShareName}ist 128 Byte.

• {TopicFilter}folgt dem gleichenThemenfilterSyntax als Abonnement ohne gemeinsame Nutzung. Die maximale Größe für{TopicFilter}ist 256 Byte.

• Die beiden erforderlichen Schrägstriche (/) für$share/{ShareName}/{TopicFilter}sind nicht enthalten in derMaximale Anzahl von Schrägstrichen in Thema und ThemenfilterGrenze.

Abonnements, die dasselbe haben{ShareName}/{TopicFilter}gehören derselben Shared Subscription-Gruppe an. Sie können mehrere Shared Abo-Gruppen erstellen und überschreiten dabei nicht dieLimit für geteilte Abonnements pro Gruppe. Weitere Informationen finden Sie unterAWS IoT CoreEndpunkte und Kontingenteaus demAWSAllgemeine Referenz.

In den folgenden Tabellen werden nicht gemeinsam genutzte Abonnements und gemeinsame Abonnements verglichen:

Abonnement	Beschreibung	Beispiele für Themenfilter
Abonnements ohne gemeinsame Nutzung	Jeder Kunde erstellt ein separates Abonnement, um die veröffentlichten Nachrichten zu erhalten. Wenn eine Nachricht zu einem Thema veröffentlicht wird, erhalten alle Abonnenten dieses Themas eine Kopie der Nachricht.	sports/tennis sports/#
Geteilte Abonnements	Mehrere Kunden können sich ein Abonnement für ein Thema teilen, und nur ein Kunde erhält Nachrichten, die zu diesem Thema nach dem Zufallsprinzip veröffentlicht wurden.	$share/consumer/sports/tennis $share/consumer/sports/#

Ablauf nicht gemeinsam genutzter Abonnements	Ablauf gemeinsam genutzter Abonnements

Wichtige Hinweise zur Verwendung von Shared Abos

• Wenn ein Veröffentlichungsversuch an einen QoS0-Abonnenten fehlschlägt, erfolgt kein Wiederholungsversuch und die Nachricht wird verworfen.

• Wenn ein Veröffentlichungsversuch an einen QoS1-Abonnenten mit einer sauberen Sitzung fehlschlägt, wird die Nachricht für mehrere Wiederholungsversuche an einen anderen Abonnenten in der Gruppe gesendet. Nachrichten, die nach all den Wiederholungsversuchen nicht zugestellt werden können, werden verworfen.

• Wenn ein Veröffentlichungsversuch an einen QoS1-Abonnenten mitpersistente Sitzungenschlägt fehl, weil der Abonnent offline ist. Die Nachrichten werden nicht in die Warteschlange gestellt und an einen anderen Abonnenten in der Gruppe weitergeleitet. Nachrichten, die nach all den Wiederholungsversuchen nicht zugestellt werden können, werden verworfen.

• Geteilte Abonnements werden nicht empfangengespeicherte Nachrichten.

• Wenn gemeinsame Abonnements Platzhalterzeichen (# oder +) enthalten, gibt es möglicherweise mehrere übereinstimmende gemeinsame Abonnements zu einem Thema. In diesem Fall kopiert der Nachrichtenbroker die Veröffentlichungsnachricht und sendet sie an einen zufälligen Client in jedem passenden Shared Subscription. Das Wildcard-Verhalten von Shared Subscriptions kann in der folgenden Abbildung erklärt werden.

  

  In diesem Beispiel gibt es drei passende Shared Subscriptions zum Veröffentlichungsthema MQTTsports/tennis. Der Nachrichtenbroker kopiert die veröffentlichte Nachricht und sendet die Nachricht an einen zufälligen Client in jeder passenden Gruppe.

  Kunde 1 und Kunde 2 teilen sich das Abonnement:$share/consumer1/sports/tennis

  Kunde 3 und Kunde 4 teilen sich das Abonnement:$share/consumer1/sports/#

  Kunde 5 und Kunde 6 teilen sich das Abonnement:$share/consumer2/sports/tennis

Weitere Informationen zu den Limits für gemeinsame Abonnements finden Sie unterAWS IoT CoreEndpunkte und Kontingenteaus demAWSAllgemeine Referenz. Um Shared Abos mit dem zu testenAWS IoTMQTT-Client imAWS IoTKonsole, sieheTesten von Shared Subscriptions im MQTT-Client. Weitere Informationen zu gemeinsamen Abonnements finden Sie unterGeteilte Abonnementsaus der MQTTv5.0-Spezifikation.

Clean Start und Ablauf der Sitzung

Sie können Clean Start und Session Expiration verwenden, um Ihre dauerhaften Sitzungen flexibler zu handhaben. Ein Clean Start-Flag gibt an, ob die Sitzung gestartet werden soll, ohne eine bestehende Sitzung zu verwenden. Ein Sitzungsablaufintervall gibt an, wie lange die Sitzung nach einer Unterbrechung beibehalten werden soll. Das Ablaufintervall der Sitzung kann bei Unterbrechung der Sitzung geändert werden. Weitere Informationen finden Sie unter Persistente MQTT-Sitzungen.

Reason-Code auf allen ACKs

Mithilfe der Ursachencodes können Sie Fehlermeldungen einfacher debuggen oder verarbeiten. Die Ursachencodes werden vom Nachrichtenbroker basierend auf der Art der Interaktion mit dem Broker (Abonnieren, Veröffentlichen, Bestätigen) zurückgegeben. Weitere Informationen finden Sie unterMQTT-Ursachencodes. Eine vollständige Liste der MQTT-Ursachencodes finden Sie unterMQTT v5-Spezifikation.

Aliase für Themen

Sie können einen Themennamen durch einen Themenalias ersetzen, der eine Zwei-Byte-Ganzzahl ist. Durch die Verwendung von Themenaliasen kann die Übertragung von Themennamen optimiert werden, um die Datenkosten für kostenpflichtige Datendienste potenziell zu senken.AWS IoT Corehat ein Standardlimit von 8 Themenaliasen. Weitere Informationen finden Sie unterAWS IoT CoreEndpunkte und Kontingenteaus demAWSAllgemeine Referenz.

Ablauf der Nachricht

Sie können veröffentlichten Nachrichten Gültigkeitswerte für Nachrichten hinzufügen. Diese Werte geben das Gültigkeitsintervall der Nachricht in Sekunden an. Wenn die Nachrichten innerhalb dieses Intervalls nicht an die Abonnenten gesendet wurden, läuft die Nachricht ab und wird entfernt. Wenn Sie den Gültigkeitswert für die Nachricht nicht festlegen, läuft die Nachricht nicht ab.

Bei ausgehender Verbindung erhält der Abonnent eine Nachricht mit der verbleibenden Zeit im Ablaufintervall. Wenn beispielsweise eine eingehende Veröffentlichungsnachricht einen Nachrichtenablauf von 30 Sekunden hat und sie nach 20 Sekunden an den Abonnenten weitergeleitet wird, wird das Feld für den Nachrichtenablauf auf 10 aktualisiert. Es ist möglich, dass die vom Abonnenten empfangene Nachricht einen aktualisierten MEI von 0 hat. Dies liegt daran, dass die verbleibende Zeit 999 ms oder weniger beträgt, auf 0 aktualisiert wird.

InAWS IoT Core, das Mindestablaufintervall für Nachrichten ist 1. Wenn das Intervall von der Clientseite auf 0 gesetzt ist, wird es auf 1 angepasst. Das maximale Nachrichtenablaufintervall beträgt 604800 (7 Tage). Alle Werte, die höher sind, werden auf den Maximalwert angepasst.

Bei der versionsübergreifenden Kommunikation wird das Verhalten des Nachrichtenablaufs von der MQTT-Version der eingehenden Veröffentlichungsnachricht bestimmt. Beispielsweise kann eine Nachricht mit Nachrichtenablauf, die von einer über MQTT5 verbundenen Sitzung gesendet wurde, für Geräte ablaufen, die MQTT3-Sitzungen abonniert haben. In der folgenden Tabelle wird aufgeführt, wie der Ablauf von Nachrichten die folgenden Arten von Veröffentlichungsnachrichten unterstützt:

Nachrichtentyp veröffentlichen	Ablaufintervall für Nachrichten
Regelmäßig veröffentlichen	Wenn ein Server die Nachricht nicht innerhalb der angegebenen Zeit zustellt, wird die abgelaufene Nachricht entfernt und der Abonnent erhält sie nicht. Dies schließt Situationen ein, z. B. wenn ein Gerät seine QoS 1-Nachrichten nicht veröffentlicht.
Beibehalten	Wenn eine gespeicherte Nachricht abläuft und ein neuer Kunde das Thema abonniert, erhält der Kunde die Nachricht nach dem Abonnement nicht.
Letzter Wille	Das Intervall für Last-Will-Nachrichten beginnt, nachdem der Client die Verbindung getrennt hat und der Server versucht, die letzte Willensnachricht an seine Abonnenten zu übermitteln.
Nachrichten in der Warteschlange	Wenn ein ausgehender QoS1 mit Nachrichtenablaufintervall abläuft, wenn ein Client offline ist, nach dempersistente Sitzungfährt fort, der Client erhält die abgelaufene Nachricht nicht.

Weitere Funktionen von MQTT 5

Verbindung zum Server trennen

Wenn eine Verbindung unterbrochen wird, kann der Server dem Client proaktiv eine DISCONNECT-Meldung senden, um das Schließen der Verbindung mit einem Grundcode für die Trennung zu benachrichtigen.

Anfrage/Antwort

Verlage können beim Empfang eine Antwort des Empfängers zu einem vom Verlag angegebenen Thema anfordern.

Maximale Paketgröße

Client und Server können unabhängig voneinander die maximale Paketgröße angeben, die sie unterstützen.

Payloadformat und Inhaltstyp

Sie können das Payload-Format (Binär, Text) und den Inhaltstyp angeben, wenn eine Nachricht veröffentlicht wird. Diese werden an den Empfänger der Nachricht weitergeleitet.

MQTT 5 Eigenschaften

MQTT 5-Eigenschaften sind wichtige Ergänzungen zum MQTT-Standard, um neue MQTT 5-Funktionen wie den Sitzungsablauf und das Anforderungs-/Antwortmuster zu unterstützen. InAWS IoT Core, du kannst erstellenRegelndas kann die Eigenschaften in ausgehenden Nachrichten weiterleiten oder verwendenHTTP-Veröffentlichungum MQTT-Nachrichten mit einigen der neuen Eigenschaften zu veröffentlichen.

In der folgenden Tabelle sind alle MQTT 5-Eigenschaften aufgeführt, dieAWS IoT Coreunterstützt.

Property (Eigenschaft)	Description (Beschreibung)	Input type	Paket
Anzeige des Payload-Formats	Ein boolescher Wert, der angibt, ob die Payload als UTF-8 formatiert ist.	Byte	VERÖFFENTLICHEN, VERBINDEN
Inhaltstyp	Eine UTF-8-Zeichenfolge, die den Inhalt der Payload beschreibt.	UTF-8-Zeichenfolge	VERÖFFENTLICHEN, VERBINDEN
Thema der Antwort	Eine UTF-8-Zeichenfolge, die das Thema beschreibt, unter dem der Empfänger im Rahmen des Anforderungs-Response-Flows veröffentlichen soll. Das Thema darf keine Platzhalterzeichen enthalten.	UTF-8-Zeichenfolge	VERÖFFENTLICHEN, VERBINDEN
Korrelationsdaten	Binärdaten, die vom Absender der Anforderungsnachricht verwendet werden, um zu identifizieren, für welche Anfrage die Antwortnachricht bestimmt ist.	Binary	VERÖFFENTLICHEN, VERBINDEN
Eigentum des Benutzers	Ein UTF-8-Zeichenkettenpaar. Diese Eigenschaft kann mehrfach in einem Paket vorkommen. Empfänger erhalten die Schlüssel-Wert-Paare in derselben Reihenfolge, in der sie gesendet wurden.	UTF-8-Zeichenkettenpaar	VERBINDEN, VERÖFFENTLICHEN, Will Properties, ABONNIEREN, TRENNEN, ABMELDEN
Ablaufintervall für Nachrichten	Eine 4-Byte-Ganzzahl, die das Gültigkeitsintervall der Nachricht in Sekunden darstellt. Wenn sie nicht vorhanden ist, läuft die Nachricht nicht ab.	4-Byte-Ganzzahl	VERÖFFENTLICHEN, VERBINDEN
Ablaufintervall der Sitzung	Eine 4-Byte-Ganzzahl, die das Sitzungsablaufintervall in Sekunden darstellt.AWS IoT Coreunterstützt maximal 7 Tage, mit einem Standardmaximum von einer Stunde. Wenn der von Ihnen eingestellte Wert das Maximum Ihres Kontos überschreitet,AWS IoT Coregibt den angepassten Wert im CONNACK zurück.	4-Byte-Ganzzahl	VERBINDEN, VERBINDEN, TRENNEN
Zugewiesene Client-ID	Eine zufällige Client-ID, generiert vonAWS IoT Corewenn eine Client-ID nicht von Geräten angegeben ist. Die zufällige Client-ID muss eine neue Client-ID sein, die von keiner anderen Sitzung verwendet wird, die derzeit vom Broker verwaltet wird.	UTF-8-Zeichenfolge	CONNACK
Server Keep Alive	Eine 2-Byte-Ganzzahl, die die vom Server zugewiesene Keep-Alive-Zeit darstellt. Der Server trennt die Verbindung zum Client, wenn der Client länger als die Keep-Alive-Zeit inaktiv ist.	2-Byte-Ganzzahl	CONNACK
Probleminformationen anfordern	Ein boolescher Wert, der angibt, ob die Reason-Zeichenfolge oder die Benutzereigenschaften bei Fehlern gesendet werden.	Byte	CONNECT
Maximales Empfangen	Eine 2-Byte-Ganzzahl, die die maximale Anzahl von PUBLISH QOS > 0 Paketen darstellt, die gesendet werden können, ohne ein PUBACK zu empfangen.	2-Byte-Ganzzahl	VERBINDEN, VERBINDEN
Thema Alias Maximum	Dieser Wert gibt den höchsten Wert an, der als Topic-Alias akzeptiert wird. Standard = 0.	2-Byte-Ganzzahl	VERBINDEN, VERBINDEN
Maximales QoS	Der maximale Wert von QoS, derAWS IoT Coreunterstützt. Die Standardeinstellung ist 1.AWS IoT Coreunterstützt QoS2 nicht.	Byte	CONNACK
Beibehalten verfügbar	Ein boolescher Wert, der angibt, obAWS IoT CoreMessage Broker unterstützt gespeicherte Nachrichten. Der Standardwert ist 1.	Byte	CONNACK
Maximale Paketgröße	Die maximale Paketgröße, dieAWS IoT Coreakzeptiert und sendet. 128 KB dürfen nicht überschritten werden.	4-Byte-Ganzzahl	VERBINDEN, VERBINDEN
Wildcard-Abonnement verfügbar	Ein boolescher Wert, der angibt, obAWS IoT CoreMessage Broker unterstützt Wildcard-Abonnement verfügbar. Der Standardwert ist 1.	Byte	CONNACK
Abonnement-ID verfügbar	Ein boolescher Wert, der angibt, obAWS IoT CoreMessage Broker unterstützt Abonnement-ID verfügbar. Der Standardwert ist 0.	Byte	CONNACK

MQTT-Ursachencodes

MQTT 5 führt eine verbesserte Fehlerberichterstattung mit Antworten auf den Ursachencode ein.AWS IoT Corekann Ursachencodes zurückgeben, einschließlich, aber nicht beschränkt auf die folgenden, nach Paketen gruppiert. Eine vollständige Liste der von MQTT 5 unterstützten Ursachencodes finden Sie unterMQTT 5-Spezifikationen.

CONNACK Ursachencodes
Wert	Sechskant	Codename des Grundes	Beschreibung
0	0x00	Herzlichen Glückwunsch	Die Verbindung wird akzeptiert.
128	0 x 80	Unspezifizierter Fehler	Der Server möchte den Grund für den Fehler nicht preisgeben, oder es trifft keiner der anderen Ursachencodes zu.
133	0x85	Client-ID ist nicht gültig	Die Client-ID ist eine gültige Zeichenfolge, wird aber vom Server nicht zugelassen.
134	0x86	Falscher Benutzername oder falsches Passwort	Der Server akzeptiert den vom Client angegebenen Benutzernamen oder das Passwort nicht.
135	0x87	Nicht autorisiert	Der Client ist nicht autorisiert, eine Verbindung herzustellen.
144	0x90	Themenname ungültig	Der Name des Testaments ist korrekt formatiert, wird aber vom Server nicht akzeptiert.
151	0x97	Kontingent überschritten	Eine umsetzungs- oder administrativ festgelegte Obergrenze wurde überschritten.
155	0x9B	QoS wird nicht unterstützt	Der Server unterstützt die in Will QoS eingestellte QoS nicht.

PUBACK-Ursachencodes
Wert	Sechskant	Codename des Grundes	Beschreibung
0	0x00	Herzlichen Glückwunsch	Die Nachricht wird akzeptiert. Die Veröffentlichung der QoS 1-Nachricht wird fortgesetzt.
128	0 x 80	Unspezifizierter Fehler	Der Empfänger akzeptiert die Veröffentlichung nicht, möchte aber entweder den Grund nicht preisgeben oder er stimmt nicht mit einem der anderen Werte überein.
135	0x87	Nicht autorisiert	Das VERÖFFENTLICHEN ist nicht autorisiert.
144	0x90	Themenname ungültig	Der Themenname ist nicht falsch formatiert, wird aber vom Client oder Server nicht akzeptiert.
145	0x91	Verwendete Paket-ID	Die Paket-ID wird bereits verwendet. Dies kann auf eine Diskrepanz im Sitzungsstatus zwischen Client und Server hindeuten.
151	0x97	Kontingent überschritten	Eine umsetzungs- oder administrativ festgelegte Obergrenze wurde überschritten.

Abschalten der Ursachencodes
Wert	Sechskant	Codename des Grundes	Beschreibung
129	0x81	Falsch formatiertes Paket	Das empfangene Paket entspricht nicht dieser Spezifikation.
130	0x82	Protokollfehler	Ein unerwartetes oder defektes Paket wurde empfangen.
135	0x87	Nicht autorisiert	Die Anfrage ist nicht autorisiert.
139	0x8B	Server wird heruntergefahren	Der Server wird heruntergefahren.
141	0x8D	Auszeit „Keep Alive“	Die Verbindung ist geschlossen, da seit dem 1,5-fachen der Keep-Alive-Zeit kein Paket empfangen wurde.
142	0x8E	Sitzung übernommen	Eine andere Verbindung, die dieselbe Client-ID verwendet, hat eine Verbindung hergestellt, wodurch diese Verbindung geschlossen wurde.
143	0x8F	Themenfilter ungültig	Der Themenfilter ist korrekt aufgebaut, wird aber vom Server nicht akzeptiert.
144	0x90	Themenname ungültig	Der Themenname ist korrekt formatiert, wird aber von diesem Client oder Server nicht akzeptiert.
147	0x93	Empfangsmaximum überschritten	Der Client oder Server hat mehr als die maximale Anzahl an empfangenen Veröffentlichungen empfangen, für die er weder PUBACK noch PUBCOMP gesendet hat.
148	0x94	Themen-Alias ungültig	Der Client oder Server hat ein PUBLISH-Paket erhalten, das einen Topic-Alias enthält, der größer ist als der maximale Topic-Alias, den er im CONNECT- oder CONNACK-Paket gesendet hat.
151	0x97	Kontingent überschritten	Eine umsetzungs- oder administrativ festgelegte Obergrenze wurde überschritten.
152	0x98	Administrative Maßnahme	Die Verbindung wurde aufgrund einer Verwaltungsmaßnahme geschlossen.
155	0x9B	QoS wird nicht unterstützt	Der Client hat eine QoS angegeben, die höher ist als die unter Maximaler QoS im CONNACK angegebene QoS.
161	0xA1	Abonnement-IDs werden nicht unterstützt	Der Server unterstützt keine Abonnement-IDs; das Abonnement wird nicht akzeptiert.

SUBACK-Ursachencodes
Wert	Sechskant	Codename des Grundes	Beschreibung
0	0x00	QoS 0 gewährt	Das Abonnement wird akzeptiert und die maximale gesendete QoS beträgt QoS 0. Dies könnte ein niedrigerer QoS sein als angefordert.
1	0x01	QoS 1 gewährt	Das Abonnement wird akzeptiert und die maximale gesendete QoS beträgt QoS 1. Dies könnte ein niedrigerer QoS sein als angefordert.
128	0 x 80	Unspezifizierter Fehler	Das Abonnement wird nicht akzeptiert und der Server möchte den Grund entweder nicht preisgeben oder es gilt keiner der anderen Ursachencodes.
135	0x87	Nicht autorisiert	Der Kunde ist nicht berechtigt, dieses Abonnement abzuschließen.
143	0x8F	Themenfilter ungültig	Der Themenfilter ist korrekt erstellt, aber für diesen Client nicht zulässig.
145	0x91	Paket-Identifier wird verwendet	Der angegebene Packet Identifier wird bereits verwendet.
151	0x97	Kontingent überschritten	Eine umsetzungs- oder administrativ festgelegte Obergrenze wurde überschritten.

UNSUBACK-Ursachencodes
Wert	Sechskant	Codename des Grundes	Beschreibung
0	0x00	Herzlichen Glückwunsch	Das Abonnement wird gelöscht.
128	0 x 80	Unspezifizierter Fehler	Die Abmeldung konnte nicht abgeschlossen werden und der Server möchte den Grund entweder nicht preisgeben oder es gilt keiner der anderen Ursachencodes.
143	0x8F	Themenfilter ungültig	Der Themenfilter ist korrekt erstellt, aber für diesen Client nicht zulässig.
145	0x91	Paket-Identifier wird verwendet	Der angegebene Packet Identifier wird bereits verwendet.

AWS IoTUnterschiede zu den MQTT-Spezifikationen

Die Message-Broker-Implementierung basiert auf demMQTT v3.1.1-Spezifikationund derMQTT v5.0-Spezifikation, unterscheidet sich jedoch auf folgende Weise von den Spezifikationen:

• AWS IoTunterstützt die folgenden Pakete für MQTT 3 nicht: PUBREC, PUBREL und PUBCOMP.

• AWS IoTunterstützt die folgenden Pakete für MQTT 5 nicht: PUBREC, PUBREL, PUBCOMP und AUTH.

• AWS IoTunterstützt keine MQTT 5-Serverumleitung.

• AWS IoTunterstützt nur die MQTT-Qualitätsstufen 0 und 1.AWS IoTunterstützt das Veröffentlichen oder Abonnieren mit QoS Level 2 nicht. Wenn QoS Level 2 angefordert wird, sendet der Message Broker kein PUBACK oder SUBACK.

• Wenn Sie in AWS IoT ein Thema mit QoS-Level 0 abonnieren, bedeutet dies, dass eine Nachricht gar nicht oder öfter übertragen wird. Nachrichten können mehr als einmal übertragen werden. Nachrichten, die mehrmals übertragen werden, können mit unterschiedlicher Paket-ID gesendet werden. In diesem Fall wird das DUP-Flag nicht festgelegt.

• Der Message Broker sendet als Antwort auf eine Verbindungsanfrage eine CONNACK-Nachricht. Diese enthält ein Flag, das angibt, ob eine frühere Sitzung wieder aufgenommen wird.

• Vor dem Senden zusätzlicher Steuerpakete oder einer Trennanforderung muss der Client warten, bis die CONNACK-Nachricht auf seinem Gerät von derAWS IoTNachrichtenbroker.

• Wenn ein Client ein Thema abonniert, kann es zwischen dem Zeitpunkt, an dem der Message Broker eine SUBACK-Nachricht sendet, und den ersten eingehenden passenden Nachrichten eine Verzögerung geben.

• Wenn ein Client das Platzhalterzeichen verwendet#im Themenfilter, um ein Thema zu abonnieren, werden alle Zeichenketten auf und unter seiner Ebene in der Themenhierarchie abgeglichen. Das übergeordnete Thema passt jedoch nicht. Zum Beispiel ein Abonnement für das Themasensor/#erhält zu den Themen veröffentlichte Nachrichtensensor/,sensor/temperature,sensor/temperature/room1, aber keine Nachrichten, die auf veröffentlicht wurdensensor. Weitere Hinweise zu Platzhaltern finden Sie unterThemenfilter.

• Der Message Broker verwendet die Client-ID, um die einzelnen Clients zu identifizieren. Die Client-ID wird vom Client im Rahmen der MQTT-Nutzlast an den Message Broker übermittelt. Zwei Clients mit derselben Client-ID können nicht gleichzeitig mit dem Message Broker verbunden werden. Wenn ein Client über eine Client-ID eine Verbindung zum Message Broker herstellt, die bereits von einem anderen Client verwendet wird, wird die neue Client-Verbindung akzeptiert und der zuvor verbundene Client getrennt.

• In seltenen Fällen kann es vorkommen, dass der Message Broker dieselbe logische PUBLISH-Nachricht mit einer unterschiedlichen Paket-ID erneut sendet.

• Wenn Sie Themenfilter abonnieren, die ein Platzhalterzeichen enthalten, können keine gespeicherten Nachrichten empfangen werden. Um eine beibehaltene Nachricht zu erhalten, muss die Abonnementanfrage einen Themenfilter enthalten, der genau dem Thema der beibehaltenen Nachricht entspricht.

• Der Nachrichtenbroker garantiert nicht die Reihenfolge, in der Nachrichten und ACK empfangen werden.

• AWS IoTkann Grenzwerte haben, die von den Spezifikationen abweichen. Weitere Informationen finden Sie unterAWS IoT CoreGrenzwerte und Kontingente für Nachrichtenbroker und Protokolleaus demAWS IoTReferenzhandbuch.