MQTT Downlink ACK / Failed, how do we know?

1

Hello,
I have an MQTT client (Python paho.mqtt.client) which subscribe to :
client.subscribe(“v3/pygate-test-local-id/devices/+/up”,qos=2)
client.subscribe(“v3/pygate-test-local-id/devices/+/down/failed”,qos=2)
client.subscribe(“v3/pygate-test-local-id/devices/+/down/ack”,qos=2)

It’s working fine, I can send downlink and receive uplink, the only problem is that for example when I send a confirmed downlink to an end-device (lopy4) that is disconnected (not powered so I’m sure), I don’t receive a failed message or something like this even on the console.

Am I missing something ?

Another quesiton is, do we have a more complete documentation on MQTT ?
I’m using that : MQTT Server | The Things Stack for LoRaWAN but I would like to have a documentation more “API like” where they show all subscribable topic with an explanation and the format of the received/sent message.

2

Why do you think it must fail? The NS will think the node is in sleep mode and forward the downlink as soon as it gets a uplink.

Turn the node on and see what happens.

When you are in the documentation, use the search bar at the top, lots to be found.

https://www.thethingsindustries.com/docs/reference/api/application_pub_sub/#message:ApplicationPubSub.MQTTProvider

1 Like
3

Nice thanks for the link !

I didn’t think of sleep mode but then, what makes a downlink to fail ?
It will always work since the NS is waiting for an uplink from the node so if the node doesn’t work we receive nothing and if it works we receive nothing too.
I guess I could just make a timer and If I don’t receive an ACK I say that the node doesn’t work but then I’m wondering the point of the failed topic.

4

The failed topic kicks in when a downlink has been sent several times and is not acknowledged.

Using downlinks to determine is a node is operational is not the way to go. First of all LoRaWAN doesn’t do downlinks well as during transmission the gateway does not receive anything so you get a scaling issue. Also an acknowledged downlink requires two uplinks to happen (first one to trigger the downlink, second one to send the ack) so depending on the LoRaWAN stack implementation on the device it either wastes airtime (when acknowledged immediately) or takes long(er) to be acknowledged.

Why not use the same timer to see if you receive data? If you get an uplink every X time the node is alive. No need to use downlinks or even worse acknowledged downlinks.

5

Yes, better than sending a downlink, Class A downlinks are only TX after a RX uplink.

Remember when you TX a downlink the gateway cant RX any uplinks.

6

Blockquote
The failed topic kicks in when a downlink has been sent several times and is not acknowledged

Could you elaborate on this please ?
I’m just wondering in which situation subscribing to the failed topic is worth, because I did send several downlink and it never kicked up (by several I mean something like 10 times)

Blockquote
Why not use the same timer to see if you receive data? If you get an uplink every X time the node is alive. No need to use downlinks or even worse acknowledged downlinks.

Yeah that’s another viable solution but I wanted a prettier way haha but I will do this if it’s the only solution

7

What is the RSSI and SNR of your node?

If you are that concern about reliability add another gateway close by.

8

How familiar are you with the LoRaWAN standard? It specifies that a confirmed packet (uplink and downlink) must be ACKed by the receiver in the next transmission to the other side. For a node this means that once an confirmed downlink is sent to the node the next uplink must contain an ACK for that downlink. If it is missing the NS will consider the downlink not to be received and retry. Depending on the implementation details of the NS it will try a fixed number of times and if no ACK had been received at that fixed number it will consider the transmission failed.
If during testing you send a downlink and the node aknowledges it correctly you will never see this failure happen. If you schedule a downlink and the node is off-line it won’t happen either because scheduled downlink do not expire, the next one will simply be send on the next uplink, no matter when that uplink will be.

It is actually the prettier solution as it does not involve additional transmissions and use of airtime. When designing for LoRaWAN you need to keep in mind:

  1. Send as little as possible, each transmission uses battery power and airtime.
  2. Use acknowledgements only if absolutely required. Acknowledgements involve additional transmissions and a gateway transmitting is not listening for any traffic so will be missing other nodes uplinks.
  3. Not every transmission will be received. A 5-10% packet loss is to be expected under normal conditions, more in extreme conditions (lots of RF noise or too many nodes).
  4. Gateways are subject to the same legal restrictions as nodes. Too many transmissions will make it run out of time to send them all.
1 Like