Deployment-time variable substitution for subscription topic names?

0

I have a lambda function deployed to several GG core device; all members of a single group. I’d like them to be triggered by messages published to dedicated topics, for example:

core:gg_1, responds to:cmd/gg_1/doTask
core:gg_2, responds to:cmd/gg-2/doTask
core:gg_n, responds to:cmd/gg_n/doTask

Examples in the docs all seem to use static topic names. I see no way to parameterize subscriptions so that individual GG cores within a group listen on distinct topics. Ideally, the subscription would support something like {coreName} in the topic; similar to policy variables in IoT Core.

I believe this can be done manually using the lower level IOT SDK, building up subscriptions at runtime. But I prefer to remain at the GG level. To achieve the same effect in a declarative GG group deployment would require something like variables in topic names, with substitution being done before subscriptions are written to group.json. But I don’t see any indication of this as a feature.

I've considered putting tokens in the topic, and doing my own fix-up on group.json. But that seems like a hack. I've also thought about using shadow updates to covey the commands, but it feels like a misuse of the shadow's state model.

Is there a way to create parameterized subscriptions so that topics are dedicated to a GG core ?

asked 4 years ago150 views
3 Answers
0

Hi,
Do you mean you are trying to deploy one group to several GGCs? This is not recommended because when several devices try to connect to the cloud, only one will remain connected.

DennisRead wrote:
I have a lambda function deployed to several GG core device; all members of a single group. I’d like them to be triggered by messages published to dedicated topics, for example:

answered 4 years ago
0

Hi,

No, I'm not trying to span a GG core across multiple groups. All our GG cores are defined within a single group. They run the same code, and should be operated and managed collectively. Sorry if that was unclear in the question.

At the end of this message is an excerpt from the AWS whitepaper on IoT Core topic design. It shows device names as part of the topic name, allowing for targeted subscriptions and delivery. That illustrates what I'm trying to do. If I deploy a group with 100 GG cores, they all get the same subscriptions, so they all receive the same events.

This project is a prototype refactoring of a solution originally built using raspberry pi devices running the IoT Core SDK. That approach provided the flexibility I'm describing (e.g. each device constructed its own subscriptions, with thingName in the topic filter). But it also required a lot of housekeeping code. I'm evaluating the possibility of moving to greengrass. So far it looks promising, but I'm stuck on how to to deploy GG core specific subscriptions.

Hopefully this gives you a better understanding of my question.

Thanks.

Excerpt from AWS whitepaper: Designing MQTT Topics for AWS IoT Core
When you design MQTT topics for command requests, follow this structure:
cmd/<application>/<context>/<destination-id>/<req-type>

destination-id: Identifies the destination device or application for this message.
By including the destination-id, the target device can subscribe to its own set of
command topics and receive any command requests.

answered 4 years ago
0

I’m marking this question as answered. After reviewing the examples and documentation, it’s clear that I’ve misunderstood the relationship between groups and cores.

I thought a group could manage multiple cores, but it seems that’s not the case. So ‘thingName’ parameterization in group topic names is unnecessary, because each core will have its own group.

Sorry for the confusion.

answered 4 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions