Measured at the Threshold: What Three Video Doorbells Do Between a Press and a Notification

A video doorbell is usually sold as a camera with a button. Engineering-wise, it is a battery, a radio, a cloud account and a push-notification service arranged around a momentary switch. That distinction matters at the front door, where the useful performance metric is not resolution but the interval between a visitor pressing the button and a phone making a sound.

Over forty days this autumn, CavLab ran three widely sold doorbells at a terraced house in the north of England. Two were battery-powered; one was mains-fed with a local microSD slot. We logged 214 deliberate button presses and 1,870 motion events, then repeated a subset with the broadband disconnected. The aim was not a buyer's guide. It was to measure where the time goes, what motion detection costs in a British winter, and how much of each product survives the loss of its cloud.

The rig at the door

The door faces a pavement, a low wall and a bus stop forty metres away. The Wi-Fi access point sits roughly six metres inside the house, behind a brick wall and a double-glazed window. Received signal strength at the three doorbells ranged from -58 dBm to -71 dBm, which is ordinary rather than laboratory-clean.

Button presses were generated by a small ESP32 rig that closed each device's contact for 180 ms and wrote a timestamp to a local log. A phone camera recorded the doorbell and the notification banner at 240 frames per second; notification arrival was also captured from the companion app's notification listener. Cross-checking the two gave a measurement uncertainty of about ±90 ms. That is ample for differences measured in seconds, but not for arguing about tens of milliseconds.

Motion events were counted by the devices themselves and cross-checked against a passive infrared sensor at the door. Battery state was logged daily. We did not disable vendor telemetry, because the point was to test the product as shipped, with default sensitivity and default recording rules.

Latency is a queue, not a number

Median press-to-notification times were 1.7 s, 2.9 s and 4.6 s across the three devices. The spread within a single device was more revealing than the median. The fastest device produced a 95th-percentile time of 3.4 s; the slowest produced 9.8 s, with one 11.2 s outlier after a firmware update.

The delay decomposes into recognisable stages. First, the device must wake from its radio power-save state, associate with the access point and complete a TLS session. On the battery models this alone accounted for roughly 0.6 s to 1.4 s. Second, the press event travels to the vendor's cloud, is processed, and is pushed back to the phone. That round trip varied from 0.3 s to 2.6 s depending on which service was involved and whether the phone was on the same LAN or on mobile data. Third, the phone's push pathway and notification handler add their own queue.

A doorbell that appears instant on a good day can therefore feel broken on a bad one. Wi-Fi power save is the main culprit. Battery devices spend most of their lives asleep, and the access point's beacon interval and DTIM settings influence how quickly they hear an incoming frame. We saw a consistent 300–700 ms penalty when the phone was on a different network, because the notification had to leave the house and come back through the vendor's infrastructure rather than travel across the LAN.

The mains-fed unit was faster, but not by as much as its always-on radio suggested: its median was 2.1 s when recording to the cloud and 1.4 s when configured for local-only operation. The difference was almost entirely the cloud leg.

What motion detection costs

The battery doorbells were rated for six months. Neither approached that in our conditions. Device B fell from 92% to 41% over forty days with default motion detection and 47 events per day, a rate driven by pedestrians and a nearby bin lorry. That is roughly 1.3 percentage points per day before the colder nights arrived. Device A, mounted slightly further from the pavement, fell from 90% to 58% with 21 events per day.

Battery drain is not linear with event count. Each wake-up carries a fixed cost: radio association, cloud handshake, image capture and upload. A device that records a ten-second clip for every passing cat spends more energy than one that records a three-second clip. Pixel-based motion detection, which some models use instead of PIR, can also wake the image sensor more often in low light. In November, with headlights sweeping the door and rain on the lens, false triggers rose by roughly a third.

The practical lesson is that motion zones and sensitivity are not cosmetic settings. Narrowing a zone to exclude the pavement cut events by 62% on Device A and extended its projected battery life from about ten weeks to four months. It also reduced notification fatigue, which is a usability issue rather than an electrical one, but no less real.

When the cloud is in Virginia

We disconnected the wide area network for twenty minutes and repeated a set of presses. No device delivered a push notification, which is expected: the notification path is a cloud service. The interesting differences were in recording.

Device A, a battery model with no local storage, recorded nothing. Device B, the mains-fed unit, continued to write clips to its microSD card, but the app refused to play them back until the cloud account re-authenticated; the footage existed, but the user interface did not admit it. Device C, a battery model with an RTSP stream and local card, kept recording and remained viewable through a local network video recorder. Its app also failed, but the stream did not.

This is what 'works with your smart home' often means in practice. One device exposed a cloud API with a documented webhook; when we triggered it from a local automation platform, the event arrived 0.4–1.2 s later than the vendor's own notification, and it stopped entirely during the outage. None of the three offered a documented local API for button events. Matter support, where present, covered basic device identity rather than the full event stream.

That architecture has consequences beyond convenience. A doorbell that depends on a remote service for playback is a doorbell whose evidence chain depends on a subscription, a firmware policy and an internet connection. For a householder, that may be acceptable. For anyone specifying a door entry system, it is a design decision that should be written down.

What we would specify

For a front door that matters, wired power and local recording are the two features that most reliably reduce failure modes. PoE is preferable where the fabric of the building allows it; mains adapters are workable but introduce their own standby load. A local RTSP or ONVIF stream is more useful than a glossy app, because it survives the cloud and can be recorded by equipment the user controls.

Wi-Fi deserves more attention than it usually gets. A doorbell at the edge of coverage will spend longer awake, drain faster and deliver slower notifications. A dedicated 2.4 GHz SSID, a fixed IP address and a access point within reasonable range are unglamorous improvements that show up directly in the latency log.

Finally, measure the press-to-ping interval yourself. It is the one number that describes the whole system — sensor, radio, cloud, phone — and it is the number a visitor experiences. The doorbell is not the product. The path between the button and your pocket is.