NodeRED, Application Handler & "Custom Node"

[Patrick Phillips]

Hello,

We purchased the NodeRED/AEP version in order rapidly develop. We would like to use the AEP to pass along our network data out to The Things Network.

We have been told that a packet forwarder would be required, but I’m also told:

The gateway can send decrypted data directly to the application handler using a custom The Things Network (TTN) node that will be available on the Node RED gateway.

Can you please provide more detail on “the application handler and the custom TTN node?

The ideal would be a ‘node’ in a NodeRED flow which could pass data directly to TTN.

Thanks,
Patrick

[Brandon Bayer]

Hey Patrick,

I’m in contact with Johan and am working on getting the Conduit working with TTN.

But for a little background, LoRa networks consist of a number of gateways running packet forwarders each forwarding packets to a single central LoRa network server. Out of the box, the Conduit is configured as a self-contained LoRa network. It hosts both a packet forwarder and network server. The packet forwarder simply forwards packets to the on-board network server.

So to use the Conduit with a public network like TTN, the network server needs to be disabled, and the packet forwarder needs reconfigured to point to the TTN network server. Unfortunately, this cannot be done using a custom TTN node. The scenario described in your quote is basically using the Conduit as configured by default and then using Node-RED to send data to some cloud server like Bluemix, m2x, or a TTN application handler (but not the TTN network server).

Since the encrypted packets are simply forwarded in packet forwarder mode to the cloud-based network server, the Conduit can’t process LoRa packets. This renders Node-RED useless for handling them (it could still be used with something like a serial or GPIO mCard). You’ll have to handle the LoRa packets using a TTN application handler (which I believe they have Node-RED for this or have plans to have it).

Now, the AEP Conduit doesn’t currently support reconfiguration as a packet forwarder (probably sometime down the road), but the mLinux version does using these instructions.

Although those instructions will successfully point the Conduit’s packet forwarder to TTN, I have yet to successfully see packets through the TTN API. Johan and I are working on this.

Does that help?

-Brandon

[Andrew Lindsay]

Could there be an option to dump the packets to the local mqtt broker as it does already and forward them on also?

Andrew

[Patrick Phillips]

Thanks, Brandon. Helps a lot.

Andrew, that was going to be one of my questions — can we sent an MQTT through NodeRED to TTN?

And, Brandon, my original question stems from your observation:

You’ll have to handle the LoRa packets using a TTN application handler (which I believe they have Node-RED for this or have plans to have it).

My great hope is to use NodeRED to point packets through a TTN application handler, as Johan and you mention.

Before Johan’s most recent conversation with MultiTech, Lawrence Griffith mentioned:

The work MT is doing is on integrating multiple AEP to form a wide area private network, and that’s probably going to be MQTT based.

We will purchase multiple AEPs. Security will be important. A hybrid private/public network may help us. Perhaps we should use MQTT. (We’ll use it for other purposes.)

Do you know what other information can I gather on defining the NodeRED TTN Node and/or MQTT and where might I get it?

I just want to make sure, before I even unpack the conduit we have. (Avoiding headaches is better than rushing at a wall . . .)

Thanks a ton,
Patrick

• This reply was modified 8 years, 7 months ago by Patrick Phillips. Reason: clarity

[Andrew Lindsay]

As I understand it, when using public mode and TTN the LoRaWAN packets are passed straight on to TTN server. This then does all the authentication and network/session key generation etc for the end nodes joining the network. This is all done on the Conduit in the AEP version and therefore would not work as-is. Whether it is possible to add in the packet forwarder as an option and subscribe to TTN data I’m not sure but there are other ways to access the data coming from the LoRa end nodes via TTN.

This is therefore making the TTN gateway product look like an attractive option as it will have just a single function of a packet forwarder.

Andrew

[Lawrence Griffiths]

Andrew I’ve been pondering whether a Proxy would be the best approach. But feel this a big bit of work. Idea the AEP has a node that emulates a LoRaWAN end-node and proxies to the TTN network an behalf on the real AEP end-nodes.

This would allow AEP work with any LoRaWAN provider. And would allow a start of starts using multiple AEP to build a bigger networks using a LoRa backbone. As the only way to AEP to AEP is wired/cellular.

Lawrence

[Brandon Bayer]

You guys are wanting an AEP model that’s easy to configure only as a packet forwarder gateway, correct?

If so, that’s easy for us to implement (we already have a proof of concept for it). It’ll basically be an option in the AEP GUI that behind the scenes will do the type of reconfiguration described in the mLinux forwarder conversion guide. You can then point AEP to any public LoRaWAN network. But, you still couldn’t use Node-RED to process LoRa packets.

If you want to process packets with Node-RED, say to only forward important events to TTN, it’s probably doable but a significantly larger problem. One possible way is to configure the Conduit’s on-board network server with the same settings as the TTN server. Then use Node-RED to process LoRa packets and send important ones to the TTN server via a REST API. Another way might be to develop some type of protocol for LoRa network servers to communicate with each other.

-Brandon

[Patrick Phillips]

Brandon, in our installation we would like to process packets with Node-RED, and yes, to forward important events. When you say “doable but a significantly larger problem” do you mean by comparison to “really easy?”

What steps would TTN and we (with your help) go through to configure our network server with the TTNs settings? If this option is reasonably feasible it would be good to test it.

Lastly, can we process MQTT through Node-RED to TTN (or anything for that matter) without matching server settings?

Thanks — Patrick

[Brandon Bayer]

Patrick,

It’s a significant problem because no one has done it before (that we know of), and there isn’t an obvious straightforward way to do it. I suggest emailing marketing at mtsmktg@multitech.com and fully describe what you’d like it to do (they & product management decide what features go into the Conduit).

Unfortunately, you can’t currently configure AEP to match the TTN network.

With any network server settings, you can use Node-RED to publish received LoRa packets to any MQTT server, but I don’t know if TTN supports receiving data via MQTT.

-Brandon

[Patrick Phillips]

Brandon, Thanks.

I posted your comment on the TTN site and Johan responded this way:

Thanks for posting. I see a huge value in using Node RED, not really on the gateway but in the cloud instead, after the routing, deduplication and decryption by open source TTN components.

If you do want to use Node RED on the gateway for other (local area network) purposes, you could indeed forward the raw LoRa packets using MQTT to a TTN router. That is indeed possible as we are offering a MQTT broker too.

Thanks,

Patrick

[Andrew Lindsay]

Hi Brandon,

I’d be interested in being a Beta tester for the AEP version of the Lora packet forwarder for TTN.

Also, my replacement LORA-MAC card has arrived so I can continue to develop sensor nodes.

Thanks

Andrew

[Terrence Spencer]

Any update on this topic?
I need to do private/public processing.

Packets that come in with my IDs need to go to Azure, those coming in from the public will go to TTN.

Can it be done?
What are the steps?

[Jason Reiss]

If you have followed the things network install guide the installed packet forwarder (global_conf.json) can be configured to pass uplink packets to the local network server and the things network server.

https://thethingsnetwork.org/wiki/Installing-your-Multitech-mLinux-Conduit

You may see downlink issues with two network servers are scheduling packets for one gateway.

[Terrence Spencer]

I have an AEP, not mLinux. Can it be done with this model? I have been following.

[wojtek t]

I posted instructions on my blog

https://iotblog.org/connect-aep-ttn-lorawan/
Enjoy

• This reply was modified 7 years, 11 months ago by wojtek t.
• This reply was modified 7 years, 11 months ago by wojtek t.

[Author]

Posts