Skip to content

Correct Usage of AWS IoT Propagating Attributes

0

Goal: I'm attempting to use propagating attributes with AWS IoT. My final goal is to use these attributes to redirect messages to a new topic based on an attribute on the thing (an organization ID in this case).

Background:

  • I have a "Thing Type" called "Meter". It has a searchable attribute called "organization" and has propagating attributes set up to propagate it (I think) - see Figure A.
  • I have a thing called "test-thing" whose thing type is also set to "Meter", and it has the "organization" attribute set to a value (see Figure B).
  • I have a test script that updates the shadow of "test-thing" every 5 seconds with a new value using MQTT 3 - see Code A

Assumptions

  • I can use MQTT 3 or MQTT 5 on my device to publish shadow updates, and messages should still propagate attributes. The documentation indicates that while subscribers must support MQTT 5, publishers may use any MQTT version
  • The propagated values should appear in the "Properties" of an MQTT message and are viewable in the MQTT Test Client within the AWS Console. This does not happen

What I would expect: See the "organization" key and its value (as set on the specific thing) listed under "User Properties" within the "Properties" in the MQTT test client in the console when the device publishes shadow updates to $aws/things/THING_NAME/shadow/name/SHADOW_NAME/update/accepted. Furthermore, this property would be accessible via the get_user_properties function within a rule so that messages can be dynamically routed/republished based on that value.

Figure A Thing Type page screenshot showing organization under attributes and propagating attributes

Figure B Thing page screenshot showing organization under attributes and propagating attributes

Code A

import { mqtt, iotshadow, iot } from 'aws-iot-device-sdk-v2'
import { Resource } from 'sst'

const thingName = 'test-thing'
const endpoint = "REDACTED" // endpoint address

console.log('building connection')
const config_builder = iot.AwsIotMqttConnectionConfigBuilder.new_mtls_builder_from_path(
  './mocks/certificates/cert.pem',
  './mocks/certificates/key.pem',
)
config_builder.with_clean_session(false)
config_builder.with_client_id(thingName)
config_builder.with_endpoint(endpoint)

const config = config_builder.build()

const client = new mqtt.MqttClient()

console.log('connecting...')
const connection = client.new_connection(config)

const shadowClient = new iotshadow.IotShadowClient(connection)

connection.on('connect', async () => {
  console.log('Connected to AWS IoT Core')
})

connection.on('disconnect', () => {
  console.log('Disconnected from AWS IoT Core')
})

connection.on('error', (error) => {
  console.error('Connection error:', error)
})

await connection.connect()

let value = 0
while (true) {
  await shadowClient.publishUpdateNamedShadow(
    {
      thingName,
      shadowName: 'state',
      state: {
        reported: {
          value: value,
        },
      },
    },
    0,
  )
  console.log('Published shadow update:', { value })

  value++

  await new Promise((resolve) => setTimeout(resolve, 5000))
}
asked 3 months ago76 views
1 Answer
-1

To correctly use AWS IoT propagating attributes for message enrichment, there are a few key points to address in your setup:

  1. Authentication Requirement: For propagating attributes to work, clients publishing messages must be authenticated with a certificate, which you appear to be doing correctly in your code.

  2. Thing Association: The thing must be properly associated with the connection. In your code, you're setting the client ID to match your thing name (test-thing), which is the correct approach for establishing this association.

  3. Propagating Attributes Configuration: Your screenshots show you've set up the "organization" attribute as a propagating attribute in your "Meter" thing type, which is good.

  4. MQTT Version Considerations: While you're correct that publishers can use MQTT 3 (and subscribers need MQTT 5 to see the enriched messages), there's an important distinction about where these attributes appear.

The main issue appears to be with your expectation about where these propagated attributes should appear. Propagating attributes are added to MQTT messages as MQTT 5 user properties, but they won't appear in shadow update messages. The shadow service is a separate AWS IoT feature that uses reserved topics.

To see the propagated attributes working:

  1. Instead of publishing to shadow topics ($aws/things/THING_NAME/shadow/...), publish to a regular application topic (e.g., meter/telemetry).

  2. Use the MQTT test client in the AWS console to subscribe to this topic with MQTT 5 enabled.

  3. When your device publishes to this topic, you should see the "organization" attribute in the User Properties section of the received messages.

For your goal of routing messages based on the organization attribute, you would:

  1. Create an AWS IoT rule that subscribes to your application topic
  2. Use the get_user_properties() function in your rule's SQL statement to access the propagated attribute
  3. Use a republish action to route the message to a dynamic topic based on that attribute value

For example, your rule SQL might look like:

SELECT *, get_user_properties('organization') as organization 
FROM 'meter/telemetry'

And the republish action could use a substitution template like:

organization/${organization}/data

This would route messages to different topics based on the organization attribute value.
Sources
Adding propagating attributes for message enrichment - AWS IoT Core
AWS IoT Core latency when updating propagated attributes to rules | AWS re:Post
Message routing based on IoT device registry attribute | AWS re:Post

answered 3 months ago
  • I published to a different, non-reserved topic (device/THING_NAME/data) and these messages still do not contain anything listed under "User properties". The MQTT test client is using MQTT 5.

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.