Test the device you have against the device you need
Emulator Workspace is the Osprio View OSDP emulator — stand in as either side of the link, a control panel or a peripheral device, run the secure channel, send OSDP commands, and script fault tests against real readers and controllers. Configure a profile, start a session, and let reusable actions drive repeatable protocol behavior instead of entering commands by hand.
In PD mode the profile editor opens into a full device-definition workflow. Declare the identity the emulator should present — OSDP version, model number, vendor code, serial number, and firmware version — so the peer on the bus sees a device with a real, consistent fingerprint rather than a bare placeholder.
Then describe what the device can actually do: contact and input monitoring, output behavior, reader-facing LEDs and audible feedback, text display, communication and security support, and general capacity hints. Each capability shapes how the emulated PD answers capability queries and behaves during a session.
Use it to stand in for a specific class of reader or controller you need to test against — model the device you already have, or the device you are about to deploy, without the hardware in hand.
Configurations live as profiles in slots on the device itself, not buried in host-side files. Load the slot table from connected hardware, then create a new profile in an empty slot, open one read-only for inspection, or promote one to the active runtime profile.
Switching between saved devices is then just selecting a slot — no re-entering addresses, keys, baud rates, or capability sets each time you change what you are emulating.
Profiles import and export as JSON, so a known-good configuration moves cleanly between sessions, machines, and test environments, and can be version-controlled alongside the rest of a test setup.
Every managed PD in a CP profile carries its own Secure Channel Base Key (SCBK) and per-PD flags, including secure-channel enforcement and unsolicited-response handling, so you configure the peer exactly as the deployment expects it.
From there the session negotiates the OSDP secure channel and runs encrypted, authenticated traffic against a peer you fully control — the right setup to exercise secure-channel establishment, key handling, and encrypted command and reply flows end to end.
Live state distinguishes a plain online link, an active secure channel, and a secure channel running on the default key (SCBK-D), so install-key fallback is something you can see rather than guess at.
A compact strip of status cards summarizes every managed PD while a session runs. Cards are ordered by PD offset from the profile and capped at the eight devices the device side currently surfaces, so the state that matters stays readable at a glance.
Each card carries a single icon for its most important live state: grey for unknown or offline, green for online without a secure channel, a green lock for an active secure channel, and an amber lock when that channel is running on SCBK-D.
Hover a card for the full textual state and how long ago it last updated — Online, Online SC Active, Online SC Active with SCBK-D, and so on. The strip is driven by live notifications from the device, which is why notification support is always enabled in the profile model.
Drive the protocol directly from the UI. In CP mode, build an OSDP command and send it to a target PD; in PD mode, submit an event toward the control panel. The available base operation follows the emulator role automatically.
Construct the payload, pick the target PD index, and fire — no scripting required for one-off traffic, and no need to leave the active session to do it.
Anything you send by hand can also be saved as a reusable action, so an ad-hoc command becomes a repeatable building block the moment it proves useful.
Base actions are the leaf operations that actually emit traffic — a CP command aimed at a PD index, or a PD-originated event submission. Save one and it becomes a card you can run with a single click.
Those base actions are the foundation for everything higher up: wrap them in repetitions, chain them into sequences, or fire them from triggers, building complex behavior from small, proven pieces instead of re-typing commands.
The actions toolbar supports an action-library workflow, so definitions can be preserved outside the current session UI and reused across runs.
The upper runtime pane splits into two live views side by side: an Event Log of incoming OSDP report activity, and a LibOSDP Logs pane of device-side log output. Watching both at once lets you line up protocol activity with what the device firmware is actually doing.
The event log carries command reports, PD event reports, and notification reports, and expands any entry for full payload inspection — so you see not just that a report arrived, but exactly what it contained.
The libosdp pane streams logs live with per-PD context tags and runtime log-level filtering, so a busy multi-PD session stays legible while you focus on one device or one severity.
When a profile drives an OSDP file transfer, the session tracks it directly so the operator can watch and manage the exchange rather than running it blind.
Outgoing transfers (CP → PD) send a registered file and show a live progress bar against the total size. Incoming transfers (PD ← CP) arrive as file cards that move through transferring to complete or failed, and a completed card holds the received bytes so the file can be downloaded.
Because a transfer is real in-flight work and a received file may not yet be saved, the workspace warns before close while one is mid-flight, so the work is never lost silently.
The actions pane turns Emulator Workspace into a lightweight automation system. Define what should happen, when it should repeat, and what should trigger it — then let the workspace drive the session while you watch the results.
Base actions are the starting point of the actions pane. Create one that sends an OSDP command to a target PD in CP mode, or submits an event toward the control panel in PD mode — the type on offer follows the current emulator role.
Each base action is saved and reusable: a named building block you can run on demand or fold into the higher-level automation types, rather than rebuilding the same payload every time.
A repetition runs another action many times on a configurable cadence. Equal mode fires a fixed count at a fixed interval — say ten times every two seconds — for predictable, evenly spaced traffic.
Random mode spreads the same count randomly across a total duration window, closer to how real traffic actually lands. Together they cover stress testing, polling validation, repeatable test cases, and soak-style load that does not fall on a tidy beat.
A sequence runs several actions in order, with a configurable delay between each step. It captures a multi-step exchange as one reusable unit instead of a handful of commands you fire by hand and hope you timed right.
Use it to model multi-step device behavior, reproduce a known command or event progression, or script a repeatable workflow — the timing is baked in, so the run comes out the same every time.
A trigger fires a target action automatically when a source condition is met, turning the pane into a lightweight event-automation system rather than a command palette.
Peer-activity triggers react to traffic on the bus. Match on any activity, or build clause groups — evaluated as OR across groups and AND within a group — where each clause tests the OSDP type code, the PD index, or a path inside the decoded payload against an expected value. A clause set can even be seeded from an observed packet.
Interval triggers fire on a timer instead, at a fixed period or randomly within a window. Every trigger has its own enabled or disabled state, controlled right from its card.
Every saved action shows up as a card in a reorderable grid, badged with its action kind and emulator mode, with edit and delete controls and a clear run-state or trigger-state indicator.
Run any non-trigger action with one click, or flip a trigger between enabled and disabled in place. Drag cards to reorder them so your most-used actions stay at the front of the pane, and active or executing actions lock against conflicting edits and duplicate runs.
The whole emulator UI configuration — your action library included — exports to JSON and imports back in a single step, so a known-good action set loads in seconds instead of being rebuilt from scratch.
That makes action libraries portable across sessions, machines, teams, and test environments, and easy to keep under version control alongside the profiles they exercise.
It is often searched for as an OSDP simulator, but strictly speaking it is an OSDP emulator. Emulator Workspace stands in for real hardware — a control panel (CP) or peripheral device (PD) — and speaks the real OSDP protocol over the RS-485 bus, so a live peer treats it as genuine hardware rather than a model of one. "Simulator" is the common label; "emulator" is the accurate term, because the software is interchangeable with a real device on the wire.
Yes. Emulator Workspace stands in as the Control Panel (CP) so you can drive and validate a physical PD or reader with no real controller on the bus — or emulate a PD to test your controller. Either side can be the software peer.
Yes. It negotiates the OSDP secure channel with full SCBK and SCBK-D handling, so you can exercise encrypted sessions and install-key fallback against a peer you fully configure.
Action cards turn any OSDP command or event into a reusable building block you can repeat on a cadence, chain into sequences, or fire from triggers — automating protocol behavior instead of typing commands.
Have a question? Ask us →
Sniff a live RS-485 bus and decode every OSDP command and reply.
Set address and baud, then key the SCBK secure channel in install mode.
Run semi-automated conformance tests and produce repeatable reports.