How to get status on publish to a MQTT Out node?

General
12

@TotallyInformation Thank you for your reply and please allow me to address some of your questions.

First, to be very clear, I'm not trying to guarantee deliver to the broker. I'm just trying to obtain some kind of pass/fail status on the publish operation so that I can either assume the message will make it to the broker or retry it myself at a later time. I know caching and retrying failed messages can be difficult so I do not expect the mqtt out node to handle that for me.

For example, the AWS IoT Python SDK returns the following on publish:

Tuple containing a Future and the ID of the PUBLISH packet. The QoS determines when the Future completes:

  • For QoS 0, completes as soon as the packet is sent.
  • For QoS 1, completes when PUBACK is received.

This is perfectly fine. The "success" scales appropriately with QoS. Failure can be tracked against reported errors or the future timing out in the case of the connection failing.

My concern with the described Node-RED behavior is that there are cases where doPublish() is not called. What happens if I check the connection and it's good, but then it goes down before doPublish() is called such that the function is not called? Please correct me if I am wrong, but it seems to me that there are windows of time where that scenario might happen. My best bet might be to check the connection, but to also view any message not triggering a complete node as a failure so that I can retry it.

That appears to have a fixed client name?

Yes, it was a fixed client name. Why do you think that is not a good idea? In many cases it's required. For example, AWS IoT Core brokers will often require you to use the "ThingName" as the client ID when connecting as part of their policy.

{
    "Version":"2012-10-17",
    "Statement":[
    {
        "Effect":"Allow",
        "Action":"iot:Connect",
        "Resource":[
            "arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}"
        ]
    }
    ]
}

I've also worked with IT departments that require it for their own monitoring purposes. I would honestly be more surprised by being told to use an automatically generated client ID than a fixed ID at this point.