Cycle IP camera snapshot views in a dashboard and switch on alarm

You have four cameras on a cell two time zones away and one metered connection back to your desk. Continuous video through that link can eat a month of traffic in a day, yet you still need eyes on the cell — and you need them on the camera that has the problem, the moment it has it. The fix is a snapshot dashboard: each camera's HTTP snapshot URL refreshes on a timer, the view cycles through the cameras, and when an alarm bit sets, the view jumps to the alarmed camera and holds. This guide gives you the refresh numbers, the traffic arithmetic, the cycle logic and the checks that prove it works.

Why snapshots, not streams, over a remote tunnel

A video stream is the wrong currency for a metered link. A VGA MJPEG stream at 10 fps with roughly 40 KB per frame runs 10 × 40 KB = 400 KB/s, which is 3.2 Mbit/s around the clock and 1.44 GB per hour; left running for a month that approaches 1 TB. Entry-tier remote-access plans commonly include around 1 GB per month, so a stream overshoots that budget by three orders of magnitude.

A snapshot cycle puts one image request on the wire at a time, and only while someone is watching or an alarm says to. A single HTTP request also passes through a remote-access HTTP proxy cleanly, where a continuous multipart video stream can stall in exactly that path. The timer lives in the viewer, which is the quiet advantage: close the tab and the traffic stops on its own.

If you want the single-camera version first, a one-button snapshot live view covers one camera on demand; this article automates it across several. The fetching mechanics — headers, retries, saving files — are in grabbing images over an HTTP snapshot URL. When the viewer sits on the cell LAN, streams are affordable and a static multi-camera layout or an embedded live feed in a web dashboard is the better tool; the snapshot cycle earns its keep specifically across the metered path. Where a stream does fit remotely, displaying an RTSP stream in an HMI compares the snapshot and stream options at the panel.

What you need

• One camera per station, on the cell LAN, each with an HTTP snapshot URL. The exact path comes from the camera manual; the example camera in this build answers at http://192.168.0.150/image/jpeg.cgi.
• A dashboard that can display an image from a URL and re-request it on a timer: a SCADA or HMI view, a gateway-hosted web view, or a plain web page.
• An alarm bit per camera the dashboard can poll as a tag or register — a PLC register, a gateway tag, or the camera's own detection output.
• A remote-access service that proxies HTTP requests to devices on the cell LAN.

Some gateways can fetch and store the snapshot themselves, so the dashboard pulls a stored image instead of reaching through to the camera; capturing IP camera snapshots to a gateway's file storage shows that variant. The arithmetic is identical either way — still one JPEG per fetch.

Size the snapshot and the traffic first

Everything downstream hangs on one number: bytes per snapshot. Estimate it, then weigh one real fetch.

Worked example, the 1.6 MP mono camera this build uses: 1,600,000 px × 1 B = 1.6 MB raw; JPEG at 10:1 gives 1,600 KB ÷ 10 = 160 KB per snapshot. Plan on 160 KB. Scene content moves it: a cluttered cell compresses closer to 5:1, about 320 KB, and a plain background closer to 20:1, about 80 KB — budget with your worst view. A 5 MP color camera runs 5,000,000 px × 3 B ÷ 15 ≈ 1 MB per snapshot.

At 160 KB per fetch, the pattern table reads:

The decision: cycle at 2 s only while the page is open; drop to a 10-minute heartbeat when it is not; let alarms drive their own bursts at 9.6 MB per alarm-minute. Against a roughly 1 GB per month allowance, the heartbeat fits with room and the always-on 30 s poll does not — that one comparison is the whole design. If you are also planning the LAN side at full frame rates, GigE multi-camera bandwidth planning for six cameras on one switch runs the same arithmetic at switch scale.

Build the cycling view

1. Prove each snapshot URL on the LAN first. Open the camera's snapshot path in a browser on the same network — http://192.168.0.150/image/jpeg.cgi for the example camera, your own path per its manual. You must get a JPEG, not a login page.
2. Sort out authentication. If the camera demands a login, check whether it accepts credentials in the URL query, or create a dedicated snapshot account on the camera and use it in the gateway's proxy settings. Use a read-only account either way.

3. Fix the snapshot profile. Set the camera's monitoring image to the resolution and JPEG quality your estimate assumes, then weigh the first real fetch. If it lands more than about 50% above 160 KB, re-run the table before you commit a refresh rate.
4. Point the image object at the first URL and set the timer. Refresh every 2,000 ms while the view is open, and append a cache-buster — ?t= plus a timestamp — so each refresh fetches a new image instead of the browser's cached one.
5. Add the cycle. On each tick, show the next camera's URL unless an alarm is active. Illustrative names throughout — this is example logic, not a documented API:

const camUrls = [
  'SNAPSHOT_URL_CAM1', 'SNAPSHOT_URL_CAM2',      // strings: each camera's
  'SNAPSHOT_URL_CAM3', 'SNAPSHOT_URL_CAM4'       // HTTP snapshot URL
];
let idx = 0;         // number: camera on screen when no alarm
let alarmCam = -1;   // number: -1 = none, else the alarmed camera's index
let holdUntil = 0;   // number: ms timestamp until which the alarm view holds

