Ten cameras, one account — and the model decides

If you are buying security cameras so that Home Assistant can show you a current image each morning, watch one thing above all others: the product line. Not the brand, not the price, not the resolution.

Ten Blink cameras hang on one sync module on my account. Five deliver an image every day. Three almost never do. They do not differ by location, battery, signal strength or age — they differ by model.

This is an observation across ten devices at one site, not a lab test. But it is one that three months of measurement could not explain away. And the investigation is still not finished.

Three model families, identifiable by firmware

I first took it for a fault that five cameras report neither temperature nor signal strength. It is design:

Firmware	Type	Temperature	Battery
2.151, 10.73	outdoor, battery	yes	as voltage
9.105	indoor, mains powered	no	none
12.87	doorbells, newer models	no	as level 1–3

Only battery-powered outdoor cameras have a temperature sensor. If you are wondering why one camera reports values and another does not: it is not broken, it is not fitted.

The count that overturned everything

For weeks I treated every failure as an individual case. First the two doorbells, then a garden camera, then a second one. A separate explanation each time, a separate repair attempt each time.

Then I counted, over ten days, how many days each camera delivered a fresh image:

Camera	Model	Days with an image (of 10)
Indoor	owl	10
Hut, indoor	owl	10
Kitchen	owl	10
Shed	owl	10
Garden, behind the house	xt	10
Terrace	catalina	9
Shed, garden	catalina	4
Garden, lower	catalina	2

All four owl and the one xt: no gaps. All three failures: catalina. And the two doorbells that had already dropped out of the daily group earlier are lotus — also not owl.

owl, xt          snapshot request reliable
catalina, lotus  unreliable to not at all

This is not a device fault. It is a pattern along the product line.

Six explanations, six times disproved

Before I write a theory down it has to survive the measurements. These did not:

Explanation	Tested with	Result
Cold — lithium cells weaken in the morning	delivery day against coldest reading, 10 days, 4 cameras	Fell. The two coldest mornings, −1.1 °C and 1.7 °C, were both delivery days.
Battery	daily mean voltage, 10 days	Fell. The problem camera sat at a constant 1.650 V throughout the outage. The camera with the highest voltage is the second worst performer.
Radio link	16 readings over 42 hours	Fell. −44 to −49 dBm — around 10 dB better than the terrace, which delivers.
Congestion on 2.4 GHz — 44 devices on the band	three attempts, then the neighbouring camera immediately	Fell. Three failures of 30 seconds each, then five seconds later the neighbour delivers in 4.8 seconds. Same band, same access point, same minute.
Address conflict on the network	searched all devices for duplicate addresses	Fell. No second hardware address.
Firmware	comparison over two weeks	Fell. Unchanged, and identical within the product line.

A seventh fell later: that the router was filtering the camera.

The finding that shifts everything

Hunting the address conflict turned up something more important than the question it belonged to. An isolated test — request this one camera only, then watch the router:

16:40:57  request sent to the camera
16:41:10  it appears at the router         (13 seconds later)
16:41:40  it disappears again              (after 30 seconds)
          -> no image, abort after 30.0 s

Confirmed twice independently. The camera wakes up, joins the Wi-Fi, gets its address, stays for half a minute and leaves — without a single byte of image.

And it is not a stills problem. Live view behaves the same: the Blink cloud accepts the command, reports the camera as available and names a media server — and then nothing arrives. The proxy logs a timeout, zero bytes.

Camera	Type	Power	Daily image	Live view
Indoor	owl	mains	10/10	941 kB in 13 s
Terrace	catalina	battery	8/10	425 kB in 16 s
Shed, garden	catalina	battery	6/10	timeout
Garden, lower	catalina	battery	0/10	0 bytes

Constant, not random

This is where a radio or weather problem drops out. Fifteen requests were in the recording, fifteen of fifteen failed — and that was only the window the recorder still held. The real run was 22 days.

An interference problem produces a probability. What stood here was a constant: this camera never, the neighbouring camera on the same module in the same minute in 4.8 seconds.

And then, after 38 days, an image arrived

At that point I had my explanation ready: the image path of this camera is broken, it is a warranty case. It fitted every single measurement.

On 4 November an image came through. The one before it was from 25 September. 38 days in between.

A broken image sensor does not deliver an image after 38 days. So the seventh explanation fell too — and it was my own, and it had looked good for 38 days.

One detail had already raised an eyebrow: during an armed weekend the same camera sent four motion alerts. So it detects motion and gets the alert out — over the same path as the sensor readings. Only the image does not come.

	working
Readings: temperature, voltage, signal	yes, continuously
Motion detection and alerting	yes
Snapshot on request	no
Live view	no

Side finding: the armed weekend cost nothing

Four days armed continuously, one camera with thirty recorded motion events — and its battery voltage afterwards sits exactly where it sat before: 1.710 V on the 28th, 1.705 V on 2 November.

That is the answer to the most common worry about motion detection. Thirty recordings over a weekend are measurably nothing. What is slowly declining was declining before, and has nothing to do with the weekend.

What does this mean when buying?

The useful part for you, even with the cause still open:

1. Mains-powered indoor cameras had no gaps here. Four out of four, over the whole period. If a reliable image matters, that is the safe choice.
2. Battery-powered outdoor cameras from the same brand are a bet. Of three, one delivers well, one moderately, one practically never — on the same account, the same sync module, with better signal.
3. Doorbells fell out of line entirely. They do not respond to snapshot requests here at all.
4. Live view only works via a detour. The bundled integration reports no streaming service for any of the ten cameras. Live view is possible, but only through an additional proxy — with everything that means in setup effort.

And the lesson that reaches beyond cameras: an explanation that fits every available measurement is not thereby correct. Seven fell on this one camera. The seventh was mine, and it looked very good for a month.

Where it goes from here

The support case is off the table for now — it would have to be opened with figures that are already outdated. The right question was never “this camera is broken” but: do these product lines answer snapshot requests reliably at all, or is that by design? Three devices of one line with the same behaviour against five without a single failure, on one module and one account — that is an argument “replace the device” does not clear away.

I am still counting. If a pattern emerges, it will be here.