- Newest
- Most votes
- Most comments
With MQTT in general and AWS IoT Core specifically, yes you can verify delivery of a message to the broker. Publishing an MQTT message using quality of service (QoS) 1, the client will continue to publish a message (PUBLISH) until is receives back an acknowledgement (PUBACK) from the broker. The acknowledge is a contract that the broker has successfully received the message and will process accordingly. If a PUBACK isn't seen within the parameters of the publish (it times out, network connection is lost, etc.), the local device client code can then take action to retry or otherwise note the message was not sent to the broker. The AWS IoT Device SDKs can help with this by setting up callback routines for unsuccessful publish attempts.
AWS IoT supports QoS 0 (message sent zero or more times) and QoS 1 (message sent at least once and then repeatedly until a PUBACK is recieved). AWS IoT Core does not support QoS 2.
For end-to-end workloads, also consider that the broker will then need to do something with the received message. It might be that another MQTT client is subscribed to the topic where the message was published, or that it is processed by an AWS IoT Rule Action that delivered to another AWS service. The message could be lost in there cases, such as the subscriber only using QoS 0, or service level limits reached on other AWS services. If this is of concern, AWS IoT can also have logging enabled where each message will have a unique traceId associated with it that can be used to trace the message through AWS IoT Core.
Please let us know if this answers your question of if you have other follow-ups?
Relevant content
- asked a year ago
- Accepted Answerasked 2 years ago
- Accepted Answerasked a year ago
AWS OFFICIALUpdated 2 years ago- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 3 years ago
On publish we are getting We have logging enabled on IoT, and we have found this log for the failed message: Dose-not specify the reason for failure . Is there any way to further investigate the reason for failure?
{ "timestamp": "2024-01-28 05:00:56.044", "logLevel": "ERROR", "traceId": "1f0525a9-aa7d-57ca-8777-f9f357bb1e5e", "accountId": "779725694896", "status": "Failure", "eventType": "Publish-In", "protocol": "MQTT", "topicName": "1e35f557-c1aa-4dd4-a342-aa5963defe79/event", "clientId": "1e35f557-c1aa-4dd4-a342-aa5963defe79", "principalId": "1bea44b86ce9d0fca1dc278b571577dfe8e7709b0e82d81401ecab5822d1fc64", "sourceIp": "5.102.247.240", "sourcePort": 29156 }
Is this intermittent or consistent? For permissions issues there should be a
reason, so if not, can you share more details? What would be helpful is maximum messages per-second, QoS level, and the effective policy for the thing.We experienced this behavior only once, and it occurred when the rate of messages being sent was between 50-60 per second. Considering that the device continuously publishes messages, this incident seems to be an isolated occurrence. Here is the policy, which should be issued as the device is consistently publishing data, and this specific issue occurred only once.
And error message