Compatibility
What the system speaks, and what it works with.
Ten open integration protocols — six in production and four in beta — and 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.
- 6
- integration protocols in production
- 4
- protocols in beta, marked on this page
- 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. Profile G — recovering what the camera's card recorded — and Profile A — opening doors — are in beta.
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 · RTUBeta
Process sensors and meters
The plant's de facto protocol. Process variables, equipment states and meter registers; the register map belongs to the device, not to us. Tested against a simulated PLC; still to be validated with one in the field.
Measurement sensors
MQTT
Wireless and IIoT sensors
The route battery sensors and radio gateways come in through. Every message is stored as a reading, and a new sensor registers itself.
Sensors and automations
OPC-UA
Reading from plant control
The system is a client: it browses the nodes of a PLC, a SCADA or a gateway, turns them into metrics with their unit and reads them periodically, with certificate signing and encryption when the device asks for it.
Industrial integration
OPC-UA · serverBeta
Letting another system read your data
The system also publishes its readings so a SCADA can read them, with no extra licence. Today it is read-only, inside the plant network, and still without encryption or users.
Plant local network
IO-LinkBeta
Smart vibration, pressure or level sensors
They come in through their IO-Link master, which publishes over MQTT, Modbus TCP or OPC-UA. Each port becomes its own sensor, decoded from its IODD sheet. Tested with real master messages; still to be validated with a device connected in the field.
Through the IO-Link master
Zigbee · Z-WaveBeta
Sirens, contacts and ambient sensors
They come in through a gateway that publishes them on MQTT: the sensor registers itself and the siren is commanded the same way. 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. Today the system opens the door through the panel or reader already in place; a direct OSDP connection to the reader does not exist yet.
HTTP · template
Opening through the panel or reader you already have
The open request is described in the door's configuration — method, path and authentication — and the edge executes it. It works for panels and readers whose opening is an HTTP request, without writing a driver per brand.
Networked panels and readers
TCP relay · ONVIF relay
Barriers, turnstiles and locks
A pulse to a networked relay board, or to the relay output of an ONVIF device. It's the route for whatever has no interface beyond a contact.
Physical barriers
Wiegand
What's already installed
It doesn't connect directly to the system: the Wiegand reader stays wired to its panel, and the panel is integrated over its network interface or by relay. So nobody has to rewire a whole building on day one.
Through the existing panel
ONVIF Profile ABeta
Opening over the same standard as video
Door opening through the ONVIF door control service. Credential management over this route is not there yet.
Compatible equipment
OSDPOn the way
Reader and controller, encrypted
The standard to specify on new work: bidirectional, encrypted, and it detects a cut cable. The direct connection isn't built yet; today an OSDP reader comes in through its panel.
Modern readers
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 another program
The same API the interface uses, plus an ingest route so any device or system can send its readings as JSON. Integrator documentation and API keys are in preparation.
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 or an SNMP, MQTT or OPC-UA device comes in through the front door without anyone here having ever seen it, and without buying an SDK. Whatever speaks Modbus, IO-Link, Zigbee or Z-Wave comes in the same way, still in beta.
- 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