Introducing AWS IoT Core’s Direct Messaging: Decrease-cost server-to-device communication with higher observability

AWS IoT Core now helps direct messaging for point-to-point communication. Beforehand, sending a message to a single IoT machine required publishing to an MQTT subject the machine subscribed to, with no built-in supply affirmation from the machine. With the brand new direct messaging functionality, you possibly can ship a message to any machine related to AWS IoT Core, decreasing messaging value in comparison with publish-subscribe (Pub-Sub) messaging for one-to-one communication patterns, and offering a supply acknowledgment from the IoT machine. AWS IoT Core additionally makes use of the supply acknowledgment to offer detailed API response codes and emit Amazon CloudWatch Logs, so you’ve got visibility into message supply standing and failure causes.

Level-to-point communication between backend servers and IoT units is a standard sample in related machine architectures. It exhibits up in use instances like sending firmware updates to a wise dwelling equipment, pushing transaction updates to a cost machine, or controlling a wise car. For these one-to-one interactions, routing by a Pub-Sub message dealer isn’t environment friendly, since you’re not utilizing the fan-out profit that Pub-Sub was designed to offer. As well as, you obtain the message supply acknowledgment from the Pub-Sub dealer slightly than from the IoT machine, requiring you to construct your individual customized answer for supply affirmation.

What’s Direct Messaging?

AWS IoT Core introduces the SendDirectMessage HTTP API. With this API, you possibly can ship a message to a particular IoT machine or shopper recognized by its MQTT shopper ID. Moderately than publishing to an MQTT subject and counting on subscription matching, AWS IoT Core routes the message point-to-point to the goal machine. You skip the subscription-matching layer, there’s no fan-out, and you’ve got the choice to obtain affirmation from the shopper.

The message is delivered to the machine on its current MQTT connection (over TCP) to AWS IoT Core, with no device-side adjustments required. The API helps two modes:

1. With out supply affirmation – The message is delivered at MQTT High quality of Service (QoS) 0. The HTTP API returns 200 OK after AWS IoT Core accepts and dispatches the message.
2. With supply affirmation – The message is delivered at MQTT QoS 1. The HTTP API returns 200 OK solely after the machine acknowledges receipt with an MQTT PUBACK (publish acknowledgment), offering true end-to-end supply affirmation. If the machine doesn’t acknowledge inside the timeout, the API returns 504 Gateway Timeout.

Key advantages

Constructed-in supply affirmation

With supply affirmation enabled (affirmation=true), you obtain acknowledgment instantly from the machine, not solely from the dealer. AWS IoT Core delivers the message at QoS 1 and waits for the machine’s PUBACK earlier than returning 200 OK. This removes the necessity to construct customized acknowledgment logic.

Speedy offline machine suggestions

With conventional Pub-Sub, a server publishing to a subject receives a profitable response no matter whether or not the machine obtained the message. With Direct Messaging, if the goal machine isn’t related, the API returns 404 Not Discovered instantly. The HTTP response message and Amazon CloudWatch Logs describe the precise cause. For instance, when the response message states that the goal shopper ID isn’t related however has an lively persistent session, the machine has an unexpired persistent session however is at the moment offline.

Value optimization

Should you use direct messaging with out supply affirmation, you pay for a single Direct Message as a substitute of separate publish-in and publish-out operations. Should you use direct messaging with supply affirmation, you pay for a single Direct Message with Affirmation as a substitute of separate publish-in, publish-out, and publish-ack operations. For particulars, see the AWS IoT Core pricing web page.

No device-side adjustments

Direct messages are delivered on current MQTT connections already established with AWS IoT Core. No firmware updates, SDK adjustments, or new subject subscriptions are required. In case your machine already subscribes to the goal subject, Direct Messaging works instantly. In case your machine doesn’t subscribe to the subject, confirm that your MQTT shopper library doesn’t filter messages on unsubscribed subjects. Most manufacturing purchasers (together with the AWS IoT System SDKs) deal with this accurately.

Use instances

Direct Messaging is the precise alternative when:

