MQTT

„Gerät gesendet CONNECT an AWS IoT Core (Happy Case)“

Überprüft, ob das zu testende Gerät eine CONNECT Anfrage sendet.

APIDefinition des Testfalls:

Anmerkung

EXECUTION_TIMEOUT hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 2 Minuten.


"tests":[
   {
      "name":"my_mqtt_connect_test",
      "configuration": {
         // optional:
         "EXECUTION_TIMEOUT":"300",   // in seconds
      },
      "test":{
         "id":"MQTT_Connect",
         "version":"0.0.0"
      }
   }
]

„Das Gerät kann PUBACK zu einem beliebigen Thema für QoS zurückkehren“

In diesem Testfall wird geprüft, ob das Gerät (Client) eine PUBACK Nachricht zurückgeben kann, wenn es nach dem Abonnieren eines Themas mit QoS1 eine Veröffentlichungsnachricht vom Broker erhalten hat.

Der Inhalt der Nutzlast und die Größe der Nutzlast sind für diesen Testfall konfigurierbar. Wenn die Nutzlastgröße konfiguriert ist, überschreibt Device Advisor den Wert für den Nutzlastinhalt und sendet eine vordefinierte Nutzlast mit der gewünschten Größe an das Gerät. Die Nutzlastgröße ist ein Wert zwischen 0 und 128 und darf 128 KB nicht überschreiten. AWS IoT Core lehnt Veröffentlichungs- und Verbindungsanfragen ab, die größer als 128 KB sind, wie auf der Seite Grenzwerte und Kontingente für AWS IoT Core -Message-Broker und -Protokolle beschrieben.

APIDefinition des Testfalls:

Anmerkung

EXECUTION_TIMEOUT hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 2 Minuten. PAYLOAD_SIZE kann auf einen Wert zwischen 0 und 128 Kilobyte konfiguriert werden. Die Definition einer Nutzlastgröße hat Vorrang vor dem Nutzlastinhalt, da Device Advisor eine vordefinierte Nutzlast mit der angegebenen Größe zurück an das Gerät sendet.


"tests":[                            
{
        "name":"my_mqtt_client_puback_qos1",
        "configuration": {
            // optional:"TRIGGER_TOPIC": "myTopic",
            "EXECUTION_TIMEOUT":"300", // in seconds
            "PAYLOAD_FOR_PUBLISH_VALIDATION":"custom payload",
            "PAYLOAD_SIZE":"100" // in kilobytes
        },
        "test": {
            "id": "MQTT_Client_Puback_QoS1",
            "version": "0.0.0"
        }
    }
]

„Die Geräteverbindung wird erneut mit Jitter-Backoff versucht — keine Antwort“ CONNACK

Überprüft, ob das getestete Gerät den richtigen Jitter-Backoff verwendet, wenn es mindestens fünfmal erneut eine Verbindung zum Broker herstellt. Der Broker protokolliert den Zeitstempel der CONNECT Anfrage des zu testenden Geräts, führt eine Paketvalidierung durch, hält an, ohne eine Nachricht an das zu testende Gerät CONNACK zu senden, und wartet, bis das zu testende Gerät die Anfrage erneut sendet. Der sechste Verbindungsversuch wird durchgelassen und darf zum CONNACK getesteten Gerät zurückfließen.

Der vorherige Vorgang wird erneut ausgeführt. Insgesamt erfordert dieser Testfall, dass das Gerät insgesamt mindestens 12 Mal eine Verbindung herstellt. Die gesammelten Zeitstempel werden verwendet, um zu überprüfen, ob das getestete Gerät den Jitter-Backoff verwendet. Wenn das getestete Gerät eine streng exponentielle Backoff-Verzögerung aufweist, wird dieser Testfall mit Warnungen bestanden.

Wir empfehlen, den Mechanismus Exponential Backoff And Jitter (Exponentielles Backoff und Jitter) auf dem getesteten Gerät zu implementieren, um diesen Testfall zu bestehen.

APIDefinition des Testfalls:

Anmerkung

EXECUTION_TIMEOUT hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 4 Minuten.


"tests":[
   {
      "name":"my_mqtt_jitter_backoff_retries_test",
      "configuration": {
         // optional:
         "EXECUTION_TIMEOUT":"300",    // in seconds
      },
      "test":{
         "id":"MQTT_Connect_Jitter_Backoff_Retries",
         "version":"0.0.0"
      }
   }
]

