Custom Application to subscribe to Uplink packets.

[Ajay K]

I am writing a custom application to subscribe to the uplink packets. It seems like I have two options to do this if I am right? One is to listen to the TCP uplink port via a socket connection and the other is to subscribe to uplink topic of the MQTT broker? I just wanted any inputs from the multitech team as to which is a better option?

I was look at the LORA input node’s source code and seems like the LORA input node subscribes to MQTT broker. However in the past few days in the node-red logs I have noticed that under high load, sometimes the node-red loses its connection to the broker and this happens very sporadically and only for a few seconds. Although it recovers the connection to the mqtt broker, but for those brief few seconds packets are lost. Also I have seen connecting to the MQTT broker and subscribing to uplink packets from the custom application takes almost 2-5 seconds, is this expected?

Thanks,
Ajay

[Peter Ferland]

We generally recommend that you use the MQTT broker. When you say “high load” what is the number of transmissions at the same time?

Do you see any errors in the lora server or node red logs? Sometimes the light in the browser goes red even though messages are still coming through, however it sounds like it is disconnecting in your case.

[Ajay K]

Thanks Peter for responding so quickly. There are around 50 mdots communicating with the Conduit. Which are not very many, however there are some of them that are far enough from the conduit that they end up having to re-join the network every now and then and transmit packets as soon as they join the network. So I am guessing the repeated rejoins and transmits cause the traffic to be higher than normal.

Having said that I was planning on using the MQTT broker, but just wanted to ensure that if there were any advantages directly connecting to the tcp port, there by preventing any packet loss. Also I do know the LORA input node is getting disconnected from the broker as it logs it in the node-red logs, but happens very sporadically and if uplink packets arrive at this time the packets get lost. But since the lora wan server receives it first it acks the packet receipt and the packet is lost for good, since the mdot assumes the packet was received and processed successfully by the conduit/node-red.

Also I am hoping in the future design I am hoping the packets submitted to the broker, and if there are no subscribers at that point yet, the packet is retained in the broker until the packet is either received by node-red lora-in node or some custom app which can load faster than node-red.

Thanks,
Ajay

[Peter Ferland]

Do you see any issues when using mosquitto-sub on the commandline? Just want to confirm that its not a problem with the lora or mosquitto server itself.

[Ajay K]

Hi Peter,

I am not sure what that exactly means i.e. mosquitto-sub? Is this a tool that I need to install so I can troubleshoot issues with the mosquitto server?

Also with my custom app I could successfully connect to mqtt broker and receive packets, just FYI, if that was what you meant?

Thanks,
Ajay

[Peter Ferland]

mosquitto-sub and mosquitto-pub are simple commandline clients for MQTT. They are provided by default on an mlinux conduit and can be installed on an AEP conduit by getting the mosquitto-clients package (opkg install mosquitto-clients).

What I wanted to establish was whether there was something wrong with node-red or mosquitto. If you ran ‘mosquitto-sub -t /lora/+/+’ every lora message would be printed to the commandline. You could direct out output of that command to a file and then compare the number of packets you see using mosquitto-sub with the number of packets seen by your node red flow.

[Author]

Posts