CC - Workstation & IoT Centralized Management Platform

English | 中文

Project Overview

CC (Central Control) is the management-side repository for a unified workstation and IoT management platform. It contains the desktop controller and data aggregation bridge. The device-side agent lives in the separate CC-rDeviceAgent repository.

Tech Stack: Rust + Tauri + TypeScript + React + MQTT + WebSocket

System Overview

Architecture

flowchart TD
    subgraph Domain_A["Network Domain A"]
        subgraph Devices_A["Devices"]
            IoT_A["IoT Device\nstationService"]
            WS_A["Workstation\nstationService"]
            Other_A["Other Equipment\nstationService"]
        end
        Broker_A["MQTT Broker\n(may have multiple)"]
        Relay_A["gRPC-Relay\n(may have multiple)"]
    end

    subgraph Domain_B["Network Domain B"]
        subgraph Devices_B["Devices"]
            IoT_B["IoT Device\nstationService"]
            WS_B["Workstation\nstationService"]
        end
        Broker_B["MQTT Broker"]
        Relay_B["gRPC-Relay"]
    end

    subgraph Controllers["Controllers (one or more)"]
        Controller1["Controller 1\nOffice/Public Network"]
        Controller2["Controller 2\nanother instance"]
    end

    subgraph Global_Services["Global Services (below Controllers)"]
        Aggregator1["Aggregator 1\n(Data Aggregation + WebSocket Bridge)"]
        Aggregator2["Aggregator 2\n(another instance)"]
    end

    %% stationService to Broker (MQTT telemetry)
    IoT_A -- "MQTT (telemetry)" --> Broker_A
    WS_A -- "MQTT (telemetry)" --> Broker_A
    Other_A -- "MQTT (telemetry)" --> Broker_A
    IoT_B -- "MQTT (telemetry)" --> Broker_B
    WS_B -- "MQTT (telemetry)" --> Broker_B

    %% stationService to Relay (gRPC)
    IoT_A -- "gRPC (control/data)\nover QUIC/HTTP2/HTTP3" --> Relay_A
    WS_A -- "gRPC (control/data)" --> Relay_A
    Other_A -- "gRPC (control/data)" --> Relay_A
    IoT_B -- "gRPC (control/data)" --> Relay_B
    WS_B -- "gRPC (control/data)" --> Relay_B

    %% Aggregators subscribe to brokers (MQTT)
    Aggregator1 -- "Subscribe raw telemetry (MQTT)" --> Broker_A
    Aggregator1 -- "Subscribe raw telemetry (MQTT)" --> Broker_B
    Aggregator2 -- "Subscribe raw telemetry (MQTT)" --> Broker_A
    Aggregator2 -- "Subscribe raw telemetry (MQTT)" --> Broker_B

    %% Aggregators push aggregated data via WebSocket to Controllers
    Aggregator1 -- "WebSocket (aggregated telemetry)" --> Controller1
    Aggregator1 -- "WebSocket (aggregated telemetry)" --> Controller2
    Aggregator2 -- "WebSocket (aggregated telemetry)" --> Controller1
    Aggregator2 -- "WebSocket (aggregated telemetry)" --> Controller2

    %% Controllers send control messages via Relay
    Controller1 -- "gRPC (control/data)" --> Relay_A
    Controller1 -- "gRPC (control/data)" --> Relay_B
    Controller2 -- "gRPC (control/data)" --> Relay_A
    Controller2 -- "gRPC (control/data)" --> Relay_B

    %% Annotation
    note1["Note: Each domain may have multiple MQTT brokers and Relays.\nAny Aggregator can connect to any broker.\nAny Controller can connect to any Relay.\nMultiple Aggregators can run in parallel."]
    note1 -.-> Domain_A
    note1 -.-> Domain_B

    style Domain_A fill:#e3f2fd,stroke:#1e88e5
    style Domain_B fill:#e8f5e9,stroke:#43a047
    style Controllers fill:#fff3e0,stroke:#fb8c00
    style Global_Services fill:#f9fbe7,stroke:#afb42b
    style Broker_A fill:#fce4ec,stroke:#e91e63
    style Broker_B fill:#fce4ec,stroke:#e91e63
    style Relay_A fill:#f3e5f5,stroke:#9c27b0
    style Relay_B fill:#f3e5f5,stroke:#9c27b0
    style Aggregator1 fill:#d1c4e9,stroke:#512da8
    style Aggregator2 fill:#d1c4e9,stroke:#512da8
    style Controller1 fill:#ffecb3,stroke:#ffa000
    style Controller2 fill:#ffecb3,stroke:#ffa000

Loading

Components

Component	Description	Language
CC-rController	Desktop GUI controller with plugin support	Tauri + React + TypeScript
CC-Aggregator	Data aggregation and WebSocket bridge	Rust
CC-rDeviceAgent	Workstation/IoT agent service, maintained in a separate repo	Rust
gRPC-Relay	A relay for gRPC over QUIC/HTTP2/HTTP3, not includes in this repo	Rust

Features

Completed Phases

• Phase 1: Architecture Refactoring - Migration from gRPC to MQTT message bus
• Phase 2: Plugin System - 5 built-in plugins (cpu, memory, network, process, disk) + Plugin Marketplace
• Phase 3: Client Plugin Architecture - Configuration-driven UI + Template Marketplace
• Phase 4: Data Flow Testing - MQTT + WebSocket integration
• Phase 5: Fix Verification - Bug fixes and validation
• Phase 6: Command Script Management - Script execution system
• Phase 7: Batch Operations - Multi-target batch task creation, execution, and result tracking
• Phase 9: Alert Rules - Real-time alert rule management and station-side alert evaluation

Operations Features

