Open AdamVD opened 2 years ago
@AdamVD, Thank you for suggesting this feature, we'll consider it and follow up here. Also of course Shadow Manager is open source so if you or anyone else implements it we'd be very happy to review the pull request.
We do a similar thing with the named shadows config1 config2 etc.. So for the ShadowManager-Config I've created one that adds about 9 of them like:
"synchronize": {
"coreThing": {
"classic": false,
"namedShadows": [
"config1",
"config2",
"config3",
"config4",
"config5",
"config6",
"config7",
"config8",
"config9",
]
},
Even if we don't use all of them.
If it is possible to add wildcards, that would also help us heaps.
I would also like this feature too. Any update on this feature?
We do a similar thing with the named shadows config1 config2 etc..
So for the ShadowManager-Config I've created one that adds about 9 of them like:
"synchronize": { "coreThing": { "classic": false, "namedShadows": [ "config1", "config2", "config3", "config4", "config5", "config6", "config7", "config8", "config9", ] },
Even if we don't use all of them.
If it is possible to add wildcards, that would also help us heaps.
Setting shadow names to sync that don't exist (yet) causes the greengrass.log to fill up with warnings. Which is less than optimal.
Feature Description A configuration option to synchronize all the Named Shadows for a Thing, so that the Shadow Manager configuration does not need to be updated when new Shadows are created.
Use Case We manage a lot of our data through Shadows attached to our core devices, and we have some data sets that need to dynamically scale beyond the 8KB size limit (I know it can increase to 30KB with quotas). We enumerate our Shadows when we go beyond the size limit of a single document, so we might start with
FooShadow0
but end up withFooShadow1
andFooShadow2
after a while of normal operation. We also regularly add new Shadows to support new devices or capabilities in our application.It's not trivial to automatically reconfigure the Shadow Manager when we dynamically scale out a set of Shadows at runtime. These new Shadows could be created either in the cloud or on the Greengrass core during operation.
Proposed Solution The Shadow Manager can periodically check IoT Core for new Shadows that are created in the cloud (list-named-shadows-for-thing) and then begin synchronizing automatically. Similarly, any new local Shadow can be automatically added to the sync process.
An exclude list could be added so that you can choose which Shadows not to sync, although this isn't important in our use case yet. The
allNamedShadows
(bool) +excludeShadows
(list) combination would need to be mutually exclusive with the existingnamedShadows
list.