Use this reference to identify the device commands used by application workflows and the release information to retain with a package.
Applies to: The tools provided by the selected RobustOS firmware and SDK release. Confirm availability and help output on the designated device before scripting a command. The available tools and component versions depend on that release.
Run the utility commands in this article in an authorized device shell. They are separate from the RobustOS command-line interface (CLI) commands such as show and status used to discover tags. Follow the device-shell access prerequisites before using shell-based tools.
The uci utility uses this form:
uci [<options>] <command> [<arguments>]
Use uci -h to inspect the supported interface. Replace bracketed values with the actual tag or file; the brackets are notation, not literal shell arguments.
| Command | Purpose |
|---|---|
get <tag> |
Read a configuration value, for example lan.ip |
set <tag> <value> |
Update a value at a tag |
add <tag> <id> |
Add a list entry with an ID |
del <tag> <id> |
Delete a list entry |
load |
Load configuration from XML |
default |
Generate default configuration |
save |
Save configuration changes |
apply |
Apply configuration changes |
commit |
Save and apply changes |
export [<xmlfile>] |
Export configuration; the default destination is /tmp/config.xml |
import <xmlfile> |
Import configuration from XML |
check <category> |
Check whether configuration has changed |
refresh [<category>] |
Reload configuration from file to RAM |
print |
Display the UCI configuration currently in RAM |
Options are -c for resetting other configuration to default values during import, -d for detailed export, -s for a simpler export that omits some disabled features, and -h for help. In particular, -c changes the import's effect; do not add it as a generic troubleshooting option.
Read the UCI configuration guide before writing settings. Use the package signing and deployment guide for the preconditions around whole-device import, export or firmware operations. The commands above are an interface reference, not a sequence to run.
USI handles reported status. It does not replace UCI configuration management.
usi <command> [<arguments>]
| Command | Purpose |
|---|---|
get <tag> |
Read status, for example system.firmware_version |
set <tag> <value> |
Update a reported status value |
clear <tag> |
Clear status at the specified tag |
sync <category> |
Synchronize status to the unified format |
Read system status through documented tags. Update only the status owned by your application; changing a status field does not configure the underlying modem or service. See the USI status guide for XML definitions and synchronization.
renv accesses the RobustOS router-environment store. It is distinct from a shell's ordinary process environment. Without a command it prints the current router environment.
renv
renv get <name>
renv set <name> <value>
renv del <name>
The command forms do not define the meaning, ownership or lifecycle of every variable. Confirm those properties for the named variable before changing it. Use the environment API reference for C access and documented return behavior.
The device-side sending interface is:
sms [options...] <phone_number> <sms_content>
The -s option selects the second modem where that device and service support it. It does not mean “second SIM card.” If sms -h reports unknown option -h, use the command interface supplied for that firmware; do not rely on a common help convention for every utility.
Sending an SMS is an external action and may incur service charges. Confirm the intended recipient and service configuration before testing. See Hardware and system services for SMS and email integration.
SDK workflows may use libraries such as OpenSSL, libevent, libxml2, curl and ncurses, and device commands such as curl, OpenSSL, mutt and TFTP. Presence in a library list does not establish that a corresponding command is installed, or that a particular feature is enabled.
Inspect the selected SDK's package tree and release records, then verify the required files on the test device. Use target-matching packages for missing dependencies. Do not substitute a desktop binary for a target binary.
The build and package guide provides the sample-package and dependency lookup path. Treat that catalogue as a starting point for a particular SDK, not a promise that an older sample name exists in every archive.
Keep the following with each application release:
A historical component list is not a current software bill of materials. Resolve missing versions, mismatched source URLs and unclear license entries with the release owner; do not turn those entries into new claims about the installed software. Retain the original evidence while corrections are reviewed.
Before handing a package to another team, check that they can identify its target, reproduce its build, locate its dependencies and distinguish the results that were tested from those that remain untested.