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.)
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.
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.
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:
Decoding the payload as it came in to TTN in the application dashboard.
Hooking up Node-Red on a raspberry pi
Used AEGIS MQTT broker inside node-red
Installed InfluxDB on the pi, and got node-red to output to InfluxDB
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.
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 whypayload_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.