Short answer: Wi-Fi roaming is a decision the client makes, not one the network can force, and a client normally goes looking for a better access point because its signal got worse — which is what walking around a building does. A phone bolted to a shelf has a stable mediocre signal, so that trigger rarely fires. It keeps the association it made during setup, and can keep it after you install a new mesh node three feet away. Nothing errors, nothing stops, and the recording is unaffected because it never touches the network at all. Only the live view is worse, and the diagnosis lives on your router rather than in any app — for a reason I will be specific about at the end.
Here is a shape of problem no setting in any camera app can fix, described in general because it is a general problem rather than one bad evening.
An old Android phone runs as a camera in a garage, a shed, a back bedroom. The live view is fine some days and syrupy on others. The sensible move is made: another mesh node, in the room with the phone. Nothing improves. A week later, nothing has improved. Power-cycle the node, reboot the router, reinstall the app.
The admin page then shows the phone still associated with the original router at the other end of the building, which it has been talking to, contentedly, since long before the new node arrived.
Nothing there is broken. It is the correct behaviour of a standard designed around an assumption your camera quietly violates.
Wi-Fi was designed for a device that moves
Roaming — leaving one access point for a better one on the same network — is a client-side decision. The infrastructure can advertise and recommend, but the last word belongs to the device.
Cisco's own explainer on fast-roaming protocols says it plainly: "The wireless clients are expected to scan RF and roam to AP with the highest signal." Expected. Not compelled.
Two amendments exist specifically to make that expectation work better, and reading what they actually do is the fastest way to see the shape of the problem:
- 802.11k lets a client request a neighbour report about nearby access points, which enables it to "avoid passive or active RF scan before the client decides to move to a different access point." It is a shortcut for a decision the client is already making.
- 802.11v lets the access point send a BSS Transition Management Request — the network telling a device that a better home is available. Cisco is blunt about its force: it "is only a suggestion. The client can honor the suggestion or discard it."
So the network can help a client roam, and can ask it to. It cannot make it.
That is a reasonable division of labour: the client is the only party that knows what its own radio is hearing, and it is assumed to be the thing that changes position. The whole design leans on movement. You walk from the kitchen to the bedroom, your signal falls, your phone scans, it finds something better, it moves.
Your camera is the first Wi-Fi device you own that never moves
Now take that machine and screw it to a wall.
A stationary phone's signal does not fall. It does not rise. It is whatever the geometry of your building says, and it stays there for months. The condition that normally provokes a client to go looking — this is getting worse — never arrives. A stably bad link and a stably excellent one look equally settled from the inside.
The industry has a name for the result. From the same Cisco document: "some clients have displayed a sticky behavior where they stay with the AP to which they are associated, even when a neighbor AP provides a stronger signal. This is referred to as a sticky client problem."
Enterprise gear has a remedy, and it is as blunt as you would expect: the controller watches the client's signal and data rate and "the client is proactively disassociated" — thrown off, so it has to choose again. Note what that implies about the softer options, and note too that Cisco's own support engineers attach a warning to it: "Optimized Roam is not suitable for all networks."
Your home mesh may or may not do anything comparable. Either way, the last word still belongs to a phone that has no reason to change its mind.
The setup ritual makes it worse
Think about how the phone got onto the network in the first place.
You sat down somewhere comfortable — sofa, kitchen table, desk — usually within a few metres of the router, because that is where people are when they set things up. You installed the app, granted permissions, joined the Wi-Fi, checked the picture. Everything was excellent, because everything was near the router. Then you carried the phone to the garage and mounted it.
The association was formed under the best radio conditions the deployment will ever see, and — this is the part that surprises people — carrying the phone across the house is exactly the kind of event that would normally trigger a re-evaluation. Sometimes it does. Sometimes the link stays just good enough at every step of the walk that nothing fires, and the phone arrives at its final position still holding a connection it chose in another room.
Which half is actually broken
Before you touch the network, be clear about what the symptom can and cannot mean, because a phone-as-camera has two jobs that fail independently.
Recording is local. Frames go from the sensor through the encoder into a file on the device's own storage. No packet crosses your Wi-Fi. A recording made during the worst network week of your life is byte-for-byte the one you would have got on a perfect network. The hard parts of building this are almost all on-device: camera sessions, encoders, storage, and what the hardware allows with two consumers at once.
The live view is the only half on the network. The phone runs a small HTTP server on your LAN and your browser fetches from it. Every stall, every grey rectangle, every reload is happening on the path — and the path includes an access point the phone picked days ago.
"My camera is broken" is almost never true. "The route to my camera is poor" usually is. Only one of those is urgent: a bad live view costs you a nervous evening, a failed recording costs you the thing you set the camera up for. It is also a third failure category alongside what a power cut does versus what an internet outage does and what the browser tab you left open does on its own account.
Why the signal bars lie, twice
The first lie is ordinary. The bars summarise the link the phone currently has. They say nothing about the better link it is declining to look for. A sticky client reports a stable, honest, mediocre number and is not wrong.
The second lie is the one that wastes an afternoon, and it is the reason I wanted to write this down.
The natural test is to carry a second phone to where the camera is and see what the signal looks like there. That test is worthless, and it is worthless for an interesting reason: the phone in your hand is doing the exact thing the mounted phone cannot do. It walked. It re-evaluated on the way. It very probably associated with the nearest node the moment you got close. You are measuring a device that roamed correctly and using it to reason about a device that never roams. It will show you a strong, encouraging number produced by an access point the camera is not talking to.
There is no version of that experiment that works: the instrument fixes the fault as a side effect of being carried.
The test that does work
Open the router or mesh admin page and look at the client list. You want two facts: which node the camera is associated with, and at what rate. Compare that to where the phone physically is. If it is on a node in another part of the building, you have your answer without measuring anything.
One complication, and it is a permission-model complication rather than a networking one. Modern Android randomises its Wi-Fi hardware address by default — from Google's own summary of the Android 10 privacy changes: "On devices that run Android 10 or higher, the system transmits randomized MAC addresses by default." So the camera is unlikely to appear under any address printed on a label or box. Find it by the hostname it advertises, or simply by the local IP address you already type in to watch the picture, which is the one identifier you definitely know.
When you have confirmed a bad association, the fix is dumb and physical: make the phone choose again. Turning the phone's Wi-Fi off and on, or restarting it, forces a fresh association from where it actually lives. Do this after any change to your network — a new node, a moved router, a new channel — and do it standing next to the camera, not before you mount it.
What I cannot fix in an app, and why
This is the part where the author of a camera app is supposed to say "we handle this for you." I cannot, and the reason is worth quoting rather than paraphrasing.
An ordinary Android app cannot make the phone reconsider its Wi-Fi connection. From the Android 10 privacy changes: the network operation methods that return a boolean — "removeNetwork(), reassociate(), enableNetwork(), disableNetwork(), reconnect(), and disconnect()" — "always returns false" for an app targeting Android 10 or higher that is not a system app or a device policy controller. The larger hammer is gone too: "Apps targeting Android 10 or higher cannot enable or disable Wi-Fi. The WifiManager.setWifiEnabled() method always returns false."
So the app cannot bounce the radio for you. Fine — could it at least tell you which access point it is on, so you do not have to log into a router?
Technically yes, and here is the price. The methods that would report it — "startScan(), getScanResults(), getConnectionInfo(), getConfiguredNetworks()" — sit on the list of Wi-Fi APIs that require the ACCESS_FINE_LOCATION permission on Android 10 and higher. Which access point you are near is, correctly, treated as location data.
That is a real trade and I want to be clear which side I am on. An app that asks for your precise location in order to display a diagnostic string has bought something small with something large, and it keeps that permission for as long as it is installed. Every argument I have made about what "local-only" actually protects and what a camera app should be allowed to touch points the same way: the diagnosis belongs on your router, where you were going to have to look anyway, and not in a permission dialog.
The honest limitation
None of this is Wi-Fi being badly designed. Sticky behaviour is the conservative default, and the alternative is worse for the case the standard was written for: a client that roams eagerly ping-pongs between access points mid-call, a far more annoying failure than a slow picture in a garage. Cisco's warning about forced disassociation is the same point from the other end.
It is also not a fault you can shop your way out of. Adding a node is the correct move for a genuine signal gap and the wrong move for a client that will not leave — and the two look identical from the sofa.
The generalisable version, which is why this piece exists: a repurposed phone inherits every assumption its designers made about phones, and the loudest one is that it moves. Battery management assumes a pocket. Heat management assumes a device that gets put down. Roaming assumes a walk down a corridor. Running one as a fixed camera means finding those assumptions one at a time, usually after it has been on a wall a while, and deciding which you can work around.
If you are placing one this week: mount it first, then reboot it, then check which node it landed on. Two minutes, at the position it will actually live in. That is the whole intervention. And if you are watching something at the far end of a building, suspect the network long before the camera.
I build Background Camera RemoteStream, an Android app that records with the screen off and serves a live view over your own LAN. More writing at superfunicular.com. Whether two people can watch at once is a related question with a genuinely different answer.
Top comments (0)