Modbus-RTU-Protokolladapter -Konnektor - AWS IoT Greengrass
VoraussetzungenParameterEingabedatenAusgabedatenModbus RTU-Anforderungen und -AntwortenVerwendungsbeispielLizenzenÄnderungsprotokollWeitere Informationen finden Sie auch unter

AWS IoT Greengrass Version 1 trat am 30. Juni 2023 in die erweiterte Lebensphase ein. Weitere Informationen finden Sie in der AWS IoT Greengrass V1 Wartungsrichtlinie. Nach diesem Datum AWS IoT Greengrass V1 werden keine Updates mehr veröffentlicht, die Funktionen, Verbesserungen, Bugfixes oder Sicherheitspatches bieten. Geräte, die auf laufen, werden AWS IoT Greengrass V1 nicht gestört und funktionieren weiterhin und stellen eine Verbindung zur Cloud her. Wir empfehlen Ihnen dringend, zu migrieren AWS IoT Greengrass Version 2, da dies wichtige neue Funktionen und Unterstützung für zusätzliche Plattformen bietet.

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.

Modbus-RTU-Protokolladapter -Konnektor

Der Modbus-RTU-ProtokolladapterAnschlussfragt Informationen von Modbus RTU-Geräten ab, die sich im befindenAWS IoT GreengrassGruppe.

Dieser Konnektor empfängt Parameter für eine Modbus RTU-Anforderung von einer benutzerdefinierten Lambda-Funktion. Er sendet die entsprechende Anforderung und veröffentlicht dann die Antwort des Zielgeräts als MQTT-Nachricht.

Dieser Konnektor hat die folgenden Versionen.

Version

ARN

3

arn:aws:greengrass:region::/connectors/ModbusRTUProtocolAdapter/versions/3

2

arn:aws:greengrass:region::/connectors/ModbusRTUProtocolAdapter/versions/2

1

arn:aws:greengrass:region::/connectors/ModbusRTUProtocolAdapter/versions/1

Informationen über Versionsänderungen finden Sie im Änderungsprotokoll.

Voraussetzungen

Dieser Konnektor hat die folgenden Anforderungen:

Version 3

  • AWS IoT Greengrass Core-Software v1.9.3 oder höher.

  • PythonVersion 3.7 oder 3.8 auf dem Core-Gerät installiert und der Umgebungsvariablen PATH hinzugefügt.

    Anmerkung

    Um Python 3.8 zu verwenden, führen Sie den folgenden Befehl aus, um einen symbolischen Link vom standardmäßigen Python 3.7-Installationsordner zu den installierten Python 3.8-Binärdateien zu erstellen.

    sudo ln -s path-to-python-3.8/python3.8 /usr/bin/python3.7

    Dadurch wird Ihr Gerät so konfiguriert, dass es die Python-Anforderung für AWS IoT Greengrass erfüllt.

  • Eine physikalische Verbindung zwischen demAWS IoT Greengrass-Core und die Modbus-Geräte. Der Core muss physisch über eine serielle Schnittstelle (z. B. eine USB-Schnittstelle) mit dem Modbus RTU-Netzwerk verbunden sein.

  • EINlokale Geräteressourcein der Greengrass-Gruppe, der auf die physische serielle Modbus-Schnittstelle zeigt.

  • Eine benutzerdefinierte Lambda-Funktion, die Modbus RTU-Anforderungsparameter an diesen Konnektor sendet. Die Anforderungsparameter müssen den erwarteten Mustern entsprechen und die IDs und Adressen der Zielgeräte im Modbus RTU-Netzwerk beinhalten. Weitere Informationen finden Sie unter Eingabedaten.

