Protocols
Browse the protocols by system or function. Each page explains the interface, common integration requirements, limitations and supporting sources.
On this page
Overview#
This section treats a protocol as more than a port number or packet layout. Each reference separates the application semantics, message or object model, transport, discovery, identity, security, failure behaviour, conformance boundary, and physical consequence.
Families#
| Family | What it connects | Start here |
|---|---|---|
| Video and media | Cameras, encoders, recorders, VMS, analytics, intercom, and browser/cloud media | Video and media |
| Web and messaging | APIs, web services, event streams, brokers, and cloud integrations | Web and messaging |
| Access control | Readers, controllers, credentials, mobile devices, and field buses | Access control |
| Alarm monitoring | Premises transmitters, receivers, monitoring automation, and verification audio | Alarm monitoring |
| Building and industrial | BMS, PLC, SCADA, gates, power systems, lifts, and field equipment | Building and industrial |
| Infrastructure | IP, discovery, time, administration, AAA, serial, wireless, power, and discrete I/O | Infrastructure |
| Interoperability and legacy | Cross system models, identity synchronisation, and legacy PTZ control | Interoperability and legacy |
Read protocol references in layers#
System outcome and safety state
↑
Application objects, events, and commands
↑
Session, transaction, retry, and discovery rules
↑
Security: identity, authorization, integrity, confidentiality
↑
Transport, network, data-link, and physical medium
A protocol at one layer doesn't inherit guarantees from a similarly named technology at another. TCP delivery isn't application acknowledgement. TLS peer authentication isn't command authorisation. A valid checksum isn't proof of an authorised sender. A successful API response isn't proof that a lock, relay, camera, or alarm path reached the intended physical state.
Developer checklist#
Before implementing or selecting a protocol, establish:
- The exact standard edition, profile, optional features, and vendor extensions at both endpoints.
- Which endpoint is authoritative for identity, time, configuration, and physical state.
- Message size, ordering, duplicate, retry, timeout, reconnect, and partial failure behaviour.
- How peers and users authenticate, how actions are authorised, and how keys or certificates rotate.
- Whether the protocol protects confidentiality, integrity, freshness, and availability, or relies on a protected conduit.
- Which actions are observational, configurational, or physically actuating.
- What evidence is needed before claiming conformance or interoperability.
Safety boundary#
References in this section are explanatory. Don't send discovery, diagnostic, configuration, write, unlock, relay, reset, silence, acknowledge, or control traffic to a live system without authorisation, an agreed change window, independent observation, and a recovery path. Keep fire, egress, duress, lockdown, lift, gate, and life safety interfaces outside exploratory work.
See verification and safety, secure protocol parsing, and segmentation and conduits.