„Erneute Geräteverbindungsversuche mit exponentiellem Backoff — Keine Antwort“ CONNACK

Überprüft, ob das getestete Gerät das richtige exponentielle Backoff verwendet, wenn es mindestens fünfmal erneut eine Verbindung zum Broker herstellt. Der Broker protokolliert den Zeitstempel der CONNECT Anfrage des zu testenden Geräts, führt eine Paketvalidierung durch, hält an, ohne eine Nachricht an das Client-Gerät CONNACK zu senden, und wartet, bis das zu testende Gerät die Anfrage erneut sendet. Die gesammelten Zeitstempel werden verwendet, um zu überprüfen, ob das getestete Gerät ein exponentielles Backoff verwendet.

Wir empfehlen, den Mechanismus Exponential Backoff And Jitter (Exponentielles Backoff und Jitter) auf dem getesteten Gerät zu implementieren, um diesen Testfall zu bestehen.

APIDefinition des Testfalls:

Anmerkung

EXECUTION_TIMEOUT hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 4 Minuten.


"tests":[
   {
      "name":"my_mqtt_exponential_backoff_retries_test",
      "configuration": {
         // optional:
         "EXECUTION_TIMEOUT":"600",  // in seconds
      },
      "test":{
         "id":"MQTT_Connect_Exponential_Backoff_Retries",
         "version":"0.0.0"
      }
   }
]

„Device re-connect with jitter backoff - After server disconnect“

Überprüft, ob ein getestetes Gerät bei der Wiederherstellung der Verbindung, nachdem es vom Server getrennt wurde, die erforderlichen Jitter- und Backoff-Werte verwendet. Device Advisor trennt das Gerät mindestens fünfmal vom Server und beobachtet das Verhalten des Geräts bei MQTT der Wiederverbindung. Device Advisor protokolliert den Zeitstempel der CONNECT Anfrage für das zu testende Gerät, führt eine Paketvalidierung durch, hält an, ohne eine Nachricht an das Client-Gerät CONNACK zu senden, und wartet, bis das zu testende Gerät die Anfrage erneut sendet. Die gesammelten Zeitstempel werden verwendet, um zu überprüfen, ob das getestete Gerät den Jitter-Backoff verwendet. Wenn das getestete Gerät eine streng exponentielle Backoff-Verzögerung aufweist oder keinen ordnungsgemäßen Jitter-Backoff-Mechanismus implementiert, wird dieser Testfall mit Warnungen bestanden. Wenn das getestete Gerät entweder einen linearen Backoff-Mechanismus oder einen konstanten Backoff-Mechanismus implementiert hat, schlägt der Test fehl.

Damit dieser Testfall bestanden wird, empfehlen wir, den Mechanismus Exponential Backoff And Jitter (Exponentielles Backoff und Jitter) auf dem getesteten Gerät zu implementieren.

APIDefinition des Testfalls:

Anmerkung

EXECUTION_TIMEOUT hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 4 Minuten.

Die Anzahl der Wiederverbindungsversuche zur Überprüfung des Backoffs kann durch Angabe der RECONNECTION_ATTEMPTS geändert werden. Die Zahl muss zwischen 5 und 10 liegen. Der Standardwert ist 5.


"tests":[
   {
      "name":"my_mqtt_reconnect_backoff_retries_on_server_disconnect",
      "configuration":{
         // optional:
         "EXECUTION_TIMEOUT":"300",  // in seconds
         "RECONNECTION_ATTEMPTS": 5
      },
      "test":{
         "id":"MQTT_Reconnect_Backoff_Retries_On_Server_Disconnect",
         "version":"0.0.0"
      }
   }
]

„Device re-connect with jitter backoff - On unstable connection“