Versions 1 - 2

  • AWS IoT GreengrassCore-Software v1.7 oder höher.

  • PythonVersion 2.7 auf dem Core-Gerät installiert und der Umgebungsvariablen PATH hinzugefügt.

  • Eine physikalische Verbindung zwischen demAWS IoT Greengrass-Core und die Modbus-Geräte. Der Core muss physisch über eine serielle Schnittstelle (z. B. eine USB-Schnittstelle) mit dem Modbus RTU-Netzwerk verbunden sein.

  • EINlokale Geräteressourcein der Greengrass-Gruppe, der auf die physische serielle Modbus-Schnittstelle zeigt.

  • Eine benutzerdefinierte Lambda-Funktion, die Modbus RTU-Anforderungsparameter an diesen Konnektor sendet. Die Anforderungsparameter müssen den erwarteten Mustern entsprechen und die IDs und Adressen der Zielgeräte im Modbus RTU-Netzwerk beinhalten. Weitere Informationen finden Sie unter Eingabedaten.

Connector-Parameter

Dieser Konnektor unterstützt die folgenden Parameter:

ModbusSerialPort-ResourceId

Die ID der lokalen Geräteressource, die die physische serielle Modbus-Schnittstelle darstellt.

Anmerkung

Dieser Konnektor hat Zugriff zum Lesen und Schreiben auf die Ressource.

Anzeigename imAWS IoT-Konsole Modbus-Schnittstelle -Ressource

Erforderlich:true

Typ: string

Gültiges Pattern:.+

ModbusSerialPort

Der absolute Pfad zur physikalischen seriellen Modbus-Schnittstelle auf dem Gerät. Dies ist der Quellpfad, der für die lokale Modbus-Geräteressource angegeben ist.

Anzeigename imAWS IoT-Konsole Quellpfad der Ressource der seriellen Modbus-Schnittstelle

Erforderlich:true

Typ: string

Gültiges Pattern:.+

Beispiel für das Erstellen eines Konnektors (AWS CLI)

Der folgende -CLI-Befehl erstellt eineConnectorDefinitionmit einer Erstversion, die den Modbus-RTU-Protokolladapter enthält.

aws greengrass create-connector-definition --name MyGreengrassConnectors --initial-version '{
    "Connectors": [
        {
            "Id": "MyModbusRTUProtocolAdapterConnector",
            "ConnectorArn": "arn:aws:greengrass:region::/connectors/ModbusRTUProtocolAdapter/versions/3",
            "Parameters": {
                "ModbusSerialPort-ResourceId": "MyLocalModbusSerialPort",
                "ModbusSerialPort": "/path-to-port"
            }
        }
    ]
}'
Anmerkung

Die Lambda-Funktion in diesem Konnektor hat einelanglebiglebenszyklus.

In derAWS IoT Greengrass-Konsole können Sie einen Connector aus demKonnektorenangezeigten. Weitere Informationen finden Sie unter Erste Schritte mit Greengrass-Konnektoren (Konsole).

Anmerkung

Nach der Bereitstellung des Modbus-RTU-Protokolladapters -Konnektors können Sie verwendenAWS IoT Things Graphum Interaktionen zwischen Geräten in Ihrer Gruppe zu orchestrieren. Weitere Informationen finden Sie unter Modbus im AWS IoT Things Graph-Benutzerhandbuch.

Eingabedaten

Dieser Konnektor akzeptiert Modbus RTU-Anforderungsparameter von einer benutzerdefinierten Lambda-Funktion zu einem MQTT-Thema. Eingabemeldungen müssen im JSON-Format vorliegen.

Themenfilter im Abonnement

modbus/adapter/request

Nachrichten-Eigenschaften

Die Anforderungsnachricht variiert je nach Art der Modbus RTU-Anfrage, die sie darstellt. Die folgenden Eigenschaften werden für alle Anforderungen benötigt:

  • Im request-Objekt:

    • operation. Der Name des auszuführenden Vorgangs. Geben Sie beispielsweise an, dass "operation": "ReadCoilsRequest" Spulen lesen soll. Dieser Wert muss eine Unicode-Zeichenfolge sein. Informationen zu unterstützten Vorgängen finden Sie unter Modbus RTU-Anforderungen und -Antworten.

    • device. Das Zielgerät der Anfrage. Dieser Wert muss zwischen 0 - 247 liegen.

  • Die id-Eigenschaft. Eine ID für die Anforderung. Dieser Wert wird für die Datendeduplizierung verwendet und wie bei der id-Eigenschaft aller Antworten, einschließlich Fehlerantworten, zurückgegeben. Dieser Wert muss eine Unicode-Zeichenfolge sein.

