Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wildcard support for thingNames in shadowDocumentsMap. #191

Open
2 tasks
abwiggins opened this issue Sep 15, 2023 · 1 comment
Open
2 tasks

Wildcard support for thingNames in shadowDocumentsMap. #191

abwiggins opened this issue Sep 15, 2023 · 1 comment

Comments

@abwiggins
Copy link

Feature Description
Is there any update on wildcard support for thingNames in shadowDocumentsMap? I see in this issue there was talk of adding but I cannot find any updates.

Use Case
Why do you need this feature?
I apply a deployment to a large number of devices. All with the same shadow document configuration and use. Adding the thingName and configuration is cumbersome for each new device added. This also means the effective configuration located on each device lists all other device names. Out of preference more than anything I'd like for each device's configuration to be dedicated for that device only and not contain anything for other devices. Please let me know if my understanding is correct as well. I may be missing something crucial on why this works the way it does.

Proposed Solution
Below is an example doc using the # in place of a thingName. I have not looked at the open source code explicitly so I am unaware how it parses through the shadowDocumentsMap. Thank you for any time or explanation that may be given to this. I appreciate it.

{
	"synchronize": {
		"shadowDocumentsMap": {
			"#": {
				"classic": false,
				"namedShadows": [
					"NameOShadowDoc"
				]
			}
		},
		"direction": "betweenDeviceAndCloud"
	}
}

Other
Add detailed explanation, stacktraces, related issues, links for us to have context, etc

  • 👋 I may be able to implement this feature request
  • ⚠️ This feature might incur a breaking change
@MikeDombo
Copy link
Member

Hi @abwiggins,

I think this is more or less a duplicate of these two issues: #125 and #124.

Synchronizing "all" shadows for all things is not something that we can implement due to performance and scalability concerns.

We are considering to synchronize shadows when they are actually requested, which would have a similar effect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants