A smart device that works perfectly for a week and then goes missing is one of the most common complaints in this whole category, and it is usually diagnosed as a Wi-Fi problem or a firmware problem. Frequently it is neither. The device is fine, the radio is fine, and the network simply handed it a different address than the one everything else had learned.
Nothing about a home network is as permanent as it looks. The address your device gets when it joins is a lease, not an assignment, and leases expire on a schedule set by the router, not by you.
A lease is a loan with a renewal date
When a device joins, it asks for an address. The router offers one and attaches a timer. Partway through that timer the device asks to renew, and in a healthy network it gets the same address back and nobody notices anything.
The interesting cases are the ones where renewal does not go to plan. The device was asleep and missed its window. The router restarted and lost its lease table. The device was powered down for a week while you were away and came back to a network where its old address had already been handed to something else.
In each of those cases the device gets a new address and carries on quite happily. It does not consider this a problem. It has no idea that your automation platform, your recorder, and your mental model of the network all still believe it lives at the old number.
From your side, the symptom is a device that is online and unreachable at the same time.
A reservation is not the same as a static address
There are two ways to make an address stick, and they are constantly confused.
A reservation is configured on the router. You tell the router that this particular device, identified by its hardware address, should always be offered the same number. The device still asks, and the router still grants; it just always grants the same one. The device needs no configuration at all, and it keeps working if you move it to a different subnet later.
A static address is configured on the device. You type in the address, the gateway, and the DNS server. The router is not involved and does not know. This works until something else on the network is assigned the same number by the router's automatic pool, at which point two devices answer to one address and the behaviour becomes genuinely strange: intermittent, load dependent, and very hard to attribute.
For anything on a smart home network, the reservation is the right answer nearly every time. It lives in one place, it survives device resets, and it cannot collide with the automatic pool in the way a badly chosen static address can.
What actually breaks when the number changes
Not everything cares. Anything that talks through a cloud service will re-register on its own, because the cloud never stored your local address as anything other than a current session. Your phone app keeps working, which is precisely why this fault is so confusing.
The things that break are the local ones. A recorder addressed a camera by number. An automation platform polled a device at a fixed address. A local dashboard had a URL in it. A script you wrote once and forgot. Each of those was correct when you set it up and is quietly wrong now.
There is a second class of breakage that is even less obvious. Local discovery protocols rely on small multicast announcements that tell the network what a device is and where to find it. Devices announce when they join, and other systems cache what they heard. When the address changes without a clean re-announcement, the cache holds a stale record for a while. Some platforms recover in minutes. Some hold the stale entry until they are restarted.
That is why a full restart of the automation host so often "fixes" this class of fault. It did not fix the network. It threw away a cached answer.
The router reboot that reshuffles everything
Router restarts deserve their own note, because they combine several of these effects at once.
Most home routers keep their lease table in memory. Power them down and the table is gone. Everything that reconnects asks again, and in the scramble the order of requests changes. A device that had held the same address for a year can come back as a different number, purely because it happened to ask in a different order this time.
Add a firmware update or a replacement router and the address range itself may change. Plenty of people have had an entire smart home go dark after an internet provider swap, not because any device failed, but because the new router used a different private range and every hard-coded local address stopped making sense.
If you have ever had a whole set of devices come back after an outage with most of them fine and two of them mysteriously absent, this is the most likely shape of the explanation.
Two routers, two networks
The other common source of this pattern is accidental duplication: a second router added to extend coverage, an old one left plugged in, an access point running in router mode instead of bridge mode.
Now there are two address servers on the same physical network. Devices get addresses from whichever answers first, which can change between reboots. Some devices end up on one range, some on the other. Local discovery crosses some of those boundaries and not others. The result is a network where things work in pairs and in combinations rather than all at once, and where the failing set changes after every restart.
The fix is unglamorous and total: one device hands out addresses, everything else bridges.
Multicast and the isolation switch
One setting deserves special mention because it is on by default in a lot of guest and IoT network features.
Client isolation, sometimes called AP isolation, stops wireless devices from talking to each other. It is a sensible security default for a guest network. It is fatal for a smart home where a recorder, a hub, or a local automation server needs to reach a device directly.
Everything still reaches the internet. Everything still works in the cloud app. Every local connection fails, and it fails in a way that looks like a device fault. If you have a separate network for these devices and nothing local ever works, check this before you check anything else.
The short configuration list
Give every fixed device a reservation on the router, keyed to its hardware address. Do this once, keep a list, and the entire class of problem stops recurring.
Keep the automatic pool and your reserved addresses in clearly separate parts of the range, so they can never overlap.
Use names rather than numbers wherever the software allows it. Some platforms will resolve a device name reliably; all of them will eventually be handed a changed number.
Restart the automation host or the recorder after a router change, rather than restarting devices. The stale cache is usually on the controller side.
After any router replacement, expect to re-point anything addressed by number, and check the private range matches the old one before assuming a device has failed.
Run one address server on the network. Anything else goes into bridge mode.
Turn off client isolation on the network these devices live on, and keep the isolation on the guest network where it belongs.
Names, and why they sometimes work and sometimes do not
There are two local naming systems in most homes and they do not know about each other.
One is the name a device announces for itself when it joins, used by discovery protocols to find things like printers and media devices. The other is the name the router records when it hands out an address, often taken from what the device told it at the time.
These two can disagree, and each is only as good as the last time it was refreshed. A platform that resolves names through the first system will find a device the router knows under a different label. A platform that relies on the second will not see a device that has not renewed since the router restarted.
This is why name-based access works beautifully for some people and unreliably for others. It is not a property of the device or of the platform; it is a property of which naming system happens to be in play, and whether anything has invalidated it recently.
The robust pattern is to have the router's reservation carry the name, so that the router's own view is always correct, and to avoid depending on name resolution in anything you would be unhappy to find broken at an inconvenient moment.
Power line and mesh kits add a second layer
Extenders, mesh nodes and power line adapters each introduce somewhere else for this to go wrong.
A mesh system is normally transparent: one network, one address server, devices roam between nodes. That is the goal, and most modern kits achieve it. The failure mode appears when a node is running in the wrong mode and starts handing out addresses of its own, which puts you straight back into the two-networks problem described above, with the added confusion that everything looks like one system in the app.
Power line kits are the same story in a more physical form. They work well in some houses and badly in others depending on the wiring, and a link that is marginal will drop devices and re-add them repeatedly. Every drop is a new address request, and a device that flaps often enough will exhaust the patience of anything that was tracking it.
The diagnostic in both cases is the same: watch the router's client list over an hour. If a device appears, disappears and reappears, you have a link problem that will eventually present as every other problem in this article.
Why devices flapping on and off is worse than being offline
A device that is genuinely offline is an easy fault. It gets reported, you find it, you fix it.
A device that disconnects and reconnects every few minutes is much more corrosive. Each cycle produces a new session, an automation platform sees a stream of unavailable and available transitions, logs fill up, notifications fire repeatedly, and any state that depended on the device being continuously present gets reset each time.
Users then disable the notifications, which removes the only signal they had, and the underlying instability stays until something else forces attention.
If you have one device that behaves like this, fix it before buying anything else on the same network. A flapping device poisons the reliability of the whole system around it, and it is nearly always a power or link problem rather than a device fault.
Why the same fault looks different on different platforms
Two people with the same network fault will describe two completely different problems, and the difference is in what their platform caches.
A cloud-first platform re-resolves constantly and recovers on its own within a minute or two. You never see the fault. A local-first platform that holds a session open will keep trying the old address until something forces it to rediscover, and you see the fault as a device that is permanently unavailable until you restart something.
Neither is wrong. One optimises for resilience across changing networks, the other for speed and for working without an internet connection. What matters is knowing which one you have, because it determines whether "wait a minute" or "restart the controller" is the right response.
It also explains a pattern that otherwise makes no sense: the same device failing on one platform and working on another, at the same moment, on the same network. The device is fine. Two pieces of software are holding two different ideas about where it lives, and only one of them has refreshed.
A note on power saving and long sleeps
Battery powered devices do not hold a network session open. They sleep, wake on a schedule or on a trigger, and rejoin the network briefly.
Every one of those joins is an address request. A device that does this efficiently keeps its old address because it remembers it and the router honours it. A device that does not will sometimes come up with a different address than it had an hour ago, and anything holding a direct connection to it has to find it again.
This is where a reservation matters most, because it makes the answer predictable no matter how many times the device rejoins. It is also why aggressive power saving settings can create an intermittent fault on an otherwise perfect network: the device is not failing to connect, it is connecting to a slightly different situation each time.
If a battery device is unreliable in a way that a mains powered one on the same network is not, look at the sleep behaviour before looking at the signal.
Address planning is five minutes of work
A short, deliberate plan removes most of this class of failure.
Pick a range for fixed devices and keep it out of the automatic pool. Write down what is in it, next to the device, in a note you will actually find in a year. Give the router a reservation for each one, keyed to the hardware address printed on the device or shown in its app.
Set lease times that make sense. Very short leases create renewal traffic for no benefit on a network where nothing changes; very long leases mean a change you make takes a long time to propagate. A day is a reasonable default for a home network.
Then, once, restart everything in a deliberate order: the router and any access points first, then the controller or automation host, then the devices. The order matters, because the controller should come up after the network it depends on, and the devices should come up last.
Done properly, this is the last time you have to think about it.
Why this is worth an hour of your time
None of this is difficult and all of it is boring, which is exactly why it gets skipped. The cost of skipping it is paid later, in intermittent faults that look like hardware failures and get "fixed" by replacing devices that were never broken.
An afternoon spent giving the fixed devices on your network a permanent address removes an entire category of future mystery. It is the least exciting improvement available and one of the highest value ones.
Where this matters when you are buying
Check the hardware first: smart switches and wall panels.
Network behaviour, protocol support and MOQ live on the Xingliao factory site; panel families and connectivity options are on the smart switch board manufacturing page. Sourcing questions go to the factory team.
Top comments (0)