Anmerkung

Wenn Ihre Anforderung ein Adressfeld enthält, müssen Sie den Wert als Ganzzahl angeben. Zum Beispiel "address": 1.

Die weiteren Parameter, die in die Anforderung aufgenommen werden sollen, hängen von der Operation ab. Alle Anforderungsparameter sind erforderlich, mit Ausnahme der CRC, die separat behandelt wird. Beispiele finden Sie unter Beispiel: Anforderungen und Antworten.

Beispieleingabe: Spulen lesen
{
    "request": {
        "operation": "ReadCoilsRequest",
    	"device": 1,
    	"address": 1,
    	"count": 1
    },
    "id": "TestRequest"
}

Ausgabedaten

Dieser Konnektor veröffentlicht Antworten auf eingehende Modbus RTU-Anfragen.

Themenfilter im Abonnement

modbus/adapter/response

Nachrichten-Eigenschaften

Das Format der Antwortnachricht variiert je nach Anforderung und Antwortstatus. Beispiele finden Sie unter Beispiel: Anforderungen und Antworten.

Anmerkung

Eine Antwort für einen Schreibvorgang ist lediglich ein Echo der Anforderung. Obwohl keine aussagekräftigen Informationen für Schreibantworten zurückgegeben werden, ist es eine gute Vorgehensweise, den Status der Antwort zu überprüfen.

Jede Antwort beinhaltet die folgenden Eigenschaften:

  • Im response-Objekt:

    • status. Der Status der Anfrage. Der Status kann einer der folgenden Werte sein:

      • Success. Die Anfrage war gültig, wurde an das Modbus RTU-Netzwerk gesendet und eine Antwort wurde zurückgegeben.

      • Exception. Die Anfrage war gültig, wurde an das Modbus-RTU-Netzwerk gesendet und eine Ausnahmeantwort wurde zurückgegeben. Weitere Informationen finden Sie unter Antwortstatus: Exception.

      • No Response. Die Anforderung war ungültig, und der Konnektor hat den Fehler abgefangen, bevor die Anforderung über das Modbus RTU-Netzwerk gesendet wurde. Weitere Informationen finden Sie unter Antwortstatus: Keine Antwort.

    • device. Das Gerät, an das die Anforderung gesendet wurde.

    • operation. Der Anfragetyp, der gesendet wurde.

    • payload. Der Antwortinhalt, der zurückgegeben wurde. Wenn der status No Response ist, enthält dieses Objekt nur eine error-Eigenschaft mit der Fehlerbeschreibung (z. B. "error": "[Input/Output] No Response received from the remote unit").

  • Die id-Eigenschaft. Die ID der Anforderung, die für die Datendeduplizierung verwendet wird.

Beispielausgabe: Herzlichen Glückwunsch
{
    "response" : {
        "status" : "success",
        "device": 1,
    	"operation": "ReadCoilsRequest",
    	"payload": {
        	"function_code": 1,
        	"bits": [1]
    	}
     },
     "id" : "TestRequest"
}
Beispielausgabe: Fehler
{
    "response" : {
        "status" : "fail",
        "error_message": "Internal Error",
        "error": "Exception",
        "device": 1,
    	"operation": "ReadCoilsRequest",
    	"payload": {
        	"function_code": 129,
        	"exception_code": 2
    	}
     },
     "id" : "TestRequest"
}

Weitere Beispiele finden Sie unter Beispiel: Anforderungen und Antworten.

Modbus RTU-Anforderungen und -Antworten

Dieser Konnektor akzeptiert Modbus RTU-Anfrageparameter als Eingabedaten und veröffentlicht Antworten als Ausgabedaten.

Die folgenden allgemeinen Operationen werden unterstützt.

