Configuration step-by-step

In this guide we will go through steps to get a Milesight Outdoors LoRaWAN gateway (UG67) up and running. This will be achieved using the UG67s built in software configuration interface, accessible through a browser.

We will focus on MQTT client applications and test the messages with a mosquitto_sub client on Linux.

The main steps are:

0. Optionally update firmware
1. Make sure gateway connects to the internet (Network configuration).
2. Set up the Network server
3. Test packets

What we will need #

Although a gateway is all we need for the configuration, we suggest to have at least one working LoRaWAN-enabled “end node” device available (with its AppKey and DeviceEUI also available). A paired end node will allow to test the configuration and will make sure that the packets are transmitted. Here is the check-list:

1. A gateway, access to power supply, ethernet cables;
2. Network connectivity using least one of: a cabled connection, a WiFi access point, a working SIM card;
3. A PC, a laptop or a smartphone with a browser for remote configuration;
4. Access to a MQTT broker (used for this tutorial) or a HTTP server accepting POST requests.
5. For a complete setup, at least one end node is required, for example, a LoRaWAN tester or a LoRaWAN enabled IoT weather station.

Establishing a connection #

Connect the plug labelled as Power+Data on the power supply to the gateway via an ethernet cable.

Connect the plug labelled as Data to the Internet (via a router or a switch, depending on your network setup).

Once the cabling is OK, the gateway will be powered on and you can connect to it for setup. When powered up, the gateway will create a wireless access point Gateway_??????. Please connect to this AP, and open http://192.168.1.1 in a browser.

Username: admin
Password: password

Upon first connection (and subsequent firmware reboots) the interface will first as to select some basic configuration settings. The “Email configuration” can be safely skipped.

We’ve prepared several short walkthroughs within the “Getting started with UG67 Milesight LoRaWAN gateway” tutorial series. This one illustrates the basic steps of a first connection.

Upgrades, backups #

As an important first step, let’s update the firmware of the gateway, as the device might have been shipped with an old version of the firmware.

These notes have been written with the firmware version v60.0.0.41-r3 (Release Date: February 15, 2023).

It is a good idea to occasionally check the manufacturer’s web page for firmware updates. Download the new firmware. Follow the Maintenance > Upgrade menu to upload it to the gateway. It can take 5 minutes or more to update the firmware. Note that here you can also reset configuration to factory default.

It is also a good idea to make configuration backups using the Maintenance > Backup and Restore menu. Backups are extremely useful: restore a broken configuration, or clone a production configuration to a new gateway.

Also, it is a good idea to backup the configuration before performing a firmware upgrade (as described a few paragraphs above).

Upgrading and backing up the configuration are separate steps that can be performed independently. The previous video tutorial shows how to upgrade and backup a configuration as well.

Network Interface #

The UG67 gateway can connect to the internet via an ethernet cable, through a wireless access point, or using a SIM Card.

It is possible to set up the network in DHCP or static IP mode.

See the following tutorial for more information.

OpenVPN client #

A gateway can be accessed by its public IP address. But what if the gateway is behind a firewall or if it does not have a static IP address?

It is possible to configure an OpenVPN client to create a safe passage in all these complicated circumstances. Do so – and you won’t have to worry about losing track of your precious gateway.

In your personal OpenVPN console <your_id>.openvpn.com, first create a connection and download the configuration file with the “ovpn” extension. Suppose that it is saved as <conn_id>.ovpn.

Configure the connection using the Network > VPN > OpenVPN Client menu as show in the image below, where the Remote IP address should be copied from <conn_id>.ovpn.

Copy-paste the text from between the following tags in <conn_id>.ovpn into the respective text files verbatim (tags should not be included):

1. <ca>...</ca> to ca.crt
2. <cert>...</cert> to <conn_id>.crt
3. <key>...</key> to <conn_id>.key
4. <tls-auth>...</tls-auth> to ta.key

Upload the certificates from the menu Network > VPN > Certifications in the following order:

1. ca.crt to “CA”
2. <conn_id>.crt to “Public Key”
3. <conn_id>.key to “Private Key”
4. ta.key to TA

Finally save the configuration, and go to Status > VPN > OpenVPN Client. If you see a row lit in green stating “openvpn_1 connected …” you should be all set. You will need the Local IP address – so take note.

