The complaint is always phrased the same way: "the camera is too slow." It detected the motion, it recorded the clip, and the phone notification arrived long after the person had walked past. Almost nobody measures where the time actually goes, because the reasonable assumption is that a camera that sees something tells you about it immediately. It does not, and it was never designed to. A battery or low-power camera is a device that spends most of its life asleep, and waking it up is a chain of steps, each with its own cost.
The delay is a queue, not a clock
There is no single "detection to notification" specification, because the path crosses four different systems that were never tuned together: the sensor, the device firmware, the cloud service, and the phone's push delivery. Each one adds latency, and each one can add a lot of it under the wrong conditions.
A useful way to think about it: the camera does not push a video to you. It detects an event, wakes a radio, uploads a clip or a thumbnail, hands it to a service, and that service sends a push message. You are not watching the camera; you are reading the last message in a relay race.
Where the seconds go
Passive infrared warm-up and debounce. The PIR sensor is what keeps a battery camera alive for months, because it draws microamps while the main processor sleeps. It is also a mechanical-ish detector: it responds to a change in infrared energy across its field, and firmware requires the change to persist for a short window before treating it as an event. That debounce is typically well under a second, and it exists to stop a passing car's headlight or a tree shadow from waking the whole system.
Wake and radio association. This is where most of the surprise lives. A sleeping camera has to bring up the processor, re-associate with the access point, and sometimes re-obtain an address. On a clean network this is a second or two. On a busy or marginal one — weak signal, congested channel, an access point that has to re-authenticate — it can be ten. If your notification delay is inconsistent, jumping between three seconds and thirty, this is the step that is varying, and the variance is almost always RF, not software.
Encode and upload. A short clip is a few hundred kilobytes to a few megabytes depending on resolution and bitrate. Uplink is the constraint: residential broadband is asymmetric, and a camera at the edge of Wi-Fi range has a low physical link rate. A clip that takes four seconds to encode can take fifteen to upload if the link rate has fallen. Cameras that send a still thumbnail with the notification feel instant for a reason — the small payload gets out first, and the video follows.
Cloud processing and push delivery. Once the clip lands, the service decides whether the event matches your rules and hands a push message to the phone platform. Push delivery is best-effort: a phone in a deep doze state with background activity restricted may hold the message until the next maintenance window. That is why "my partner's phone got it immediately and mine got it a minute later" can be true with one camera and one event.
The two you can actually shorten
Signal quality. The single highest-leverage fix is getting the camera's RSSI up. Moving an access point one metre out of a cabinet, changing to a less congested 2.4 GHz channel, or adding a mesh node closer to the camera removes the wake/association and upload penalties at the same time. If the camera reports a signal figure in its app, read it before changing anything else.
Notification payload. If the app lets you choose between "notify with thumbnail" and "notify with video," the thumbnail option is dramatically faster, because it does not wait for the clip to finish uploading. You still get the recording; you just learn about it sooner.
Things that do not help: raising resolution, buying a camera with a bigger sensor, or switching brands because one claims lower latency. None of those touch a queue.
The two you cannot
PIR debounce and warm-up are the price of battery life. A camera configured to trigger on the first sign of any change will also trigger on rain, insects and passing headlights, and the notification volume makes the whole system useless.
Push delivery on a dozing phone is controlled by the phone platform and by the app's background permissions. If battery optimisation is aggressive on your device, exempt the camera app.
Measure your own chain before changing hardware
- Stand where the camera is with a phone, on the same 2.4 GHz network, and read the signal level. If it is marginal there, it is worse for the camera, which has a smaller antenna.
- Trigger a detection on purpose and time it from the moment you cross the field of view to the moment the phone vibrates. Do it five times across the day. Consistent delay is a design choice; wildly varying delay is RF.
- Compare a mains-powered camera at the same spot. If the powered one is consistently fast and the battery one is not, you have isolated the sleep/wake cost.
If both are slow, it is the network. If only the battery one is slow, it is the sleep cycle, and it is working as intended.
Current cameras and their detection behaviour are compared in the Tuya and Reolink security camera breakdown, and the selection criteria that matter for a house are set out in how to choose a security camera for home. The full range is at the surveillance camera category, and the OEM side is covered by the CCTV camera manufacturing programme.
Top comments (0)