• Script Management - Create, edit, filter, and execute reusable shell scripts
• Batch Task Management - Create reusable batch tasks, pin frequently used tasks to the main toolbar, select saved scripts, run tasks against saved targets, and inspect execution results
• Alert Rule Management - Create alert rules from templates, execute rule checks, and review alert history

Plugin System (5 Built-in Plugins)

1. CPU Monitor - Real-time CPU usage and metrics
2. Memory Monitor - RAM utilization tracking
3. Network Monitor - Network interface statistics
4. Process Monitor - Running process management
5. Disk Monitor - Storage usage and I/O metrics

Marketplace Features

• Plugin Marketplace - Browse and install community plugins
• Template Marketplace - UI layout and visualization templates

Project Structure

~/CC/
├── CC-rController/           # Tauri desktop controller (React + TypeScript)
│   ├── src/              # Frontend source
│   │   ├── plugin/       # Plugin system
│   │   │   ├── script/   # Script management UI
│   │   │   ├── batch/    # Batch task UI
│   │   │   └── alert/    # Alert rule UI
│   │   └── App.tsx       # Main application
│   └── src-tauri/       # Rust backend
│       └── src/
│           ├── ws_bridge.rs    # WebSocket client
│           ├── script_ops.rs   # Script commands
│           ├── batch_ops.rs    # Batch task commands
│           ├── alert_ops.rs    # Alert rule commands
│           └── lib.rs           # Tauri commands
├── CC-Aggregator/       # Data aggregator (MQTT → WebSocket)
│   ├── src/
│   │   ├── mqtt.rs       # MQTT client
│   │   ├── websocket.rs  # WebSocket server
│   │   └── config.rs    # Configuration
│   └── CC-Aggregator.toml
├── proto/
│   └── cc.proto          # Shared gRPC contract snapshot
├── scripts/              # Startup scripts
│   └── start-all.sh     # One-click start
└── logs/                # Application logs

~/CC-rDeviceAgent/     # Split repository for the device-side agent

Quick Start

Prerequisites

• Docker (for MQTT broker)
• Rust 1.70+
• Node.js 18+
• pnpm (recommended) or npm

Step 1: Start MQTT Broker

# Start Mosquitto MQTT broker
docker run -d --name mosquitto \
  -p 1883:1883 \
  -p 9001:9001 \
  eclipse-mosquitto:latest \
  mosquitto -c /mosquitto-no-auth.conf

Step 2: Start All Components

cd ~/CC
./scripts/start-all.sh

This script starts:

1. CC-Aggregator (MQTT → WebSocket bridge)
2. CC-rDeviceAgent (Workstation agent)
3. CC-rController (Desktop UI)

By default the scripts look for CC-rDeviceAgent next to this checkout:

~/CC
~/CC-rDeviceAgent

Set CC_RDEVICEAGENT_DIR=/path/to/CC-rDeviceAgent when the agent checkout is elsewhere.

Step 2b: Start IoT Device Simulation

Use the dedicated launcher when you want a lightweight MQTT broker plus N simulated CC-rDeviceAgent devices in Docker:

cd ~/CC
./scripts/start-iot-sim.sh 20

Useful commands:

./scripts/start-iot-sim.sh --status
./scripts/start-iot-sim.sh --stop
./scripts/start-iot-sim.sh 20 --dry-run

Optional environment overrides:

BROKER_PORT=1884 STATE_INTERVAL_SECONDS=2 ./scripts/start-iot-sim.sh 50
BUILD_MODE=debug ./scripts/start-iot-sim.sh 10
REBUILD_BINARY=1 ./scripts/start-iot-sim.sh 20
USE_HOST_BROKER=1 HOST_BROKER_HOST=host.docker.internal ./scripts/start-iot-sim.sh 20

This flow builds a small runtime image for CC-rDeviceAgent, starts one Mosquitto broker, then launches deterministic stations such as iot-001, iot-002, and so on. The Docker image is assembled from a host-built cc-rdeviceagent binary instead of recompiling Rust inside Docker, so simulator startup is much faster. If host port 1883 is already occupied, the launcher automatically reuses the existing host MQTT broker instead of trying to bind a second Mosquitto container.

Step 3: Access the Application

• Desktop Controller: Launch CC-rController application
• WebSocket: ws://127.0.0.1:8080
• MQTT: localhost:1883

Configuration

CC-Aggregator (CC-Aggregator.toml)

server_id = "aggregator-001"

[mqtt]
host = "localhost"
port = 1883
client_id = "cc-aggregator-001"
keepalive_secs = 30

[websocket]
listen_addr = "127.0.0.1:8080"
max_connections = 1000

[logging]
level = "info"

CC-rDeviceAgent (CC-rDeviceAgent.toml)

Configuration for workstation agent (MQTT client, plugins, etc.)

Development

Build Components

# Build Aggregator
cd CC-Aggregator && cargo build

# Build Device Agent from its split repository
cd ../CC-rDeviceAgent && cargo build

# Build Client
cd CC-rController && pnpm install && pnpm tauri build

Logs

Logs are stored in ~/CC/logs/:

• aggregator.log - Aggregator output
• rdeviceagent.log - Station service output
• rcontroller.log - Controller output
• iot-sim/docker-compose.generated.yml - Generated compose file for the Docker simulation

Troubleshooting

Connection Refused Errors

If you see "Could not connect to localhost: Connection refused":

1. Check MQTT Broker

   docker ps | grep mosquitto
   nc -zv localhost 1883

2. Check Aggregator Running

   ps aux | grep cc-aggregator
   tail -f logs/aggregator.log

3. Check WebSocket Port

   ss -tlnp | grep 8080

Rebuild After Changes

cd CC-Aggregator && cargo build --release
./scripts/start-all.sh

Stop IoT Simulation

./scripts/start-iot-sim.sh --stop

License

MIT License