System #

Make sure that the time is correct and set to local time zone in System > General Settings > System Time.

Network Server #

Network server defines all the aspects of communication between the device and end users on the Internet. A LoRa device that wants to be on the network must first register on the network server.

Each UG67 comes equipped with its own network server. This simplifies the networking. But on the flip side, each end node should be registered with at least one UG67, with which it is expected to establish a connection. As we shall see later, the easiest way to go about it is to register all devices with all UG67s using bulk import and configuration backup.

The device registration is our final target here. However, a device can only be registered when a relevant profile, application and application codec are present on the network server. In this section we will walk you through the process in the order that assumes we are starting from scratch.

A typical loop of device administration is to create the necessary profiles, applications and codecs first, and then import as many devices as needed one by one, or in bulk.

Network access profile #

An activation profile defines how a device and a server communicate. It must be registered with the ‘join server’.

Create one OTAA profile for OTAA devices +and one ABP profile for ABP devices+ (the ABP profiles are not recommended for security reasons).

Set the power to 0 (which will set the transmitted power to the maximum of 14 dBm). Usually the IoT weather stations are OTAA devices, but an Adeunis tester can be configured in either way.

Application #

An application defines what happens to the received payload: the method of transport and the destination’s end-point.

UG67 provides four distinct destination servers to choose from:

1. MQTT broker (preferred by IoT applications)
2. HTTP server
3. HTTPS server

Note however that only zero or one instance of each can be activated in one application. So for example, we could serve a payload as an MQTT message as well as an HTTP POST request concurrently, but it is not possible to serve it to two MQTT brokers simultaneously.

From Wikipedia: MQTT is a lightweight, publish-subscribe, machine to machine network protocol for message queue/message queuing service. It is designed for connections with remote locations that have devices with resource constraints or limited network bandwidth, such as in the Internet of Things (IoT).

It is OK to use public MQTT services but eventually you will probably want to install a dedicated MQTT broker. See our MQTT broker guide. Our favorite public service is mosquitto.

Create one application for each device type.

For example, if you want to use an Adeunis tester, you will need an application for that. Call it tester_adeunis or whatever. For multi-site installations with stationary devices (such as weather stations) it makes sense to indicate the end node’s type and gateway’s location in the application’s name (example: accra_meteorain).

One application can be used to register any number of equivalent devices on the network. However, it makes no sense to register logically distinct devices (e.g. testers and weather stations) in the same application.

Application Codec #

An application decoder defines how humans or machines will read the device’s payload.

Usually, the manufacturer of a LoRaWAN-enabled device provides also a default application decoder/encoder for Chirpstack, which may be simply copied into the respective fields.

When designing a custom decoder, you need to ask yourself whether there are any formatting constraints in place for content delivery. For example if the payload is supposed to be consumed by a database, and this database expects a certain JSON structure, then a custom decoder had better take that into account.

If there are no such constraints in place, then the default codec will do just fine. Otherwise, you may need to tweak the default coded to match the expected data structure.

Add devices one by one #

Devices can be added one-by-one from the Network Server > Device > Add menu.

Note that you will be requested to choose from existing profiles, applications, and application codecs. The application codec will only be active once the the device EUI is entered.

Add multiple devices #

It is possible to add many devices in one go from the Network Server > Device > Bulk Import menu. To do that you will need to create a data file in csv format. We provide a tool to create bulk import data files.

Message test: MQTT broker #

If all went fine, the messages will be transmitted.

Transmitted packets can be inspected from the configuration interface’s Network Server > Packets menu.

However, this interface is only available to the gateway’s admin. The messages are available to the end user through the transport defined in the applications.

To access them as a typical user would, we have to retrieve them from the MQTT broker by subscribing to the topic of interest using a MQTT client. The topic strings are defined in the applications. If you don’t know which topic is of interest you can subscribe to all topics using the string '#'.

Any MQTT client can be used to test for the messages. In this tutorial we will be using a command-line MQTT client mosquitto_sub on Linux. There are many MQTT clients available on the market such as PAHO MQTT, MQTT Explorer, IoTMQTT Panel, etc., some of which also run on smartphones and tablets.