Vorgangsname in Anforderung Funktionscode in Antwort
ReadCoilsRequest 01
ReadDiscreteInputsRequest 02
ReadHoldingRegistersRequest 03
ReadInputRegistersRequest 04
WriteSingleCoilRequest 05
WriteSingleRegisterRequest 06
WriteMultipleCoilsRequest 15
WriteMultipleRegistersRequest 16
MaskWriteRegisterRequest 22
ReadWriteMultipleRegistersRequest 23

Im Folgenden finden Sie Beispiele für Anfragen und Antworten für unterstützte Operationen.

Spulen lesen

Anfragebeispiel:

{
    "request": {
        "operation": "ReadCoilsRequest",
    	"device": 1,
    	"address": 1,
    	"count": 1
    },
    "id": "TestRequest"
}

Antwortbeispiel:

{
    "response": {
        "status": "success",
        "device": 1,
    	"operation": "ReadCoilsRequest",
    	"payload": {
        	"function_code": 1,
        	"bits": [1]
    	}
     },
     "id" : "TestRequest"
}
Digitaleingänge lesen

Anfragebeispiel:

{
    "request": {
        "operation": "ReadDiscreteInputsRequest",
        "device": 1,
        "address": 1,
        "count": 1
    },
    "id": "TestRequest"
}

Antwortbeispiel:

{
    "response": {
        "status": "success",
        "device": 1,
        "operation": "ReadDiscreteInputsRequest",
        "payload": {
            "function_code": 2,
            "bits": [1]
        }
     },
     "id" : "TestRequest"
}
Lesen von Holdingregistern

Anfragebeispiel:

{
    "request": {
        "operation": "ReadHoldingRegistersRequest",
    	"device": 1,
    	"address": 1,
    	"count": 1
    },
    "id": "TestRequest"
}

Antwortbeispiel:

{
    "response": {
        "status": "success",
        "device": 1,
    	"operation": "ReadHoldingRegistersRequest",
    	"payload": {
    	    "function_code": 3,
            "registers": [20,30]
    	}
     },
     "id" : "TestRequest"
}
Lesen von Eingangsregistern

Anfragebeispiel:

{
    "request": {
        "operation": "ReadInputRegistersRequest",
    	"device": 1,
    	"address": 1,
    	"value": 1
    },
    "id": "TestRequest"
}
Schreiben Einzelspule

Anfragebeispiel:

{
    "request": {
        "operation": "WriteSingleCoilRequest",
    	"device": 1,
    	"address": 1,
    	"value": 1
    },
    "id": "TestRequest"
}

Antwortbeispiel:

