- Newest
- Most votes
- Most comments
To correctly use AWS IoT propagating attributes for message enrichment, there are a few key points to address in your setup:
-
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.
-
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. -
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.
-
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:
-
Instead of publishing to shadow topics (
$aws/things/THING_NAME/shadow/...), publish to a regular application topic (e.g.,meter/telemetry). -
Use the MQTT test client in the AWS console to subscribe to this topic with MQTT 5 enabled.
-
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:
- Create an AWS IoT rule that subscribes to your application topic
- Use the
get_user_properties()function in your rule's SQL statement to access the propagated attribute - 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
Relevant content
- asked 4 years 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.