Überprüft, ob ein getestetes Gerät beim erneuten Herstellen der Verbindung über eine instabile Verbindung die erforderlichen Jitter- und Backoff-Werte verwendet. Device Advisor trennt das Gerät nach fünf erfolgreichen Verbindungen vom Server und beobachtet das Verhalten des Geräts bei MQTT der Wiederverbindung. Device Advisor protokolliert den Zeitstempel der CONNECT Anfrage für das zu testende Gerät, führt eine Paketvalidierung durch, sendet zurück, trennt die VerbindungCONNACK, protokolliert den Zeitstempel der Verbindungsunterbrechung und wartet, bis das zu testende Gerät die Anfrage erneut sendet. Die gesammelten Zeitstempel werden verwendet, um zu überprüfen, ob das getestete Gerät Jitter und Backoff verwendet, während es nach erfolgreichen, aber instabilen Verbindungen erneut eine Verbindung herstellt. Wenn das getestete Gerät eine streng exponentielle Backoff-Verzögerung aufweist oder keinen ordnungsgemäßen Jitter-Backoff-Mechanismus implementiert, wird dieser Testfall mit Warnungen bestanden. Wenn das getestete Gerät entweder einen linearen Backoff-Mechanismus oder einen konstanten Backoff-Mechanismus implementiert hat, schlägt der Test fehl.

Damit dieser Testfall bestanden wird, empfehlen wir, den Mechanismus Exponential Backoff And Jitter (Exponentielles Backoff und Jitter) auf dem getesteten Gerät zu implementieren.

APIDefinition des Testfalls:

Anmerkung

EXECUTION_TIMEOUT hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 4 Minuten.

Die Anzahl der Wiederverbindungsversuche zur Überprüfung des Backoffs kann durch Angabe der RECONNECTION_ATTEMPTS geändert werden. Die Zahl muss zwischen 5 und 10 liegen. Der Standardwert ist 5.


"tests":[
   {
      "name":"my_mqtt_reconnect_backoff_retries_on_unstable_connection",
      "configuration":{
         // optional:
         "EXECUTION_TIMEOUT":"300",  // in seconds
         "RECONNECTION_ATTEMPTS": 5
      },
      "test":{
         "id":"MQTT_Reconnect_Backoff_Retries_On_Unstable_Connection",
         "version":"0.0.0"
      }
   }
]

„QoS0 (Happy Case)“

Überprüft, ob das getestete Gerät eine Nachricht mit QoS0 oder QoS1 veröffentlicht. Sie können auch das Thema der Nachricht und die Nutzlast überprüfen, indem Sie den Themenwert und die Nutzlast in den Testeinstellungen angeben.

Anmerkung

EXECUTION_TIMEOUT hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 2 Minuten.


"tests":[
   {
      "name":"my_mqtt_publish_test",
      "configuration":{
         // optional:
         "EXECUTION_TIMEOUT":"300",  // in seconds
         "TOPIC_FOR_PUBLISH_VALIDATION": "my_TOPIC_FOR_PUBLISH_VALIDATION",
         "PAYLOAD_FOR_PUBLISH_VALIDATION": "my_PAYLOAD_FOR_PUBLISH_VALIDATION",
      },
      "test":{
         "id":"MQTT_Publish",
         "version":"0.0.0"
      }
   }
]

„QoS1-Veröffentlichung erneut versuchen — Nein“ PUBACK

Überprüft, ob das zu testende Gerät eine mit QoS1 gesendete Nachricht erneut veröffentlicht, falls der Broker sie nicht sendet. PUBACK Sie können auch das Thema der Nachricht überprüfen, indem Sie dieses Thema in den Testeinstellungen angeben. Das Client-Gerät darf die Verbindung nicht trennen, bevor die Nachricht erneut veröffentlicht wird. Mit diesem Test wird auch überprüft, ob die erneut veröffentlichte Nachricht dieselbe Paket-ID wie das Original hat. Wenn das Gerät während der Testausführung die Verbindung verliert und die Verbindung wiederherstellt, wird der Testfall ohne Fehler zurückgesetzt und das Gerät muss die Testfallschritte erneut ausführen.

APIDefinition des Testfalls:

Anmerkung

EXECUTION_TIMEOUT hat einen Standardwert von 5 Minuten. Es wird eine Dauer von mindestens 4 Minuten empfohlen.


"tests":[
   {
      "name":"my_mqtt_publish_retry_test",
      "configuration":{
         // optional:
         "EXECUTION_TIMEOUT":"300",  // in seconds
         "TOPIC_FOR_PUBLISH_VALIDATION": "my_TOPIC_FOR_PUBLISH_VALIDATION",
         "PAYLOAD_FOR_PUBLISH_VALIDATION": "my_PAYLOAD_FOR_PUBLISH_VALIDATION",
      },
      "test":{
         "id":"MQTT_Publish_Retry_No_Puback",
         "version":"0.0.0"
      }
   }
]

