Send downlink to multiple devices

Hello everyone, i am totaly new to node-red. At the moment i have two devices which send data to the ttn. This data is received in node-red using ttn uplink node. I didnt specify device id so all data is sent to the same node from both devices. In case of particular message i want to send back 01 to the device which send the message. I am able to do that using ttn downlink node, with device id specified. The problem is i need a separete downlink node for each device, and in the end i might have 50 or 60 devices connected to ttn. So is there some way to reuse nodes in node-red, or have some functions which would help to destinquish between the devices and send response back to the correct device without creating 100 of nodes in the node-red application? Any help much appreciated

1 Like

Currently the version of LoRaWAN implemented by TTN only supports downlinking to a single node. The evolving LoRaWAN specification has some extremely complicated tentative ways to “multicast” but these are not presently supported by the installed version of the TTN network.

Generally TTN (and LoRaWAN itself) is for “uplink mostly” applications where downlinks are rare. As such, it may not be a fit for more control-oriented use cases.

Thank you for your replay. I was hopping to use that downlink message as acknowledge, as in my application that one message is really important and it would help to ensure that the message was delivered successfully. But it seems i will have to find another way to do that. Thank you again, as you saved me a lot of time keep looking though videos of how to achieve unachievable.

If I understand your question correctly you need to send a downlink to one device in response an uplink from that device with the TTN node red code?
Looking at the quick start that can be done by setting the dev_id in the input provided to the TTN Send node.

1 Like


These 3 node assemblies does the same thing only in the end they send ack to the different device. So what i wanted instead of creating loads of those somehow to be able to pass device id to the downlink node and use the same one for all the data coming in.

Sorry, but providing a screenshot of the icons doesn’t show us that the configuration of the nodes is so I’m unable to suggest how to proceed.


Ok i was able to reduce the number of nodes slightly but when number of nodes will be 100 or so its still a lot.

Code in functions which connects to ACK to dev1, 2, 3 is as follows

var newmsg = JSON.stringify(msg.payload).substring(19,22);
var ID = msg.dev_id;
if (newmsg === "JC/"){
    if (ID === "device1"){
         return { payload: "01"};

only changes device1 to equivalent device.

the last function only prepares data to be saved i database

var d = new Date();
var nodes = [];
var myDateJSON = (JSON.stringify(d)).substring(1,20).replace('T',' ');
var newmsg = JSON.stringify(msg.payload).substring(19,22);
var ID = msg.dev_id;
if (newmsg === "JC/"){
    var myJobJSON = JSON.stringify(msg.payload).substring(22);
    nodes = myJobJSON.split(',')
    msg.topic = "INSERT INTO JobChange_tbl(Job,Date,ProgenID) VALUES ('"+nodes[0] + "','"+ myDateJSON+"','" +nodes[1] + "')";
    return msg;

i wonder can i reduce even more the number of nodes, maybe the function can send the replay to the ttn somehow or maybe there is some other way?

Seems to me that @kersing already told you how to limit the number of output nodes?

Also, I’ve not used the TTN Node-RED library, but beware it’s been marked “archived”. I’ve no idea why, but that makes me wonder if the future V3 will be supported. Many SDKs have been archived too, and explicitly marked deprecated.

So, I’d simply use a standard MQTT Input node in Node-RED, which when using MQTT wildcards allows you to subscribe to all devices in an application. (I guess the TTN library allows for that too.) And a single MQTT Output node (probably using the very same MQTT Config node) could then be used for the downlinks.

Of course, if the downlink is always a function of the uplink, then there’s no need for a downlink at all. The device could determine the downlink’s payload without any server side code then.

Also, using JSON.stringify(msg.payload) followed by some substring looks weird and will fail when the format changes. I’d use attributes of the JavaScript object msg.payload, rather than using a string representation of that object.

(Please see How do I format my forum post? [HowTo] And totally aside: your above database code would be very unsafe when you cannot be sure that the payload is always trusted.)

Thank you for the replay. I will try to use MQTT hopefully it will work.

As for JSON.stringify(msg.payload) this just works for me, though i am sure there is better ways to do that. There is about 12 different messages which is sent to node red, and they all have similar format, and it just so happens that each of them has different message identifier which is at position 19 to 22, those 3 bytes tells me what message that is and i only care about the one which has JC/ identifier, so only in that case i am sending back acknowledge. I am using 01, but it really could be anything, this 01 is send back to the device, which then knows that message was delivered successfully. If it wont receive acknowledge device will continue send this message until confirmed.

Thank you for editing my message i will make sure i read in the forum on how to do it properly.

Ah, I figured msg.payload was the MQTT payload. But in case of the TTN Node-RED library this seems to be the LoRaWAN application payload? If this implies that each device is sending a unique ID in its LoRaWAN application payload, while each device can already be uniquely identified using its registration in TTN Console (which is included in the MQTT message), I’d say that’s a bit of a waste. Also, it seems you’re sending text? Even more wasteful.

Note that your Node-RED scheduled downlink will probably not (always) be sent after the uplink that scheduled it, so that won’t work; see My application's downlink is always queued for next uplink. Also, it seems you’re reinventing the LoRaWAN confirmed uplink, which handles this much better. (But in any case: on the community network you’re limited to at most 10 downlinks or confirmed uplinks per day, per device.)

Or maybe not, emphasis mine:

Best might be to not need any confirmation at all…

Ah, my bad again, you wrote message identifier. Still, it’s text. Don’t send text. See also Multiple sensors with different payload decoding TTN.

Message i need to reply to only happens 1-6 times in 24 hours. After that message device sends a dummy message to get back the downlink message.

As for the message format itself i didn’t create them, the device i am using only listens for communications between two devices. Depending on messages it does something or doesn’t.

Some of received messages are sent to ttn and from there to node-red where they are saved in database. If message is particular type “JC/” job change then i am sending back acknowledge to the device which sent this message. But those messages as i mentioned only happens 1-6 times in 24 hours