Emulator Workspace

Emulator Workspace is the device-control workflow for emulator-capable hardware. It takes the user from device connection, through slot-backed CP or PD profile configuration, into a live emulation session with runtime status, logs, and reusable action automation.

Workspace story ​

Emulator Workspace is easiest to understand as a three-stage flow:

1. connect emulator-capable hardware
2. configure or load a slot-backed profile
3. run live emulation and drive behavior from the active session UI

That flow matters because the workspace is not only a form editor. It owns both persistent profile state on the device and the live operational session that runs after a profile is loaded.

What this workspace owns ​

Emulator Workspace owns emulator-session UX only:

• selecting and connecting emulator-capable hardware
• loading slot information from the connected device
• creating, opening, importing, and exporting slot-backed profiles
• configuring CP or PD behavior and profile details
• writing profile state back to device slots
• starting and stopping runtime emulation
• showing live OSDP reports, libosdp logs, PD status, and action automation

USB transport ownership, cross-tab exclusivity, and session binding remain outside the workspace in shared managers.

Stage 1: Connect hardware ​

Device setup ​

1. Open an Emulator tab.
2. Click PAIR NEW if the device has not been authorized yet.
3. Select an emulator-capable device from the list.
4. Click Connect.

If you are using Osprio Mini hardware, make sure the device is running the emulator app. Osprio Mini cannot expose monitor and emulator roles at the same time.

What happens after connect ​

After the device is connected, the workspace loads the emulator slot table from the device and shows the available profile slots.

From there, the user can:

• create a new profile in an empty slot
• open an existing slot for read-only inspection
• manage an existing slot as the active runtime profile
• import profile JSON into a slot-backed workflow

Stage 2: Configure the profile ​

Slot and profile flow ​

The normal setup path is:

1. connect the device
2. load slot information
3. create, open, or import a profile
4. choose CP or PD mode
5. configure the profile details
6. save the profile to the selected slot
7. continue into the active emulator session

Profile import and export use JSON so profile state can move between sessions and test environments.

Mode selection ​

The workspace supports two emulator roles:

• CP for Control Panel emulation
• PD for Peripheral Device emulation

The profile editor changes shape depending on the selected mode.

Common profile fields ​

Both modes expose shared top-level profile settings:

• profile name
• baud rate
• log level

These fields define the slot-backed runtime configuration that will be used once emulation starts.

Managed PD configuration ​

In CP mode, the profile editor manages a list of PD definitions.

Each PD entry includes:

• PD name
• PD address
• secure channel base key (SCBK)
• selected flags such as secure-channel enforcement or unsolicited-response handling

The UI always enables notifications internally. Notification support is treated as a required invariant for OsprioView because the active session expects PD status and secure-channel updates from the device.

PDs are stored in profile order, and that same order is later used by the active session for PD status presentation and action targeting.

PD identity and capabilities ​

In PD mode, the editor expands into a device-definition workflow and includes:

• PD identity fields such as version, model, vendor code, serial number, and firmware version
• PD capabilities used to model the kind of device behavior the profile represents

This is useful when the emulator should resemble a real class of device rather than acting as a minimal placeholder.

Typical capability categories include:

• contact or input monitoring
• output behavior
• reader-facing indicators and audible feedback
• text display support
• communication and security support
• general device size or capacity hints

Use capabilities to describe the device you want the profile to resemble, and keep that description consistent with the rest of the profile.

Stage 3: Run the active emulator session ​

Once the workspace enters the active session, the layout changes from profile editing to operational control.

Header controls and runtime status ​

The active header provides:

• back navigation to the slot workflow
• the current mode label (CP or PD)
• Start and Stop runtime control
• the connected USB device badge
• live PD status cards

PD status cards ​

The PD status cards summarize managed PD runtime state in a compact badge-style format.

A card is shown for each configured PD, ordered by PD offset from the profile. The strip is capped at 8 visible PDs because that matches the device-side maximum currently surfaced in the UI.

Each card shows:

• PD plus the configured PD address
• a single status icon for the most important live state

The icon states are:

• grey circle: PD state unknown or offline
• green circle: PD online with no secure channel active
• green lock: secure channel active
• amber lock: secure channel active with SCBK-D

Hovering a card shows the textual state and the relative update age, for example:

• Unknown
• Offline
• Online
• Online, SC Inactive
• Online, SC Active
• Online, SC Active (SCBK-D)

