Operate
These guides show you how to act on devices that are already deployed: update their firmware, send them actions, exchange files with them, and open a terminal or a tunnel to them, all without a site visit.
For a product-level overview, see Operate remotely.
Before you begin
-
Your devices are provisioned and connected. See Devices.
-
You can call the Public API, or you have the
funCLI installed and logged in:fun login -
You know your
<project-id>and<registry-id>, and the device IDs or serial numbers you want to act on. -
Some features need software on the device. The Edge components implement the device side for Linux and MCU devices.
Choose the right tool
| You want to… | Use | Guide |
|---|---|---|
| Install a new firmware on one device or a whole fleet | Firmware update command, single or batch | Firmware updates (OTA) |
| Send your own instructions with timeouts, retries and priority | Actions, optionally with capabilities and encoders | Actions and custom encoders |
| Push a file to a device, or pull a log file from it | File transfers | File transfers |
| Open a shell, or reach a service running on the device | Remote terminal, port forwarding | Remote terminal and port forwarding |
How the pieces fit
- Commands are the platform's built-in operations, such as
firmware-updateandreboot. You send them to one device, or to many devices as a batch that is tracked device by device. - Actions are your own operations. An action type sets the timeouts, the number of retries and the priority. Each action is tracked per device, from
pendingtosuccess,failure,timeoutorcancel. - Capabilities and encoders let a single action work across device types and firmware versions. Your encoder, a cloud function, converts the action into each device's format.
- File transfers send presigned URLs to the device, which then downloads or uploads the file over HTTPS. Each file shows up as an action on the device.
- Remote terminal and port forwarding go through the device's existing connection to Fundamentum, so the device needs no inbound port.
All of these show up live in the Hub, on the device page and in the batch and action views.
A typical first session
-
Check that the device is online, then open a terminal on it from the Hub to look around. See Remote terminal and port forwarding.
-
Pull its log file to your machine:
fun devices transfer device-to-cloud -p <project-id> -r <registry-id> -s <serial-number> \ --remote-path /var/log/myapp.log -n myapp.log -
Push a corrected configuration file back:
fun devices transfer cloud-to-device -p <project-id> -r <registry-id> -s <serial-number> \ -f app.toml --remote-path /etc/myapp/app.toml -
Once the fix is in a new firmware, roll it out to the fleet as a batch and follow it device by device. See Firmware updates (OTA).
Common rules
- Every operation is scoped to a project, and most to a registry. Your role on the project decides what you can do. See Roles and permissions.
- Commands and actions wait for their device: an offline device receives them when it reconnects, within the timeouts you set.
- Everything the Hub does goes through the Public API, so you can script it with
fun apior plain HTTP.