Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
MQTT
AWS IoT Core unterstützt Geräteverbindungen, die das MQTT-Protokoll und das MQTT-over-WSS-Protokoll verwenden und die durch eine Client-ID identifiziert werden. AWS IoT Gerät SDKs unterstützen beide Protokolle und sind die empfohlenen Verbindungsmethoden für Geräte zu AWS IoT Core Das AWS IoT Gerät SDKs unterstützt die Funktionen, die Geräte und Clients benötigen, um sich mit Diensten zu verbinden und auf sie zuzugreifen AWS IoT . Das Gerät SDKs unterstützt die Authentifizierungsprotokolle, die für die AWS IoT Dienste erforderlich sind, und die Verbindungs-ID-Anforderungen, die für das MQTT-Protokoll und die Protokolle MQTT over WSS erforderlich sind. Informationen darüber, wie Sie AWS IoT mithilfe des AWS Geräts eine Verbindung herstellen können, SDKs sowie Links zu Beispielen AWS IoT in den unterstützten Sprachen finden Sie unter. Über das Gerät eine Verbindung mit MQTT herstellen AWS IoT SDKs Weitere Informationen zu Authentifizierung und Portzuordnungen für MQTT-Meldungen unter Protokolle, Port-Zuweisungen und Authentifizierung.
Wir empfehlen zwar, das AWS IoT Gerät SDKs für die Verbindung zu verwenden AWS IoT, sie sind jedoch nicht erforderlich. Wenn Sie das AWS IoT Gerät jedoch nicht verwenden SDKs, müssen Sie für die erforderliche Verbindungs- und Kommunikationssicherheit sorgen. Clients müssen auch die Server Name Indication (SNI)-TLS-Erweiterung
In diesem Thema:
Über das Gerät eine Verbindung mit MQTT herstellen AWS IoT SDKs
Dieser Abschnitt enthält Links zum AWS IoT Gerät SDKs und zum Quellcode von Beispielprogrammen, die veranschaulichen, wie ein Gerät angeschlossen AWS IoT wird. Die hier verlinkten Beispiel-Apps zeigen, wie Sie AWS IoT mithilfe des MQTT-Protokolls und MQTT über WSS eine Verbindung herstellen können.
Anmerkung
Das AWS IoT Gerät SDKs hat einen MQTT 5-Client veröffentlicht.
Verwenden des AWS IoT C++-Geräte-SDK zum Verbinden von Geräten
MQTT QoS-(Quality of Service)-Optionen
AWS IoT und das AWS IoT Gerät SDKs unterstützt die MQTT-Qualitätsstufen 0 (QoS)1 Das MQTT-Protokoll definiert eine dritte Ebene von QoS, Ebene2, unterstützt AWS IoT diese jedoch nicht. Nur das MQTT-Protokoll unterstützt die QoS-Funktion. HTTPS unterstützt QoS, indem es einen Abfragezeichenfolge-Parameter ?qos=qos übergibt, sein Wert kann 0 oder 1 sein.
Die Tabelle beschreibt, wie sich jede QoS-Stufe auf Meldungen auswirkt, die an und von Message Broker veröffentlicht werden.
|
Mit einem QoS-Level von ... |
Die Meldung ist … |
Kommentare |
|---|---|---|
|
QoS Stufe 0 |
Null oder mehr Mal gesendet |
Diese Stufe sollte für Meldungen 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 eine |
Die Meldung gilt erst dann als vollständig, wenn der Absender eine |
Persistente MQTT-Sitzungen
Persistente Sitzungen speichern Abonnements und Meldungen eines Kunden mit einer Quality of Service (QoS) von 1, sofern diese nicht vom Kunden bestätigt wurden. Wenn das Gerät wieder eine Verbindung zu einer dauerhaften Sitzung herstellt, wird die Sitzung wieder aufgenommen, Abonnements werden wieder hergestellt und unbestätigte abonnierte Meldungen, die vor der Wiederverbindung empfangen und gespeichert wurden, werden an den Client gesendet.
Die Verarbeitung der gespeicherten Nachrichten wird in CloudWatch Logs aufgezeichnet. CloudWatch Informationen zu den in Logs geschriebenen Einträgen CloudWatch und CloudWatch Logs finden Sie unter Message Broker-Metriken undProtokolleintrag in der Warteschlange.
Erstellen einer persistenten Sitzung
Erstellen Sie in MQTT 3 eine persistente MQTT-Sitzung, indem Sie eine CONNECTMeldung versenden und das cleanSession Flag auf 0 festlegen. Wenn für den Client, der die CONNECT-Meldung versendet, keine Sitzung vorhanden ist, wird eine neue persistente Sitzung 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 eine CONNECT Meldung und setzen das cleanSession Flag auf 1. Der Broker speichert dann keinen Sitzungsstatus, wenn der Client die Verbindung trennt.
In MQTT 5 behandeln Sie persistente Sitzungen, indem Sie das Clean Start Flag und Session Expiry Interval festlegen. Clean Start steuert den Beginn der Verbindungssitzung und das Ende der vorherigen Sitzung. Wenn Sie Clean
Start = 1 setzen, wird eine neue Sitzung erstellt und eine vorherige Sitzung wird beendet, falls sie existiert. Wenn Sie Clean Start = 0 setzen, nimmt die Verbindungssitzung eine vorherige Sitzung wieder auf, falls sie existiert. Das Sitzungsablaufintervall bestimmt das Ende der Verbindungssitzung. Das Sitzungsablaufintervall gibt die Zeit in Sekunden (4-Byte-Ganzzahl) an, für die eine Sitzung nach der Trennung bestehen bleibt. Einstellung Session Expiry interval = 0 bewirkt, dass die Sitzung sofort nach der Trennung beendet wird. Wenn das Sitzungsablaufintervall nicht in der CONNECT-Meldung angegeben ist, ist der Standardwert 0.
| Eigenschaftenwert | Beschreibung |
|---|---|
Clean Start= 1 |
Erzeugt eine neue Sitzung und beendet eine vorherige Sitzung, falls eine existiert. |
Clean Start= 0 |
Nimmt eine Sitzung wieder auf, falls eine vorherige Sitzung existiert. |
Session Expiry Interval> 0 |
Hält eine Sitzung aufrecht. |
Session Expiry interval= 0 |
Behält eine Sitzung nicht bei. |
Wenn Sie in MQTT 5 Clean Start = 1 und Session
Expiry Interval = 0 setzen, entspricht dies einer sauberen MQTT-3-Sitzung. Wenn Sie Clean Start = 0 und Session Expiry Interval >0 setzen, entspricht dies einer persistenten MQTT-3-Sitzung.
Anmerkung
MQTT-übergreifende (MQTT 3 und MQTT 5) persistente Sitzungen 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
Clients müssen das sessionPresent-Attribut in der Connection Acknowledged (CONNACK)-Meldung nutzen, um festzustellen, ob eine persistente Sitzung vorhanden ist. Wenn sessionPresent auf 1 gesetzt ist, liegt eine persistente Sitzung vor und alle gespeicherten Meldungen für den Client werden an den Client zugestellt, nachdem der Client CONNACK empfangen hat, wie unter Meldungsverkehr nach Wiederverbindung mit einer persistenten Sitzung beschrieben. Wenn sessionPresent auf 1 gesetzt ist, muss der Client kein erneutes Abonnement abschließen. Wenn sessionPresent auf 0 gesetzt ist, ist keine persistente Sitzung vorhanden, und der Client muss die Themenfilter erneut abonnieren.
Nachdem der Client der persistenten Sitzung beigetreten ist, kann er weiterhin Meldungen veröffentlichen und Themenfilter ohne zusätzliche Flags für jede Maßnahme abonnieren.
Meldungsverkehr nach Wiederverbindung zu einer persistenten Sitzung
Eine persistente Sitzung stellt eine fortlaufende Verbindung zwischen einem Client und einem MQTT-Message Broker dar. Wenn ein Client eine Verbindung mit dem Message Broker über eine persistente Sitzung herstellt, speichert der Message Broker alle Abonnements, die der Client während der Verbindung erstellt. Wenn der Client getrennt wird, speichert der Message Broker unbestätigte QoS 1-Meldungen und neue QoS 1-Meldungen, die zu Themen veröffentlicht wurden, die der Client abonniert hat. Meldungen werden gemäß dem Kontolimit gespeichert. Meldungen, die das Limit überschreiten werden gelöscht. Weitere Informationen zu persistenten Nachrichtenlimits finden Sie unter AWS IoT Core Endpunkte und Kontingente. Wenn der Client die Verbindung zur persistenten Sitzung wiederherstellt, werden alle Abonnements reaktiviert und alle gespeicherten Meldungen werden bei einer maximalen Rate von 10 Meldungen pro Sekunde an den Client gesendet. Wenn in MQTT 5 eine ausgehende QoS1-Verbindung mit dem Meldungsablaufintervall abläuft, während ein Client offline ist, empfängt der Client nach der Wiederaufnahme der Verbindung die abgelaufene Meldung nicht.
Nach der Wiederverbindung werden die gespeicherten Meldungen an den Client gesendet, und zwar mit einer Geschwindigkeit, die auf 10 gespeicherte Meldungen pro Sekunde begrenzt ist, zusammen mit dem aktuellen Meldungsverkehr, bis das Publish
requests per second per connection-Limit erreicht ist. Da die Zustellungsrate der gespeicherten Meldungen begrenzt ist, dauert es mehrere Sekunden, bis alle gespeicherten Meldungen zugestellt werden, wenn in einer Sitzung nach der Wiederverbindung mehr als 10 gespeicherte Meldungen zugestellt werden müssen.
Eine persistente Sitzung wird beendet.
Dauerhafte Sitzungen können wie folgt 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 das Timeout überschritten hat.
-
Der Client sendet eine
CONNECTNachricht, die dascleanSessionFlag auf1setzt.
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 in den Paketen CONNECT und DISCONNECT 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 einen Wert über 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 auf DISCONNECT beendet.
-
Andernfalls aktualisiert das Sitzungsablaufintervall für das DISCONNECT-Paket das Sitzungsablaufintervall der aktuellen Sitzung.
Anmerkung
Die gespeicherten Meldungen, die darauf warten, am Ende einer Sitzung an den Client gesendet zu werden, werden verworfen. Sie werden jedoch weiterhin zum Standardnachrichtentarif in Rechnung gestellt, obwohl sie nicht gesendet werden konnten. Weitere Informationen zu Preisen erhalten Sie unter AWS IoT Core
Preise
Wiederverbindung nach Ablauf einer persistenten Sitzung
Wenn ein Client vor Ablauf nicht wieder eine Verbindung zu seiner persistenten Sitzung herstellt, wird die Sitzung beendet und die gespeicherten Meldungen werden verworfen. Wenn ein Client nach Ablauf der Sitzung wieder eine Verbindung herstellt und das cleanSession-Flag auf 0 setzt, erstellt der Dienst eine neue persistente Sitzung. Alle Abonnements oder Meldungen aus der vorherigen Sitzung sind für diese Sitzung nicht verfügbar, da sie beim Ablauf der vorherigen Sitzung verworfen wurden.
Gebühren für Meldungen während einer dauerhaften Sitzung
Nachrichten werden Ihnen in Rechnung gestellt, AWS-Konto wenn der Message Broker eine Nachricht an einen Client oder eine persistente Offline-Sitzung sendet. Wenn ein Offline-Gerät mit einer dauerhaften Sitzung erneut eine Verbindung herstellt und seine Sitzung wieder aufnimmt, werden die gespeicherten Meldungen an das Gerät übermittelt und Ihrem Konto erneut belastet. Weitere Informationen zu den Preisen für Meldungen finden Sie unter AWS IoT Core Preise – Meldungsübermittlung
Die standardmäßige Ablaufzeit einer persistenten Sitzung von einer Stunde kann erhöht werden, indem das standardmäßige Verfahren zum Erhöhen von Limits verwendet wird. Beachten Sie, dass durch eine Verlängerung der Sitzungsablaufzeit Ihre Meldungsgebühren steigen können, da durch die zusätzliche Zeit mehr Meldungen für das Offline-Gerät gespeichert werden können und diese zusätzlichen Meldungen Ihrem Konto zum Standardnachrichtentarif in Rechnung gestellt würden. Bei der Ablaufzeit der Sitzung handelt es sich um einen ungefähren Wert, und eine Sitzung kann bis zu 30 Minuten länger als das Kontolimit andauern. Eine Sitzung darf das Kontolimit jedoch nicht unterschreiten. Weitere Informationen zu Sitzungslimits finden Sie unter AWS -Service Quotas.
Beibehaltene MQTT-Meldungen
AWS IoT Core unterstützt das im MQTT-Protokoll beschriebene RETAIN-Flag. Wenn ein Client das RETAIN-Flag für eine von ihm veröffentlichte MQTT-Nachricht setzt, wird die Nachricht AWS IoT Core gespeichert. Sie kann dann an neue Abonnenten gesendet, durch Aufrufen des GetRetainedMessageVorgangs abgerufen und in der AWS IoT Konsole
Beispiele für die Verwendung von gespeicherten MQTT-Meldungen
-
Als erste Konfigurationsnachricht
In MQTT gespeicherte Meldungen werden an einen Client gesendet, nachdem der Client ein Thema abonniert hat. Wenn Sie möchten, dass alle Clients, die ein Thema abonnieren, die beibehaltene MQTT-Nachricht direkt 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, wenn eine neue Konfigurationsnachricht veröffentlicht wird.
-
Als letzte bekannte Zustandsmeldung
Geräte können das RETAIN-Flag für Meldungen mit aktuellem Status setzen, sodass AWS IoT Core sie speichern werden. Wenn Anwendungen eine Verbindung herstellen oder erneut eine Verbindung herstellen, können sie dieses Thema abonnieren und den zuletzt gemeldeten Status direkt nach dem Abonnieren des beibehaltenen Nachrichtenthemas abrufen. Auf diese Weise können sie vermeiden, dass sie bis zur nächsten Meldung vom Gerät warten müssen, um den aktuellen Status zu sehen.
In diesem Abschnitt:
Häufige Aufgaben mit MQTT-Aufbewahrungsnachrichten in AWS IoT Core
AWS IoT Core speichert MQTT-Nachrichten mit gesetztem RETAIN-Flag. Diese gespeicherten Meldungen werden als normale MQTT-Meldung an alle Clients gesendet, die das Thema abonniert haben, und sie werden auch gespeichert, um an neue Abonnenten des Themas gesendet zu werden.
Archivierte MQTT-Meldungen erfordern spezifische Richtlinienaktionen, um Clients den Zugriff auf sie zu autorisieren. Beispiele für die Verwendung von Richtlinien für gespeicherte Meldungen finden Sie unter Beispielrichtlinien für beibehaltene Nachrichten.
In diesem Abschnitt werden allgemeine Vorgänge beschrieben, bei denen gespeicherte Meldungen verwendet werden.
-
Erstellen einer beibehaltenen Nachricht
Der Client bestimmt, ob eine Meldung beibehalten wird, wenn er eine MQTT-Meldung veröffentlicht. Clients können das RETAIN-Flag setzen, wenn sie eine Meldung veröffentlichen, indem sie ein Device SDK verwenden. Anwendungen und Dienste können das RETAIN-Flag setzen, wenn sie die
PublishAktion zum Veröffentlichen einer MQTT-Meldung verwenden.Pro Themenname wird nur eine Meldung beibehalten. Eine neue Meldung mit gesetztem RETAIN-Flag, die zu einem Thema veröffentlicht wurde, ersetzt alle vorhandenen beibehaltenen Meldungen, die zuvor an das Thema gesendet wurden.
HINWEIS: Sie können nicht zu einem reservierten Thema veröffentlichen, wenn das RETAIN-Flag gesetzt ist.
-
Abonnieren eines beibehaltenen Meldungsthemas
Kunden abonnieren Themen für beibehaltene Meldungen wie jedes andere MQTT-Meldungsthema. Bei gespeicherten Meldungen, die durch das Abonnieren eines gespeicherten Meldungsthemas empfangen wurden, ist das RETAIN-Flag gesetzt.
Aufbewahrte Nachrichten werden gelöscht, AWS IoT Core sobald ein Client eine beibehaltene Nachricht mit einer 0-Byte-Nachrichtennutzlast im Thema der beibehaltenen Nachricht veröffentlicht. Clients, die das beibehaltene Meldungsthema abonniert haben, erhalten auch die 0-Byte-Nachricht.
Wenn Sie einen Wildcard-Themenfilter abonnieren, der ein aufbewahrtes Meldungsthema enthält, kann der Client nachfolgende Meldungen empfangen, die zum Thema der beibehaltenen Meldung veröffentlicht wurden, aber die beibehaltene Meldung wird beim Abonnement nicht zugestellt.
HINWEIS: Wenn Sie eine aufbewahrte Meldung abonnieren möchten, muss der Themenfilter in der Anforderung genau dem Thema der aufbewahrten Meldung entsprechen.
Bei gespeicherten Meldungen, die beim Abonnieren eines gespeicherten Meldungsthemas empfangen wurden, ist das RETAIN-Flag gesetzt. Bei gespeicherten Meldungen, die nach dem Abonnement von einem abonnierten Client empfangen werden, ist dies nicht der Fall.
-
Eine beibehaltene Meldung wird abgerufen.
Aufbewahrte Meldungen werden automatisch an Clients zugestellt, wenn sie das Thema mit der gespeicherten Meldung abonnieren. Damit ein Kunde die beibehaltene Meldung nach dem Abonnement erhalten kann, muss er den genauen Themennamen der gespeicherten Meldung abonnieren. Wenn Sie einen Wildcard-Themenfilter abonnieren, der ein aufbewahrtes Meldungsthema enthält, kann der Client nachfolgende Meldungen empfangen, die zum Thema der beibehaltenen Meldung veröffentlicht wurden, aber die beibehaltene Meldung wird beim Abonnement nicht zugestellt.
Dienste und Apps können gespeicherte Meldungen auflisten und abrufen, indem sie
ListRetainedMessagesundGetRetainedMessageaufrufen.Ein Client kann nicht daran gehindert werden, Meldungen zu einem gespeicherten Meldungsthema zu veröffentlichen, ohne das RETAIN-Flag zu setzen. Dies kann zu unerwarteten Ergebnissen führen, z. B. dass die gespeicherte Meldung nicht mit der Meldung übereinstimmt, die durch das Abonnieren des Themas empfangen wurde.
Wenn bei MQTT 5 für eine beibehaltene Meldung das Meldungsablaufintervall festgelegt ist und die beibehaltene Meldung abläuft, erhält ein neuer Abonnent, der dieses Thema abonniert, die beibehaltene Meldung bei erfolgreichem Abonnement nicht.
-
Themen der beibehaltenen Meldungen auflisten
Sie können die gespeicherten Meldungen auflisten, indem Sie
ListRetainedMessagestelefonisch abrufen, und die gespeicherten Meldungen können in der AWS IoT Konsoleeingesehen werden. -
Details zu gespeicherten Meldungen abrufen
Sie können die gespeicherten Meldungsdetails telefonisch unter
GetRetainedMessageabrufen, und sie können in der AWS IoT Konsoleangezeigt werden. -
Beibehaltung einer Willensnachricht
MQTT-Will-Meldungen
, die erstellt werden, wenn ein Gerät eine Verbindung herstellt, können beibehalten werden, indem das Will RetainFlag imConnect Flag bitsFeld gesetzt wird. -
Löschen einer beibehaltenen Nachricht
Geräte, Anwendungen und Dienste können eine gespeicherte Meldung löschen, indem sie eine Meldung mit gesetztem RETAIN-Flag und einer leeren Meldungs-Payload (0 Byte) im Themennamen der zu löschenden Meldung veröffentlichen. Solche Nachrichten löschen die gespeicherte Nachricht von und werden an Clients gesendet AWS IoT Core, die das Thema abonniert haben, aber sie werden nicht von gespeichert. AWS IoT Core
Beibehaltene Meldungen können auch interaktiv gelöscht werden, indem Sie in der AWS IoT Konsole
auf die gespeicherte Meldung zugreifen. Archivierte Meldungen, die mithilfe der AWS IoT Konsole gelöscht werden, senden auch eine 0-Byte-Meldung an Clients, die das Thema der gespeicherten Meldung abonniert haben. Aufbewahrte Meldungen können nicht wiederhergestellt werden, nachdem sie gelöscht wurden. Ein Client müsste eine neue beibehaltene Meldung veröffentlichen, um die gelöschte Meldung zu ersetzen.
-
Debuggen und Problembehandlung bei gespeicherten Meldungen
Die AWS IoT Konsole
bietet mehrere Tools, mit denen Sie Fehler bei gespeicherten Meldungen beheben können: -
Die Seite „Zurückbehaltene Meldungen
“ Die Seite „Zurückbehaltene Meldungen“ in der AWS IoT Konsole enthält eine paginierte Liste der gespeicherten Meldungen, die von Ihrem Konto in der aktuellen Region gespeichert wurden. Auf dieser Seite können Sie:
-
Sehen Sie sich die Details jeder gespeicherten Meldung an, z. B. die Meldungsnutzlast, QoS und den Zeitpunkt, zu dem sie empfangen wurde.
-
Aktualisieren Sie den Inhalt einer gespeicherten Nachricht.
-
Löscht eine beibehaltene Nachricht.
-
-
Der MQTT-Testclient
Auf der MQTT-Testclient-Seite in der AWS IoT Konsole können MQTT-Themen abonniert und veröffentlicht werden. Mit der Veröffentlichungsoption können Sie das RETAIN-Flag für die von Ihnen veröffentlichten Meldungen setzen, um zu simulieren, wie sich Ihre Geräte verhalten könnten.
Einige unerwartete Ergebnisse können auf diese Aspekte der Implementierung von gespeicherten Nachrichten zurückzuführen sein AWS IoT Core.
-
Beibehaltene Meldungslimits
Wenn ein Konto die maximale Anzahl an gespeicherten Nachrichten gespeichert hat, wird eine gedrosselte Antwort auf Nachrichten AWS IoT Core zurückgegeben, die mit aktiviertem RETAIN und Payloads von mehr als 0 Byte veröffentlicht wurden, bis einige der gespeicherten Nachrichten gelöscht wurden und die Anzahl der gespeicherten Nachrichten unter den Grenzwert fällt.
-
Beibehaltene Reihenfolge der Meldungszustellung
Die Reihenfolge zwischen beibehaltener und abonnierter Meldungszustellung kann nicht garantiert werden.
-
Abrechnung und gespeicherte Meldungen
Beim Veröffentlichen von Meldungen, bei denen das RETAIN-Flag gesetzt ist, von einem Client aus, über die AWS IoT
Konsole oder per Anruf Publish fallen zusätzliche Gebühren für Meldungsübermittlung an, die unter AWS IoT Core Preise – Meldungsübermittlung
Beim Abrufen von gespeicherten Nachrichten durch einen Client, über die AWS IoT Konsole oder durch einen Anruf GetRetainedMessagefallen zusätzlich zu den normalen API-Nutzungsgebühren Gebühren für Nachrichtenübermittlung an. Die zusätzlichen Gebühren sind unter AWS IoT Core
Preise – Meldungsübermittlung
Für Will-Meldungen, die veröffentlicht werden, wenn die Verbindung zu einem Gerät unerwartet unterbrochen wird, fallen Gebühren für die Meldungsübermittlung an, die unter AWS IoT Core Preise – Meldungsübermittlung
Weitere Informationen zu den Messaging-Kosten finden Sie unter AWS IoT Core Preise – Meldungsübermittlung
Vergleich von beibehaltenen MQTT-Meldungen und persistenten MQTT-Sitzungen
Aufbewahrte Meldungen und persistente Sitzungen sind Standardfunktionen von MQTT, die es Geräten ermöglichen, Meldungen zu empfangen, die veröffentlicht wurden, während sie offline waren. Aufbewahrte Meldungen können aus persistenten Sitzungen heraus veröffentlicht werden. In diesem Abschnitt werden die wichtigsten Aspekte dieser Funktionen und ihr Zusammenspiel beschrieben.
|
Beibehaltene Meldungen |
Persistente MQTT-Sitzungen |
|
|---|---|---|
|
Schlüsselfunktionen |
Aufbewahrte Meldungen können verwendet werden, um große Gruppen von Geräten zu konfigurieren oder zu benachrichtigen, nachdem sie eine Verbindung hergestellt haben. Aufbewahrte Meldungen können auch verwendet werden, wenn Geräte nach einer erneuten Verbindung nur die zuletzt zu einem Thema veröffentlichte Meldung empfangen sollen. |
Dauerhafte Sitzungen sind nützlich für Geräte, deren Konnektivität unterbrochen ist und bei denen möglicherweise mehrere wichtige Meldungen übersehen werden. Geräte können sich mit einer dauerhaften Sitzung verbinden, um Meldungen zu empfangen, die gesendet werden, während sie offline sind. |
|
Beispiele |
Gespeicherte Meldungen können Geräten Konfigurationsinformationen über ihre Umgebung geben, wenn sie online gehen. Die Erstkonfiguration könnte eine Liste anderer Meldungsthemen enthalten, die das Gerät 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önnten persistente Sitzungen verwenden, um zu verhindern, dass wichtige Meldungen verpasst werden, die gesendet werden, wenn ein Gerät nicht mit Netzempfang versorgt ist oder sein Mobilfunknetz ausgeschaltet werden muss. |
|
Meldungen, die beim ersten Abonnement eines Themas eingegangen sind |
Nach dem Abonnieren eines Themas mit einer beibehaltenen Meldung wird die neueste beibehaltene Meldung empfangen. |
Nach dem Abonnieren eines Themas ohne beibehaltene Meldung wird keine Meldung empfangen, bis eine Meldung zu dem Thema veröffentlicht wird. |
|
Abonnierte Themen nach dem erneuten Verbindungsaufbau |
Ohne eine dauerhafte Sitzung muss der Client nach der Wiederverbindung Themen abonnieren. |
Abonnierte Themen werden nach der Wiederverbindung wiederhergestellt. |
|
Nach der Wiederverbindung empfangene Meldungen |
Nach dem Abonnieren eines Themas mit einer beibehaltenen Meldung wird die neueste beibehaltene Meldung empfangen. |
Alle Meldungen, die mit QOS = 1 veröffentlicht und mit QOS =1 abonniert wurden, während das Gerät getrennt wurde, werden gesendet, nachdem das Gerät wieder eine Verbindung hergestellt hat. |
|
Sitzungsablauf |
In MQTT 3 laufen gespeicherte Meldungen nicht ab. Sie werden gespeichert, bis sie ersetzt oder gelöscht werden. In MQTT 5 laufen gespeicherte Meldungen nach dem von Ihnen festgelegten Meldungsablaufintervall ab. Weitere Informationen finden Sie unter Message templates (Meldungsvorlagen). |
Persistente Sitzungen laufen ab, wenn der Client innerhalb des Timeout-Zeitraums keine erneute Verbindung herstellt. Nach Ablauf einer dauerhaften Sitzung werden die Abonnements und gespeicherten Meldungen des Clients gelöscht, die mit einem QOS = 1 veröffentlicht und mit einem QOS =1 abonniert wurden, während das Gerät getrennt wurde. Abgelaufene Meldungen werden nicht zugestellt. Weitere Hinweise zum Ablauf von Sitzungen mit persistenten Sitzungen finden Sie unter Persistente MQTT-Sitzungen. |
Informationen zu persistentem Speicher siehe Persistente MQTT-Sitzungen.
Bei Retained Messages bestimmt der Publishing-Client, ob eine Meldung aufbewahrt und an ein Gerät gesendet werden soll, nachdem das Gerät eine Verbindung hergestellt hat, unabhängig davon, ob es eine vorherige Sitzung hatte oder nicht. Die Entscheidung, eine Meldung zu speichern, wird vom Herausgeber getroffen, und die gespeicherte Meldung wird an alle aktuellen und zukünftigen Clients zugestellt, die ein Abonnement für QoS 0 oder QoS 1 abgeschlossen haben. Bei gespeicherten Meldungen wird jeweils nur eine Meldung zu einem bestimmten Thema gespeichert.
Wenn ein Konto die maximale Anzahl an gespeicherten Meldungen gespeichert hat, wird AWS IoT Core eine gedrosselte Antwort auf Meldungen zurückgeben, bei denen RETAIN aktiviert war, und Nutzlasten von mehr als 0 Byte, bis einige beibehaltene Meldungen gelöscht wurden und die Anzahl der gespeicherten Meldungen unter den Grenzwert fällt.
In MQTT gespeicherte Nachrichten und Device Shadows AWS IoT
Sowohl bei gespeicherten Meldungen als auch bei Geräteschatten werden Daten von einem Gerät gespeichert, sie verhalten sich jedoch unterschiedlich und dienen unterschiedlichen Zwecken. In diesem Abschnitt werden ihre Ähnlichkeiten und Unterschiede beschrieben.
|
Beibehaltene Meldungen |
Geräteschatten |
|
|---|---|---|
|
Die Meldungsnutzlast hat eine vordefinierte Struktur oder ein vordefiniertes Schema. |
Wie in der Implementierung definiert. MQTT spezifiziert keine Struktur oder kein Schema für seine Meldungsnutzlast. |
AWS IoT unterstützt eine bestimmte Datenstruktur. |
|
Durch die Aktualisierung der Meldungsnutzlast werden Ereignismeldungen generiert. |
Durch das Veröffentlichen einer gespeicherten Meldung wird die Meldung an abonnierte Clients gesendet, es werden jedoch keine zusätzlichen Aktualisierungsnachrichten generiert. |
Beim Aktualisieren eines Geräteschattens werden Aktualisierungsmeldungen angezeigt, die die Änderung beschreiben. |
|
Meldungsaktualisierungen sind nummeriert. |
Aufbewahrte Meldungen werden nicht automatisch nummeriert. | Geräteschatten-Dokumente haben automatische Versionsnummern und Zeitstempel. |
|
Die Meldungen-Payload ist an eine Ding-Ressource angehängt. |
Beibehaltene Meldungen sind nicht an eine Ding-Ressource angehängt. |
Geräteschatten sind an eine Ding-Ressource angehängt. |
|
Einzelne Elemente der Meldungs-Payload werden aktualisiert. |
Einzelne Elemente der Meldung können nicht geändert werden, ohne die gesamte Meldungsnutzlast zu aktualisieren. |
Einzelne Elemente eines Geräteschatten-Dokuments können aktualisiert werden, ohne dass das gesamte Geräteschatten-Dokument aktualisiert werden muss. |
|
Der Kunde erhält Meldungsdaten bei Abschluss des Abonnements. |
Der Kunde erhält automatisch eine gespeicherte Nachricht, nachdem er ein Thema mit einer gespeicherten Meldung abonniert hat. |
Clients können Geräteschatten-Updates abonnieren, müssen den aktuellen Status jedoch bewusst anfordern. |
|
Indizierung und Durchsuchbarkeit |
Zurückbehaltene Meldungen werden nicht für die Suche indexiert. |
Flottenindizierung indexiert Geräteschatten-Daten für die Suche und Aggregation. |
MQTT-Meldungen des letzten Willens und Testaments (LWT)
Last Will and Testament (LWT) ist ein Feature in MQTT. Mit LWT können Kunden eine Meldung 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 Clients angegebene Meldung wird als LWT-Meldung oder Will-Meldung bezeichnet, und das von den Clients definierte Thema wird Will-Thema genannt. Sie können eine LWT-Meldung angeben, wenn ein Gerät eine Verbindung zum Broker herstellt. Diese Meldungen können beibehalten werden, indem während der Verbindung die Will
Retain Markierung im Connect Flag bits Feld gesetzt wird. Wenn die Will Retain Markierung beispielsweise auf 1 gesetzt ist, wird eine Will-Meldung im Broker im zugehörigen Testament-Thema gespeichert. Weitere Informationen finden Sie unter Meldungsvorlagen
Der Broker speichert die Will-Meldungen, bis es zu einer uninitiierten Verbindungsunterbrechung kommt. In diesem Fall veröffentlicht der Broker die Meldungen an alle Clients, die das Will-Thema abonniert haben, um den Verbindungsabbruch zu melden. Wenn der Client die Verbindung zum Broker mit einer vom Client initiierten Verbindungsunterbrechung mithilfe der MQTT DISCONNECT-Meldung trennt, veröffentlicht der Broker die gespeicherten LWT-Meldungen nicht. In allen anderen Fällen werden die LWT-Meldungen versendet. Eine vollständige Liste der Verbindungsszenarien, in denen der Broker die LWT-Meldungen sendet, finden Sie unter Connect/Disconnect events.
ConnectAttributes verwenden
ConnectAttributes ermöglichen es Ihnen, in Ihren IAM-Richtlinien anzugeben, welche Attribute Sie in Ihrer Connect-Meldung verwenden möchten, z. B. PersistentConnect und LastWill Mit ConnectAttributes kö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 wurde.
connectAttributes unterstützt die folgenden Funktionen:
PersistentConnect-
Verwenden Sie die
PersistentConnectFunktion, um alle Abonnements zu speichern, die der Client während der Verbindung abschließt, wenn die Verbindung zwischen dem Client und dem Broker unterbrochen wird. LastWill-
Verwenden Sie die
LastWillFunktion, um eine Meldung anLastWillTopiczu veröffentlichen, wenn 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.
ConnectAttributesBeispiele finden Sie unter Beispiele für Connect-Richtlinien.
Von MQTT 5 unterstützte Funktionen
AWS IoT Core Die Unterstützung für MQTT 5 basiert auf der MQTT v5.0-Spezifikation
AWS IoT Core unterstützt die folgenden MQTT 5-Funktionen:
Geteilte Abonnements
AWS IoT Core unterstützt Shared Subscriptions sowohl für MQTT 3 als auch für MQTT 5. Geteilte Abonnements ermöglichen es mehreren Clients, ein Abonnement für ein Thema gemeinsam zu nutzen, und nur ein Client erhält Meldungen, die zu diesem Thema veröffentlicht wurden, nach dem Zufallsprinzip. Mit geteilten Abonnements können MQTT-Meldungen effektiv auf mehrere Abonnenten verteilt werden. Nehmen wir zum Beispiel an, Sie haben 1.000 Geräte, die zum gleichen Thema veröffentlichen, und 10 Backend-Anwendungen, die diese Meldungen verarbeiten. In diesem Fall können die Backend-Anwendungen dasselbe Thema abonnieren und jede Anwendung würde nach dem Zufallsprinzip Meldungen empfangen, die von den Geräten zu dem gemeinsamen Thema veröffentlicht wurden. Auf diese Weise wird die Menge dieser Meldungen quasi „geteilt“. Geteilte Abonnements ermöglichen auch eine bessere Ausfallsicherheit. Wenn eine Back-End-Anwendung die Verbindung trennt, verteilt der Broker die Last auf die verbleibenden Abonnenten in der Gruppe.
Um gemeinsame Abonnements zu verwenden, abonnieren Kunden den Themenfilter eines gemeinsamen Abonnements wie folgt:
$share/{ShareName}/{TopicFilter}
-
$shareist eine wörtliche Zeichenfolge, die den Themenfilter eines geteilten Abonnements angibt, der mit$sharebeginnen muss. -
{ShareName}ist eine Zeichenfolge zur Angabe des gemeinsamen Namens, der von einer Gruppe von Abonnenten verwendet wird. Der Themenfilter eines geteilten Abonnements muss einShareNameund gefolgt von einem/Zeichen enthalten.{ShareName}darf die folgenden Zeichen nicht enthalten:/,+oder#. Die maximale Hash-Schlüsselgröße für{ShareName}ist 128 Byte. -
{TopicFilter}folgt derselben Themenfiltersyntax wie ein Abonnement ohne gemeinsame Nutzung. Die maximale Hash-Schlüsselgröße für{TopicFilter}ist 256 Byte. -
Die beiden erforderlichen Schrägstriche (
/) für$share/{ShareName}/{TopicFilter}sind nicht in den Grenzwerten „Maximale Anzahl von Schrägstrichen im Thema“ und „Themenfilter“enthalten.
Abonnements, die dasselbe {ShareName}/{TopicFilter} haben, gehören derselben gemeinsamen Abonnementgruppe an. Sie können mehrere Gruppen gemeinsam genutzter Abonnements erstellen und dabei das Limit für gemeinsame Abonnements pro Gruppe nicht überschreiten. Weitere Informationen finden Sie unter AWS IoT Core -Endpunkte und -Kontingente in der AWS Allgemeinen Referenz.
In den folgenden Tabellen werden nicht gemeinsam genutzte Abonnements und geteilte Abonnements verglichen:
| Abonnement | Beschreibung | Beispiele für Metrikfilter |
|---|---|---|
| Nicht gemeinsam genutzte Abonnements | Jeder Client erstellt ein separates Abonnement für den Empfang der veröffentlichten Meldungen. Wenn eine Meldung zu einem Thema veröffentlicht wird, erhalten alle Abonnenten dieses Themas eine Kopie der Nachricht. |
|
| Geteilte Abonnements | Mehrere Kunden können sich ein Abonnement für ein Thema teilen, und nur ein Kunde erhält Meldungen, die zu diesem Thema veröffentlicht wurden, nach dem Zufallsprinzip. |
|
| Es werden nicht gemeinsam genutzte Abonnements angeboten. | Ablauf geteilter Abonnements |
|---|---|
|
|
Wichtige Hinweise zur Verwendung von geteilten Abonnements
-
Wenn ein Veröffentlichungsversuch für einen QoS0-Abonnenten fehlschlägt, erfolgt kein erneuter Versuch, und die Meldung wird gelöscht.
-
Wenn ein Veröffentlichungsversuch für einen QoS1-Abonnenten mit sauberer Sitzung fehlschlägt, wird die Meldung an einen anderen Abonnenten in der Gruppe für mehrere Wiederholungsversuche gesendet. Meldungen, die nach allen Wiederholungsversuchen nicht zugestellt werden können, werden verworfen.
-
Wenn ein Veröffentlichungsversuch für einen QoS1-Abonnenten mit persistenten Sitzungen fehlschlägt, weil der Abonnent offline ist, werden die Meldungen nicht in die Warteschlange gestellt, sondern an einen anderen Abonnenten in der Gruppe weitergeleitet. Meldungen, die nach allen Wiederholungsversuchen nicht zugestellt werden können, werden verworfen.
-
Geteilte Abonnements empfangen keine gespeicherten Meldungen.
-
Wenn gemeinsame Abonnements Platzhalterzeichen (# oder +) enthalten, gibt es möglicherweise mehrere übereinstimmende gemeinsame Abonnements zu einem Thema. In diesem Fall kopiert der Message Broker die Veröffentlichungsnachricht und sendet sie in jedem passenden gemeinsamen Abonnement an einen zufälligen Client. Das Platzhalterverhalten von gemeinsamen Abonnements kann in der folgenden Abbildung erklärt werden.
In diesem Beispiel gibt es drei passende gemeinsame Abonnements zum Thema Veröffentlichung von MQTT
sports/tennis. Der Message Broker kopiert die veröffentlichte Meldung und sendet die Meldung an einen zufälligen Client in jeder passenden Gruppe.Kunde 1 und Kunde 2 teilen sich das Abonnement:
$share/consumer1/sports/tennisKunde 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 unter AWS IoT Core Endpunkte und Kontingente in der AWS Allgemeinen Referenz. Informationen zum Testen von gemeinsamen Abonnements mit dem AWS IoT MQTT-Client in der AWS IoT Konsole
Clean Start und Ablauf der Sitzung
Sie können Clean Start und Session Expiry verwenden, um Ihre persistenten 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 für die Sitzung kann bei der Trennung geändert werden. Weitere Informationen finden Sie unter Persistente MQTT-Sitzungen.
Ursachencode für alle ACKs
Mithilfe der Ursachencodes können Sie Fehlermeldungen einfacher debuggen oder verarbeiten. Ursachencodes werden vom Message Broker auf der Grundlage der Art der Interaktion mit dem Broker zurückgegeben (Abonnieren, Veröffentlichen, Bestätigen). Weitere Informationen finden Sie unter MQTT. Eine vollständige Liste der MQTT-Ursachencodes finden Sie in der MQTT v5-Spezifikation
Themen-Aliase
Sie können einen Themennamen durch einen Themenalias ersetzen, bei dem es sich um eine Zwei-Byte-Ganzzahl handelt. Durch die Verwendung von Themenaliasnamen kann die Übertragung von Themennamen optimiert und so potenziell die Datenkosten für Dienste mit Messdaten gesenkt werden. AWS IoT Core hat ein Standardlimit von 8 Themenaliasnamen. Weitere Informationen finden Sie unter AWS IoT Core -Endpunkte und -Kontingente in der AWS Allgemeinen Referenz.
Ablauf der Nachricht
Sie können veröffentlichten Meldungen Werte für den Ablauf von Meldungen hinzufügen. Diese Werte stellen das Meldungsablaufintervall in Sekunden dar. Wenn die Meldungen innerhalb dieses Intervalls nicht an die Abonnenten gesendet wurden, läuft die Meldung ab und wird entfernt. Wenn Sie den Wert für das Verfallsdatum der Meldung nicht festlegen, läuft die Meldung nicht ab.
Beim ausgehenden Versand erhält der Abonnent eine Meldung mit der verbleibenden Restzeit des Ablaufintervalls. Wenn beispielsweise eine eingehende Veröffentlichungsnachricht einen Meldungsablauf von 30 Sekunden hat und sie nach 20 Sekunden an den Abonnenten weitergeleitet wird, wird das Feld für den Ablauf der Meldung auf 10 aktualisiert. Es ist möglich, dass die vom Abonnenten empfangene Meldung einen aktualisierten MEI von 0 hat. Dies liegt daran, dass sie auf 0 aktualisiert wird, sobald die verbleibende Zeit 999 ms oder weniger beträgt.
In AWS IoT Core, das Mindestablaufintervall für Nachrichten ist 1. Wenn das Intervall auf der Clientseite auf 0 gesetzt ist, wird es auf 1 eingestellt. Das maximale Verfallsintervall für Meldungen beträgt 604800 (7 Tage). Alle Werte, die über diesem Wert liegen, werden an den Maximalwert angepasst.
Bei der versionsübergreifenden Kommunikation wird das Verhalten des Meldungsablaufs durch die MQTT-Version der eingehenden Veröffentlichungsnachricht bestimmt. Beispielsweise MQTT5 kann eine Nachricht mit Ablauf der Nachricht, die von einer Sitzung gesendet wurde, über die eine Verbindung hergestellt wurde, für Geräte ablaufen, die über MQTT3 Sitzungen abonniert wurden. In der folgenden Tabelle ist aufgeführt, wie der Ablauf von Meldungen die folgenden Arten von Veröffentlichungsnachrichten unterstützt:
| Veröffentlichen eines Meldungstyps | Ablaufintervall für Meldungen |
|---|---|
| Reguläres Veröffentlichen | Wenn ein Server die Meldung nicht innerhalb der angegebenen Zeit zustellt, wird die abgelaufene Meldung entfernt und der Abonnent erhält sie nicht. Dies schließt Situationen ein, z. B. wenn ein Gerät seine QoS 1-Meldungen nicht veröffentlicht. |
| Beibehalten | Wenn eine gespeicherte Meldung abläuft und ein neuer Kunde das Thema abonniert, erhält der Client die Meldung nach Abschluss des Abonnements nicht. |
| Letzter Wille | Das Intervall für Meldungen des letzten Willens beginnt, nachdem der Client die Verbindung getrennt hat und der Server versucht, seinen Abonnenten die letzte Willensnachricht zuzustellen. |
| In die Warteschlange eingestellte Meldungen | Wenn ein ausgehender QoS1-Dienst mit Meldungsablaufintervall abläuft, während ein Client offline ist, empfängt der Client nach der Wiederaufnahme der persistenten Sitzung die abgelaufene Meldung 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 den Verbindungsabbruch mit einem Ursachencode für die Trennung zu benachrichtigen.
Request Response (Antwort anfordern)
Verlage können verlangen, dass der Empfänger nach Erhalt eine Antwort auf ein vom Verlag spezifiziertes Thema sendet.
Maximale Teilegröße
Client und Server können unabhängig voneinander die maximale Paketgröße angeben, die sie unterstützen.
Payload-Format und Inhaltstyp
Sie können das Payload-Format (Binär, Text) und den Inhaltstyp angeben, wenn eine Meldung veröffentlicht wird. Diese werden an den Empfänger der Meldung weitergeleitet.
MQTT 5 Eigenschaften
MQTT 5-Eigenschaften sind wichtige Ergänzungen des MQTT-Standards zur Unterstützung neuer MQTT 5-Funktionen wie Session Expiry und das Request/Response-Muster. In können Sie Regeln erstellen AWS IoT Core, die die Eigenschaften ausgehender Nachrichten weiterleiten können, oder HTTP Publish verwenden, um MQTT-Nachrichten mit einigen der neuen Eigenschaften zu veröffentlichen.
In der folgenden Tabelle sind alle MQTT 5-Eigenschaften aufgeführt, die unterstützt werden. AWS IoT Core
| Property (Eigenschaft) | Description (Beschreibung) | Eingabetyp | packets |
|---|---|---|---|
| Nutzlastformatindikator Nutzlastnutzlast | Ein Zeichenfolgenwert, der angibt, ob die Nutzlast als UTF-8 formatiert ist. | Byte | VERÖFFENTLICHEN, VERBINDEN |
| Inhaltstyp | Eine UTF-8-Zeichenfolge, die den Inhalt der Nutzlast beschreibt. | UTF-8-Zeichenfolge | VERÖFFENTLICHEN, VERBINDEN |
| Thema der Antwort | Eine UTF-8-Zeichenfolge, die das Thema beschreibt, zu dem der Empfänger im Rahmen des Anfrage-Antwort-Ablaufs etwas veröffentlichen sollte. 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. | Binär | VERÖFFENTLICHEN, VERBINDEN |
| Benutzereigenschaften | Ein UTF-8-Stringpaar. Diese Eigenschaft kann in einem Paket mehrfach vorkommen. Die Empfänger empfangen die Schlüssel-Wert-Paare in derselben Reihenfolge, in der sie gesendet wurden. | UTF-8-String-Paar | VERBINDEN, VERÖFFENTLICHEN, Will-Eigenschaften, ABONNIEREN, TRENNEN, ABBESTELLEN |
| Ablaufintervall für Meldungen | Eine 4-Byte-Ganzzahl, die das Verfallsintervall der Meldung in Sekunden darstellt. Wenn nicht vorhanden, läuft die Meldung nicht ab. | 4-Byte-Ganzzahl | VERÖFFENTLICHEN, VERBINDEN |
| Ablaufintervall der Sitzung |
Eine 4-Byte-Ganzzahl, die das Ablaufintervall der Sitzung in Sekunden darstellt. AWS IoT Core unterstützt maximal 7 Tage, mit einem standardmäßigen Maximum von einer Stunde. Wenn der von Ihnen festgelegte Wert das Maximum Ihres Kontos überschreitet, AWS IoT Core wird der angepasste Wert im CONNACK zurückgegeben. |
4-Byte-Ganzzahl | VERBINDEN, VERBINDEN, TRENNEN |
| Zugewiesene Client-ID | Eine zufällige Client-ID, die generiert wird AWS IoT Core , wenn eine Client-ID nicht von Geräten angegeben wird. Bei der zufälligen Client-ID muss es sich um eine neue Client-ID handeln, 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 Ursachenzeichenfolge oder die Benutzereigenschaften bei Fehlern gesendet werden. | Byte | CONNECT |
| Maximal empfangen | Eine 2-Byte-Ganzzahl, die die maximale Anzahl von PUBLISH QOS > 0-Paketen darstellt, die gesendet werden können, ohne dass ein PUBACK empfangen wird. | 2-Byte-Ganzzahl | VERBINDEN, CONNACK |
| Thema Alias Maximum | Dieser Wert gibt den höchsten Wert an, der als Themen-Alias akzeptiert wird. Standard = 0. | 2-Byte-Ganzzahl | VERBINDEN, CONNACK |
| Maximale QoS | Der maximale Wert von QoS, der AWS IoT Core unterstützt wird. Der Standardwert lautet 1. AWS IoT Core unterstützt QoS2 nicht. | Byte | CONNACK |
| Beibehaltung verfügbar |
Ein boolescher Wert, der angibt, ob der AWS IoT Core Message Broker gespeicherte Nachrichten unterstützt. Der Standardwert ist 1. |
Byte | CONNACK |
| Maximale Teilegröße | Die maximale Paketgröße, die AWS IoT Core akzeptiert und gesendet wird. Kann 128 KB nicht überschreiten. | 4-Byte-Ganzzahl | VERBINDEN, CONNACK |
| Wildcard-Abonnement verfügbar |
Ein boolescher Wert, der angibt, ob der AWS IoT Core Message Broker Wildcard Subscription Available unterstützt. Der Standardwert ist 1. |
Byte | CONNACK |
| Abonnement-ID verfügbar |
Ein boolescher Wert, der angibt, ob der AWS IoT Core Message Broker Subscription Identifier Available unterstützt. Der Standardwert ist 0. |
Byte | CONNACK |
MQTT-Ursachencodes
MQTT 5 führt eine verbesserte Fehlerberichterstattung mit Antworten auf Ursachencodes ein. AWS IoT Core kann Ursachencodes zurückgeben, einschließlich, aber nicht beschränkt auf die folgenden, gruppiert nach Paketen. Eine vollständige Liste der von MQTT 5 unterstützten Ursachencodes finden Sie in den MQTT 5-Spezifikationen
| Wert | HEX() | Name des Grundcodes | Beschreibung |
|---|---|---|---|
| 0 | 0x00 | Herzlichen Glückwunsch | Die Verbindung wurde akzeptiert. |
| 128 | 0x80 | Unbekannter Fehler | Der Server möchte den Grund für den Fehler nicht preisgeben, oder keiner der anderen Ursachencodes trifft zu. |
| 133 | 0x85 | Die Client-ID ist nicht gültig. | Die Client-ID ist eine gültige Zeichenfolge, die jedoch vom Server nicht zugelassen wird. |
| 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 Will-Themas ist korrekt formatiert, wird aber vom Server nicht akzeptiert. |
| 151 | 0 x 97 | Kontingent überschritten | Ein von der Implementierung oder vom Administrator auferlegtes Limit wurde überschritten. |
| 155 | 0 x 9 B | QoS nicht unterstützt | Der Server unterstützt die in Will QoS eingestellte QoS nicht. |
| Wert | HEX() | Name des Grundcodes | Beschreibung |
|---|---|---|---|
| 0 | 0x00 | Herzlichen Glückwunsch | Die Meldung wurde akzeptiert. Die Veröffentlichung der QoS 1-Meldung wird fortgesetzt. |
| 128 | 0x80 | Unbekannter Fehler | Der Empfänger akzeptiert die Veröffentlichung nicht, möchte aber entweder den Grund nicht preisgeben, oder er entspricht keinem der anderen Werte. |
| 135 | 0x87 | Nicht autorisiert. | Die Veröffentlichung ist nicht autorisiert. |
| 144 | 0x90 | Themenname ungültig | Der Themenname ist nicht falsch formatiert, wird aber vom Client oder Server nicht akzeptiert. |
| 145 | 0x91 | Paket-ID wird verwendet. | Die Paket-ID wird bereits verwendet. Dies könnte auf eine Nichtübereinstimmung des Sitzungsstatus zwischen Client und Server hinweisen. |
| 151 | 0 x 97 | Kontingent überschritten | Ein von der Implementierung oder vom Administrator auferlegtes Limit wurde überschritten. |
| Wert | HEX() | Name des Grundcodes | Beschreibung |
|---|---|---|---|
| 129 | 0x81 | Fehlerhaftes Paket | Das empfangene Paket entspricht nicht dieser Spezifikation. |
| 130 | 0x82 | Protokollfehler | Ein unerwartetes Paket oder ein Paket, das nicht in der richtigen Reihenfolge ist, wurde empfangen. |
| 135 | 0x87 | Nicht autorisiert. | Die Anfrage ist nicht autorisiert. |
| 139 | 0x8B | Server wird heruntergefahren. | Der Server wird heruntergefahren. |
| 141 | 0x8D | Keep Alive Timeout | Die Verbindung wurde geschlossen, weil seit dem 1,5-fachen der Keep-Alive-Zeit kein Paket mehr 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 | Ungültiger Themenfilter | Der Themenfilter ist korrekt formatiert, 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 | 0 x 93 | Empfangsmaximum überschritten | Der Client oder Server hat mehr als die Empfangsmaximum-Publikation erhalten, für die er weder PUBACK noch PUBCOMP gesendet hat. |
| 148 | 0 x 94 | Ungültiges Thema-Alias | Der Client oder Server hat ein PUBLISH-Paket erhalten, das einen Themen-Alias enthält, der größer ist als die maximale Anzahl an Themen-Alias, die er im CONNECT- oder CONNACK-Paket gesendet hat. |
| 151 | 0 x 97 | Kontingent überschritten | Ein von der Implementierung oder vom Administrator auferlegtes Limit wurde überschritten. |
| 152 | 0x98 | Administrative Maßnahmen | Die Verbindung wurde aufgrund einer Verwaltungsmaßnahme geschlossen. |
| 155 | 0 x 9 B | QoS nicht unterstützt | Der Client hat eine QoS angegeben, die höher ist als die QoS, die in einem Maximum QoS im CONNACK angegeben ist. |
| 161 | 0 x A1 | Abonnement-Identifikatoren werden nicht unterstützt. | Der Server unterstützt keine Abonnement-IDs. Das Abonnement wird nicht akzeptiert. |
| Wert | HEX() | Name des Grundcodes | Beschreibung |
|---|---|---|---|
| 0 | 0x00 | QoS gewährt 0 | Das Abonnement wurde akzeptiert, und die maximale gesendete QoS beträgt QoS 0. Dies könnte eine niedrigere QoS sein als gewünscht. |
| 1 | 0x01 | QoS 1 gewährt 1 | Das Abonnement wurde akzeptiert, und die maximale gesendete QoS beträgt QoS 1. Dies könnte eine niedrigere QoS sein als gewünscht. |
| 128 | 0x80 | Unbekannter Fehler | Das Abonnement wurde nicht akzeptiert, und der Server möchte den Grund entweder nicht preisgeben oder keiner der anderen Ursachencodes trifft zu. |
| 135 | 0x87 | Nicht autorisiert. | Der Kunde ist nicht berechtigt, dieses Abonnement abzuschließen. |
| 143 | 0x8F | Ungültiger Themenfilter | Der Themenfilter ist korrekt formatiert, ist aber für diesen Client nicht zulässig. |
| 145 | 0x91 | Paket-ID wird verwendet. | Die angegebene Paket-ID wird bereits verwendet. |
| 151 | 0 x 97 | Kontingent überschritten | Ein von der Implementierung oder vom Administrator auferlegtes Limit wurde überschritten. |
| Wert | HEX() | Name des Grundcodes | Beschreibung |
|---|---|---|---|
| 0 | 0x00 | Herzlichen Glückwunsch | Das Abonnement wird gelöscht. |
| 128 | 0x80 | Unbekannter Fehler | Die Abmeldung konnte nicht abgeschlossen werden, und der Server möchte den Grund entweder nicht preisgeben oder keiner der anderen Ursachencodes trifft zu. |
| 143 | 0x8F | Ungültiger Themenfilter | Der Themenfilter ist korrekt formatiert, ist aber für diesen Client nicht zulässig. |
| 145 | 0x91 | Paket-ID wird verwendet. | Die angegebene Paket-ID wird bereits verwendet. |
AWS IoT Unterschiede zu den MQTT-Spezifikationen
Die Message-Broker-Implementierung basiert auf der MQTT-Spezifikation v3.1.1
-
AWS IoT unterstützt die folgenden Pakete für MQTT 3 nicht: PUBREC, PUBREL und PUBCOMP.
-
AWS IoT unterstützt die folgenden Pakete für MQTT 5 nicht: PUBREC, PUBREL, PUBCOMP und AUTH.
-
AWS IoT unterstützt keine MQTT 5-Serverumleitung.
-
AWS IoT unterstützt nur die MQTT Quality of Service (QoS) Stufen 0 und 1. AWS IoT unterstützt das Veröffentlichen oder Abonnieren mit QoS Level 2 nicht. Bei Abfragen über QoS-Ebene 2 sendet der Message Broker kein PUBACK oder SUBACK.
-
In AWS IoT bedeutet das Abonnieren eines Themas mit QoS-Stufe 0, dass eine Nachricht null Mal oder öfter zugestellt wird. Meldungen können mehr als einmal übertragen werden. Meldungen, 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.
-
Bevor der Client zusätzliche Steuerpakete oder eine Anfrage zum Trennen der Verbindung sendet, muss er warten, bis die CONNACK-Meldung vom Message Broker auf seinem Gerät empfangen wird. AWS IoT
-
Wenn ein Client ein Thema abonniert, kann es zwischen dem Zeitpunkt, an dem der Message Broker eine SUBACK-Meldung sendet, und den ersten eingehenden passenden Meldungen eine Verzögerung geben.
-
Wenn ein Client das Platzhalterzeichen
#im Themenfilter verwendet, um ein Thema zu abonnieren, werden alle Zeichenfolgen auf und unter seiner Ebene in der Themenhierarchie abgeglichen. Das übergeordnete Thema stimmt jedoch nicht überein. Wenn Sie beispielsweise das Themasensor/#abonnieren, erhalten Sie Meldungen, die fürsensor/,sensor/temperatureodersensor/temperature/room1veröffentlicht werden, nicht jedoch Meldungen, die fürsensorveröffentlicht werden. Weitere Informationen zu Platzhaltern unter Themenfilter. -
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 identischen Client-IDs können nicht gleichzeitig mit dem Message Broker verbunden sein. Stellt ein Client eine Verbindung zum Message Broker über eine Client-ID her, die bereits von einem anderen Client verwendet wird, wird die neue Client-Verbindung akzeptiert und die Verbindung des früher verbundenen Clients getrennt.
-
In seltenen Fällen kann der Message Broker die gleiche logische PUBLISH Meldung mit einer anderen Paket-ID erneut senden.
-
Wenn Sie Themenfilter abonnieren, die ein Platzhalterzeichen enthalten, können keine beibehaltenen Meldungen empfangen werden. Um eine gespeicherte Meldung zu erhalten, muss die Anforderung einen Themenfilter enthalten, der genau dem Thema der gespeicherten Meldung entspricht.
-
Die Reihenfolge, in der Meldungen und ACK empfangen werden, kann vom Message Broker nicht garantiert werden.
-
AWS IoT kann Grenzwerte haben, die von den Spezifikationen abweichen. Weitere Informationen zu den Grenzwerten von AWS IoT Core Message Broker finden Sie im AWS IoT Referenzhandbuch.
-
Das MQTT DUP-Flag wird nicht unterstützt.