// showSnapshot(url) stands in for your dashboard's image-update call
setInterval(() => {
  const active = alarmCam >= 0 ? alarmCam : idx;      // alarm overrides the cycle
  showSnapshot(camUrls[active] + '?t=' + Date.now()); // cache-buster forces a fresh fetch
  if (alarmCam < 0) idx = (idx + 1) % camUrls.length; // advance only when healthy
}, 2000);            // 2 s while someone is watching

6. Add the alarm-bit poll on the same timer, with the hold logic from the next section.

The test that proves the result: with the timer running, the browser's network log must show 30 image requests in one minute, one every 2 s, each HTTP 200 and each near your planned 160 KB. Then close the tab: the request count must stop. If it keeps climbing, the polling lives on the gateway instead of in the view, and it is spending traffic while nobody watches.

Switch the view on the alarm bit

Poll the alarm bits as tags: a few dozen bytes per read, about 0.08 GB per month at one read every 2 s, which rides inside the heartbeat budget. When a bit sets, three things happen. The cycle jumps to that camera immediately — mid-cycle is fine. The alarmed camera refreshes faster, one fetch per second, because during an alarm every image carries information. And the view holds for 30 s after the bit clears, so a chattering sensor cannot flicker the display between cameras. Worst-case jump latency with one 2 s timer driving both poll and refresh is 2 s: the bit sets just after a tick, and the next tick lands on the alarmed camera.

// uses alarmCam and holdUntil from the cycle above
function onTagPoll(alarmBit, alarmCameraIdx) {  // boolean and number from the gateway tag
  const now = Date.now();                       // number: ms timestamp
  if (alarmBit && alarmCam !== alarmCameraIdx) {
    alarmCam = alarmCameraIdx;                  // jump now
    holdUntil = now + 30000;                    // hold 30 s after the bit clears
  } else if (!alarmBit && now > holdUntil) {
    alarmCam = -1;                              // resume the cycle
  }
}

If operators want the last word, replace the timed hold with an acknowledge: the view stays until someone acknowledges, then the cycle resumes. Pick hold or acknowledge as the rule — stacked without logic, the view ends up stuck.

The same snapshot-from-a-URL display exists on local panel HMIs; displaying IP camera snapshots on HMI panels walks one panel family through it. When the dashboard should also carry the inspection numbers beside the image, streaming smart camera live video and metrics to a custom dashboard covers the metric side. And where the switch can happen at the capture source rather than in the viewer, synchronized camera bank switching is the hardware-side cousin of this logic.

Cameras on the cell side

Any camera that serves an HTTP snapshot fits the pattern. In a vision cell, the cameras watching the cell are usually the same smart cameras running the inspection, already on the LAN; what matters for the monitoring view is the interface and the resolution:

A Fast Ethernet link runs 100 Mbit/s and the whole monitoring cycle needs 0.64 Mbit/s — one 160 KB fetch every 2 s — about 0.6% of the wire, so monitoring never competes with inspection data on the LAN. If the alarmed view has to resolve a gauge reading or a small mark, step the resolution up on the camera watching that station:

A 6 MP mono snapshot runs about 600 KB (6,000,000 px × 1 B ÷ 10), so re-run the traffic table with the real size before committing the refresh rate. Where an operator may need to zoom after the fact, the area scan cameras category includes sensors past 25 MP. To filter the whole line-up by interface and resolution, use the camera finder.

Checks before you trust it

• Freshness. Cover a lens: the cache-buster changes every fetch, so a scene that stops updating shows the fetch stopped — the dashboard never quietly presents a minutes-old frame as live.
• Dead camera. Unplug one and set each fetch's timeout at or below the 2 s refresh so a dead camera cannot stack pending requests; the cycle should show a placeholder and keep going.
• Alarm path, end to end. Force the bit at the PLC: the view must land on that camera within one tick (2 s worst case) and hold 30 s after release.
• Meter. Watch the connection's traffic counter for one unattended day: about 23 MB, matching the table. Ten times that means something is polling that should not be.

Common mistakes

• No cache-buster. The browser re-shows its cached frame and the dashboard looks alive while displaying an old image.
• Gateway-side polling. The timer belongs in the viewer; on the gateway it fetches around the clock and turns the 0.69 GB plan into the 13.8 GB one.
• All cameras at once. Four cameras at 1 Hz is 640 KB/s and about 2.3 GB per hour; cycle one at a time — nobody can watch four images anyway.
• Administrator credentials in the URL. The snapshot works, then the URL leaks full camera control into every log it touches.
• No hold on the alarm view. Without the 30 s hold, a chattering bit strobes the display between cameras exactly when someone needs to look.

For a worked remote-monitoring build on real equipment, the CNC spindle monitoring camera set-up is the closest cousin; more patterns like this sit on the systems topic page.

Where to go next

Pick the cell cameras first: the vision configurator steps through the camera and then the rest of the chain, or bring your camera count, snapshot size and alarm list to the contact page and we will help you size the refresh plan.