• You must ship a message to a particular machine (not a multicast).
• You must know whether or not the machine really obtained the message.
• You need to simplify retry and error-handling logic.

Examples: server-to-device instructions (locking a car, toggling a wise equipment, pushing a configuration replace), machine acknowledgments, cost-sensitive high-volume messaging, and real-time notifications.

Conventional Pub-Sub stays the precise alternative while you want fan-out (one message to many subscribers) or message queuing for offline units.

Getting began

On this put up, you’ll configure the AWS Identification and Entry Administration (IAM) insurance policies, ship a Direct Message in three alternative ways, and obtain it on a related machine.

Stipulations

You will need to have the next conditions to observe together with this put up.

• An AWS account with AWS IoT Core configured.
• IoT units registered and related by MQTT 3.1.1 or MQTT 5.0. See the AWS IoT Core Developer Information to learn to join units.
• Backend server code that calls the Direct Messaging API (server-side adjustments solely).

Step 1: Configure authorization

Each the sender and the receiver require particular coverage actions. The sender wants iot:SendDirectMessage permission with the goal shopper’s Amazon Useful resource Identify (ARN) because the useful resource. You may optionally limit which subjects can be utilized with the iot:Subject situation key.

The next sender coverage permits direct messages to shopper myDevice on the subjects instructions/reboot and instructions/replace. For SigV4-authenticated backend servers, add this to an IAM coverage. For X.509-authenticated units, add it to an AWS IoT Core coverage.

{
    "Model": "2012-10-17",
    "Assertion": [
        {
            "Effect": "Allow",
            "Action": "iot:SendDirectMessage",
            "Resource": "arn:aws:iot:us-west-2:123456789012:client/myDevice",
            "Condition": {
                "StringEquals": {
                    "iot:Topic": ["commands/reboot", "commands/update"]
                }
            }
        }
    ]
}

The receiver should have iot:Obtain permission on the goal subject. The receiver doesn’t want iot:Subscribe. Direct Messaging delivers to the related shopper with out requiring a subject subscription.

The next receiver coverage permits iot:Obtain on two particular subjects:

{
    "Model": "2012-10-17",
    "Assertion": [
        {
            "Effect": "Allow",
            "Action": "iot:Receive",
            "Resource": "arn:aws:iot:us-west-2:123456789012:topic/commands/reboot"
        },
        {
            "Effect": "Allow",
            "Action": "iot:Receive",
            "Resource": "arn:aws:iot:us-west-2:123456789012:topic/commands/update"
        }
    ]
}

You can too use a wildcard to obtain direct messages on any subject underneath a prefix:

{
    "Model": "2012-10-17",
    "Assertion": [
        {
            "Effect": "Allow",
            "Action": "iot:Receive",
            "Resource": "arn:aws:iot:us-west-2:123456789012:topic/commands/*"
        }
    ]
}

For extra coverage examples, together with sending to any shopper on particular subjects or on any subject, see Direct messaging coverage examples.

Step 2: Ship a Direct Message

Senders make an HTTP POST request to a client-specific URL:

POST https://{IoT_data_endpoint}/connections/{url_encoded_client_id}/messages?subject={url_encoded_topic}&affirmation=true&timeout=10

{IoT_data_endpoint} is your account’s AWS IoT machine knowledge endpoint. The next three examples ship the identical instructions/reboot message to shopper myDevice with supply affirmation.

Utilizing curl (X.509 shopper certificates authentication, port 8443):

curl --tlsv1.2 
  --cacert AmazonRootCA1.pem 
  --cert machine.pem.crt 
  --key personal.pem.key 
  --request POST 
  --data '{"motion": "reboot"}' 
  "https://{IoT_data_endpoint}:8443/connections/myDevice/messages?subject=commandspercent2Freboot&affirmation=true&timeout=10"

Utilizing the AWS Command Line Interface (AWS CLI):

aws iot-data send-direct-message 
  --client-id myDevice 
  --topic instructions/reboot 
  --confirmation 
  --timeout 10 
  --payload '{"motion": "reboot"}' 
  --cli-binary-format raw-in-base64-out 
  --region us-west-2 
  --endpoint-url https://{IoT_data_endpoint}

