acknowledgement - qos = 1 between python and node-red

[Chris Jefferies]

At the top on my python script (which collects xbee data and constantly publishes to a node-red MQTT input) I want to send a single json config to node-red.  If the message is not sent or acknowledged, then that means node-red is not running or there is a down connection.

If it times out or fails, the python script should stop and shut down.

I'm publishing the json data like this:

import paho.mqtt.publish as publish
publish.single("tinaja/sensorgate2/sensorconf", str(sensorconf), hostname=NR_SERVER, port=NR_PORT, qos=1)

This is a one-time shot so it doesn't matter if it takes 1, or 10, or 30 seconds, but I'd like it to acknowledge that it did or did not get to node-red.

Please, what are the mechanics for retrieving the acknowledgement?  I tried retrieving the return value from publish.single() but it always returns None.

Thanks for any advice,

Chris.

[Andy Stanford-Clark]

Hi Chris
this is one of the times you need end-to-end application-level acknowledgment... your python app needs to know that your node-red app is alive.
If you want your python app to decide reasonably quickly that the other end isn't there, and shut down, then the recommended way to do this is...

1. subscribe to a topic that is unique to your device (e.g. reply/xxxxx where xxxxx is the mac address or serial number or something that won't get used by another device on your broker.
2. publish a QoS *0* message with the config info to node-RED
3. start a timer
4. at the node-red end, when you receive a config message from a device, publish back a message to say you got it, to the reply/xxxx topic of the device (usually we put that topic in the request message from the device, so node-red knows where to reply to)
5. If your device receives the response message from node-RED before the timer pops, you're up and running.
6. if the timer pops and you haven't heard from node-RED yet, assume it's not there, and shut yourself down.

Hope that helps :)
Andy

--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
To post to this group, send email to mq...@googlegroups.com.
Visit this group at https://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.

[Chris Jefferies]

Andy,

I'll give that a try.  

Thanks for your help,

Chris.

[Karl Palsson]

Andy Stanford-Clark <an...@stanford-clark.com> wrote:
> Hi Chris
> this is one of the times you need end-to-end application-level
> acknowledgment... your python app needs to know that your
> node-red app is alive. If you want your python app to decide
> reasonably quickly that the other end isn't there, and shut
> down, then the recommended way to do this is...
>
> 1. subscribe to a topic that is unique to your device (e.g.
> reply/xxxxx where xxxxx is the mac address or serial number or
> something that won't get used by another device on your broker.
> 2. publish a QoS *0* message with the config info to node-RED
> 3. start a timer 4. at the node-red end, when you receive a
> config message from a device, publish back a message to say you
> got it, to the reply/xxxx topic of the device (usually we put
> that topic in the request message from the device, so node-red
> knows where to reply to) 5. If your device receives the
> response message from node-RED before the timer pops, you're up
> and running. 6. if the timer pops and you haven't heard from
> node-RED yet, assume it's not there, and shut yourself down.
>

While I generally agree with this model, why are you explicitly
making it a qos -0- post? what difference does that really make
to this scenario? At qos0, you don't even know if you message got
to the broker!

Cheers,
Karl P

[Andy Stanford-Clark]

It's QoS0, because you need to know that the end-to-end path (from the device to Node-RED) is available *now*.
With QoS > 1, if (say) the link from the broker to Node-RED was down for a few days, then *eventually* your configuration message would be delivered, but it would be way too late to be useful to anyone.

So we use the lowest QoS to make sure the end-to-end connection is available to us.

Andy

[Karl Palsson]

Hrmm, I get what you're getting at, but you already have a
timeout for the response message. A higher qos should only _help_
work around a flaky link, it shouldn't _hurt_ in any way. I mean,
the steps all work, but you explicitly highlighted the need to
send at qos 0, and I can't see how it will make any difference in
the flow outlined.

Cheers,
Karl P

(If you want to ensure that you don't _happen_ to get the "old"
qos1 reply days later when you next start your application, you
should include a correlation id in your request, so you can pair
a reply to it's request, not just be forced to assume that _any_
reply is for the request you sent, this is still idependent of
the qos level)