{
    "response": {
        "status": "success",
        "device": 1,
    	"operation": "WriteSingleCoilRequest",
    	"payload": {
    	    "function_code": 5,
    	    "address": 1,
    	    "value": true
    	}
     },
     "id" : "TestRequest"
Schreiben eines Einzelregisters

Anfragebeispiel:

{
    "request": {
        "operation": "WriteSingleRegisterRequest",
    	"device": 1,
    	"address": 1,
    	"value": 1
    },
    "id": "TestRequest"
}
Schreiben mehrerer Spulen

Anfragebeispiel:

{
    "request": {
        "operation": "WriteMultipleCoilsRequest",
    	"device": 1,
    	"address": 1,
    	"values": [1,0,0,1]
    },
    "id": "TestRequest"
}

Antwortbeispiel:

{
    "response": {
        "status": "success",
        "device": 1,
    	"operation": "WriteMultipleCoilsRequest",
    	"payload": {
    	    "function_code": 15,
    	    "address": 1,
    	    "count": 4
    	}
     },
     "id" : "TestRequest"
}
Schreiben mehrerer Register

Anfragebeispiel:

{
    "request": {
        "operation": "WriteMultipleRegistersRequest",
    	"device": 1,
    	"address": 1,
    	"values": [20,30,10]
    },
    "id": "TestRequest"
}

Antwortbeispiel:

{
    "response": {
        "status": "success",
        "device": 1,
    	"operation": "WriteMultipleRegistersRequest",
    	"payload": {
    	    "function_code": 23,
    	    "address": 1,
       		"count": 3
    	}
     },
     "id" : "TestRequest"
}
Masken-Schreibregister

Anfragebeispiel:

{
    "request": {
        "operation": "MaskWriteRegisterRequest",
    	"device": 1,
    	"address": 1,
        "and_mask": 175,
        "or_mask": 1
    },
    "id": "TestRequest"
}

Antwortbeispiel:

{
    "response": {
        "status": "success",
        "device": 1,
    	"operation": "MaskWriteRegisterRequest",
    	"payload": {
    	    "function_code": 22,
            "and_mask": 0,
            "or_mask": 8
    	}
     },
     "id" : "TestRequest"
}
Lesen mehrerer Register

Anfragebeispiel:

{
    "request": {
        "operation": "ReadWriteMultipleRegistersRequest",
    	"device": 1,
    	"read_address": 1,
        "read_count": 2,
        "write_address": 3,
        "write_registers": [20,30,40]
    },
    "id": "TestRequest"
}

Antwortbeispiel:

{
    "response": {
        "status": "success",
        "device": 1,
    	"operation": "ReadWriteMultipleRegistersRequest",
    	"payload": {
    	    "function_code": 23,
    	    "registers": [10,20,10,20]
    	}
     },
     "id" : "TestRequest"
}
Anmerkung

Die in dieser Antwort zurückgegebenen Register sind die Register, aus denen gelesen wird.

Ausnahmen können auftreten, wenn das Anfrageformat gültig ist, die Anfrage aber nicht erfolgreich abgeschlossen wurde. In diesem Fall enthält die Antwort die folgenden Informationen:

  • Der status wird auf Exception gesetzt.

  • Der function_code entspricht dem Funktionscode der Anforderung + 128.

  • Der exception_code enthält den Ausnahmecode. Weitere Informationen finden Sie unter Modbus-Ausnahmecodes.

Beispiel:

{
    "response" : {
        "status" : "fail",
        "error_message": "Internal Error",
        "error": "Exception",
        "device": 1,
    	"operation": "ReadCoilsRequest",
    	"payload": {
        	"function_code": 129,
        	"exception_code": 2
    	}
     },
     "id" : "TestRequest"
}

Dieser Konnektor führt Validierungsprüfungen für die Modbus-Anforderung durch. So wird beispielsweise nach ungültigen Formaten und fehlenden Feldern gesucht. Wenn die Validierung fehlschlägt, sendet der Konnektor die Anforderung nicht. Stattdessen gibt er eine Antwort zurück, die die folgenden Informationen enthält:

  • Der status wird auf No Response gesetzt.

  • Dieerrorenthält den Grund für den Fehler.

  • Die error_message enthält die Fehlermeldung.

Beispiele:

{
    "response" : {
        "status" : "fail",
        "error_message": "Invalid address field. Expected <type 'int'>, got <type 'str'>",
        "error": "No Response",
        "device": 1,
    	"operation": "ReadCoilsRequest",
    	"payload": {
        	"error": "Invalid address field. Expected <type 'int'>, got <type 'str'>"
    	}
     },
     "id" : "TestRequest"
}

Wenn die Anforderung auf ein nicht vorhandenes Gerät abzielt oder wenn das Modbus RTU-Netzwerk nicht funktioniert, erhalten Sie möglicherweise eine ModbusIOException, die das No Response-Format verwendet.

{
    "response" : {
        "status" : "fail",
        "error_message": "[Input/Output] No Response received from the remote unit",
        "error": "No Response",
        "device": 1,
    	"operation": "ReadCoilsRequest",
    	"payload": {
        	"error": "[Input/Output] No Response received from the remote unit"
    	}
     },
     "id" : "TestRequest"
}

Verwendungsbeispiel

Führen Sie die folgenden allgemeinen Schritte aus, um eine Python 3.7—Beispielfunktion Lambda einzurichten, mit der Sie den Konnektor ausprobieren können.

Anmerkung

  1. Stellen Sie sicher, dass Sie die Anforderungen für den Konnektor erfüllen.

  2. Erstellen und veröffentlichen Sie eine Lambda-Funktion, die Eingabedaten an den -Konnektor sendet.

    Speichern Sie den Beispielcode als PY-Datei. Downloaden und entpacken Sie esAWS IoT GreengrassCore-SDK für Python. Erstellen Sie dann ein ZIP-Paket, das die PY-Datei und den Ordner greengrasssdk auf Stammebene enthält. Dieses ZIP-Paket ist das Bereitstellungspaket, das Sie auf hochladenAWS Lambda.

    Nachdem Sie die Python 3.7-Lambda-Funktion erstellt haben, veröffentlichen Sie eine Funktionsversion und erstellen Sie einen Alias.

  3. Konfigurieren Sie Ihre Greengrass-Gruppe.

    1. Fügen Sie die Lambda-Funktion über ihren Alias hinzu (empfohlen). Konfiguration des Lambda-Lebenszyklus als langlebig (oder"Pinned": truein der CLI).

    2. Fügen Sie die erforderliche lokale Geräteressource hinzu und gewähren Sie Lese-/Schreibzugriff auf die Lambda-Funktion.

    3. Fügen Sie den Konnektor hinzu und konfigurieren Sie seine Parameter.

    4. Fügen Sie Abonnements hinzu, die es dem Konnektor ermöglichen, Eingabedaten zu empfangen und Ausgabedaten zu unterstützten Themenfiltern zu senden.

      • Legen Sie die Lambda-Funktion als Quelle und den Konnektor als Ziel fest und verwenden Sie einen unterstützten Eingabethemenfilter.

      • Legen Sie den Konnektor als Quelle und AWS IoT Core als Ziel fest und verwenden Sie einen unterstützten Ausgabethemenfilter. Sie verwenden dieses Abonnement zum Anzeigen von Statusmeldungen imAWS IoTconsole.

  4. Stellen Sie die Gruppe bereit.

  5. In derAWS IoT-Konsole auf derTestdas Thema Ausgabedaten abonnieren, um Statusmeldungen vom Connector anzuzeigen. Die -Beispielfunktion Lambda ist langlebig und beginnt sofort nach der Bereitstellung der Gruppe mit dem Senden von Nachrichten.

    Wenn Sie mit dem Testen fertig sind, können Sie den Lambda-Lebenszyklus auf On-Demand (oder"Pinned": falsein der CLI) und stellen Sie die Gruppe bereit. Dadurch wird verhindert, dass die Funktion Nachrichten sendet.

Beispiel

Die folgende Lambda-Beispielfunktion sendet eine Eingabemeldung an den Konnektor.

import greengrasssdk
import json

TOPIC_REQUEST = 'modbus/adapter/request'

# Creating a greengrass core sdk client
iot_client = greengrasssdk.client('iot-data')

def create_read_coils_request():
	request = {
		"request": {
			"operation": "ReadCoilsRequest",
			"device": 1,
			"address": 1,
			"count": 1
		},
		"id": "TestRequest"
	}
	return request

def publish_basic_request():
	iot_client.publish(payload=json.dumps(create_read_coils_request()), topic=TOPIC_REQUEST)

publish_basic_request()

def lambda_handler(event, context):
	return

Lizenzen

Der Modbus-RTU-Protokolladapter enthält die folgende Drittanbieter-Software/Lizenz:

Dieser Connector wird unter demLizenzvereinbarung für die Greengrass Core-Software.

Änderungsprotokoll

In der folgenden Tabelle werden die wichtigen Änderungen in jeder Version des -Konnektors für beschrieben.

Version

Änderungen

3

Die Lambda-Laufzeitumgebung wurde auf Python 3.7 aktualisiert, was die Laufzeitanforderung ändert.

2

Konnektor-ARN aktualisiert fürAWS-Region-Support.

Verbesserte Fehlerprotokollierung.

1

Erstversion.

Eine Greengrass-Gruppe kann nur jeweils eine Version des -Konnektors enthalten. Weitere Informationen zum Aktualisieren einer Konnektorversion finden Sie unter Aktualisieren von Konnektorversionen.

Weitere Informationen finden Sie auch unter