Setting up The Things Gateway in Charlottetown, Prince Edward Island

Home Labs Stories Setting up The Things Gateway in Charlottetown, Prince Edward Island

by Peter Rukavina

ABOUT THIS STORY

Posted on June 8, 2018

#Gateway #Community #Application #MQTT #thethings #Range #Ports #Firewall

Intermediate

1 person likes this

Contact author

Introduction

We are working to set up an environmental sensor network in the city of Charlottetown, Prince Edward Island, a small community of 36,000 people off the east coast of Canada. We are, right now, a small group of people of diverse backgrounds, operating as an ad hoc advisory committee with City Hall. We're inspired, in part, by the efforts of a similar group in Amersfoort, NL under the Meetjestad.nl banner.

This is the story of installing a Things Network Gateway, setting up a test sensor using a Things Uno, testing the range, and optimizing the location of the gateway's location and antenna. It's work in progress.

Internet Access Issues

To connect The Things Gateway to the Internet we had three options at City Hall: a guest wifi network, an internal wifi network, and an internal wired network.

Trying the Wifi

We were unsuccessful, despite multiple attempts, in getting The Things Gateway to connect to either the guest or internal wifi network: the SSID showed up on the gateway setup page, we could enter the WPA password, but LED 2 on the gateway stayed in "fast flashing" mode, which, it says here, means that it could not connect to the Internet.

Trying the Wired Network

Once we switched to a hardwired Ethernet connection to the City Hall network, we had more success: the gateway connected to the Internet, but then became stuck on slow-flashing LED 4, indicating it could not connect to The Things Network via MQTT.

Firewall Issues?

We learned from this forum post that the source of this issue may be outbound traffic being blocked on necessary ports on the City Hall network, namely:

1) 1700/udp (legacy/Semtech, incl “connection tracking” in iptables)
2) 1883/tcp + 8883/tcp (MQTT forwarder) (any other name for this?)
3) 1900/tcp + 1901/tcp (Go forwarder aka the “new packet forwarder” as it’s named in eg.

Using telnet on a MacBook Air connected to the same network, we were able to confirm that the firewall was, indeed, preventing the required outbound traffic; for example:

telnet test.mosquitto.org 1883

did not result in a successful connection.

So we sent an email to the City Hall IT department, as follows:

As we discussed this afternoon, to be able to send sensor data (received wirelessly from sensors around the city) to The Things Network, where it can be used, the gateway we’d like to install in City Hall needs to be able to communicate on ports other that the standard ports 80 and 443 that the City Hall firewall is set up to allow.

Specifically, the following is required of the firewall:

1. Port 1700/UDP (including “connection tracking”).
2. Ports 1883/TCP and 8883/TCP.
3. Ports 1900/TCP and 1901/TCP.

For all of the above, it’s only outbound traffic that needs to be allowed — there’s no need for traffic from the Internet inbound to be allowed in to the City Hall network.

The required firewall changes were made quickly, and the next morning we were ready for testing again.

Success!

With the ports on the firewall open, we were able to get The Things Gateway connected to both the Internet (through a wired connection to the City Hall network) and to The Things Network, confirmed both by the state of the LEDs on the gateway, and by The Things Network console:

Things Uno Setup

With The Things Gateway in place and operating properly, we were ready to test the LoRaWAN part of the setup; our test device was a Things Uno (an Arduino Leonardo with a LoRaWAN chip on it).

Arduino Script

Our first step, after confirming that the Things Uno was working properly and obtaining its Device EUI, was to write a script, using the Arduino IDE, to broadcast a single-byte "ping" every 10 seconds. The script looks like this:


#include <TheThingsNetwork.h>

// Set your AppEUI and AppKey
const char *appEui = "XXXXXXXXXXX";
const char *appKey = "XXXXXXXXXXX";

#define loraSerial Serial1
#define debugSerial Serial
#define freqPlan TTN_FP_US915

TheThingsNetwork ttn(loraSerial, debugSerial, freqPlan);

void setup()
{
  loraSerial.begin(57600);
  debugSerial.begin(9600);

  // Wait a maximum of 10s for Serial Monitor
  while (!debugSerial && millis() < 10000)
    ;

  // initialize digital pin 13 as an output.
  pinMode(13, OUTPUT);

  // turn off the LED
  digitalWrite(LED_BUILTIN, LOW);

  // show the TTN status
  ttn.showStatus();

  // join TTN
  ttn.join(appEui, appKey);
}

void loop()
{
  // Prepare payload of 1 byte to indicate LED status
  byte payload[1];
  payload[0] = 1;

  // Send it off
  ttn.sendBytes(payload, sizeof(payload));

  // wait 7 seconds while flashing the LED 
  waitAwhile();
}

wait 7 seconds while flashing the LED 
void waitAwhile()
{

 for (int i=0; i <= 10; i++){
  digitalWrite(LED_BUILTIN, LOW);
  delay(350);
  digitalWrite(LED_BUILTIN, HIGH);      
  delay(350);
 }
}

Set Up The Things Network Application

We next setup of a The Things Network Application called charlottetown-heatmap and attached a Device to it called charlottetown-things-uno, attaching the Device EUI we'd discovered earlier; with the Device in place, we were able to copy-and-paste the appEui and appKey values from the "Example Code" section of the console into the Arduino script above, and upload that to the Things Uno.

Success!

As soon as the script was uploaded, we started to see activity under the "Data" tab of the "Device" section in The Things Network console, which confirmed that everything LoRaWAN was working properly.

A Case for the Things Uno

If were were going to be taking the Things Uno out into the field, we wanted to protect it from the elements a little; fortunately, someone else had already gone down this road, and we were able to download a ready-made STL file for our 3D printer.

It's Too Big!

Looking at a preview of the Things Uno case STL file, it became evident that we couldn't use it as-is on our Monoprice Select Mini 3D printer, as the printer only has a 10 cm by 10 cm bed, and the case parts, top and bottom, were ganged together in the STL file:

The solution to this was to import the STL file into Tinkercad and then to draw a "hole" over one side, join the "hole" to the case (thus erasing the other half) and exporting the result as a brand new STL file, and then to repeat for the other side. The result was two separate STL files, one for the bottom of the case, and one for the top:

(The original case and the sliced up versions are Creative Commons Attribution Share Alike. Commercial use is allowed, you must attribute the creator, you may remix this work and the remixed work should be made available under this license).

Printing the Case

Printing the case took a long time–about 3 hours for the top and 2.5 hours for the bottom–but the result was very satisfying and fits together well, leaving all the bits of the Things Uno that can benefit from being exposed open for access.