Cannot schedule downlink using curl or MQTT

Dear all

I need to send the DOWNLINK message to TTN to manage mcf88 Lora plug remotely. The payload is 04000100000000000000 to switch on the plug.
I tried 2 proposed solutions by HTTP and MQTT. Related commands are

For HTTP :
curl -X POST --data '{"dev_id":"plug1_mcf88","port":1,"confirmed":false,"payload_raw":"BAABAAAAAAAAAA=="}'***thekeyofmyapplication

For MQTT :
mosquitto_pub -h -t "plug1_mcf88/devices/plug1-mcf88/down" -u "plug1_mcf88" -P "ttn-account-v2.***thekeyofmyapplication" -m {""payload_raw"" **:"BAABAAAAAAAAAA=="** }"

In both cases the command is going well. But in the data window of the device i don’t see any downlink appear. Only usual every minute uplink.


What can be the problem?

Thank you for your advice and help

With best regards, Ken

To debug curl, see Having trouble sending downlink with HTTP Integration. For the MQTT command the opening { is outside of your quotes, and you’re nesting quotes without escaping them.

Also, notice the downlink on port 0 that TTN sends after each of your uplinks. That probably implies that TTN does not like the data rate you’re using for your uplinks. You’ll need to investigate that, like see LMIC Library Always Does Unwanted Downlink. It does not seem related to the problem you’re seeing, but maybe it affects it, and it needs fixing anyhow.

Finally, if TTN does not like your data rate as the downlinks are in RX2, the uplinks are probably SF12 SF9 or worse? Then you’re sending way too often! But even on the best data rate, SF7, with the 17 bytes you’re sending you’re only allowed an average of 17 messages per hour. For SF12, the limit is less than 1 message per hour.

You should not be using confirmed uplink when you transmit this frequently, the automatic confirmation downlinks will quickly exhaust your allowance.

That might not be causing things to fail (though really, such an egregious misuse should…) but it’s something you need to stop doing.

Your polling uplinks need to be unconfirmed traffic. If the switch cannot do that, then it’s not appropriate for use on TTN.

1 Like

Thank you very much for your answer. I started from HTTP. I corrected all ’ to " and tried use all links that you recommend and also to send the downlink by Postman.
The curl line is:

curl.exe -i -v -X POST -d “{“dev_id”:"plug1-mcf88",“port”:1,"payload_raw":"AQE="}”<secret code>

And in all cases i have the error HTTP/1.1 400 Bad Request.

I tried with/without port, confirmed, or another payload raw, etc. All time i have this problem.
If i send the downlink directly from the TTN to this port 1, it works, and the equipment answer. But by http what can be the problem?

I also tried on the other equipment to test the same thing ( downlink about the state of one of the thermal sensors), i did through the curl and through the Postmman exactly how it was indicated in the example, but all time i received the HTTP/1.1 400 Bad Request. Directly from TTN the equipment receive and answers.

What it can be ?

That yields nested quotes. Also, you have curly “..” quotes in your command now.

Having trouble sending downlink with HTTP Integration refers to Using curl or Postman for the HTTP Integration on Windows which explains how to “escape” the nested quotes.

Aside, please see How do I format my forum post? [HowTo] to avoid the forum software from replacing ".." with “..”.

Dear Arjan

Thank you for your answer. I revised good and tried all approaches that were described in indicated pages of the forum.

I formed the link considering Using curl or Postman for the HTTP Integration on Windows
More details :

device : plug1-mcf88
application : plug1_mcf88
http integration: plug1

C:\mos>curl.exe -i -v -X POST -data "{ "dev_id ": "plug1-mcf88 ", "payload_raw ": "AQE= "}" key>

but i tried with and without spaces, all different combinations of *
"{ "dev_id": "plug1-mcf88", "payload_raw": "AQE="}"
"{ "dev_id":"plug1-mcf88", "payload_raw":"AQE="}"
etc. throught the curl and Postmant

But in all i have HTTP/1.1 400 Bad Request.

What it can be?

Thank you for your help

It’s not about the spaces. But none of the above “escape” the nested double-quotes.

The JSON message you want to send to the server is:


This is the very same as:

{"dev_id": "plug1-mcf88", "port": 1, "payload_raw": "AQE="}

…or even:

  "dev_id": "plug1-mcf88",
  "port": 1,
  "payload_raw": "AQE="

So, the JSON message you want to send includes double-quotes around the keys (such as "dev_id") and around text values (such as "plug1-mcf88"), but not around numbers (such as port number 1). This way, computers know where a text value starts and where it ends. Without that, it would not know what to do with the whitespace around the values, like in the 2nd and 3rd examples.

The above should work with Postman just fine.

Next, on the Windows curl.exe command line, you specify the data you want to send using:

--data "your data here"

On a Mac or on Linux, you could also use single-quotes:

--data 'your data here'

But on Windows, the parameter’s value needs to be surrounded by double-qoutes. However, the JSON data already includes double-quotes itself. Now, if you’d erroneously use:

--data "{"dev_id": "plug1-mcf88", "port": 1, "payload_raw": "AQE="}"

…then Windows cannot tell where the keys and values start and end; it doesn’t even know that the value continues after seeing "{". To avoid that, you’ll need to escape the double-quotes in the parameter value:

--data "{\"dev_id\": \"plug1-mcf88\", \"port\": 1, \"payload_raw\": "\AQE=\"}"

Also, again, please see How do I format my forum post? [HowTo]

1 Like

Thank you very much for your very precise description.

Now it is clear for me and it is work quite well

Thank you very much for your help!

1 Like