The --cli-binary-format raw-in-base64-out possibility is required with AWS CLI v2 so the --payload worth is shipped as-is. To make it the default, run aws configure set cli-binary-format raw-in-base64-out. This command requires AWS CLI v2 model 2.34.57 or newer.

Utilizing the AWS SDK for Python (Boto3):

import boto3
import json

shopper = boto3.shopper("iot-data", region_name="us-west-2")

response = shopper.send_direct_message(
    clientId="myDevice",
    subject="instructions/reboot",
    affirmation=True,
    timeout=10,
    contentType="utility/json",
    payload=json.dumps({"motion": "reboot"}).encode("utf-8"),
)

# The response incorporates a standing message and a traceId for troubleshooting.
print(response["message"], response["traceId"])

With affirmation=true, the API waits for the machine to acknowledge. A 200 OK confirms end-to-end supply. A 504 Gateway Timeout signifies the receiver didn’t acknowledge inside the timeout interval. The supply state is ambiguous, so implement idempotent dealing with when you retry.

Request parameters:

Step 3: Obtain Direct Messages on the machine

Your current MQTT shopper receives Direct Messages on the required subject. In contrast to commonplace MQTT Pub-Sub, the machine doesn’t want an lively subscription. Direct Messages are delivered based mostly on the shopper ID. The machine can nonetheless optionally subscribe to the subject, nevertheless it’s not required for supply.

The QoS stage of the delivered message is ready by the sender’s affirmation parameter, not by the receiver’s subscription. When affirmation=true, the message arrives at QoS 1 and the shopper should ship a PUBACK to acknowledge supply. Most MQTT shopper libraries do that mechanically. When affirmation=false, the message arrives at QoS 0 with no acknowledgment required. Be certain that your shopper handles each QoS 0 and QoS 1 incoming messages accurately.

Monitoring with CloudWatch

AWS IoT Core returns detailed HTTP response codes for each SendDirectMessage name. Whenever you allow AWS IoT Core CloudWatch logging, the service additionally emits SendDirectMessage occasion logs that embrace a machine-readable cause area, so you possibly can construct automated retry logic, monitor machine connectivity, and troubleshoot supply points programmatically. Evaluate the HTTP response message or CloudWatch logs to establish the precise cause for any failure.

HTTP response standing codes:

Limitations and concerns

• No message queuing – Direct Messages aren’t queued for offline units. Use Pub-Sub with QoS 1 and chronic classes for message persistence.
• No message retention – The MQTT retained flag isn’t supported. Use Amazon DynamoDB or AWS IoT System Shadow for state synchronization.
• No Guidelines Engine processing – The AWS IoT guidelines engine doesn’t course of Direct Messages.
• Reserved subjects – Direct Messaging helps customized subjects. Matters should not begin with $ and should not be AWS IoT reserved subjects.
• Consumer ID restrictions – Consumer IDs should not exceed 128 characters and should not begin with $. Consumer IDs containing characters which can be invalid in HTTP requests (similar to /) have to be percent-encoded within the URL path.
• Limits and quotas – See the AWS IoT Core developer information and repair quotas for payload measurement, subject depth, and API limits.
• Protocol – Works with current MQTT 3.1.1 and MQTT 5.0 purchasers. (MQTT 5.0 properties similar to content material sort and response subject will not be delivered to MQTT 3.1.1 purchasers.)

Availability

AWS IoT Core Direct Messaging is on the market immediately in all AWS Areas the place AWS IoT Core is on the market.

Conclusion

On this put up, you noticed how AWS IoT Core Direct Messaging routes server-to-device messages point-to-point by MQTT shopper ID, returns a real end-to-end supply acknowledgment while you choose in with affirmation=true, and studies actionable HTTP response codes for offline or unauthorized targets. The potential works on current MQTT connections, so you possibly can undertake it with out modifying machine firmware.

To get began, see the Direct Messaging subject within the AWS IoT Core Developer Information. For pricing particulars, see the AWS IoT Core pricing web page. Check in to the AWS IoT console to start out sending direct messages to your related units.

Concerning the authors