- Newest
- Most votes
- Most comments
Using separate topics for publishing and subscribing, as you mentioned, is a standard approach to handling bidirectional communication in MQTT-based systems. This allows you to segregate the data flow and ensure that messages are processed appropriately by each part of your system.
Regarding your question about using certificates for multiple Things in AWS IoT:
- Single Certificate for Multiple Things: In AWS IoT, you can attach the same certificate to multiple Things. This allows devices or services using that certificate to assume the identity of any of the Things it's attached to. This approach could work for your scenario, where the platform and the RP2040 device could use the same certificate and, depending on the topic they are publishing to or subscribing from, they could act as different Things.
- Creating and Attaching Policies: Make sure that the IoT policy attached to your certificate allows publishing and subscribing to the topics you plan to use for both the device and the platform. Policies in AWS IoT define the permissions for the certificate and can include multiple statements allowing different actions (publish, subscribe, connect, etc.) on different topics.
- Implementing in Firmware: When implementing this in your device firmware, you'll use the same certificate as before but make sure your device logic includes the capability to publish or subscribe to the two different topics as needed. The device will authenticate using the same certificate, and the permissions granted to that certificate via the attached policy will determine what actions it can perform.
- Testing and Monitoring: After implementing the changes, use the AWS IoT Core Test Client available in the AWS Console to monitor the messages being published and subscribed to both topics. This will help you ensure that your setup is working as intended and debug any issues.
- Security Considerations: Be mindful of the security implications of using the same certificate for multiple Things. Ensure that your IoT policies are as restrictive as possible to limit actions to only what's necessary for each Thing's role.
If you decide to proceed with this setup, it's essential to test thoroughly to ensure that the platform and device interactions are working as expected and that there are no security loopholes introduced by using the same certificate for multiple purposes.
Can you confirm that mqtt broker in this case is AWS IoT Core, and that you have a device (thing) successfully publishing to a topic (from process.env.MQTT_PUB_TOPIC
that is invoking an AWS IoT Rule sending data to DynamoDB?
If that is the case, based on your code, the publish of device=>broker is configured. To have the client code get data, you need to subscribe to a topic where the set data is being sent. It is best practice to use two separate topics for publishing and subscribing. E.g., you can publish on thingX/telemetry
and also subscribe on thingX/commands
. Normal sensor data is sent to the telemetry topic (and evaluated by the rules engine) and when a command or other payload is published via a cloud resource or other device to the command topic, your device receives it.
Depending up the SDK or library you are using, look for the subscribe
method. Normally there are implemented as callbacks so that when a message is received you can then process and take action accordingly.
Please let me know if this helps and if you have any follow-up questions add a comment.
Hello. Thank you for the response. Yes, I'm using AWS IOT mqtt broker and with the current created thing, the device can successfully publish to provided MQTT_PUB_TOPIC. Your idea of using two topics to support the two endpoints(platform and device) really sounds good and I would like to run a test using it. However, may I know how to go about using the certificates kindly? For with this approach on my project model it means the device MQTT_PUB_TOPIC will be from the THING_1 for instance and MQTT_SUB_TOPIC from THING_2. If this interpretation is correct, then I find it challenging to implement for it means I'll have to make use of both topics' certificates in the device firmware implementation as I'm currently using for the set up Thing. Is this possible? Or can I use same certificates for the two THINGS?
If this is okay, I'll then be publishing to THING_2 topic from the platform and listen to its subscribe topic from the device.
Thank you once again.
Lots of appreciation to @Giovanni and @Gavin_A for your positively insightful response. Combining your well elaborated responses I have successfully managed to get around the task.
Yes, utilizing same certificates for the two things provisioned(although I'll consider to use independent certificate for each as recommended), I've successfully managed to publish to the same AWS IoT Thing topic (device_dht22/pub
) from multiple endpoints i.e RP2040 device and the platform supported with nodejs.
First, I had the main AWS IoT thing, DEVICE_DHT22
with clientID as DEVICE_DHT22
and pub/sub topics as device_dht22/pub
and device_dht22/sub
respectively. The device publish sensor data to broker via device_dht22/pub.
//DEVICE_DHT22 thing policy ---------------------------------------------------
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iot:Connect",
"Resource": "arn:XXXXXX:client/DEVICE_DHT22"
},
{
"Effect": "Allow",
"Action": "iot:Publish",
"Resource": "arn:XXXXXX:topic/device_dht22/pub"
},
{
"Effect": "Allow",
"Action": "iot:Subscribe",
"Resource": "arn:XXXXXX:topicfilter/device_dht22/sub"
},
{
"Effect": "Allow",
"Action": "iot:Receive",
"Resource": "arn:XXXXXX:topic/device_dht22/sub"
}
]
}
// END ------------------------------------------------------------------------
On the other hand, the platform is to publish control threshold settings back to the connected device via the broker through device_dht22/sub
, the topic to which the device is listening to ( subscribed to ) for the set thresholds.
The second AWS IoT thing is PLATFORM_DHT
with clientID as PLATFORM_DHT
and pub/sub topics as device_dht22/sub
for publish topic and the subscribe topic as platform_dht/sub
.
//PLATFORM_DHT thing policy ---------------------------------------------------
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iot:Connect",
"Resource": "arn:aws:XXXXXX:client/PLATFORM_DHT"
},
{
"Effect": "Allow",
"Action": "iot:Publish",
"Resource": "arn:aws:XXXXXX:topic/device_dht22/sub"
},
{
"Effect": "Allow",
"Action": "iot:Subscribe",
"Resource": "arn:aws:XXXXXX:topicfilter/platform_dht/sub"
},
{
"Effect": "Allow",
"Action": "iot:Receive",
"Resource": "arn:aws:XXXXXX:topic/platform_dht/sub"
}
]
}
// END ------------------------------------------------------------------------
These two AWS IoT things sharing same certificate
and having different client IDs
from their policy settings made it possible to initiate simultaneous exchange of data between the device and the platform backend database endpoints via the MQTT broker of a single AWS IoT thing DEVICE_DHT22
.
Thank you!
Glad you got it working Ochieno! If you wouldn't mind, could you accept the answer on this question? It helps guide others here and with search optimization. One other thing is if you can have unique certificates (and/or policies) per "thing" (device or platform), that is best practice from a security perspective. Reduces blast radius if the certificate is ever compromised.
Relevant content
- AWS OFFICIALUpdated 3 years ago
- AWS OFFICIALUpdated 5 months ago
- AWS OFFICIALUpdated 5 months ago
- AWS OFFICIALUpdated a year ago
Thank you so much @Giovanni for the well elaborated response.