Check Runtime Status

When you're driving the Agent app and want a quick answer to "what is my robot actually doing?" — without leaving the home screen, and without firing up the wizard — the Runtime Status row on the face is the first place to look.

The glance row on the home screen

On the Agent's home screen, just above the connection row, you'll see a one-line strip that always reflects the live Runtime:

• preset: name — the active preset the agent is running
• A short status word: Idle, Building…, Flashing…, Running, Error, …
• A small bulb showing the firmware link health (grey = disconnected, amber = connecting/silent, green = connected)
• TX / RX byte counters that move while serial traffic is flowing
• A cog button on the right edge

Click the cog to open the full Runtime Status activity.

The Runtime Status activity

The activity is reachable two ways:

1. The cog on the glance row.
2. The Runtime → Runtime Status entry in Fixo Studio.

It shows four sections, top to bottom:

1. Build & Inject — the same band you see inside the Fixo wizard. Build, flash, and run controls live here. The chips report the active preset, board, and Run-stage details.
2. Live Values — placeholder for now; will populate as the firmware protocol grows a read-back path.
3. Numex Channels — one row per active channel with the stanza name and an activity light.
4. Event Log — the persistent record of every status change, connection change, ping-timeout, error, preset swap, and firmware reply that has happened on this agent. Survives restarts so you can come back the next morning and see what happened overnight.

Use Change active preset… at the bottom to switch the agent to a different preset (the active runtime tears down and the new one boots).

Use Clear log… to wipe the event log when you're starting a fresh investigation.

When the event log is most useful

The event log catches the moments you don't witness live:

• The agent booted, came up Running, then dropped to Silent at 03:14 — and a PingTimeout entry tells you what the firmware said before going quiet.
• A preset rebuild silently failed because the board reverted to FlashFailed — the StatusChange chain shows the exact transition.
• A user changed the preset to something they shouldn't have — PresetChange records the swap with both names and content hashes.

Sample one firmware-status entry per minute and capture the first reply per (preset, firmware-hash) pair, so a quick boot still leaves a baseline. The rest are stripped to keep the log human-readable.