„Publish Retained messages“

Überprüft, ob das getestete Gerät eine Nachricht veröffentlicht, bei der retainFlag auf „true“ gesetzt ist. Sie können das Thema der Nachricht und die Nutzlast überprüfen, indem Sie den Themenwert und die Nutzlast in den Testeinstellungen angeben. Wenn der im PUBLISH Paket retainFlag gesendete Wert nicht auf true gesetzt ist, schlägt der Testfall fehl.

APITestfalldefinition:

Anmerkung

EXECUTION_TIMEOUT hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 2 Minuten. Um diesen Testfall auszuführen, fügen Sie die iot:RetainPublish-Aktion zu Ihrer Geräterolle hinzu.


"tests":[
   {
      "name":"my_mqtt_publish_retained_messages_test",
      "configuration":{
         // optional:
         "EXECUTION_TIMEOUT":"300",  // in seconds
         "TOPIC_FOR_PUBLISH_RETAINED_VALIDATION": "my_TOPIC_FOR_PUBLISH_RETAINED_VALIDATION",
         "PAYLOAD_FOR_PUBLISH_RETAINED_VALIDATION": "my_PAYLOAD_FOR_PUBLISH_RETAINED_VALIDATION",
      },
      "test":{
         "id":"MQTT_Publish_Retained_Messages",
         "version":"0.0.0"
      }
   }
]

„Publish with User Property“

Überprüft, ob das getestete Gerät eine Nachricht mit der korrekten Benutzereigenschaft veröffentlicht. Sie können die Benutzereigenschaft überprüfen, indem Sie das Name-Wert-Paar in den Testeinstellungen festlegen. Wenn die Benutzereigenschaft nicht bereitgestellt wird oder nicht übereinstimmt, schlägt der Testfall fehl.

APIDefinition des Testfalls:

Anmerkung

Dies ist MQTT5 nur ein Testfall.

EXECUTION_TIMEOUT hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 2 Minuten.


"tests":[
   {
      "name":"my_mqtt_user_property_test",
      "test":{
        "USER_PROPERTIES": [
            {"name": "name1", "value":"value1"},
            {"name": "name2", "value":"value2"}
        ],
        "EXECUTION_TIMEOUT":"300",  // in seconds
      },
      "test":{
         "id":"MQTT_Publish_User_Property",
         "version":"0.0.0"
      }
   }
]

„Can Subscribe (Happy Case)“

Überprüft, ob das zu testende Gerät Themen MQTT abonniert. Sie können auch das Thema überprüfen, das das getestete Gerät abonniert, indem Sie dieses Thema in den Testeinstellungen angeben.

APIDefinition des Testfalls:

Anmerkung

EXECUTION_TIMEOUT hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 2 Minuten.


"tests":[
   {
      "name":"my_mqtt_subscribe_test",
      "configuration":{
         // optional:
         "EXECUTION_TIMEOUT":"300",  // in seconds
         "TOPIC_LIST_FOR_SUBSCRIPTION_VALIDATION":["my_TOPIC_FOR_PUBLISH_VALIDATION_a","my_TOPIC_FOR_PUBLISH_VALIDATION_b"]
      },
      "test":{
         "id":"MQTT_Subscribe",
         "version":"0.0.0"
      }
   }
]

„Abonnieren, erneut versuchen — NeinSUBACK“

Überprüft, ob das getestete Gerät erneut versucht, Themen zu abonnieren, die fehlgeschlagen sind. MQTT Der Server wartet dann und sendet keine. SUBACK Wenn das Client-Gerät das Abonnement nicht erneut versucht, schlägt der Test fehl. Das Client-Gerät muss das fehlgeschlagene Abonnement mit derselben Paket-ID erneut versuchen. Sie können auch das Thema überprüfen, das das getestete Gerät abonniert, indem Sie dieses Thema in den Testeinstellungen angeben. Wenn das Gerät während der Testausführung die Verbindung verliert und die Verbindung wiederherstellt, wird der Testfall ohne Fehler zurückgesetzt und das Gerät muss die Testfallschritte erneut ausführen.

APITestfalldefinition:

Anmerkung

EXECUTION_TIMEOUT hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 4 Minuten.


