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.

What is firsthand here? Our setup used an AT&T fiber gateway, three TP-Link Deco BE11000 units with Ethernet connections, and five Deco M4R satellites. The Deco mesh operated in access-point mode. The outdoor Ring camera had weak signal readings before placement experiments. Specific dates, intermediate configuration changes, and the exact sequence of every fix are not fully documented, so this article does not pretend otherwise. Diagrams are illustrative, not our home's floor plan.

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.

CoverageCan the device hear a nearby access point clearly?
BackhaulHow does that access point reach the rest of the network?
AddressingWhich device gives clients their local IP addresses?
Device behaviorIs one camera failing while other clients work?

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.

InternetService provider Fiber gatewayRouter + DHCP Mesh AP AMesh AP BMesh AP CEthernet uplinkEthernet uplinkEthernet uplink Wi-Fi clientsWi-Fi clientsWi-Fi clients
Illustrative network roles, not a wiring diagram for a specific home. Actual supported Ethernet topology varies by Deco model and operating mode.

Before touching DHCP, ask these questions

  1. Who is the router? Identify the device handling internet routing and the default gateway for clients.
  2. Who assigns addresses? Check DHCP settings and client IP information; don't assume every “DHCP” toggle does the same job.
  3. Is there a conflict? Look for duplicate IPs, an incorrect subnet, or an unexpected second router only if symptoms justify it.
  4. 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.
Safety note: Disabling DHCP on the wrong device can leave clients without usable addresses. Changing gateway modes can disrupt internet access and remote management. Follow the instructions for your exact equipment and make a rollback plan before modifying network-wide settings.

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.

Important distinction: Switching off the gateway's wireless radios does not switch off its router, internet connection, or DHCP server. In our setup, the Deco units operated in access-point mode and the gateway remained responsible for routing and DHCP. Do not disable DHCP, turn on IP Passthrough, or change the Deco operating mode just because you're disabling gateway Wi-Fi; those are separate network-design decisions. If you depend on gateway Wi-Fi to reach its settings, make sure you have an alternative way back in before changing anything.

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.

Wireless relayWired backhaulMain nodeSatelliteMain nodeSatelliteWi-Fi link between nodesEthernet link between nodesDepends on radio conditionsAvoids that wireless hop
Conceptual comparison only. Actual speed depends on Ethernet link speed, switch layout, interference, and client capabilities.

How to test wired backhaul without guessing

  1. Confirm the node and cable are compatible with the intended topology.
  2. Verify the node appears online in the mesh app and reports Ethernet backhaul where the app supports that status.
  3. Test a nearby client before and after, from roughly the same location and under similar conditions.
  4. Check whether the problem device actually uses the expected access point; some clients are slow to roam.
  5. 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.

Better starting pointOpen placement with fewer dense obstacles and a strong path back to the network.
Common trapAdding nodes so close together that clients keep attaching to less useful access points.
Measure, don't guessRecord RSSI, association, and real application performance before moving again.

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.

Reported readings during troubleshooting−73 dBmEarly reading−69 dBmSome improvementLess negative usually means stronger received signal.Bar lengths are illustrative, not a calibrated signal scale.
RSSI is only one clue. Test actual live video, latency, and stability too.

Camera troubleshooting, in the order we'd use now

  1. Confirm the camera is powered and the app/service itself is working.
  2. Check the camera's reported Wi-Fi signal and compare it with the same camera over time.
  3. Check which Deco node the camera is connected to, if your mesh app exposes that information.
  4. Move or adjust a node temporarily, then retest live view before making the placement permanent.
  5. Restart the affected camera if needed; avoid rebooting the whole network as your first move.
  6. 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 seeWhat to check firstWhat not to assume
Wi-Fi connected, internet unavailableClient IP address, gateway, DNS, and upstream internetThat stronger Wi-Fi signal will fix routing
One camera has slow live viewCamera power, RSSI, node association, app statusThat every device on the network is affected
Device reconnects to an unexpected nodeActual client association and signal at its locationThat a device will always choose the nearest node
Many devices fail after a setting changeLast configuration change, DHCP/router roles, cablingThat all devices suddenly broke independently
Only one older IoT gadget won't joinIts supported band, security mode, onboarding requirementsThat 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.

  1. Write down the symptoms. Which devices, locations, and times? Is it Wi-Fi connection, internet access, or one app?
  2. Sketch the network roles. Identify modem/gateway, router, mesh access points, switches, and Ethernet paths—without publishing private details.
  3. Record a baseline. Device association, signal, gateway/DHCP status, and one real-world test such as live video.
  4. Check the simplest physical causes. Power, cables, distance, obstructions, and whether the affected device itself needs a restart.
  5. Make one change. Move one node, replace one cable, or adjust one documented setting—not all three.
  6. Retest and log the result. If nothing improved, undo the change when practical.
  7. Escalate carefully. Review gateway/DHCP design or app re-pairing only when the evidence points there.
  8. Stop when the real task works. A reliable camera view matters more than chasing the prettiest signal number.
Printable mental checklist: Symptom → baseline → one change → same test → keep or revert. That's the method that prevents “I changed six things and now I don't know which one worked.”

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.

← All guides · Equipment library