These cards are driven by runtime notifications from the device. The workspace treats those notifications as operationally important, which is why notification support is always enabled in the profile model.

Event log and device log ​

The upper runtime pane is split into two live views:

• Event Log for incoming OSDP report activity
• LibOSDP Logs for device-side log output

This lets the user correlate protocol activity with lower-level device behavior during a run.

The event log is used for:

• command reports
• PD event reports
• notification reports
• expanded payload inspection

The libosdp log panel is used for:

• live log streaming from the device
• per-PD context tags
• log-level filtering during runtime

Actions pane ​

The lower runtime pane is the actions workspace. It is where the user defines reusable runtime behavior instead of manually re-entering commands or events every time.

What the actions pane does ​

The actions pane supports four action types:

• base actions
• repetitions
• sequences
• triggers

The available base action type depends on emulator mode:

• in CP mode, the base action is a command sent to a target PD
• in PD mode, the base action is an event submitted toward the control panel

Toolbar actions ​

The actions toolbar exposes mode-aware creation and configuration controls:

• Add Command or Add Event
• Create Repetition
• Create Sequence
• Create Trigger
• import or export of emulator UI config JSON

The toolbar also enables an action-library style workflow where action definitions can be preserved outside the current session UI.

Base actions ​

Base actions are the leaf operations that actually emit runtime traffic.

Examples include:

• CP commands targeted at a PD index
• PD-originated event submissions

These base actions become the building blocks for the higher-level automation types.

Repetitions ​

A repetition executes another action multiple times, with a configurable cadence:

• equal — a fixed count at a fixed interval (for example, ×10 every 2s)
• random — the same count spread randomly across a total duration window

This is useful for:

• fixed interval command bursts
• repeated event generation
• repeatable command or event test cases
• soak-style traffic that does not land on a predictable beat

Sequences ​

A sequence runs multiple actions in order with configurable per-step delays.

This is useful for:

• modeling multi-step device behavior
• reproducing a known command or event progression
• creating a reusable scripted workflow without manual timing

Triggers ​

A trigger automatically executes a target action when a source condition is met.

The trigger model supports two source types:

• Peer-activity matching — fire in response to traffic seen on the bus. The match can be any (any peer activity) or a set of clause groups, evaluated as OR across groups and AND within a group. Each clause tests a field — the OSDP type code, the PD index, or a path inside the decoded payload — against an expected value. A starting clause set can be seeded from an observed packet's payload.
• Interval activation — fire on a timer, either at a fixed period or at random within a window.

Each trigger has an enabled/disabled state controlled from its card.

This makes the pane more than a command palette. It becomes a lightweight event automation system for emulator sessions.

Action cards ​

Saved actions appear as cards in a reorderable grid.

Each card provides:

• drag handle for reordering
• action kind and mode badges
• edit and delete controls
• run state or trigger state indication
• one-click execution for non-trigger actions
• enable or disable control for trigger actions

The grid is drag-sortable, so users can keep commonly used actions near the front of the pane.

Runtime expectations for actions ​

Action execution is tied to the live emulator session.

In practical terms:

• actions can only send traffic when the emulator is running
• trigger actions react automatically instead of being manually sent
• active or executing actions are locked against conflicting edits or duplicate execution

File transfer ​

When the profile drives an OSDP file transfer, the session tracks it directly so the operator can watch and manage the exchange:

• Outgoing transfers (CP → PD) send a registered file; the active transfer shows a live progress bar against the total size.
• Incoming transfers (PD ← CP) appear as file cards that move through transferring, then complete or failed. A completed card holds the received bytes so the file can be downloaded to the client.

Because a transfer represents real in-flight work and received files may not yet be saved, the workspace guards against losing them — see the close behavior below.

Session lifecycle and close behavior ​

Runtime behavior ​

While emulation is running, the session is operationally active in the same way a live capture tab is active.

Running emulation can block close until the user confirms, and the shell performs stop and cleanup work before tab removal or return-to-wizard. A file transfer that is still in flight, or a received file that has not yet been downloaded, also prompts before close so the work is not lost silently.

Device disconnect behavior ​

If hardware disconnects during use, the tab is not silently destroyed.

Instead, the session can fall back into an orphaned state so the user keeps the current view of:

• slot/profile context
• event history
• libosdp logs
• action definitions

That makes disconnect handling explicit and inspectable instead of destructive.