En utilisant AWS re:Post, vous acceptez les AWS re:Post Conditions d’utilisation

How to handle core devices with same Greengrass V2 components but different component configuration for each Thing

1

Hi,

We are in the process of using Greengrass v2 Fleet Management to handle lots of devices in factories uploading timeseries to our cloud datalake.

The components are the same on all devices, but the configurations used by the components will be different for each device. To facilitate management and maintenance of the fleet, we wanted to have a single Deployment attached to a Thing Group, and all devices being Things in the groups. Hence, when we update/patch the Deployment, all Things would be updated/patched with the garanteed same versions.

But a deployment can (apparently) only have one configuration, which would be the same for all Things.

So there seem to be two approaches:

  1. To create one Deployment per Thing and use the Deployment configuration to configure the device. This has two downsides:
    • It is more difficult to garantee that all deployments are up-to-date with the right versions of the components
    • The list of deployments would be huge on the console
  2. To create a single Deployment associated to a Thing Group containing all Things and use different device shadows associated to each Thing. The downside of this is:
    • We must implement ourselves the logic of updating the components' configuration based on the shadows changes, and this needs to be used in all components needing specific configuration.

I also saw a post that suggests having a common Deployment and other specific Deployments for components that need specific configuration, but that would fall into the first approach.

Hence my questions:

demandé il y a 2 ans569 vues
1 réponse
2
Réponse acceptée

Hello,

To answer the questions:

  1. Yes, your assumption is correct. When a deployment is made to a thing group, the configuration and the component versions are uniform across all the things which are a part of the thing group. The configuration for the component can however be overridden on a per device basis using a separate component for configuration.
  2. You can also use a static file per device, managed separately on your end which can be used by the code running on the component to get the custom parameters for the specific device. You can also facilitate this using a custom component to get the device ID and download the configuration for the specific device ID from a remote location (like an S3 bucket or your FTP server). Using this custom component as a part of the group deployment will allow you to have a single deployment to get the custom settings for running your code tuned to the specific device. Downloading the static files based on the device ID via your code allows you more customisation on downloading the configuration file for your code.

Hope this helps.

AWS
INGÉNIEUR EN ASSISTANCE TECHNIQUE
répondu il y a 2 ans
profile picture
EXPERT
vérifié il y a 6 mois
  • Thanks. So to summarize, in any case, we will have to implement something that will have to handle configuration specifics for a Thing, including the changes in configuration.

    In this case, we will use device shadows rather than other implementations based on S3 buckets, static files and a dedicated configuration component for the following reasons :

    1. Shadows are displayed on the console interface of the Thing. This means that we have a centralised place where we can see and manage all parts of the Things, including configuration through shadows.
    2. There is no need to setup any other infrastructure (S3 bucket) and component
    3. Shadows have a mechanism to be notified of updates and to handle errors

    Thanks again for the clarifications!

Vous n'êtes pas connecté. Se connecter pour publier une réponse.

Une bonne réponse répond clairement à la question, contient des commentaires constructifs et encourage le développement professionnel de la personne qui pose la question.

Instructions pour répondre aux questions