Compatibility
What the system speaks, and what it works with.
Fifteen open protocols, no mandatory SDK. If your fleet is already installed, this is the page that says how it gets in — without a sales call in between, and without a brand list we could not stand behind.
- 15
- protocols in production
- Open
- protocols, no mandatory SDK
- 0
- mandatory proprietary SDKs
Video
What comes in from the camera. ONVIF is the front door; the rest are ways of moving that video to the screen, and each one exists because the previous one doesn't always work.
ONVIF
Discovering the camera and talking to it
Network onboarding, video profiles, dome movement and events. Profile S for the stream, G for on-camera recording and A for access control.
The basis of the whole video inventory
RTSP
Bringing in the video stream
The standard transport for live video. When the path isn't the one the brand documents, the system learns it by probing and stores it: without that, a restart leaves the camera mute.
Every camera
WebRTC
Watching it in the browser without lag
Under a second of latency on the video wall. It's what makes following someone with the dome not a fight against delay.
Video wall and live view
HLS
When WebRTC can't
Fallback for cameras whose sub-stream is H.265, with hardware decoding. It carries more delay but doesn't leave the operator without a picture.
Automatic fallback
MJPEG
The last resort
Frame by frame, expensive in compute and network. Used only when nothing else decodes, and the system says so rather than hiding it.
Older cameras
ISAPI · VAPIX
What ONVIF doesn't reach
Vendor interfaces for what the standard doesn't cover: radiometry, on-board analytics or fine configuration. Used on top of ONVIF, never instead of it.
Bespoke integration
Measurement and process
What comes in from sensors and plant equipment. Here the data isn't an image: it's a number with a unit, and it has to arrive with its origin.
SNMP v1 · v2c · v3
Energy and infrastructure
Power supplies, PDUs, UPS and network gear. Polled reads and trap reception, which is how equipment reports for itself instead of waiting for the next round.
Energy module
Modbus TCP · RTU
Process sensors and actuators
The plant's de facto protocol. Process variables, equipment states and outputs; the register map belongs to the device, not to us.
Measurement sensors
MQTT
Wireless and IIoT sensors
The route battery sensors come in through, and Zigbee and Z-Wave gateways too. One path for many radio protocols.
Sensors and automations
OPC-UA
Talking to control and to the historian
The system is a client and also a server: it reads from a SCADA and publishes its own historian for others to read. No extra licence for a foreign program to read your data.
Industrial integration
Zigbee · Z-Wave
Sirens, contacts and ambient sensors
They come in through a gateway over MQTT. Low-power radio for what doesn't justify cabling.
Via MQTT gateway
Access control
Doors, readers and credentials. It's where the modern standard and thirty-year-old wiring coexist most, and the system has to accept both.
OSDP
Reader and controller, encrypted
The current standard: bidirectional, encrypted, and it detects a cut cable. It's what to specify on new work.
Modern readers
Wiegand
What's already installed
One-way and unencrypted, but it's in half the world. Accepted so nobody has to rewire a whole building on day one.
Existing fleet
ONVIF Profile A
Access over the same standard as video
Door and credential configuration through the same route already used for cameras.
Compatible equipment
Output
What goes out to the customer's systems. Your data leaves free: it's one of the seven contract clauses, not a paid feature.
REST API
Reading and writing from any program
One thousand three hundred and seventy-seven routes documented with OpenAPI. What the interface does, a program can do.
The whole platform
CSV and PDF export
Reports and evidence
Certificates with their hash chain so a third party can verify the document wasn't touched.
Reports and logs
Contracts to ERP · TOS · SCADA
Sending the data to the business system
A declarative translator maps our output to the format the destination expects — JSON, XML or CSV — with no new code per customer, and a retry queue.
Industrial traffic and maintenance
Integration
The protocol decides. The brand, only when needed.
The platform is vendor-agnostic: what decides whether a device gets in is the PROTOCOL it speaks, not the logo it carries. An ONVIF camera, a Modbus, SNMP, MQTT or OPC-UA device, an OSDP reader — all of that comes in through the front door without anyone here having ever seen it, and without buying an SDK.
- 01
First, the standard
If the device speaks an open protocol, it comes in on day one. We do not need to know it, it does not need to be on any list, and nobody needs to approve it.
- 02
Then, what the standard does not cover
Real radiometry, optical gas imaging, biometric readers: there the standard falls short and dedicated code is needed for that device. It gets written when there is a case that justifies it.
- 03
And it is tested against the equipment, not the datasheet
Every new integration is verified with the machine in front of us. Until that happens we do not say it works — and that is why this page publishes no brand list.
You will not find a wall of logos here. Publishing a brand asserts that we tested it with that model, that firmware version, that configuration — and most of those combinations we have not seen. We would rather tell you which protocols we speak, which is what can actually be checked before signing anything, and verify YOUR specific equipment when it matters.
Already have the fleet installed? Tell us make, model and firmware. If it speaks an open protocol we will tell you which functions come through and which do not; if it carries a proprietary protocol, we will tell you what it would take and how long. Both answers save more time than a list.
Any trademarks that may come up in a technical conversation belong to their respective owners. No mention implies a commercial relationship, endorsement or certification by the manufacturer.
Can't find your equipment?
Tell us the make and model. If it speaks an open protocol we'll test it and tell you what comes out; if it doesn't, we'll tell you that too — which usually saves more time.
Ask about a device