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.
Adapter für das Bol-RTU-Protokoll
Die microSD-RTU-Protokolladapterkomponente (aws.greengrass.Modbus) fragt Informationen von lokalen RTU-Geräten ab.
Um Informationen von einem lokalen Bol RTU-Gerät mit dieser Komponente anzufordern, veröffentlichen Sie eine Nachricht zu dem Thema, in dem diese Komponente abonniert wird. Geben Sie in der Nachricht die Bol RTU-Anforderung an, die an ein Gerät gesendet werden soll. Anschließend veröffentlicht diese Komponente eine Antwort, die das Ergebnis der Bol-RTU-Anforderung enthält.
Anmerkung
Diese Komponente bietet ähnliche Funktionen wie der Bol RTU-Protokolladapter-Konnektor in AWS IoT Greengrass V1. Weitere Informationen finden Sie unter Bol RTU-Protokolladapter-Konnektor im AWS IoT Greengrass V1-Entwicklerhandbuch.
Themen
Versionen
Diese Komponente hat die folgenden Versionen:
-
2.1.x
-
2.0.x
Typ
Diese Komponente ist eine Lambda-Komponente (aws.greengrass.lambda). Der Greengrass-Kern führt die Lambda-Funktion dieser Komponente mit der Lambda-Launcher-Komponente aus.
Weitere Informationen finden Sie unter Komponententypen.
Betriebssystem
Diese Komponente kann nur auf Linux-Core-Geräten installiert werden.
Voraussetzungen
Für diese Komponente gelten die folgenden Anforderungen:
-
Ihr Core-Gerät muss die Anforderungen für die Ausführung von Lambda-Funktionen erfüllen. Wenn Sie möchten, dass das Core-Gerät containerisierte Lambda-Funktionen ausführt, muss das Gerät die Voraussetzungen dafür erfüllen. Weitere Informationen finden Sie unter Anforderungen an die Lambda-Funktion.
-
Python
Version 3.7 ist auf dem Core-Gerät installiert und der PATH-Umgebungsvariablen hinzugefügt. -
Eine physische Verbindung zwischen dem AWS IoT Greengrass Core-Gerät und den Bol-Geräten. Das Core-Gerät muss physisch über einen seriellen Port, z. B. einen USB-Port, mit dem Bol RTU-Netzwerk verbunden sein.
-
Um Ausgabedaten von dieser Komponente zu erhalten, müssen Sie das folgende Konfigurationsupdate für die Legacy-Abonnement-Routerkomponente (
aws.greengrass.LegacySubscriptionRouter) zusammenführen, wenn Sie diese Komponente bereitstellen. Diese Konfiguration gibt das Thema an, in dem diese Komponente Antworten veröffentlicht.Weitere Informationen finden Sie unter Erstellen von Bereitstellungen.
-
Der Bol-RTU-Protokolladapter wird für die Ausführung in einer VPC unterstützt.
Abhängigkeiten
Wenn Sie eine Komponente bereitstellen, stellt AWS IoT Greengrass auch kompatible Versionen ihrer Abhängigkeiten bereit. Das bedeutet, dass Sie die Anforderungen für die Komponente und alle ihre Abhängigkeiten erfüllen müssen, um die Komponente erfolgreich bereitzustellen. In diesem Abschnitt werden die Abhängigkeiten für die veröffentlichten Versionen dieser Komponente und die semantischen Versionseinschränkungen aufgeführt, die die Komponentenversionen für jede Abhängigkeit definieren. Sie können auch die Abhängigkeiten für jede Version der Komponente in der AWS IoT Greengrass Konsole
Weitere Informationen zu Komponentenabhängigkeiten finden Sie in der Referenz zum Komponentenrezept .
Konfiguration
Diese Komponente bietet die folgenden Konfigurationsparameter, die Sie anpassen können, wenn Sie die Komponente bereitstellen.
Anmerkung
Die Standardkonfiguration dieser Komponente enthält Lambda-Funktionsparameter. Wir empfehlen Ihnen, nur die folgenden Parameter zu bearbeiten, um diese Komponente auf Ihren Geräten zu konfigurieren.
Eingabedaten
Diese Komponente akzeptiert Bol RTU-Anforderungsparameter zum folgenden Thema und sendet die RTU-Anforderung an das Gerät. Standardmäßig abonniert diese Komponente lokale Veröffentlichungs-/Abonnementnachrichten. Weitere Informationen zum Veröffentlichen von Nachrichten in dieser Komponente aus Ihren benutzerdefinierten Komponenten finden Sie unter Lokale Nachrichten veröffentlichen/abonnieren.
Standardthema (lokales Veröffentlichen/Abonnieren): modbus/adapter/request
Die Nachricht akzeptiert die folgenden Eigenschaften. Eingabenachrichten müssen im JSON-Format vorliegen.
request-
Die Parameter für die zu sendende Bol RTU-Anforderung.
Die Form der Anforderungsnachricht hängt von der Art der Bol-RTU-Anforderung ab, die sie darstellt. Die folgenden Eigenschaften sind für alle Anforderungen erforderlich.
Typ:
object, der die folgenden Informationen enthält:operation-
Der Name der auszuführenden Operation. Geben Sie zum Beispiel an,
ReadCoilsRequestum Telefonie auf einem microSD-RTU-Gerät zu lesen. Weitere Informationen zu unterstützten Operationen finden Sie unter Modbus RTU-Anforderungen und -Antworten.Typ:
string device-
Das Zielgerät der Anfrage.
Dieser Wert muss eine Ganzzahl zwischen
0und sein247.Typ:
integer
Die weiteren Parameter, die in die Anforderung aufgenommen werden sollen, hängen von der Operation ab. Diese Komponente übernimmt die zyklische Redundanzprüfung (CRC),
um Datenanforderungen für Sie zu überprüfen. Anmerkung
Wenn Ihre Anforderung eine -
addressEigenschaft enthält, müssen Sie ihren Wert als Ganzzahl angeben. Beispiel:"address": 1 id-
Eine willkürliche ID für die Anforderung. Verwenden Sie diese Eigenschaft, um eine Eingabeanforderung einer Ausgabeantwort zuzuordnen. Wenn Sie diese Eigenschaft angeben, legt die Komponente die
idEigenschaft im Antwortobjekt auf diesen Wert fest.Typ:
string
Beispieleingabe: Lesen Spulenanforderungen
{ "request": { "operation": "ReadCoilsRequest", "device": 1, "address": 1, "count": 1 }, "id": "MyRequest" }
Ausgabedaten
Diese Komponente veröffentlicht Antworten standardmäßig als Ausgabedaten zum folgenden MQTT-Thema. Sie müssen dieses Thema als subject in der Konfiguration für die Legacy-Abonnement-Routerkomponente angeben. Weitere Informationen zum Abonnieren von Nachrichten zu diesem Thema in Ihren benutzerdefinierten Komponenten finden Sie unter MQTT-Nachrichten veröffentlichen/abonnieren AWS IoT Core.
Standardthema (AWS IoT Core MQTT): modbus/adapter/response
Die Form der Antwortnachricht hängt von der Anforderungsoperation und dem Antwortstatus ab. Beispiele finden Sie unter Beispiel: Anforderungen und Antworten.
Jede Antwort beinhaltet die folgenden Eigenschaften:
response-
Die Antwort des Bol RTU-Geräts.
Typ:
object, der die folgenden Informationen enthält:status-
Der Status der Anforderung. Der Status kann einer der folgenden Werte sein:
-
Success– Die Anforderung war gültig, die Komponente hat die Anforderung an das Bol-RTU-Netzwerk gesendet und das-RTU-Netzwerk hat eine Antwort zurückgegeben. -
Exception– Die Anforderung war gültig, die Komponente hat die Anforderung an das Bol-RTU-Netzwerk gesendet und das Bol-RTU-Netzwerk hat eine Ausnahme zurückgegeben. Weitere Informationen finden Sie unter Antwortstatus: Ausnahme. -
No Response– Die Anforderung war ungültig, und die Komponente hat den Fehler erkannt, bevor sie die Anforderung an das Bol-RTU-Netzwerk gesendet hat. Weitere Informationen finden Sie unter Antwortstatus: Keine Antwort.
-
operation-
Der Vorgang, den die Komponente angefordert hat.
device-
Das Gerät, an das die Komponente die Anforderung gesendet hat.
payload-
Die Antwort des Bol RTU-Geräts. Wenn
statusistNo Response, enthält dieses Objekt nur eine -errorEigenschaft mit der Beschreibung des Fehlers (z. B.[Input/Output] No Response received from the remote unit).
id-
Die ID der Anforderung, mit der Sie ermitteln können, welche Antwort welcher Anforderung entspricht.
Anmerkung
Eine Antwort für einen Schreibvorgang ist lediglich ein Echo der Anforderung. Obwohl Schreibantworten keine aussagekräftigen Informationen enthalten, empfiehlt es sich, den Status der Antwort zu überprüfen, um festzustellen, ob die Anforderung erfolgreich ist oder fehlschlägt.
Beispielausgabe: Erfolg
{ "response" : { "status" : "success", "device": 1, "operation": "ReadCoilsRequest", "payload": { "function_code": 1, "bits": [1] } }, "id" : "MyRequest" }
Beispielausgabe: Fehler
{ "response" : { "status" : "fail", "error_message": "Internal Error", "error": "Exception", "device": 1, "operation": "ReadCoilsRequest", "payload": { "function_code": 129, "exception_code": 2 } }, "id" : "MyRequest" }
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.
- Lesen Sie sich die Abschnitte durch
-
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" } - Lesen diskreter Eingaben
-
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 Warteregistern
-
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" } - Leseeingabe-Register
-
Anfragebeispiel:
{ "request": { "operation": "ReadInputRegistersRequest", "device": 1, "address": 1, "count": 1 }, "id": "TestRequest" } - Schreiben einer einzelnen Kabel
-
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 einzelnen Registers
-
Anfragebeispiel:
{ "request": { "operation": "WriteSingleRegisterRequest", "device": 1, "address": 1, "value": 1 }, "id": "TestRequest" } - Schreiben mehrerer Kabel
-
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" } - Schreibregister maskieren
-
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 von Schreibvorgängen für mehrere 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 Antwort enthält die Registrierungen, die die Komponente liest.
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
statuswird aufExceptiongesetzt. -
Der
function_codeentspricht dem Funktionscode der Anforderung + 128. -
Der
exception_codeenthä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
statuswird aufNo Responsegesetzt. -
Der
errorenthält die Fehlerursache. -
Die
error_messageenthä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 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" }
Lokale Protokolldatei
Diese Komponente verwendet die folgende Protokolldatei.
/logs/aws.greengrass.Modbus.log/greengrass/v2
So zeigen Sie die Protokolle dieser Komponente an
-
Führen Sie den folgenden Befehl auf dem Core-Gerät aus, um die Protokolldatei dieser Komponente in Echtzeit anzuzeigen. Ersetzen Sie durch
/greengrass/v2sudo tail -f/greengrass/v2
Lizenzen
Diese Komponente umfasst die folgende Software/Lizenzierung von Drittanbietern:
Diese Komponente wird gemäß dem Greengrass Core Software License Agreement
Änderungsprotokoll
In der folgenden Tabelle werden die Änderungen in jeder Version der Komponente beschrieben.
|
Version |
Änderungen |
|---|---|
|
2.1.8 |
Version für Greengrass-Kern Version 2.12.0 aktualisiert. |
|
2.1.7 |
Version für Greengrass-Kern Version 2.11.0 aktualisiert. |
|
2.1.6 |
Version für Greengrass-Kernversion 2.10.0 aktualisiert. |
|
2.1.5 |
|
|
2.1.4 |
Version für Greengrass-Kern Version 2.9.0 aktualisiert. |
|
2.1.3 |
Version für Greengrass-Kern Version 2.8.0 aktualisiert. |
|
2.1.2 |
Version für Greengrass-Kern Version 2.7.0 aktualisiert. |
|
2.1.1 |
Version für Greengrass-Kern Version 2.6.0 aktualisiert. |
|
2.1.0 |
|
|
2.0.8 |
Version für Greengrass-Kern Version 2.5.0 aktualisiert. |
|
2.0.7 |
Version für Greengrass-Kern Version 2.4.0 aktualisiert. |
|
2.0.6 |
Version für Greengrass-Kern Version 2.3.0 aktualisiert. |
|
2.0.5 |
Version für Greengrass-Kern Version 2.2.0 aktualisiert. |
|
2.0.4 |
Version für Greengrass-Kern Version 2.1.0 aktualisiert. |
|
2.0.3 |
Erste Version |
