Avis de fin de support : le 7 octobre 2026, AWS le support de. AWS IoT Greengrass Version 1 Après le 7 octobre 2026, vous ne pourrez plus accéder aux AWS IoT Greengrass V1 ressources. Pour plus d'informations, rendez-vous sur [Migrer depuis AWS IoT Greengrass Version 1](https://docs.aws.amazon.com/greengrass/v2/developerguide/migrate-from-v1.html). Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Connecteur adaptateur de protocole Modbus-RTU Le [connecteur](connectors.md) de l'adaptateur de protocole Modbus-RTU interroge les informations des appareils Modbus RTU du groupe. AWS IoT Greengrass Ce connecteur reçoit les paramètres d'une demande Modbus RTU à partir d'une fonction Lambda définie par l'utilisateur. Il envoie la demande correspondante, puis publie la réponse à partir du périphérique cible comme un message MQTT. Ce connecteur est disponible dans les versions suivantes. | 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` | Pour obtenir des informations sur les changements apportés aux versions, veuillez consulter le [Journal des modifications](#modbus-protocol-adapter-connector-changelog). ## Exigences Ce connecteur possède les critères suivants : ------ #### [ Version 3 ] + AWS IoT Greengrass Logiciel de base v1.9.3 ou version ultérieure. + [Python](https://www.python.org/) version 3.7 ou 3.8 installé sur le périphérique principal et ajouté à la variable d'environnement PATH. **Note** Pour utiliser Python 3.8, exécutez la commande suivante pour créer un lien symbolique entre le dossier d'installation par défaut de Python 3.7 et les fichiers binaires Python 3.8 installés. ``` sudo ln -s path-to-python-3.8/python3.8 /usr/bin/python3.7 ``` Ceci configure votre appareil de sorte qu'il réponde aux exigence de Python pour AWS IoT Greengrass. + Connexion physique entre le AWS IoT Greengrass cœur et les appareils Modbus. Le noyau doit être physiquement connecté au réseau Modbus RTU via un port série (par exemple, un port USB). + Une [ressource de périphérique locale](access-local-resources.md) du groupe Greengrass qui pointe vers le port série physique Modbus. + Fonction Lambda définie par l'utilisateur qui envoie les paramètres de requête Modbus RTU à ce connecteur. Les paramètres de demande doivent être conformes aux modèles attendus et inclure les adresses IDs et des équipements cibles sur le réseau Modbus RTU. Pour de plus amples informations, veuillez consulter [Données d’entrée](#modbus-protocol-adapter-connector-data-input). ------ #### [ Versions 1 - 2 ] + AWS IoT Greengrass Logiciel principal v1.7 ou version ultérieure. + [Python](https://www.python.org/) version 2.7 installé sur le périphérique principal et ajouté à la variable d'environnement PATH. + Connexion physique entre le AWS IoT Greengrass cœur et les appareils Modbus. Le noyau doit être physiquement connecté au réseau Modbus RTU via un port série (par exemple, un port USB). + Une [ressource de périphérique locale](access-local-resources.md) du groupe Greengrass qui pointe vers le port série physique Modbus. + Fonction Lambda définie par l'utilisateur qui envoie les paramètres de requête Modbus RTU à ce connecteur. Les paramètres de demande doivent être conformes aux modèles attendus et inclure les adresses IDs et des équipements cibles sur le réseau Modbus RTU. Pour de plus amples informations, veuillez consulter [Données d’entrée](#modbus-protocol-adapter-connector-data-input). ------ ## Paramètres du connecteur Ce connecteur prend en charge les paramètres suivants : `ModbusSerialPort-ResourceId` L'ID de la ressource de l'appareil local qui représente le port série physique Modbus. Ce connecteur bénéficie d'un accès en lecture/écriture à la ressource. Nom affiché dans la AWS IoT console : ressource du **port série Modbus** Nécessaire : `true` Type : `string` Schéma valide : `.+` `ModbusSerialPort` Chemin d'accès absolu au port série Modbus physique sur le périphérique. Il s'agit du chemin d'accès source qui est spécifié pour la ressource du périphérique local Modbus. Nom affiché dans la AWS IoT console : **chemin source de la ressource du port série Modbus** Nécessaire : `true` Type : `string` Schéma valide : `.+` ### Exemple de création de connecteur (AWS CLI) La commande CLI suivante crée un `ConnectorDefinition` avec une version initiale contenant le connecteur d'adaptateur de protocole Modbus-RTU. ``` 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" } } ] }' ``` **Note** La fonction Lambda de ce connecteur a un cycle de [vie](lambda-functions.md#lambda-lifecycle) prolongé. Dans la AWS IoT Greengrass console, vous pouvez ajouter un connecteur depuis la page **Connecteurs** du groupe. Pour de plus amples informations, veuillez consulter [Mise en route avec les connecteurs Greengrass (console)](connectors-console.md). **Note** Après avoir déployé le connecteur d'adaptateur de protocole Modbus-RTU, vous pouvez l'utiliser AWS IoT Things Graph pour orchestrer les interactions entre les appareils de votre groupe. Pour plus d'informations, consultez [Modbus](https://docs.aws.amazon.com/thingsgraph/latest/ug/iot-tg-protocols-modbus.html) dans le *Guide de l'utilisateur AWS IoT Things Graph *. ## Données d’entrée Ce connecteur accepte les paramètres de requête Modbus RTU provenant d'une fonction Lambda définie par l'utilisateur sur un sujet MQTT. Les messages d'entrée doivent être au format JSON. **Filtre de rubrique dans l'abonnement** `modbus/adapter/request` **Propriétés des messages** Le message de demande varie en fonction du type de demande Modbus RTU qu'il représente. Les propriétés suivantes sont requises pour toutes les demandes : + Dans l'objet `request` : + `operation`. Nom de l'opération à exécuter. Par exemple, spécifiez `"operation": "ReadCoilsRequest"` pour lire les bobines. Cette valeur doit être une chaîne Unicode. Pour les opérations prises en charge, veuillez consulter [Demandes et réponses de Modbus RTU](#modbus-protocol-adapter-connector-requests-responses). + `device`. L'appareil cible de la demande. Cette valeur doit être comprise entre `0 - 247`. + La propriété `id`. Un ID pour la demande. Cette valeur est utilisée pour la déduplication des données et est renvoyée en l'état dans la propriété `id` de toutes les réponses, y compris les réponses d'erreur. Cette valeur doit être une chaîne Unicode. Si votre demande inclut un champ d'adresse, vous devez spécifier la valeur sous la forme d'un entier. Par exemple, `"address": 1`. Les autres paramètres à inclure dans la demande dépendent de l'opération. Tous les paramètres de demande sont obligatoires, à l'exception du CRC, qui est traité séparément. Pour obtenir des exemples, consultez [Exemples de demandes et de réponses](#modbus-protocol-adapter-connector-examples). **Exemple d'entrée : demande de lecture de bobines** ``` { "request": { "operation": "ReadCoilsRequest", "device": 1, "address": 1, "count": 1 }, "id": "TestRequest" } ``` ## Données de sortie Ce connecteur publie des réponses aux demandes Modbus RTU entrantes. **Filtre de rubrique dans l'abonnement** `modbus/adapter/response` **Propriétés des messages** Le format du message de réponse varie en fonction de la demande correspondante et du statut de le réponse. Pour obtenir des exemples, consultez [Exemples de demandes et de réponses](#modbus-protocol-adapter-connector-examples). Une réponse pour une opération d'écriture est simplement un écho de la demande. Même si aucune information constructive n'est renvoyée pour des réponses en écriture, il est recommandé de vérifier l'état de la réponse. Chaque réponse inclut les propriétés suivantes : + Dans l'objet `response` : + `status`. État de la demande. Le statut peut avoir l'une des valeurs suivantes : + `Success`. La demande était valide, envoyée au réseau Modbus RTU et une réponse a été renvoyée. + `Exception`. La demande était valide, envoyée au réseau Modbus RTU et une réponse d'exception a été renvoyée. Pour de plus amples informations, veuillez consulter [Statut de la réponse : Exception](#modbus-protocol-adapter-connector-response-exception). + `No Response`. La demande n'était pas valide et le connecteur a détecté l'erreur avant que la demande ne soit envoyée sur le réseau Modbus RTU. Pour de plus amples informations, veuillez consulter [Statut de la réponse : Pas de réponse](#modbus-protocol-adapter-connector-response-noresponse). + `device`. L'appareil auquel la demande a été envoyée. + `operation`. Le type de demande qui a été envoyé. + `payload`. Le contenu de la réponse qui a été renvoyée. Si le `status` est `No Response`, cet objet contient uniquement une propriété `error` avec la description de l'erreur (par exemple, `"error": "[Input/Output] No Response received from the remote unit"`). + La propriété `id`. L'ID de la demande, utilisé pour la déduplication des données. **Exemple de sortie : réussite** ``` { "response" : { "status" : "success", "device": 1, "operation": "ReadCoilsRequest", "payload": { "function_code": 1, "bits": [1] } }, "id" : "TestRequest" } ``` **Exemple de sortie : échec** ``` { "response" : { "status" : "fail", "error_message": "Internal Error", "error": "Exception", "device": 1, "operation": "ReadCoilsRequest", "payload": { "function_code": 129, "exception_code": 2 } }, "id" : "TestRequest" } ``` Pour obtenir plus d’exemples, consultez [Exemples de demandes et de réponses](#modbus-protocol-adapter-connector-examples). ## Demandes et réponses de Modbus RTU Ce connecteur accepte les paramètres de demande de Modbus RTU en tant que [données d'entrée](#modbus-protocol-adapter-connector-data-input) et publie les réponses en tant que [données de sortie](#modbus-protocol-adapter-connector-data-output). Les opérations communes suivantes sont prises en charge. | Nom de l'opération dans la demande | Code de fonction dans la réponse | | --- | --- | | ReadCoilsRequest | 01 | | ReadDiscreteInputsRequest | 02 | | ReadHoldingRegistersRequest | 03 | | ReadInputRegistersRequest | 04 | | WriteSingleCoilRequest | 05 | | WriteSingleRegisterRequest | 06 | | WriteMultipleCoilsRequest | 15 | | WriteMultipleRegistersRequest | 16 | | MaskWriteRegisterRequest | 22 | | ReadWriteMultipleRegistersRequest | 23 | ### Exemples de demandes et de réponses Voici des exemples de demandes et de réponses pour les opérations prises en charge. Read Coils (Lire des spires) **Exemple de requête :** ``` { "request": { "operation": "ReadCoilsRequest", "device": 1, "address": 1, "count": 1 }, "id": "TestRequest" } ``` **Exemple de réponse :** ``` { "response": { "status": "success", "device": 1, "operation": "ReadCoilsRequest", "payload": { "function_code": 1, "bits": [1] } }, "id" : "TestRequest" } ``` Read Discrete Inputs (Lire des entrées discrètes) **Exemple de requête :** ``` { "request": { "operation": "ReadDiscreteInputsRequest", "device": 1, "address": 1, "count": 1 }, "id": "TestRequest" } ``` **Exemple de réponse :** ``` { "response": { "status": "success", "device": 1, "operation": "ReadDiscreteInputsRequest", "payload": { "function_code": 2, "bits": [1] } }, "id" : "TestRequest" } ``` Read Holding Registers (Lire les registres en attente) **Exemple de requête :** ``` { "request": { "operation": "ReadHoldingRegistersRequest", "device": 1, "address": 1, "count": 1 }, "id": "TestRequest" } ``` **Exemple de réponse :** ``` { "response": { "status": "success", "device": 1, "operation": "ReadHoldingRegistersRequest", "payload": { "function_code": 3, "registers": [20,30] } }, "id" : "TestRequest" } ``` Read Input Registers (Lire les registres d'entrée) **Exemple de requête :** ``` { "request": { "operation": "ReadInputRegistersRequest", "device": 1, "address": 1, "value": 1 }, "id": "TestRequest" } ``` Write Single Coil (Écrire une spire unique) **Exemple de requête :** ``` { "request": { "operation": "WriteSingleCoilRequest", "device": 1, "address": 1, "value": 1 }, "id": "TestRequest" } ``` **Exemple de réponse :** ``` { "response": { "status": "success", "device": 1, "operation": "WriteSingleCoilRequest", "payload": { "function_code": 5, "address": 1, "value": true } }, "id" : "TestRequest" ``` Write Single Register (Écrire un registre unique) **Exemple de requête :** ``` { "request": { "operation": "WriteSingleRegisterRequest", "device": 1, "address": 1, "value": 1 }, "id": "TestRequest" } ``` Write Multiple Coils (Écrire plusieurs spires) **Exemple de requête :** ``` { "request": { "operation": "WriteMultipleCoilsRequest", "device": 1, "address": 1, "values": [1,0,0,1] }, "id": "TestRequest" } ``` **Exemple de réponse :** ``` { "response": { "status": "success", "device": 1, "operation": "WriteMultipleCoilsRequest", "payload": { "function_code": 15, "address": 1, "count": 4 } }, "id" : "TestRequest" } ``` Write Multiple Registers (Écrire plusieurs registres) **Exemple de requête :** ``` { "request": { "operation": "WriteMultipleRegistersRequest", "device": 1, "address": 1, "values": [20,30,10] }, "id": "TestRequest" } ``` **Exemple de réponse :** ``` { "response": { "status": "success", "device": 1, "operation": "WriteMultipleRegistersRequest", "payload": { "function_code": 23, "address": 1, "count": 3 } }, "id" : "TestRequest" } ``` Mask Write Register (Masquer le registre d'écriture) **Exemple de requête :** ``` { "request": { "operation": "MaskWriteRegisterRequest", "device": 1, "address": 1, "and_mask": 175, "or_mask": 1 }, "id": "TestRequest" } ``` **Exemple de réponse :** ``` { "response": { "status": "success", "device": 1, "operation": "MaskWriteRegisterRequest", "payload": { "function_code": 22, "and_mask": 0, "or_mask": 8 } }, "id" : "TestRequest" } ``` Read Write Multiple Registers (Écrire/lire plusieurs registres) **Exemple de requête :** ``` { "request": { "operation": "ReadWriteMultipleRegistersRequest", "device": 1, "read_address": 1, "read_count": 2, "write_address": 3, "write_registers": [20,30,40] }, "id": "TestRequest" } ``` **Exemple de réponse :** ``` { "response": { "status": "success", "device": 1, "operation": "ReadWriteMultipleRegistersRequest", "payload": { "function_code": 23, "registers": [10,20,10,20] } }, "id" : "TestRequest" } ``` Les registres renvoyés dans cette réponse sont les registres qui sont lus. ### Statut de la réponse : Exception Des exceptions peuvent se produire lorsque le format de la demande est valide, mais la demande échoue. Dans ce cas, la réponse contient les informations suivantes : + Le `status` est réglé sur `Exception`. + Le `function_code` est égal au code de fonction de la requête \$1 128. + Le `exception_code` contient le code d'exception. Pour plus d'informations, consultez les codes d'exception de Modbus. **Exemple :** ``` { "response" : { "status" : "fail", "error_message": "Internal Error", "error": "Exception", "device": 1, "operation": "ReadCoilsRequest", "payload": { "function_code": 129, "exception_code": 2 } }, "id" : "TestRequest" } ``` ### Statut de la réponse : Pas de réponse Ce connecteur effectue des vérifications de validation sur la demande Modbus. Par exemple, il vérifie les formats non valides et les champs manquants. Si la validation échoue, le connecteur n'envoie pas la demande. A la place, il renvoie une réponse qui contient les informations suivantes : + Le `status` est réglé sur `No Response`. + `error`Contient la raison de l'erreur. + Le `error_message` contient le message de l'erreur. **Exemples :** ``` { "response" : { "status" : "fail", "error_message": "Invalid address field. Expected , got ", "error": "No Response", "device": 1, "operation": "ReadCoilsRequest", "payload": { "error": "Invalid address field. Expected , got " } }, "id" : "TestRequest" } ``` Si la demande vise un appareil qui n'existe pas ou si le réseau Modbus RTU ne fonctionne pas, vous pouvez obtenir une `ModbusIOException` qui utilise le format No Response. ``` { "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" } ``` ## Exemple d'utilisation Suivez les étapes de haut niveau suivantes pour configurer un exemple de fonction Lambda en Python 3.7 que vous pouvez utiliser pour tester le connecteur. **Note** Si vous utilisez d'autres environnements d'exécution Python, vous pouvez créer un lien symbolique entre Python3.x et Python 3.7. Les rubriques [Démarrer avec les connecteurs (console)](connectors-console.md) et [Démarrer avec les connecteurs (CLI)](connectors-cli.md) contiennent des étapes détaillées qui vous montrent comment configurer et déployer un exemple de connecteur Twilio Notifications. 1. Veillez à répondre aux [conditions requises](#modbus-protocol-adapter-connector-req) pour le connecteur. 1. Créez et publiez une fonction Lambda qui envoie des données d'entrée au connecteur. Enregistrez l'[exemple de code](#modbus-protocol-adapter-connector-usage-example) en tant que fichier PY. Téléchargez et décompressez le [SDK AWS IoT Greengrass de base pour Python](lambda-functions.md#lambda-sdks-core). Ensuite, créez un package zip contenant le fichier PY et le dossier `greengrasssdk` au niveau racine. Ce package zip est le package de déploiement vers lequel vous effectuez le téléchargement AWS Lambda. Après avoir créé la fonction Lambda de Python 3.7, publiez une version de la fonction et créez un alias. 1. Configurez votre groupe Greengrass. 1. Ajoutez la fonction Lambda par son alias (recommandé). Configurez le cycle de vie Lambda comme étant de longue durée (ou dans `"Pinned": true` la CLI). 1. Ajoutez la ressource de périphérique locale requise et accordez read/write l'accès à la fonction Lambda. 1. Ajoutez le connecteur et configurez ses [paramètres](#modbus-protocol-adapter-connector-param). 1. Ajoutez des abonnements qui permettent au connecteur de recevoir des [données d'entrée](#modbus-protocol-adapter-connector-data-input) et d'envoyer des [données de sortie](#modbus-protocol-adapter-connector-data-output) sur des filtres de rubrique pris en charge. + Définissez la fonction Lambda comme source, le connecteur comme cible et utilisez un filtre de rubrique d'entrée compatible. + Définissez le connecteur en tant que source, AWS IoT Core en tant que cible et utilisez un filtre de rubrique de sortie pris en charge. Vous utilisez cet abonnement pour afficher les messages d'état dans la AWS IoT console. 1. Déployez le groupe. 1. Dans la AWS IoT console, sur la page **Test**, abonnez-vous à la rubrique des données de sortie pour consulter les messages d'état du connecteur. L'exemple de fonction Lambda a une longue durée de vie et commence à envoyer des messages immédiatement après le déploiement du groupe. Lorsque vous avez terminé les tests, vous pouvez définir le cycle de vie Lambda à la demande (ou `"Pinned": false` dans la CLI) et déployer le groupe. Cela empêche la fonction d'envoyer des messages. ### Exemple L'exemple suivant de fonction Lambda envoie un message d'entrée au connecteur. ``` 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 ``` ## Licences Le connecteur d'adaptateur de protocole Modbus-RTU inclut les logiciels/licences tiers suivants : + [pymodbus](https://github.com/riptideio/pymodbus/blob/master/README.rst)/BSD + [pyserial](https://github.com/pyserial/pyserial)/BSD Ce connecteur est publié dans le cadre du contrat de [licence logicielle Greengrass Core](https://greengrass-release-license.s3.us-west-2.amazonaws.com/greengrass-license-v1.pdf). ## Journal des modifications Le tableau suivant décrit les modifications apportées à chaque version du connecteur. | Version | Modifications | | --- | --- | | 3 | Mise à niveau de l'environnement d'exécution Lambda vers Python 3.7, ce qui modifie les exigences d'exécution. | | 2 | L'ARN du connecteur a été mis à jour pour Région AWS le support. Amélioration de la journalisation des erreurs. | | 1 | Première version. | Un groupe Greengrass ne peut contenir qu'une seule version du connecteur à la fois. Pour de plus amples informations sur la mise à niveau d'une version de connecteur, veuillez consulter [Mise à niveau des versions du connecteur](connectors.md#upgrade-connector-versions). ## Consultez aussi + [Intégrer à des services et protocoles à l'aide de connecteurs Greengrass](connectors.md) + [Mise en route avec les connecteurs Greengrass (console)](connectors-console.md) + [Démarrage avec les connecteurs Greengrass (CLI)](connectors-cli.md)