By using AWS re:Post, you agree to the Terms of Use
/IoT device/device profile tags in payload/

IoT device/device profile tags in payload


Is it possible to add IoT device tags & possible the devices profile tags in the message as it move across IoT Core/MQTT broker?

To be more specific, we have several tags for the device configured in the web console for this device. I'd like to add those tags like so:


to the primary payload message before its sent off further downstream.

    "PayloadData": "<REDACTED>",
    "WirelessDeviceId": "<REDACTED>",
    "WirelessMetadata": {
        "LoRaWAN": {
            "ADR": true,
            "Bandwidth": 125,
            "ClassB": false,
            "CodeRate": "4/5",
            "DataRate": "3",
            "DevAddr": "<<REDACTED>>",
            "DevEui": "<REDACTED>",
            "FCnt": 2196,
            "FOptLen": 1,
            "FPort": 10,
            "Frequency": "904300000",
            "Gateways": [{
                "GatewayEui": "<REDACTED>",
                "Rssi": -31,
                "Snr": 7.75
            "MIC": "<<REDACTED>>",
            "MType": "UnconfirmedDataUp",
            "Major": "LoRaWANR1",
            "Modulation": "LORA",
            "PolarizationInversion": false,
            "SpreadingFactor": 7,
            "Timestamp": "2021-12-11T17:37:56Z"

I have a suspicion this is done in the IoT rule SQL but it isn't clear with the syntax or if its even possible.

1 Answers


it's not possible to access device tags from IoT SQL statement, however you have several alternative options to achieve that:

  1. Store the necessary key/value pairs per device in a DynamoDB table (instead of Device tsgs) and use get_dynamodb function of IoT SQL (see to enrich your message with this data in IoT rule. I recommend this option, as it causes the least operational overhead and scales very well with increasing number of the devices due to a scalability of DynamoDB (see

  2. Store the necessary key/value pairs per device in Device Shadow and use get_thing_shadow function of IoT SQL to enrich your message with this data in IoT rule. Knowing more about kind of data you want to store in key/value pairs would help to decide if this is a feasible option.

  3. In case you decide against using DynamoDB or shadow, I suggest to store key/value pairs not in tags, but in Thing Attributes : Then you could build a Lambda function that reads the Thing Attributes using DescribeThing (, and then use aws_lambda function of IoT SQL to call that Lambda function and enrich your message with tag data in IoT rule. This option has two disadvantages: a/ potential scalability limits due to Transaction Per Second quotas on DescribeThing API call (350 Transactions per seconds, adjustable but not limitless) b/ Higher operational overhead as you need to develop and maintain an additional Lambda function. I recommend to consider options 1) and 2) before looking at 3)

Please let me know if that helps.

br , Andrei

answered 7 months ago
  • Excellent thank you Andrei. I'm not familiar enough with DynamoDB and I'm not too worried about scale, so I think my best option is #2 with the Things Shadows for now. It's also useful since I've been meaning to learn how to use shadows anyway.

    Could you offer some more tips considering #2? I see the attributes are associated at the thing level, not at the shadow level since a thing could have multiple shadows? If that's the case is the shadow even necessary? Couldn't I just add the attributes to the thing and leave it at that?

    If I'm wrong and the attributes are defined at the shadow level then what am I missing when the only option I see on the shadow details that seems editable is the state. Am I supposed to add the attributes here?

      "state": {
        "desired": {
          "welcome": "aws-iot"
        "reported": {
          "welcome": "aws-iot"
  • First I want to mention that learning how DynamoDB works is probably lower effort compared to scenario of researching and designing how IoT Shadow would work for your use case. So if the effort for learning DynamoDB is what you are concerned about, you should not :)

    Regarding the shadow option. Each IoT Thing has several shadows, one of them is unnamed and others are named. Please see this doc for the description of the related concepts: You could

    Could you provide an example of an attributes you intend to use to better understand kind of parameters you intend to store?

  • Maybe you're right about DynamoDB effort. I spent some time yesterday trying to wrap my head around shadows and its a bit more involved than I thought.

    Here's an example of the kind of attributes I want to follow the device and its payloads.

    • manufacturer:
    • device_type: lora, wifi, cellular
    • (if cellular) imei
    • (if lora) payload_type

    That kind of stuff. This originated from wanted to just indicate the payload_type for Lora devices so that my Lambda decoder could pick the correct function to properly decode the message.

    I wanted to get that info to come in on the event received by Lambda


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