Sending downlinks with CayenneLPP Codec

ChirpStack Application Server
1

Hi,

I’ve been trying to send a downlink message for several days to a device using the CayenneLpp codec function.
I already checked some threads dealing with the same issue (forum. chirpstack. io/t/cayennelpp-codec-downlinks/7296 - not answered), https://forum.rakwireless.com/t/difficulty-with-mqtt-downlink-messages/2016 - answered but doesn’t work) and (Problem with sending downlink via MQTT - answered but doesn’t work).
The latter 2 topics offer useful information but I couldn’t do it work with such information.
The complexity is due there is few information about how the downlink messages should be scheduled based on which codec function you are using.
As I said, I’m using CayenneLpp codec and uplink messages are working perfectly. Now, when I try to schedule a downlink, either via MQTT or in Chirpstack application server device view form, it doesn’t work. It seems like the message has been enqueued, but the device never receives it. I’ve also tried with TTN and downlinks work perfectly (because there it’s not needed to encode to base64, json objects with base64 data or similar).

The things that I’ve tried to achieve the downlink message are:

  1. Send the byte64-encoded payload in the CS application server device form. I send MQ== which is 1 in base64 to any port. The message is not received in LoRa node.

  2. Send a JSON object using MQTT (directly and from files) with a byte64-encoded data field (mosquitto_pub -h 192.168.1.114 -t ‘application/2/device/DEVEUI/tx’ -m ‘{“confirmed”: true, “fPort”: 11, “data”: “MQ==”}’). The encoded data is 1. The message is not received in LoRa node.

  3. Send a JSON object using MQTT again (directly and from files) with a byte64-encoded CayenneLpp Hex buffer in the data field (mosquitto_pub -h 192.168.1.114 -t “application/2/device/DEVEUI/tx” -m ‘{“confirmed”: true,“fPort”: 10,“data”:“AQEB”}’). AQEB means 010101 in hexadecimal, which means a CayenneLPP array of LppData(channel = 1, type = Digital Output, value = (1,)). Again, the message is not received in LoRa node.

Additional considerations: MQTT messages have been checked and are correct. The application ID and DEVEUI are correct. The GW is working fine (8-channel LoRaWAN compliant GW). TTN downlinks work seamlessly. End device is Microchip RN2903.

A lot of work to send a “1” to a node in a downlink message.

Please help me with a useful guide or explanations.

Thanks in advance.

Santiago.

2

Hi,

Have you solved this issue ?

3

Hi @MoShawa, yes.

The problem was due to a bidirectional problem between the Chirpstack NS and Chirpstack Gateway Bridge. Specifically, it was a UDP problem (I use Semtech Packet Forwarder) because the network has restrictions for UDP. Thus, I needed to update Gateways to work with MQTT instead of UDP, i.e., install Chirpstack Gateway Bridge on Gateways rather than on central server. This way, connectivity could be checked (as UDP is not oriented to guarantee connectivity).
My GWs are Raspberry Pi-based, then, I updated their OS to latest Raspberry PI OS, which is the only one which supports Chirpstack Gateway Bridge package.
One the link is established, the downlink messages are straightforward, you only need to send Byte64 encoded packets (No CayenneLPP format is required to send downlinks). Of course, you will receive hex data in your end device, then, the decoding process should be performed in your end device.

I hope this help.

Regards,

Santiago.

…

2 Likes