SENSORLOGIX · FOR EQUIPMENT MAKERS
Connect your cameras, radars and sensors
Four ways in, from no work at all to running on your own hardware. All four end as the same observation, so zones, alert status, reports and releases work the same whatever you make.
Test your device offline, against simulators, with no account.
FOUR WAYS IN
Pick the way your device already works
WHAT YOU GET
Everything to integrate before you talk to us
Integration docs and samples
Public docs and sample payloads for every way in.
A conformance tool
Checks your device field by field, offline, before anyone deploys it.
Simulators
Test with no account: simulated zones, boxes and alert receivers.
A sandbox organization
On request, to test end to end with the console and the alert stream.
Versioned contracts
Changes within a version only add. A breaking change comes with a year’s notice.
WHAT A DEVICE NEEDS
What a device needs, and how your system takes alerts back
What a device needs
- Its own identity. Each device signs in as itself.
- A stated clock accuracy. So its reports line up with every other sensor’s.
- A stated position accuracy. So a zone rule knows how far to trust its location.
- A heartbeat. So a silent device raises an alert instead of looking like an empty zone.
- A secondary stream, if it has one. The box reads it, so it never takes a stream or session your own console needs.
How your system takes alerts
- Webhooks. Raised, changed and withdrawn alerts, signed.
- The SDKs. TypeScript and Python.
- The alert stream. With replay after a restart.
- Cursor on Target. For systems that speak TAK.
THE RULES YOUR DEVICE PLAYS BY
Why a mixed fleet can be trusted
- It can’t change the rules. Nothing a vendor integrates can change rules, zones or an alert’s status.
- It never confirms. A vendor’s detection never counts as confirmed: that takes a person.
- Independence is real. Two sensors count as independent only if they’re different platforms or different kinds of sensor.
- Its model is named. On-device analytics arrive tagged unverified, with the model that made them.
- Your console always wins. If your own console moves a camera during a hold, the hold ends at once.
THE SECOND SEAT
For cameras that can be held for a short time
An authorized person can hold a fixed camera’s view for a short time, when an operator can’t wait. What a camera needs to offer it:
- A control credential of its own. Separate from the one that reads video, and sealed on the box.
- A way to say its own console moved it. So a hold can end the moment your console takes over. A camera that can’t report it gets look-here requests only.
- Nothing inbound from outside. A hold reaches the camera from a box on its own network, and the box opens no inbound port.
- Off by default. An admin turns the hold on camera by camera, and every step of it is on the record.
OPEN STANDARDS
If it speaks one of these, it needs no work
MQTT, LoRaWAN and other event formats connect through a sensor profile.
Restricted equipment
Equipment from makers barred by US federal procurement or FCC rules stays off, whichever way in it uses. It can be turned on only for an organization those rules don’t cover, such as one outside the United States or one that holds an exemption.
Send us a sample payload
We’ll run it through the conformance tool with you and say which way in fits.