Greengrass - best way to handle setting a topic based on the core device?

0

I have an app that sends a mqtt packet to AWS IOT Core. I will deploy the app to multiple core devices. The core devices will all be a part of the same group. Each device will be physically installed in a piece of manufacturing equipment and will take a cycle input. I want each cor device to have it's own unique value for the topic but have the same custom component deployed to all the core devices in that group.

What is the best way to set a non volatile, unique topic value on each core device once and have the component read that topic when it starts?

I suppose that I could write a file to each core device that holds the topic value and then read that file from my component python script but perhaps there is a better way?

flycast
asked 2 years ago354 views
3 Answers
1
Accepted Answer

Hi flycast.

As per MQTT design best practices, the topic would typically include the Thing name.

The component can use the AWS_IOT_THING_NAME environment variable to construct topics that include the Thing name.

https://docs.aws.amazon.com/greengrass/v2/developerguide/component-environment-variables.html

And for authorization, you can use the iot:thingName recipe variable to ensure each device has least privilege.

https://docs.aws.amazon.com/greengrass/v2/developerguide/ipc-iot-core-mqtt.html#ipc-iot-core-mqtt-authorization

profile pictureAWS
EXPERT
Greg_B
answered 2 years ago
  • Perfect! Exactly the kind of answer I was hoping for Greg. I appreciate it.

0

Thanks @Greg_B - All great ideas. So let's list them:

  • Dynamo database
  • Shadow
  • Deploy component with each segment and use config store
  • Write a file that the component can access when commissioning the thing that has the info.
  • If python perhaps use dbm Thanks for your help here. The dynamodb and shadow has some appeal. Looks like it would be super inexpensive in this case as well. The shadow is an already available 'thing' capability so it wouldn't require an additional service.
flycast
answered 2 years ago
-1

I was hasty in marking this answered. I want to ask a follow up question. I will be deploying this component to many devices but the topic name prefix to the thing name will be different on different devices. Example:

My thing is named "Thing". My topic has department and location in it as well:

Company/Group/Department/ThingName

I want to deploy things using the same component to different Company/group/department. I like being able to deploy one component to all those things and just pick up a variable that is written once to each thing for the topic segments. Naming my thing with the full topic will not work as it will exceed the allowed length on network device name. I can use the thing name for part of the topic but I really need to pick up a non volatile string for the rest (Company/Group/Department).

I am trying to make dbm work with the following code:

try:
    with dbm.open('/home/ggc_user/greengrass.db', 'r') as db:
        topic = db.get('topic_prefix', b'undefined').encode('ASCII')
         print("Topic prefix set as: " + topic)
         topic = topic + "/" + os.getenv("AWS_IOT_THING_NAME")
except:
         print("Error getting topic: ", sys.exc_info()[0])
        print("Traceback: ", sys.exc_info()[2])
        topic = "undefined" + os.getenv("AWS_IOT_THING_NAME")

my python script running as default user ggc_user does not seem to be able to access the database file in it's home directory. Even with permissions on the file set to 777.

 sudo ls -l /home/ggc_user/
 -rwxrwxrwx 1 ggc_user ggc_user 12288 Sep 16 22:41 greengrass.db

I get the error:

Error getting topic: <class 'dbm.error'>

Any ideas would be appreciated.

flycast
answered 2 years ago
  • Hi flycast. I think my answer answered the question that was asked. Ideally you should ask new questions in a new question, not in an answer to an old question. I think you also have two different (and unrelated) questions embedded in this answer. New questions will get more eyes on them; I don't know the answer to the dbm part, so a new question is more effective.

  • For Company, Group and Department, this information can be sent to the device as component configuration. You may perhaps make a new component (let's say "ConfigStore") to hold that information. You can have a deployment targeting your whole fleet for your existing component, and one deployment per department perhaps for sending the config. Then your component could use GetConfiguration to get the information from "ConfigStore". This is just one way.

  • Does the device actually need to know what Company, Group and Department it's deployed in? If not, instead of having them in the topic, you might just hold them as Thing attributes on the cloud side.

  • Sorry about that @greg_b. I was thinking I was asking this in the question : What is the best way to set a non volatile, unique topic value on each core device once and have the component read that topic when it starts?

    I do see your point though.

    I am using topic to route data using rules. The thing does need to know the full topic and it changes depending on where the thing is.

    I Googled and checked the developer guide and could not find a way to get thing attributes in python. Is it possible for a component to retrieve thing attributes in python?

  • All good. If the device needs to know the Company, Group and Department, I would recommend component configuration or maybe a shadow (if each device needs unique configuration). Since each device in a department will have the same Company/Group/Dept (I think), and you only want to set it once, component configuration is the better match. Just in case it's not clear, a core device can be targeted by multiple deployments. So you can have one deployment that targets the whole fleet, and other deployments that target a Department or even individual devices.

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