Why is Node-RED integration no longer supported?

I’ve been eyeing off using Node-Red for a while now. It seems pretty simple for the purpose of data management, and will undoubtedly save me a fair bit of code when I wish to take sensor data and put it into a database.

I see, however, that TTN advises the Node-Red integration is discouraged and no longer supported. I cannot find a reason why this is.

Why is Node-Red no longer supported when it seems to be one of the better options?

To be precise: the The Things Network Node-RED Nodes, node-red-contrib-ttn, are no longer supported. But those are basically just a wrapper around the MQTT Data API, with some discovery of the server addresses. What special features, if anything, of that library did you like?

You can still use Node-RED by using its built-in MQTT support. True, you’ll need to configure the server address and MQTT topics, but that’s about it. (In fact, knowing MQTT I found that the TTN wrapper just added confusion. And it added a dependency on that discovery.)

See https://cookbook.nodered.org/#mqtt

As for why support ended: a wild guess would be that The Things Industries also thinks the added benefits are low. But they would still need to maintain it when things change in Node-RED (already, apparently things stopped working on a Raspberry Pi), or in TTN’s backend services, especially for the upcoming changes for V3. So, it works while it does, but won’t be fixed when it breaks.



I am not sure if this would be something for you but you could try our Datacake cloud-hosted Node-RED variant - aka Cake Red - which is an on-top integration on our Datacake Platform that has native Integration for any LoRaWAN Device that runs on TTN (or all the other LoRaWAN Network Server available).

If you have been using Node-RED for bringing Data into a Database and on a Dashboard (like the awesome Node-RED Dashboard extension) then Datacake could be a drop in solution for you.

When you have a device running on TTN you can easily integrate that on our platform. We also offer templates to get you started and have payload decoding on our side so you don’t need to configure an application on TTN console anymore.

See this video for an explanation: https://youtu.be/oGnZeQv7Zp0

Or the Documentation here:


And once you have all your device on Datacake you can then activate Cake Red and have a cloud hosted Node-RED in your Workspaces. This allows you to use Node-RED in the Cloud.

If you have Node-RED in your personal environment already set up, you could use the Datacake Nodes:

So if you bring your devices on Datacake you can have them available in your Node-RED.

Here’s a guide on how to get started:


It’s a bit of a workaround but an easy way to get started. If you’re just looking for Datastorage then you should take a look at Datacake.

It’s free for the first 2 devices. I am happy to offer my help in settings things up and assisting you.

I want to note that Datacake has a strong commercial character that does not scale well with DIY and community activities that are on low budget.

Node-red in combination with MQTT runs very well. There is no need to use the depreciated TTN nodes.

Setting up MQTT in Node-RED is really, pun intended, a piece of cake!

See MQTT in Node-RED [HowTo].


Very helpful that, thanks for sharing

Ah, nowadays Node-RED allows for selecting “Output: a parsed JSON object” in the “mqtt in” node. Nice.

(I updated my earlier post, now also using a “switch” node rather than a “function” to split the events.)


Thanks for all the replies eveyrone.

I hadn’t actually seen @arjanvanb 's reply before I got my nodes working with MQTT, but seriously, what a great post!

For future readers
In the end I wound up:

  1. Decoding the payload as it came in to TTN in the application dashboard.
  2. Hooking up Node-Red on a raspberry pi
  3. Used AEGIS MQTT broker inside node-red
  4. Installed InfluxDB on the pi, and got node-red to output to InfluxDB
  5. Installed Grafana on the pi and had it read from influxdb

It’s been a number of days now, and about 900 messages successfully recieved and put into the database. I’m using a long distance link to a gateway I don’t control, so my signal stability is not amazing. What has been excellent is the MQTT --> Node-red --> InfluxDB connection.

Maybe you’re using that for something else, but in general it’s not needed to have a broker. A broker allows other MQTT clients to connect to it. (Assuming your Raspberry Pi can be accessed by those.) One can set up one’s own broker in “bridge” mode to act as a client towards TTN and be a broker for others.

For most use cases (and also for the details you described), just being a client to TTN’s broker suffices. Such client is built-in into Node-RED.

If this means you’re using a Decoder in TTN’s Payload Formats in TTN Console: fine indeed. But beware: Payload available but sometimes not decoded to payload_fields in MQTT.

In fact, the timestamp below the “error occurred” debug node in my screenshot was due to some “Unable to decode payload fields: Internal error: Interrupted javascript execution for Decoder after 120.862081ms”. At the time I created that screenshot that error occurred for 0.5% of the messages (6 out of 1,238 = 0.005, in 15 hours). Note that those uplinks will still be delivered through MQTT (after the two minutes timeout as mentioned in the error message), but without a payload_fields attribute. That’s also why it’s important to subscribe to the .../errors events, to know why payload_fields is missing. (It could also fail due to a programming error, or unexpected data.)

I’d recommend decoding in your application instead of TTN Console.

Good to know on both those points. Thank you very much.