LoRaWAN is typically used for reading data from field transmitters (sensors, meters etc), with the means of such devices transmitting "uplinks". How about communicating down to a device?
Introduction
LoRaWAN is a perfect protocol for monitoring data from field devices. The nature of the protocol and the devices that support it is to be a Long Range (LoRa), low data, low power eco system.
The field devices are typically transmitting data every few minutes, and going to a sleep state in between intervals to preserve the battery. Data is received by a LoRa gateway, which then can relay such data over LoRa again, push it over the internet to an IoT service using a dedicated connector, or pushing it over IP/internet to a receiving aggregator (like a Tridium device) via MQTT or HTTP.
The nature of the system makes it less recommended for main controls (slow data rate and potential data loss), but perfect for secondary controls such as energy optimizations and comfort improvements, controls strategies that are not going to compromise the core functionality of a system if they were not available.
There are however some LoRaWAN devices which do accept messages sent to them. Messages going to a LoRaWAN transmitters are referred to as "downlinks".
In this article we are going to use this specifically to drive the 2 available digital outputs of the UC300.
This article is based on the MQTT article from Milesight, which you can find HERE
The implementation we are going to use for the downlinks is by the article on Step 6, second method using the $deveui (I found it easier to implement).
Preparing the UC300
The UC300 is configurable using a PC, connecting via USB C and using the Toolbox software (available HERE).
Connect with Toolbox (default password is 123456) to enable the 2 digital outputs
Set the Application Port and Confirmed Mode (I use port 85 and unconfirmed on this guide)
Configuring the UG65
Note that in this article we are not going to explain how to add LoRa devices to the UG65, or talk about the payload decoders. If you need to know more about this part, start by checking this article HERE
The article uses HTTP as a method to transmit data, but most of the article is applicable also when using MQTT: the payload will still be a JSON payload, the setup of the sensors/transmitters is pretty much the same.
Just remember that with MQTT you will need a broker to manage your data. You can install Mosquitto on a PC, raspberry pi, or use a third party broker as preferred.
For a generic introduction to MQTT, check THIS ARTICLE
We start from the UG65 settings, by adding the MQTT data transmission on the Application associated with our UC300
While configuring the MQTT settings, the "uplink" topic is where the system will publish all the information received by the field sensors.
The "downlink data" topic will be instead subscribed to and the UG65 is going to check it to verify your commands to be sent to the field device.
Because we use method 2 from the Milesight article, we need to add the dynamic topic part $deveui to the topic. This will make the topic dynamic, so an individual downlink topic will be available to each device using this application
Configuring the Niagara station
For the purpose of this article, we are not going through the entire setup of MQTT on Niagara.
However, we have THIS ARTICLE that can give you a full guide on how to set the standard Abstract MQTT Driver Network, which is what we also used in this example.
We added a subscribe string point called "uplinks", where all the sensor data is going to be received, and 1 publish string point called "downlinks" where the specific payloads for my UC300 are going to be published.
Note the topic containing the DevEUI of my UC300 zoomed in below:
For the "reading" part of the uplinks, you can see the result below.
You can reference these 2 articles on how to use the JSON decoding blocks, HERE using the Json Toolkit from Tridium, and HERE using the Innon Json module from us.
Note below highlighted the state of the 2 digital outputs of my UC300 are shown
As for writing the downlink payloads, we need a bit of background.
The "data" required to action the Digital Outputs on the UC300 is highlighted in the LoRa Communication Protocol document HERE
To summarize, the data we need is the following:
070000ff to open output 1
070100ff to close output 1
080000ff to open output 2
080100ff to close output 2
How to we translate this into a payload for our MQTT communication?
The payload would need to be the following:
{"confirmed":[true/false],"fport":[Data Port],"data":"[Data in Base64]"}
Once we know that for our settings we need "confirmed" to be "false", data port "85", we can translate the HEX data above into BASE64, using an external tool (link THIS ONE).
The payload required to action on the digital outputs will then be as following:
{"confirmed":false,"fport":85,"data":"BwAA/w=="}
Switches OFF digital output 1
{"confirmed":false,"fport":85,"data":"BwEA/w=="}
Switches ON digital output 1
{"confirmed":false,"fport":85,"data":"CAAA/w=="}
Switches OFF digital output 2
{"confirmed":false,"fport":85,"data":"CAEA/w=="}
Switches ON digital output 2
See here below an example of implementation I made for my test, but you can build your own strategy to send the desired payload accordingly
Things to check if it doesn't work
Is the SF (Spreading Factor) setting in the sensor matching the SF setting in the Gateway Local Network Server settings (profile)?
Is the Class also the same? Sensors with batteries tend to use class A, and even if writable, they will need to be configured in Class A without adding other classes, otherwise the Local Network Server will interpret the Downlink message as a Class C message instead of A. If the sensor is powered, Class C might be needed. Please check your settings.
Is "Confirmed" being used on the sensor and did you set your payload accordingly (true/false)?
Are you using the right fport? For Milesight sensors the default is typically 85.
Did you check on the Packages section of your Local Network Server if the downlink message is getting through? If not, you might be pushing to the wrong topic or your payload has a mistake.