WobotRelay

Our primary goal with WobotRelay is to make device onboarding and distributed fleet management effortless and hassle-free.
One Tool for everthing you need whether it's Edge AI or the Cloud AI processing.

Onboarding Made Easy. No Hassle. One tool for

We aim to enable true one-click device onboarding—whether it's for the Edge AI or the Cloud AI processing. Simplify your deployment process and get your devices connected and managed in no time.

Stop Wrestling With SSH & Scattered Installs

Say goodbye to countless guides, tedious port-forwards, and juggling half a dozen tools just to get connected.

• Manual SSH Headaches? Endless commands, managing private keys, navigating firewalls… enough already.
• Multiple Install Guides? SmartStreamer, WMS, Hailo drivers, DT, WoPipe… one complex setup for every tool.
• Ports to Open—Every Time? Firewall rules, NAT punch-through, VPN tunnels… a constant battle for connectivity.
• Bandwidth Metrics Needed? Do you really want to constantly bug your users just to get throughput information?
• Toolchain Overload? RPort, ffmpeg, custom scripts—why complicate simple tasks with so many moving parts?

Imagine skipping all of that—and going live with a single click.

WobotRelay handles everything—from connectivity to configuration—to get your streams and commands flowing in seconds.

WobotRelay is a powerful server-client system designed to manage distributed fleets of devices with ease. It provides centralized control over remote agents, enabling configuration management, task execution, and real-time monitoring through a secure relay server.

Key Features

• Centralized configuration management for distributed clients
• Remote command execution with real-time feedback
• Network speed testing capabilities
• Process management with automatic restart policies
• Configuration file watching and automatic reloading
• Comprehensive logging and status monitoring
• Secure authentication and authorization workflows

The WobotRelay server acts as the central hub for all communication between admin interfaces and client agents. It handles authentication, message routing, and state management for the entire system.

Core Components

Server Endpoints

Server Message Types

The WobotRelay client is a managed agent that connects to the central server, executes commands, and reports status. It handles local process management and can perform tasks like speed tests when requested.

Client Lifecycle State Machine

Core Components

Configuration File (config.yaml)

name: "Client-1"
handshakeKey: "group-default123"
clientID: "" # Will be populated after approval
clientSecret: "" # Will be populated after approval
logLevel: "info"
commandRestartMaxDelay: "5m"
paths:
  service-A:
    runOnInit: "/usr/bin/my-service --config /etc/my-service.conf"
    runOnInitRestart: "yes" # Restart if it crashes
    environment:
      - "ENV=production"
      - "LOG_LEVEL=debug"
  backup-job:
    runOnInit: "/usr/local/bin/backup --daily"
    runOnInitRestart: "no" # Only run once on start

Client Message Handling

Client Authentication Flow

Admin Authentication Flow

Security Considerations

Communication between the Admin UI/API and the Relay Server, and between the Relay Server and Clients, is primarily handled via WebSocket messages. Messages follow a standard JSON structure.

Message Structure

{
  "type": "message_type", // e.g., "command", "config_update", "speed_test_result"
  "correlationID": "unique_request_id", // Used to match requests and responses
  "clientID": "target_client_id", // Optional: Specifies target client for server->client messages
  "payload": {
    // Message-specific data
  }
}

The correlationID is crucial for asynchronous communication, allowing the sender to associate a response message with its original request.

Common Message Types

This is not an exhaustive list. Refer to the server source code for the complete set of message types and their payloads.

Client config.yaml

A basic client configuration file looks like this:

serverAddress: "wss://your-relay-server.com/ws"
handshakeKey: "your-initial-handshake-key"
clientID: "" # Will be populated after approval
clientSecret: "" # Will be populated after approval
logLevel: "info"
commandRestartMaxDelay: "5m"
paths:
  # Define processes to manage
  my-app-service:
    runOnInit: "/opt/my-app/start.sh"
    runOnInitRestart: "yes" # Restart if it crashes
    environment:
      - "APP_ENV=production"
  data-collector:
    runOnInit: "/usr/local/bin/collect-data"
    runOnInitRestart: "no" # Only run once on start

The clientID and clientSecret fields are initially empty and are populated by the server during the authentication and approval process.

Sending a Command (Admin API/UI)

To execute a command on a specific client via the WebSocket API, you would send a JSON message like this:

{
  "type": "execute_command",
  "correlationID": "cmd-xyz123", // Unique ID for this request
  "clientID": "client-abc-123", // The ID of the target client
  "payload": {
    "command": "ls",
    "args": ["-l", "/home/user"]
  }
}

The server would then route this message to the client with ID "client-abc-123". The client would execute ls -l /home/user and send back a command_output message with the same correlationID.

Updating Client Configuration (Admin API/UI)

To update a client's configuration, send an update_client_config message:

{
  "type": "update_client_config",
  "correlationID": "cfg-update-789",
  "clientID": "client-abc-123",
  "payload": {
    "config": {
      "logLevel": "debug",
      "paths": {
        "my-app-service": {
          "runOnInit": "/opt/my-app/start.sh",
          "runOnInitRestart": "yes",
          "environment": [
            "APP_ENV=staging" // Change environment variable
          ]
        }
      }
    }
  }
}

The client will receive this update, save it to its local config.yaml, and trigger a reload if necessary (or if reload_config is sent).