Protequ Adapter Developer Docs

Build a device adapter that bridges physical security hardware — controllers, readers, NVRs, panels — to the Protequ platform. You describe the device in YAML and write thin C# protocol logic; the framework and its source generator handle the rest.

Start here

• Overview — what an adapter is and how it fits together
• Getting started — from zero to your first event
• Local dev setup — run and debug an adapter locally

Understand the model

• Code generation — how YAML + your C# become typed Things, commands, and events
• Framework architecture — the runtime: Thing tree, lifecycle, messaging, capabilities
• Core concepts — events, status, commands, functions, and the rest of the vocabulary

Build

• Patterns — proven recipes: command handling, event translation, status polling, video streaming, and more
• Archetypes — end-to-end shapes for common device families
• Reference — the generated API, functions registry, and YAML properties
• Supported devices — per-adapter reference: device model, capabilities, events, acceptance test results

Ship

• Publishing an adapter — package your adapter as a labelled container image and push it to repo.protequ.com
• Writing and delivering documentation — the full path from device documentation to the published adapter pages
• PQ SDK Tooling — install the tooling, prepare the coverage file, validate the bundle, and preview the generated pages
• Image anatomy — the Dockerfile, the runtime contract, and how the installer runs your container
• Label reference — every OCI label the platform reads, and what it drives

Prove it works

Two kinds of checks

Technical requirements protect the platform: memory safety, stable long-running operation and correct use of the framework (for example, no direct EventBuilder calls). Protequ requires them. The build enforces many of them with analyzers; review checks the rest.

Behavior checks describe how a device appears in PQ (for example, a detector alarm also raises its partition). We recommend that your adapter meets all of them. If you decide not to, for any reason, that is a legitimate choice and it is yours. How closely an adapter matches PQ behavior can only influence a customer's decision whether to install it.

• Definition of done — what "finished" means, and the states a capability can end in
• Implementation checklist — informal per-capability progress tracker while you build
• Acceptance tests — the behavior your adapter has to produce on real hardware, scenario by scenario
• Build diagnostics — the rules the build checks for you, and what each diagnostic id wants

---

New to the framework? Read Code generation and Framework architecture first — they are the mental model everything else builds on.