"tests":[
   {
      "name":"my_mqtt_subscribe_retry_test",
      "configuration":{
         "EXECUTION_TIMEOUT":"300",  // in seconds
         // optional:
         "TOPIC_LIST_FOR_SUBSCRIPTION_VALIDATION":["myTOPIC_FOR_PUBLISH_VALIDATION_a","my_TOPIC_FOR_PUBLISH_VALIDATION_b"]
      },
      "test":{
         "id":"MQTT_Subscribe_Retry_No_Suback",
         "version":"0.0.0"
      }
   }
]

„Matt Nein Ack“ PingResp

Dieser Testfall überprüft, ob das getestete Gerät die Verbindung trennt, wenn es keine Ping-Antwort erhält. Im Rahmen dieses Testfalls blockiert Device Advisor Antworten von AWS IoT Core Veröffentlichungs-, Abonnement- und Ping-Anfragen. Außerdem wird überprüft, ob das getestete Gerät die MQTT Verbindung unterbricht.

APIDefinition des Testfalls:

Anmerkung

EXECUTION_TIMEOUT hat einen Standardwert von 5 Minuten. Wir empfehlen ein Timeout, das mehr als das 1,5-fache des keepAliveTime-Werts beträgt.

Die maximale keepAliveTime darf für diesen Test nicht länger als 230 Sekunden betragen.


"tests":[
    {
       "name":"Mqtt No Ack PingResp",
       "configuration": 
          //optional:
          "EXECUTION_TIMEOUT":"306",   // in seconds
       },
       "test":{
          "id":"MQTT_No_Ack_PingResp",
          "version":"0.0.0"
       }
    }
]

„Persistent Session (Happy Case)“

Dieser Testfall validiert das Geräteverhalten, wenn die Verbindung zu einer persistenten Sitzung getrennt wird. Der Testfall prüft, ob das Gerät erneut eine Verbindung herstellen kann, die Abonnements für seine Trigger-Themen fortsetzen kann, ohne sich explizit erneut anzumelden, die in den Themen gespeicherten Nachrichten empfangen kann und während einer persistenten Sitzung erwartungsgemäß funktionieren kann. Wenn dieser Testfall erfolgreich ist, bedeutet dies, dass das Client-Gerät in der Lage ist, eine dauerhafte Sitzung mit dem AWS IoT Core Broker wie erwartet aufrechtzuerhalten. Weitere Informationen zu AWS IoT persistenten Sitzungen finden Sie unter Verwenden MQTT persistenter Sitzungen.

In diesem Testfall wird erwartet, dass das Client-Gerät das Flag AWS IoT Core with a clean session auf false gesetzt hat und dann ein Trigger-Thema abonniert. CONNECT Nach einem erfolgreichen Abonnement wird das Gerät von AWS IoT Core Device Advisor getrennt. Solange sich das Gerät in einem getrennten Zustand befindet, wird eine QoS 1-Nachrichtennutzlast in diesem Thema gespeichert. Device Advisor ermöglicht dem Client-Gerät dann, erneut eine Verbindung mit dem Testendpunkt herzustellen. Da zu diesem Zeitpunkt eine persistente Sitzung besteht, wird erwartet, dass das Client-Gerät seine Themenabonnements wieder aufnimmt, ohne zusätzliche SUBSCRIBE Pakete zu senden, und die QoS 1-Nachricht vom Broker empfängt. Wenn das Client-Gerät nach der erneuten Verbindung sein Trigger-Thema erneut abonniert, indem es ein zusätzliches SUBSCRIBE Paket sendet und/oder wenn der Client die gespeicherte Nachricht vom Trigger-Thema nicht empfängt, schlägt der Testfall fehl.

APIDefinition des Testfalls:

Anmerkung

EXECUTION_TIMEOUT hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von mindestens 4 Minuten. Bei der ersten Verbindung muss das Client-Gerät explizit ein TRIGGER_TOPIC abonnieren, die zuvor nicht abonniert wurde. Um den Testfall zu bestehen, muss das Client-Gerät erfolgreich TRIGGER_TOPIC mit einer QoS 1 abonnieren. Nach dem erneuten Herstellen der Verbindung wird erwartet, dass das Client-Gerät erkennt, dass eine aktive persistente Sitzung besteht. Daher sollte es die gespeicherte Nachricht akzeptieren, die vom Trigger-Thema gesendet wurde, und PUBACK für diese spezifische Nachricht zurückkehren.


