Featured guide · Real-world networking
It began with a familiar smart-home mystery: dozens upon dozens of connected devices, a powerful mesh Wi-Fi system, and a few gadgets that apparently hadn't received the memo about cooperating. Some cameras behaved. Others stalled. One outdoor camera seemed to think live video was an optional feature. And every time the network looked settled, another device had questions.
The answer wasn't a magical router setting. It was days of methodical testing: checking the fiber gateway, untangling DHCP questions, experimenting with mesh placement, using Ethernet where possible, and learning to change one variable at a time. This is the story of that project—and a field guide for tackling your own.
Chapter 1: Welcome to the device jungle
A few laptops and phones are one thing. Add smart speakers, televisions, lights, cameras, switches, vacuums, and assorted gadgets, and suddenly the Wi-Fi network has become the busiest member of the household. During one check, the Deco app reported 171 connected clients. That's a point-in-time count, not a performance benchmark—and not proof that 171 devices were all active at once.
With that many clients, it's tempting to blame the first device that misbehaves. But a frozen camera view might involve signal strength, congestion, a poor connection to a mesh node, an addressing issue, or the camera itself. The trick is to separate those possibilities before spending money.
Chapter 2: Two boxes, two very different jobs
Our fiber gateway connected the home to the internet. The Decos distributed Wi-Fi. Those roles sound simple until both systems offer router features, DHCP options, and their own device lists. That's when troubleshooting can turn into a game of “Which dashboard am I supposed to believe?”
DHCP stands for Dynamic Host Configuration Protocol. It normally gives devices local IP addresses and other network information so they can communicate. If a client has no valid address, it may appear connected to Wi-Fi but still be unable to reach what it needs. Conversely, a device with a valid address can still suffer weak radio signal or an application problem.
Our Deco system was configured in access-point (AP) mode, with the gateway providing the upstream routing function. AP mode is not universally the right choice; it's a way to avoid stacking another routing layer onto an existing router when that is the desired design. The specific DHCP behavior depends on the gateway, Deco model, firmware, and topology.
Before touching DHCP, ask these questions
- Who is the router? Identify the device handling internet routing and the default gateway for clients.
- Who assigns addresses? Check DHCP settings and client IP information; don't assume every “DHCP” toggle does the same job.
- Is there a conflict? Look for duplicate IPs, an incorrect subnet, or an unexpected second router only if symptoms justify it.
- What will happen if I change this? Record existing settings, keep a way to reconnect, and avoid changing DHCP, bridge/IP-passthrough, and AP mode simultaneously.
Two Wi-Fi networks walk into a house. One has to go.
One important part of our project was making sure the AT&T gateway wasn't also broadcasting Wi-Fi. We intentionally turned off both the 2.4 GHz and 5 GHz Wi-Fi radios on the gateway, leaving the Deco mesh as the wireless network for our devices. Otherwise, a phone or camera with credentials saved for both networks could connect to the gateway's Wi-Fi when we wanted it on the Decos. Two access-point systems aren't automatically a problem, but they complicated the network we were trying to troubleshoot.
How to check a similar setup safely: First, confirm that the Deco system is working and that you have a reliable way to access the gateway's administration page, ideally from a computer connected by Ethernet. Record the original gateway Wi-Fi settings. On an AT&T gateway such as the BGW320, sign in to its local administration interface using the access information on the gateway; look for the Home Network → Wi-Fi controls. Check the 2.4 GHz and 5 GHz radio settings separately, and disable each radio only if the Deco network is intended to provide all household Wi-Fi. Save the changes, then verify that the gateway's wireless network names no longer appear in a nearby device's available-networks list, while Deco Wi-Fi and internet access still work. Menu names can vary by model and firmware.
Chapter 3: Ethernet—the unglamorous hero
Mesh Wi-Fi nodes can often relay traffic wirelessly, which is wonderfully convenient—until walls, distance, and competing signals turn that wireless hop into a bottleneck. Connecting compatible nodes through Ethernet is called wired backhaul. It gives those nodes a wired path back into the network, leaving the wireless radios to focus more on client connections.
We used Ethernet connections for the three BE11000 units. That didn't guarantee perfect coverage everywhere; it did give the network a stronger foundation for testing placement and client behavior. A wired node in a poor location can still provide disappointing Wi-Fi to a distant camera.
How to test wired backhaul without guessing
- Confirm the node and cable are compatible with the intended topology.
- Verify the node appears online in the mesh app and reports Ethernet backhaul where the app supports that status.
- Test a nearby client before and after, from roughly the same location and under similar conditions.
- Check whether the problem device actually uses the expected access point; some clients are slow to roam.
- Don't assume a cable is good just because it clicks into place—test the link and port if results are inconsistent.
Chapter 4: The great node-placement shuffle
Once the backbone was understood, the project became a careful game of moving mesh units and observing the results. A node tucked neatly out of sight may look great in a room but perform poorly behind dense walls, metal, appliances, or other obstacles. A closer node isn't automatically the best one if its own connection back to the network is weak.
Our setup included BE11000 units and M4R satellites, with a documented inventory of three wired BE11000s and five active M4Rs at one point. That count describes a snapshot of the setup, not a universal formula for how many nodes any home needs.
We also experimented with Deco options such as roaming-related features and stability settings. Those are not universal “turn these off” recommendations. Their behavior depends on device firmware and client compatibility. If changing one, document the original value and test the specific problem it is intended to solve.
Chapter 5: The camera that wanted its own Wi-Fi department
The most memorable example was an outdoor Ring camera mounted on the rear of a shop in the backyard. Its signal reading was around −73 dBm early in the troubleshooting, then around −69 dBm after a placement/association adjustment. Live view was still unreliable. That distinction matters: a modestly better signal number did not, by itself, solve the problem.
Later placement experiments with a Deco satellite closer to the camera produced a substantially stronger reported signal in our notes. The exact final reading and which individual change deserves credit are not independently verifiable from the material available for this article, so we're not presenting a precise before-and-after speed claim.
Camera troubleshooting, in the order we'd use now
- Confirm the camera is powered and the app/service itself is working.
- Check the camera's reported Wi-Fi signal and compare it with the same camera over time.
- Check which Deco node the camera is connected to, if your mesh app exposes that information.
- Move or adjust a node temporarily, then retest live view before making the placement permanent.
- Restart the affected camera if needed; avoid rebooting the whole network as your first move.
- Only consider removing and re-adding the camera after simpler checks fail—and first confirm you have the credentials, setup code, and account access needed to restore it.
For more detail, see our Ring camera mesh troubleshooting guide and the beginner's guide to RSSI.
Chapter 6: When your smart home starts acting like it has a mind of its own
One smart device goes offline, another reconnects, and a third works only when you're standing next to it. The temptation is to reset everything and hope the network gets the message. Unfortunately, a factory reset can turn one problem into a whole weekend.
| What you see | What to check first | What not to assume |
|---|---|---|
| Wi-Fi connected, internet unavailable | Client IP address, gateway, DNS, and upstream internet | That stronger Wi-Fi signal will fix routing |
| One camera has slow live view | Camera power, RSSI, node association, app status | That every device on the network is affected |
| Device reconnects to an unexpected node | Actual client association and signal at its location | That a device will always choose the nearest node |
| Many devices fail after a setting change | Last configuration change, DHCP/router roles, cabling | That all devices suddenly broke independently |
| Only one older IoT gadget won't join | Its supported band, security mode, onboarding requirements | That the entire mesh needs a factory reset |
Removing a device from its manufacturer's app and adding it again can help with stale onboarding or changed network credentials, but it's a late troubleshooting step, not a routine Wi-Fi tune-up. Deleting a device may remove schedules, automations, or account associations. Check what will be lost first.
Chapter 7: The EzeLuma troubleshooting playbook
If we were starting again, we'd approach the network like a small engineering project rather than a scavenger hunt through settings menus.
- Write down the symptoms. Which devices, locations, and times? Is it Wi-Fi connection, internet access, or one app?
- Sketch the network roles. Identify modem/gateway, router, mesh access points, switches, and Ethernet paths—without publishing private details.
- Record a baseline. Device association, signal, gateway/DHCP status, and one real-world test such as live video.
- Check the simplest physical causes. Power, cables, distance, obstructions, and whether the affected device itself needs a restart.
- Make one change. Move one node, replace one cable, or adjust one documented setting—not all three.
- Retest and log the result. If nothing improved, undo the change when practical.
- Escalate carefully. Review gateway/DHCP design or app re-pairing only when the evidence points there.
- Stop when the real task works. A reliable camera view matters more than chasing the prettiest signal number.
Chapter 8: What we'd do differently next time
We'd start by mapping the gateway's role and the wired links, then take a consistent baseline before moving satellites. We'd label which node a troublesome device actually uses, avoid broad resets, and spend more time measuring useful performance than admiring a signal-strength screen.
We'd also resist the urge to buy hardware until we knew what problem the purchase would solve. More nodes can be helpful, but the wrong placement can add complexity without improving coverage. Sometimes the best upgrade is a cable, a better location, or simply understanding the network already in place.
The ending: Less magic, more method
There was no single button labeled “Make 171 devices behave.” Believe us, we would have pressed it. Instead, the project became a lesson in separating Wi-Fi coverage, wired connectivity, address assignment, and individual-device problems.
And that's the whole EzeLuma idea: you don't need to become a network engineer to build a smarter home. You need a clear explanation, a repeatable process, and the patience to change one thing at a time. Preferably before the camera decides to take another day off.
Continue learning: DHCP and smart-home reliability · Fixing weak Ring camera Wi-Fi · Bringing smart-home apps together.