--- title: "Commands" canonical: "https://help.scopious.co.nz/space/KB/399605774/Commands" format: markdown --- > Macro (excerpt) > > Downlink Commands are a way to remotely manage and control your devices using the Scopious application. > ℹ️ This feature depends on your device’s hardware and firmware versions. Not all devices may support commands. To ensure your device is supported, check the [pre-approved device](https://scopious.atlassian.net/wiki/spaces/KB/pages/185368593) list. This guide explains how downlink commands work in the system, so you can better understand how to use them and what limitations apply. This is for informational and problem-solving purposes; you do not need to know this information to use the commands. Refer to [Send a Command](https://scopious.atlassian.net/wiki/spaces/KB/pages/399278108) to get started with commands. > Macro (toc) # What commands are supported? The features available through downlink commands are set by the device manufacturers. However, common uses include restarting the device or changing how often the device sends data (uplink interval). For most devices, commands allow users to remotely restart or update device settings. We classify these as ***configuration*** commands. Other devices provide further functionality. Devices that support ***control*** class commands allow users to interact with the environment by changing the state or I/O lines of the device. For example, you might control a valve’s servo, switch on lights, lock a gate, or trigger an alarm. The use cases for ***control*** commands are endless, and you are limited only by the capabilities of the device and connected equipment. A list of supported commands can be found in the documentation of each [pre-approved device](https://scopious.atlassian.net/wiki/spaces/KB/pages/185368593). If the command is not listed or you are using a non-preapproved device, you can still send a command to the device using the raw (hexadecimal) custom command input box. You will need to know how your device works and what format it expects. # How does it work? ## Command Processing Overview Commands use the downlink functionality supported by LoRaWAN networks. When a command is issued, it is added to a queue. Once a command has been queued, we pass the command to the LoRaWAN network server. The network server will then forward that message to the device at the next available opportunity. Most commands require the device to acknowledge that it received the command. The device does this by sending an acknowledgment message (ACK). Some commands, like the restart command, do not send an acknowledgment. How a command is processed depends on whether an acknowledgment is expected. ### ACK Expected 1. The command is sent to the network server, where it waits to be forwarded to the device. The command status is set to ***Waiting for uplink*** (more on this later). 2. The network server finds a window and sends the command. The command status is set to ***Waiting for ack***. 3. The network server receives an **ACK** from the device. The command status is set to ***Success***. If the command fails to be successfully acknowledged by the device (e.g. device is off, out of range, no ACK received, etc), the command status is set to ***Failed***. > 📝 If a command is acknowledged, it means the device successfully received the command. However, it doesn’t guarantee the command was successfully carried out. There is a possibility that the command may still fail to be executed due to invalid parameters, unsupported features, internal errors, etc. ### ACK Not Expected 1. The command is sent to the network server, where it waits to be forwarded to the device. The command status is set to ***Waiting for uplink*** (more on this later). 2. The network server finds a window and sends the command. The command status is set to ***Sent***. > 📝 Because there is no acknowledgment from the device, we cannot determine if the command was successfully received. Therefore, the final state is ***Sent***. ### Queueing Behaviour Each device has its own queue, and each queue operates on a FIFO basis. If multiple commands are issued to the same device, they will remain queued until the previous command either succeeds or fails. If for any reason a command cannot be sent or fails to be acknowledged, it will automatically fail after 24 hours. This is a safeguard to prevent queues from getting stuck when devices go offline or the network suffers a failure for an extended period of time. > ⚠️ A side effect of this automatic timeout period is that you need to ensure devices send uplinks at least once every 24 hours. ### Retry Behaviour Both automatic and manual retries are supported: - Automatic Retry - commands can be configured to automatically retry if they fail to be received by the device. Retry behaviour is configured when the command is sent. - Manual Retry - you can manually retry a command by finding it in the command history and resending it. ## When are Downlink Commands Sent? One of the key benefits of LoRaWAN devices is long battery life. A single device can last many years without needing to be charged. This is achieved by minimising running time. Most devices are asleep for the majority of time, only waking to read sensors and send uplinks at periodic intervals. This means there are limitations on when a downlink command can be sent to a device, determined by the device ***class***. ### Class A Devices With **Class A** devices, after each uplink, the device opens two small windows for receiving downlinks. This results in the lowest power consumption, at the cost of long downlink delays. A downlink can only be sent as fast as the device’s uplink interval. Once a command is queued, the network server waits for an uplink; only after this, the downlink is sent, making sure to match the device's downlink receive window. For acknowledged commands, this often means that it takes twice the uplink interval to complete all states. Once the device receives the command, it sets the acknowledgement bit to be sent in the next uplink. On some devices, the uplink will be sent immediately, on others it is combined and sent on the next uplink interval. > 📝 The majority of LoRaWAN devices are Class A, and commands to these devices are significantly rate-limited. At most one command can be sent per uplink. If your device is configured to send uplinks once every 12 hours, then only one command can be sent every 12 hours (up to 24 hours if it needs to be acknowledged). ### Class B Devices With **Class B** devices, additional receive windows are opened at scheduled times. The network server knows about the additional time slots the device is listening on and schedules downlink commands in those slots. Class B devices provide reduced latency compared to Class A devices while still conserving power. It is handy for devices that don’t send periodic uplinks or when periodic uplinks are very infrequent. Class B devices will always operate as Class A as well. ### Class C Devices With **Class C** devices, the device is always active and always listening. Class C devices are connected to a continuous power supply and do not rely on batteries. They are always actively listening for downlinks, resulting in the lowest response time, at the cost of power consumption. This tradeoff can be worthwhile for devices that need to react within tight time constraints.