Setting up Multitech Conduit Gateway for TTN

Hi @johan — we’ll be setting up our conduit this weekend. Looking forward to at least seeing where our “edge” is in relation to TTNs. Love to know how your Multitech call went, when you get a chance. —P

1 Like

@creatinghere, @Ropu, @johan Can we all have a Skype call this weekend ? I think we are all looking for the same information.

1 Like

Following this thread…

I am adding @eduardo who is helping us in the project in Sao Paulo too. He is a software developer.

I am able - skypename: artsandideas – but mine in the AEP NodeRED issue. Different endpoint/protocol.
I would very much like to know specifics for my platform of choice. BTW, in a firm believer in the nodeRED. It provides easy and rapid development.

Personal note: One key “capacitor” and real social value-maker of TTN should, in my opinion, be to foster an “everyone as engineer”, diverse, low barrier to entry philosophy.

Low cost, wide access, diversity and simple “hacking” is crucial… That is why we purchased NodeRED.

:smile:

Patrick

2 Likes

Hi @flavio

I have been playing with the MT stuff for a while in the TTN dungeon at RockStart and here are my findings:

Next to the micro USB cable you will need either a PC equiped with an old school serial port or a USB to Serial RS-232 with DB9 male to be able to run the AT commands to the mDot development board.

For the connection to the MT Conduit a simple ethernet cable is fine.

For the mLinux model you can use this guide to do the setup: http://www.multitech.net/developer/software/mlinux/
Some basic Linux knowledge could help and make sure to have an SSH client installed. I personally use TeraTerm

For setting up the mbed mDot you would need an account at mbed and the platform can be found here:
https://developer.mbed.org/platforms/MTS-mDot-F411/

In two weeks I will join the hackers space again and continue my exploration :slight_smile:

2 Likes

Thanks @KarlNL for sharing this info. @eduardo has experience with Linux and he is helping me here.

Sorry for the late reply @creatinghere @flavio @iikaw @eduardo @Ropu

I had a good call with Multitech about integrating their Conduit with The Things Network. So there are a couple of versions, two of them are interesting for us: the mLinux and the Node RED one.

The mLinux will run a packet forwarder. They are currently working on that and I expect results this week. Instructions will follow once they have that working.

The Node RED version is intended for private networks and does all the decryption on the gateway. That’s fine but doesn’t really align with the default set up of The Things Network. It will be supported though; the gateway can send decrypted data directly to the application handler using a custom The Things Network node that will be available on the Node RED gateway. People that want to use the Node RED gateway as a “normal” gateway: they can flash it to a mLinux version and run the packet forwarder.

BTW @creatinghere we will support Node RED on the application handler too. I don’t think there’s much use for it in wide area networks on the gateways.

1 Like

Thank you @johan.

Two questions come to mind:

  • Is there any ETA on “custom The Things Network node”?
  • And, by “node” you do mean a TTN node for building MT NR flows into TTN, right?

If so, this would be killer, it would signal great dev. diversity and adoption — we can’t wait! :smile:

Thanks,
— Patrick

Hi @flavio @creatinghere @KarlNL @Ropu @johan ! Let me share with you my first impressions about tradeoff between mLinux and Node RED technical approaches. Node RED puts abstraction layer to obtain results supposedly faster (service-oriented) and mLinux seems to me a bottom up approach. For those who have knowledge in Linux, mLinux sounds good, mainly because it gives a better control of development process. Please, let me know what you think about it.

True, but I think it’s primarily intended for another architecture. For the nodes to actually do things with data, you need to decrypt the data on the gateway. In wide area networks, you don’t know the application keys at the gateway level.

@johan, For us, a broad, community-driven project (5 towns on an island) ease of development is vital for widespread adoption/use and diverse applications. NodeRed on the conduit makes that possible.

  1. Can we use MQTT as our pub/sub protocol with TTN?

Andrew @thinginnovations wondered:

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

Or, 2) are you thinking of another way for NodeRed conduits to exchange authenticated packets with TTN?

Cheers.

Patrick

@eduardo the as @johan has said the Node-RED version is designed for private networks and not for public TTN. What it does allow is do processing closer to the edge which does seem to appeal to some of the TTN community. Also node-red version gives you for free DeviceHQ which allows remote re-boot, firmware and node-red updates from the cloud. You don’t get device HQ with mLinux.

BTW we use Conduit AEP (Node-RED) to cover a single site and to integrate to onsite and cloud servers via mqtt/web services. Also Conduit has other mCards for WIFI/BLE/Thread so makes great integration tool.

Lawrence

@johan @iikaw @thinginnovations I want to post a portion of a conversation with Brandon Bayer at Multi-Tech here, verbatim. It may help the TTN/AEP configuration process:

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.

Here’s an update from Brandon: One quick way to send data to TTN from Node-RED would be MQTT:

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.

That would be easiest and convenient. Possible?

1 Like

Thanks for posting @creatinghere. 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.

1 Like

@johan Very happy to hear you’re a big proponent of Node-RED! Excited too that the post-decryption option might be supported! This particular configuration would allow us to "have our cake and eat it too — allow people to do some local area processing w/NodeRED AND manage some post / TTN processing as well.

And, I would like to use MQTT as it would mean I could route MQTT packet to your broker AND route them to my Mongodb for use in web applications!

Where do I get the TTN broker info?

All good news. Thanks so much!

Patrick

1 Like

I am posting details Friday late afternoon or evening. I’m presenting from 3 PM CEST at The Things Network Hackerspace our network architecture, including details on how to get the data as a developer. If you’re interested, we can set up a Hangout.

So the idea is indeed to offer Node RED as a TTN offered approach to work with decrypted data directly in a cloud environment. This allows you to shoot messages directly in your MongoDB or a cloud middleware platform.

2 Likes

Very much want to. (You are 6 hours ahead, correct?) 9am EST.
— Let’s set up a hangout and I’ll attend.

Excellent!

@johan I would like to attend too. I will check if @eduardo can participate on Friday too.

1 Like

@johan that is what we have here to start playing:

I will meet with @eduardo tomorrow to start the setup of the DIY gateway.

1 Like