deploy-solution

Deploy Solution Skill

Deploy IoT solutions through the provisioning station backend API. The core workflow is: discover backend → pick solution → get deploy-info → fill parameters → start → monitor → verify.

1. Discover Backend

The installed desktop App uses a dynamic port (picked at launch to avoid conflicts) — it is NOT 3260. Only the ./dev.sh development server uses the fixed port 3260. So discover the port first:

# Option A — ask the user: open the App → Settings → API Access, read the port shown there

# Option B — find it automatically (sidecar is launched with --port <PORT>):
PORT=$(ps aux | grep "[p]rovisioning-station --port" | grep -oE -- "--port [0-9]+" | head -1 | awk '{print $2}')
echo "Backend port: $PORT"

# Dev mode only (./dev.sh): PORT=3260

Then set the base URL and verify it's running:

BASE="http://127.0.0.1:${PORT:-3260}"
curl -s "$BASE/api/health"

Use $BASE for all subsequent commands. If the health check fails, the user needs to start the App (or ./dev.sh in dev mode).

2. Deployment Flow

Step 1: List solutions

curl -s $BASE/api/solutions?lang=en | python3 -m json.tool

Step 2: Get deploy-info (the key endpoint)

This is the AI-friendly endpoint — it returns structured parameters and a ready-to-fill request template. Always use this instead of /deployment.

# Without preset — returns all presets and all steps
curl -s "$BASE/api/solutions/{solution_id}/deploy-info?lang=en"

# With preset — returns only steps for that preset (recommended)
curl -s "$BASE/api/solutions/{solution_id}/deploy-info?lang=en&preset_id=<preset_id>"

Don't hardcode a preset_id — call without it first, read the available presets from the presets array, then re-call with the one the user picks.

Response structure:

• presets — available presets with IDs and names
• steps[] — each step with device_id, type, required, parameters, and optional targets
• request_template — a JSON body you can fill in and POST directly to /deployments/start