Beyond Cortex

VOLTRA Device Status

Read and summarize VOLTRA device state through Cortex. **Read-only — does not issue control commands.** Use when the user asks about connected devices, battery level, training mode, power/load state, cable zero position, saved devices, nearby devices, or wants an AI agent to inspect device readiness before taking action. To actually change a setting or start training, use `voltra-device-training`.

Use the local voltra command as the source of truth. Prefer JSON output for machine parsing, and avoid inferring live device state from cached local files unless the user explicitly asks about storage.

Workflow

  1. Confirm Cortex resolves:
where.exe voltra
voltra --version
voltra -v
  1. Check the current session:
voltra status --json
  1. If disconnected, list known devices and reconnect only when the user asked to inspect a device:
voltra list-known --json
voltra reconnect --json

Use voltra disconnect --json only when the user asks to end the local Cortex session or switch devices.

  1. Refresh live device state before reporting readiness:
voltra refresh <scope> --json   # e.g. all, epStatus
voltra status --json
  1. For cable readiness, use the explicit command:
voltra check-cable-zero --json

What To Report

Summarize only fields observed from Cortex output:

  • Connection: connected/disconnected and device name/id.
  • Battery: battery percent when present; say unknown if not present.
  • Mode: none, weightTraining, resistanceBand, damper, isokinetic, isometric, customCurve/Professional, rowing, or skiing when exposed.
  • Power/load: powerEnabled true/false/unknown.
  • Cable: result of check-cable-zero when relevant.
  • Dock/readiness: only report dock state when Cortex output exposes it directly or a guarded command returns a clear dock message.
  • Twin topology: report the explicit topology/pairing state when present; do not infer a confirmed pair from two independently connected devices.
  • Blocking state: repeat Cortex's explicit message when command output says blocked.

Guardrails

  • Do not repeatedly retry a command that returns a clear blocked reason such as place the device on the dock first, cable-not-zero, or workout-mode-none.
  • Do not claim the device is on the dock unless Cortex exposes that state or a control command succeeds after its dock guard.
  • Do not use .voltra storage as live battery, dock, or power state. Treat it as saved-device metadata only.
  • Do not treat battery below 20% as a Cortex blocker. Cortex does not enforce a low-battery training gate; report battery level as-is and only block if the device or Cortex explicitly rejects a command for low battery.
  • For confirmed Twin topology, inspect the connected logical master with voltra twin status --json. The --master <MASTER> selector is optional and is only needed to disambiguate multiple connected sessions or pairs. Pairing, unpairing, and Twin telemetry control belong to voltra-device-training; do not infer Twin state from two ordinary status responses.
  • If voltra is not found, diagnose install/PATH before discussing device state.
  • If the device reports unexpected blocking states or connection issues that persist, load voltra-cli-troubleshooting for systematic diagnosis.
  • For first-time setup, use voltra-getting-started.
  • For training control, use voltra-device-training.
  • For workout data, use voltra-workout-data.

Useful Commands

voltra scan --json
voltra list-known --json     # alias: voltra devices
voltra connect <device-id-or-name> --json
voltra reconnect --json
voltra disconnect --json
voltra refresh <scope> --json   # scopes include all, epStatus, trainingMode, resistanceBand, autoUnload, weightTraining, damper, isokinetic, cableLength, workoutState
voltra status --json
voltra check-cable-zero --json
voltra twin status --json