IP Addresses and Why a Device Disappears
Why this matters
A device that is online, connected to Wi-Fi and working by its own app can still vanish from the system that is supposed to control it. The camera recorder shows "no signal" on two of four cameras. The home automation controller says the pool pump is unreachable. The customer is sure the device broke; the device is fine and has simply moved to a different address on the home network, and whatever was looking for it is knocking on the old door. A tech who understands addresses, leases and reservations can find that in five minutes instead of replacing hardware that was never faulty.
What an IP address is, in the house
Every device on a home network gets an IP address, a number that identifies it on that network so traffic can find it. In a home the addresses are private: they only mean something inside that house. The common ranges are 192.168.x.x, 10.x.x.x, and 172.16.x.x through 172.31.x.x. A thermostat at 192.168.1.40 in one house and a camera at 192.168.1.40 next door never meet.
Three related numbers turn up on every device's network page:
- Subnet mask, usually 255.255.255.0 in a home (also written /24). It says which part of the address is the network and which part is the device. With /24, the first three numbers are the network and the last is the device, so a home network has room for 254 devices, numbered 1 to 254.
- Gateway, the router's own address, usually .1 or .254 on the home network. It is where a device sends anything bound outside the house.
- DNS server, the address the device asks to turn names into addresses. Often the same as the gateway.
A device whose address starts with 169.254 has not been given an address at all. It assigned itself one because nobody answered when it asked. That is a different fault from the one this card is about: the device never got onto the network properly. See related: Getting a Stubborn Device onto the Customer Network.
Who hands out the addresses: DHCP
Almost nobody types addresses into home devices. The router runs a service called DHCP (Dynamic Host Configuration Protocol) that hands one out to each device that joins. Each device identifies itself by its MAC address, a hardware identifier that looks like six pairs of characters separated by colons, such as 3C:61:05:A2:4F:19. It is usually printed on the device's label and shown in its app.
The router hands out addresses from a pool, a range it has been set to use, for example 192.168.1.100 to 192.168.1.199. Anything outside that range on the same network is left for addresses set by hand.
The address is a lease, not a gift. DHCP gives each device its address for a set lease time, after which the device has to renew it. Common router defaults run anywhere from a few hours to a day, and some routers use a week. A device that stays connected renews quietly before the lease ends and usually keeps the same address. Usually is the key word.
Why a device moves
A device gets a new address whenever the router decides to give it one, and the router has no idea that a recorder, a hub or a controller somewhere is relying on the old one. The common causes:
| Cause | What happens | How it shows up |
|---|---|---|
| Router restarted | Some routers forget their lease table on a restart and hand addresses out in whatever order devices ask | Several devices change at once after a power cut |
| Device offline past its lease | Its lease expires; its old address may go to another device; it gets a new one on return | One device that was unplugged for a while |
| Router replaced | The new router may use a different network entirely, such as 192.168.0.x instead of 192.168.1.x | Every local integration in the house breaks at once |
| Device's identity changed | Some devices present a new or randomised MAC address after a firmware update or a factory reset | The router treats it as a brand-new device |
| A second router added | A mesh node or a second router running its own DHCP puts devices on a separate network behind it | Devices on one side cannot see devices on the other |
The router-replaced and second-router cases have their own articles; this card is about addresses moving on an otherwise unchanged network. See related: The Whole House Went Offline After a New Router.
Why only some systems notice
Cloud-connected devices do not care. A device that talks to its manufacturer's servers, and an app that reaches it through those servers, finds it wherever it is. The device reaches out; nobody has to know its address. This is why the customer's app still shows the camera fine while the recorder in the closet shows it missing. See related: Cloud, Local and Hub-Based Devices.
Local integrations do care. Anything that talks to a device directly across the home network has to know where to find it, and many find it by IP address typed in once at setup:
- A camera recorder that pulls video from each camera by address.
- A home automation controller or hub that commands a pool controller, an inverter or a thermostat over the local network.
- An energy monitor that reads a solar inverter or a battery locally.
- A printer, a media server, a door intercom.
Better-designed integrations find devices by name, using the device's own announcement on the network, and follow them when the address changes. Many do not, and in the field you will meet both.
Reservations versus static addresses
There are two ways to make a device keep the same address, and only one is the right default.
A DHCP reservation is set on the router: "always give the device with this MAC address this IP address." The device still asks for its address the normal way; the router just always gives the same answer. The setting lives in one place, it can be seen by anyone looking at the router, and nothing on the device changes.
A static address is set on the device itself: the device stops asking and just uses the address it was told. It works, but it has two traps. First, if the static address sits inside the router's DHCP pool, the router may later hand the same address to another device, and the two conflict: both drop in and out unpredictably, and it looks like two unrelated faults. Second, the setting is buried in the device, so the next tech who replaces the router to a different network has no way to know this one device will not follow.
Default to reservations. Use a static address only where the device documentation requires it, and when you do, pick an address outside the DHCP pool and write it down where the next person will find it. See related: Leaving a Device Record the Next Tech Can Use.
Changing the router's settings is the customer's network, not yours, and a reservation is a router setting. It runs under the customer's consent and a written record of what was changed. See related: The Customer Network Change Authorization SOP.
A worked case: two cameras gone after a storm
A customer's camera recorder shows four camera tiles; after an overnight power cut, two of them read "no video." The recorder was set up by IP address, two years ago. The customer's camera app, which reaches the cameras through the cloud, shows all four live.
That split is the first clue. If the cameras were dead, the app would show them dead too. The cameras are on the network; the recorder is looking for two of them in the wrong place.
The recorder's camera list and the router's connected-devices list, side by side:
RECORDER (set up 2 yrs ago) ROUTER CLIENT LIST (today)
ch name address name address
1 Front door 192.168.1.121 Front door 192.168.1.121
2 Driveway 192.168.1.122 Driveway 192.168.1.134
3 Back yard 192.168.1.123 Back yard 192.168.1.123
4 Garage 192.168.1.124 Garage 192.168.1.131
Router DHCP pool: 192.168.1.100 - 192.168.1.199
Lease time: 24 hours Reservations: none
Reading it. Channels 2 and 4 are the two showing no video, and they are the two whose addresses changed: Driveway from .122 to .134, Garage from .124 to .131. Channels 1 and 3 kept their addresses and kept working. Every address in both lists sits inside the DHCP pool, and there are no reservations, so every camera has been holding its address on luck for two years. After the power cut the router came back first, the cameras came back in no particular order, and the router reissued two of the four addresses differently.
The quick fix and the right fix. Typing .134 and .131 into the recorder brings both channels back in a minute, and that is the right move to restore recording on the visit. It is not the fix, because the next power cut can shuffle them again. The fix is a DHCP reservation for each camera, matched to its MAC address from the router's list. Because the cameras now hold .121, .134, .123 and .131, reserving those exact addresses means the recorder, now corrected, never needs touching again.
What would have changed the answer. If the router's client list had shown no entry at all for the Garage camera, it is not on the network, and the address is not the question; check power and the camera's own connection first. If all four cameras had moved and the addresses now started 192.168.0 instead of 192.168.1, the customer has a different router, or a second one, and the fix is a different conversation. And if the recorder supported finding cameras by name rather than by address, switching it over would be worth the extra few minutes, since it removes the dependency rather than pinning it.
How to check your read before you leave
- Restart one of the reserved cameras and confirm it comes back at the reserved address within a few minutes, both in the router's list and on the recorder.
- Confirm every address you reserved or set by hand is either inside the pool as a reservation or outside the pool if static, never a static address inside the pool.
- Write the address, the MAC and the method (reservation or static) for each device into the customer's equipment record, so the next tech has it.
References
- See related: Cloud, Local and Hub-Based Devices
- See related: The Whole House Went Offline After a New Router
- See related: The Customer Network Change Authorization SOP
- See related: Leaving a Device Record the Next Tech Can Use
- IETF RFC 1918 (private address ranges) and RFC 2131 (DHCP)