- Newest
- Most votes
- Most comments
Hi. The problem is that you've configured Greengrass and Device Client with the same thing name, so they use the same MQTT client ID. Since they make independent connections to AWS IoT Core, and MQTT client IDs must be unique, they keep forcing the other to disconnect.
You could change one of them to use a different thing name. In that case, you should likely consider to use the new thing-to-connection association feature. This will mean paying double connectivity costs however, because you have two connections.
Instead of using both Device Client and Greengrass, I think you should consider to develop a Greengrass component that receives and executes jobs. This is possible through the Greengrass IPC mechanism, and hence you only need a single MQTT connection to AWS IoT Core. As an example, this Greengrass component uses jobs: https://github.com/awslabs/aws-greengrass-labs-certificate-rotator
The issue you're experiencing is related to a conflict between AWS IoT Greengrass Nucleus and AWS IoT Device Client (AIDC) when they attempt to connect simultaneously. This conflict occurs because both are trying to use the same client ID to connect to AWS IoT Core.
To resolve this issue and enable both Nucleus and AIDC to work together, you have a few options:
-
Use different client IDs: Configure AIDC to use a different client ID than the one used by Nucleus. This can typically be done in the AIDC configuration file by setting a unique client ID.
-
Utilize Greengrass components: Instead of using AIDC directly, consider creating a custom Greengrass component that incorporates the functionality you need from AIDC. This approach would allow you to leverage Greengrass's built-in features and avoid conflicts.
-
Use IPC (Inter-Process Communication): Greengrass v2 supports IPC, which allows components to communicate with the Nucleus and perform various operations. You could create a custom component that uses IPC to interact with AWS IoT Core for job execution and other commands.
-
Explore Greengrass CLI: The Greengrass CLI component provides local command-line access to various Greengrass operations. This might offer an alternative way to manage your devices without relying on AIDC.
-
Use different endpoints: If possible, configure AIDC to connect to a different AWS IoT endpoint than the one used by Nucleus.
It's important to note that while Nucleus itself may not directly support running jobs like rebooting, you can create custom components within Greengrass v2 that can handle these tasks. This approach would allow you to maintain a unified management system through Greengrass without the need for a separate AIDC instance.
For your specific use case of managing a large fleet of production machines, it's recommended to explore Greengrass v2's native capabilities and custom component development to meet your requirements for remote management and command execution.
If you decide to proceed with using AIDC alongside Greengrass, ensure that you carefully manage the client IDs and connection parameters to avoid conflicts. You may also want to consider reaching out to AWS support for more specific guidance on your implementation strategy, given the scale of your deployment.
Sources
Choose an MQTT broker - AWS IoT Greengrass
Use the AWS IoT Device SDK to communicate with the Greengrass nucleus, other components, and AWS IoT Core - AWS IoT Greengrass
Troubleshooting client devices - AWS IoT Greengrass
Only use AWS Greengrass core devices? | AWS re:Post
Relevant content
asked 3 years ago
- AWS OFFICIALUpdated 4 years ago