"tests":[
   {
      "name":"my_mqtt_persistent_session_happy_case",
      "configuration":{
         //required:
         "TRIGGER_TOPIC": "myTrigger/topic",
         // optional:
         // if Payload not provided, a string will be stored in the trigger topic to be sent back to the client device
         "PAYLOAD": "The message which should be received from AWS IoT Broker after re-connecting to a persistent session from the specified trigger topic.",            
         "EXECUTION_TIMEOUT":"300" // in seconds
      },
      "test":{
         "id":"MQTT_Persistent_Session_Happy_Case",
         "version":"0.0.0"
      }
   }
]

„Persistent Session - Session Expiry“

Dieser Testfall hilft bei der Überprüfung des Geräteverhaltens, wenn ein getrenntes Gerät erneut eine Verbindung zu einer abgelaufenen persistenten Sitzung herstellt. Nach Ablauf der Sitzung erwarten wir, dass das Gerät die zuvor abonnierten Themen erneut abonniert, indem es explizit ein neues Paket sendet. SUBSCRIBE

Während der ersten Verbindung erwarten wir, dass das Testgerät CONNECT mit dem AWS IoT-Broker verbunden ist, da sein CleanSession Flag auf False gesetzt ist, um eine persistente Sitzung zu initiieren. Das Gerät sollte dann ein Trigger-Thema abonnieren. Nach einem erfolgreichen Abonnement und der Initiierung einer dauerhaften Sitzung wird das AWS IoT Core Gerät dann von Device Advisor getrennt. Nach dem Trennen der Verbindung ermöglicht AWS IoT Core Device Advisor dem Testgerät, sich wieder mit dem Testendpunkt zu verbinden. Wenn das Testgerät zu diesem Zeitpunkt ein weiteres CONNECT Paket sendet, sendet AWS IoT Core Device Advisor ein CONNACK Paket zurück, das angibt, dass die persistente Sitzung abgelaufen ist. Das Testgerät muss dieses Paket richtig interpretieren und es wird erwartet, dass es dasselbe Trigger-Thema erneut abonniert, wenn die persistente Sitzung beendet wird. Wenn das Testgerät seinen Themen-Trigger nicht erneut abonniert, schlägt der Testfall fehl. Damit der Test erfolgreich ist, muss das Gerät erkennen, dass die persistente Sitzung beendet ist, und in der zweiten Verbindung ein neues SUBSCRIBE Paket für dasselbe Trigger-Thema zurücksenden.

Wenn dieser Testfall für ein Testgerät erfolgreich ist, bedeutet dies, dass das Gerät in der Lage ist, die erneute Verbindung nach Ablauf der persistenten Sitzung erwartungsgemäß zu handhaben.

APIDefinition des Testfalls:

Anmerkung

EXECUTION_TIMEOUT hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von mindestens 4 Minuten. Das Testgerät muss explizit ein TRIGGER_TOPIC abonnieren, das es zuvor nicht abonniert hatte. Um den Testfall zu bestehen, muss das Testgerät ein CONNECT Paket mit einem auf False gesetzten CleanSession Flag senden und erfolgreich ein Trigger-Thema mit QoS 1 abonnieren. Nach einer erfolgreichen Verbindung trennt AWS IoT Core Device Advisor die Verbindung zum Gerät. Nach dem Trennen der Verbindung ermöglicht AWS IoT Core Device Advisor dem Gerät, wieder eine Verbindung herzustellen, und es wird erwartet, dass das Gerät dieselbe erneut abonniert, TRIGGER_TOPIC da AWS IoT Core Device Advisor die persistente Sitzung beendet hätte.


"tests":[
   {
      "name":"my_expired_persistent_session_test",
      "configuration":{
         //required:
         "TRIGGER_TOPIC": "myTrigger/topic",
         // optional:       
         "EXECUTION_TIMEOUT":"300" // in seconds
      },
      "test":{
         "id":"MQTT_Expired_Persistent_Session",
         "version":"0.0.0"
      }
   }
]

CONNECT,DISCONNECT, und RECONNECT

Anmerkung

Anmerkung

Anmerkung

Anmerkung

Anmerkung

Anmerkung

Veröffentlichen

Anmerkung

Anmerkung

Anmerkung

Anmerkung

Anmerkung

Anmerkung

Keep-Alive

Anmerkung

Persistente Sitzung

Anmerkung

Anmerkung