E-Fire USA monitors industrial sites with thermal cameras that watch for heat, fire and smoke. They needed a platform their customers could trust: live temperatures, instant alerts and video, on any device.
Partway through scoping, the camera maker confirmed there was no SDK. We built the integration from the raw protocol documents instead, and proved live data before writing a single screen.
Book a similar engagement →The original plan relied on the camera maker's SDK for streaming and control. After scoping began, the manufacturer confirmed they don't offer one, only protocol documents.
The camera pushed data over plain HTTP, but the server forced a redirect to HTTPS. The camera couldn't follow it, so every request died silently.
The test camera sat on a remote network with a subnet mismatch, and the person beside it wasn't technical. Every fix had to be talked through remotely.
Instead of stopping, the team studied the three protocol documents the manufacturer provided: HTTP Push, WebSocket and RTSP. We built a Node.js endpoint to receive camera data, traced the silent failure to the forced HTTPS redirect and fixed it, then resolved the network mismatch remotely, step by step.
Only when heartbeats, per-zone temperatures and alarm events were arriving reliably did UI work start. That order meant every screen was built on real camera data, not on assumptions about it.
Four steps, in this order, before any interface was built.
Studied HTTP Push, WebSocket and RTSP documentation and built an endpoint to receive camera pushes.
Traced dropped requests to a forced HTTPS redirect the camera couldn't follow, and removed it for the camera endpoint.
Resolved a subnet mismatch by guiding a non-technical contact on site through each change.
Confirmed heartbeats, zone temperatures and alarm events arriving reliably, then started the UI.
// POST /camera/push · live data from the thermal camera { "method": "engine_echo", "serialno": "DM75x60x••••" } 200 OK { "method": "temperature", "zones": [ { "id": 1, "max": 41.6, "min": 22.3, "alarm": 0 }, { "id": 2, "max": 38.9, "min": 21.7, "alarm": 0 } ] } 200 OK { "method": "engine_echo", "serialno": "DM75x60x••••" } 200 OK { "method": "alarm", "type": "smoke", "image": "base64…" } 200 OK // alert queued → push · SMS · email · web
Waiting for a vendor SDK would have stalled the project indefinitely. Working from the protocol documents gave E-Fire an integration they control, with no dependency on the manufacturer's release schedule.
Building the interface on assumed payloads is how projects discover problems in week ten. Proving the data first meant the dashboards, zones and alerts matched exactly what the cameras send.
Alarm events and temperatures arrive as lightweight pushes the server can act on instantly, while video uses the camera's RTSP streams only when someone is watching.
A fire alert that goes unseen is a failure. Push, SMS, email and web alerts each have their own delivery record, so customers and E-Fire can see who was told and when.
