Why Did My Control4 System Stop Working After Changing My Router?

A practical guide to diagnosing controller connectivity, IP-controlled devices, Wi-Fi, network discovery and remote-access problems

Your new router is installed. Your phone connects, websites load, and an internet speed test looks excellent. Yet the Control4 app cannot find your system, the home theatre no longer responds, or several touchscreens appear offline.

It is tempting to conclude that Control4 needs reprogramming—or that the controller has failed. Neither should be the starting assumption.

Replacing a router does not, by itself, erase the Control4 project. The project’s devices, connections and programming are stored on the Control4 controller, not in the router. A network change can make those devices unable to communicate while the underlying project remains intact. (Control4: project and backup documentation)

The objective is therefore not to “reset everything until it works.” It is to determine which communication path changed, prove the failure, and correct it without disturbing the parts of the installation that still work.

This guide begins with homeowner checks and progresses into the diagnostic work an experienced Control4 integrator should perform. Product capabilities, app screens and Composer Pro menus vary with the installed hardware and software; model-specific documentation takes precedence over a generic procedure.

In this guide

1. Why working internet does not prove the Control4 network is healthy
2. Step-by-step homeowner troubleshooting
3. DHCP, reservations, static addresses and driver identity
4. Wi-Fi, VLANs, discovery and remote access
5. Professional Control4 diagnostics
6. Three illustrative troubleshooting cases
7. Repair validation
8. Preventing another outage
9. Frequently asked questions

A Control4 installation can use several different methods to communicate with equipment: Ethernet, Wi-Fi, Zigbee, infrared, serial connections and other interfaces. The method depends on the device and how the system was designed. (Control4: installing and connecting devices)

Consider three separate actions:

An app requests a lighting scene. The app must communicate with the relevant Control4 services, and the controller must execute the programmed actions.

Control4 changes an AV receiver’s volume. The receiver might receive an IP command over the home network—or an infrared or serial command through a controller or interface.

A wall dimmer operates its attached light. That successful action tells you that particular control path works. It does not demonstrate that the controller can reach the receiver.

Control4’s troubleshooting documentation makes this distinction between network communication and Control/AV connections. Both must match the actual installation. (Control4: troubleshooting guidelines)

Likewise, an internet speed test measures a different path from a command travelling between two devices inside your home. Local devices on the same subnet can communicate without sending that traffic through the internet connection. Equipment on different subnets needs an appropriate routed path. (Microsoft: TCP/IP addressing and subnetting)

The first useful question is not “Does the internet work?” It is “What still communicates with what?”

Start with this symptom map

Use this as an investigation guide, not a diagnosis by itself.

Record these observations before restarting equipment. They give you a repeatable starting point for every later test.

Step 1 — Record exactly what changed

Create a short incident note:

“The router was replaced on Tuesday. Both living-room remotes still wake up, but neither controls the receiver. The kitchen touchscreen works. The phone app works on home Wi-Fi but not over cellular.”

That is more useful than “Control4 is down.”

Also record whether the installer replaced only the internet gateway or also changed switches, access points, Ethernet connections, Wi-Fi names or passwords. Photograph the accessible equipment and cable labels before moving anything.

Choose one repeatable test—for example, selecting a particular source in one room—and use the same test after each correction.

Step 2 — Identify the controller and check the physical connection

Locate the Control4 controller using its manufacturer label. Check its power connection, normal status indicators and visible Ethernet connection against the documentation for that model. Control4’s installation guidance treats power, physical connectivity and network addressing as separate checks. (Control4: installation guidance)

Do not assume that every Control4-branded box performs the same role. Record all controller models rather than selecting one at random.

Trace accessible, labelled connections far enough to establish whether the controller’s network switch is still connected to the new router. A cable that was moved during the router installation deserves inspection; unrelated HDMI, speaker and lighting connections do not need to be disturbed.

Do not press a recessed reset button. Identifying equipment and observing its indicators should not alter its configuration.

Step 3 — Check the phone’s access before blaming the controller

Test a second Control4 interface, such as another phone or a touchscreen.

On an iPhone or iPad, open:

Settings → Privacy & Security → Local Network

Confirm that local-network access is enabled for the Control4 app when it is listed. Apple permits an app to retain internet access even when direct local-network permission is denied, so working web browsing does not rule out this problem. (Apple: local-network privacy)

Next, check that the phone has joined the intended household network—not a guest network or a newly installed router’s separate network.

Compare operation on home Wi-Fi with operation over cellular, recording the exact error. Treat the comparison as evidence, not absolute proof of which connection method the app used.

Remote model matters, too. Do not classify every Control4 remote as Zigbee. Halo, for example, uses Wi-Fi and supports both 2.4 GHz and 5 GHz. Its documented setup includes joining the home Wi-Fi network. (Control4 Halo product documentation)

Step 4 — Identify your current network configuration

In the router’s app or administration interface, look for LAN, Local Network, DHCP, Connected Devices or equivalent settings.

On a Windows computer connected to the relevant household network, open Command Prompt and run:

ipconfig /all

Read the active Ethernet or Wi-Fi adapter—not a disconnected adapter or unrelated virtual interface. The output shows that computer’s IP configuration; it does not show the controller’s configuration. (Microsoft: ipconfig)

An illustrative result might be:

IPv4 Address:       192.168.50.45
Subnet Mask:        255.255.255.0
Default Gateway:    192.168.50.1
DHCP Server:        192.168.50.1

Here, the computer is on 192.168.50.0/24. The /24 corresponds to the displayed mask.

The IP address identifies the interface. The subnet mask determines which destinations it considers local. The default gateway is its normal route to destinations outside that subnet. Compare the complete configuration—not just whether two addresses “look similar.” (Microsoft: TCP/IP addressing and subnetting)

Record these values. Do not immediately change the router to resemble an example in this article.

Step 5 — Find the actual controller and affected device

Use the router’s device list and the equipment’s own network-information screen, where available. Match the device using its label and network-interface details, not just a friendly name such as “Living Room.”

Distinguish a DHCP lease list from a broader connected-client list. A device with a manually configured address does not need to obtain a DHCP lease, so absence from the lease list alone does not establish that it is disconnected. DHCP and non-DHCP hosts can coexist on a network. (RFC 2131: Dynamic Host Configuration Protocol)

Create a small inventory:

Leave unknown fields marked unknown. Guessing defeats the purpose of the inventory.

Step 6 — Perform optional, read-only connectivity tests

The following addresses are examples. Replace them with your confirmed gateway, controller and affected-device addresses:

ping -n 10 192.168.50.1
ping -n 10 192.168.50.20
ping -n 10 192.168.50.80

These tests send ten ICMP echo requests to each destination. Replies show that something at the target address responded from your computer’s network location during that test. (Microsoft: ping)

Interpret the results carefully:

• Replies are useful, but limited. They do not demonstrate that a Control4 driver can authenticate or send commands.
• Timeouts are inconclusive. The address may be wrong, the path may be blocked, or the equipment may not answer ICMP.
• A short successful test does not exclude an intermittent fault. Repeat it when the actual problem occurs.

On Windows, you can also inspect the local address-resolution cache:

arp -a

This shows cached IP-to-MAC mappings, not a complete inventory or a live scan. Across a routed boundary, the local Ethernet destination is normally the next-hop router rather than the remote device itself. Do not treat a missing ARP entry as proof of failure. (Microsoft: arp)

At this point, you should know whether the problem is phone-specific, device-specific, shared across several devices, or associated with a changed network.

A DHCP reservation is not the same as a static address entered into a device

With DHCP, the device requests network configuration from a server, usually the residential router.

A DHCP reservation tells that server to give a particular device a consistent address.

With a manually configured static address, the address is entered into the device itself. Replacing the router does not automatically rewrite that setting. (RFC 2131: DHCP)

This distinction determines the correction.

Adding a reservation to the new router will not repair a receiver that is still manually configured on the old subnet.

Problem A — The router’s LAN range changed

Suppose the original network used 192.168.1.0/24, but the replacement uses 192.168.50.0/24.

DHCP devices may receive new addresses. A manually addressed receiver may retain 192.168.1.80. In a simple replacement network without a route to the old subnet, the new controller address and the receiver no longer have the expected communication path.

There are two possible design decisions: restore the original LAN plan, or migrate the equipment to the new plan.

Neither should be applied blindly. Restoring the old range requires checking for conflicts with the upstream gateway, other subnets and remote connections. Migrating requires accounting for manually configured devices and integrations that reference their addresses.

The subnet change explains a potential failure; the inventory establishes whether it actually happened.

Problem B — The subnet stayed the same, but a reservation disappeared

The controller might previously have contacted an IP-based receiver at 192.168.1.80. After the router replacement, the receiver receives .112 while the configured driver still references .80.

The appropriate correction depends on how that driver identifies the device.

For an address-based integration, a documented reservation can provide a stable target. Control4’s Luma troubleshooting guidance recommends reservations for several integrated products, including controllers, bridges, cameras and Chime doorbells. That is a targeted addressing recommendation—not a requirement to manually configure every device. (Control4: Luma troubleshooting)

A limited homeowner correction: restoring a known reservation

This is appropriate only when you administer the router and have confirmed the device’s identity, its DHCP setting and the intended address.

1. Back up the router configuration.
2. Select the confirmed device in the router’s reservation interface.
3. Verify that the proposed address belongs to the current LAN and is not assigned to another device.
4. Save the reservation according to the router’s instructions.
5. Allow the device to obtain the updated lease using its documented procedure, then verify its address and retest the failed function.

Reservation rules vary by router. For manually configured addresses, keep them outside the dynamic allocation pool or explicitly excluded according to the network design. Araknis documentation distinguishes reservation-based configuration from manual static addressing and warns against placing manual addresses in the router’s dynamic range. (Araknis: LAN settings)

Do not choose an address merely because it does not answer a ping.

Problem C — The address changed, but that was not actually the fault

Control4 does not require static IP addresses everywhere.

SDDP-compatible devices can advertise their identity, driver information and current address. Control4 documents that this allows unique identification while using DHCP, without restricting those devices to static addresses.

Consequently, “the IP changed” is not sufficient evidence that a correctly functioning SDDP integration should fail. The technician must establish how the installed driver identifies its device. Discovery, identification and working control are related, but separate. (Control4: SDDP discovery)

Wi-Fi credentials, security and network assignment

A replacement may introduce a different Wi-Fi name, password or security mode. Older equipment may not support a new security-only configuration. Apple’s guidance distinguishes WPA3 from WPA2/WPA3 transitional operation and advises against insecure WEP, TKIP or open-network workarounds. Check the actual device’s supported modes before changing security. (Apple: recommended router settings)

Also distinguish joining Wi-Fi from reaching the required devices. A guest or isolated network may provide internet access while restricting local communication.

Do not assume that moving every device to 2.4 GHz solves this. The relevant questions are whether the device supports the wireless settings and whether its network permits the required communication.

A second router was introduced

Two configurations are often confused.

Routers connected in series can create separate networks and double NAT. Equipment attached to the upstream gateway and equipment behind the downstream router are not necessarily on the same LAN.

Two uncoordinated DHCP servers on the same LAN can instead supply inconsistent configuration to clients.

These are different problems and require different corrections. Apple identifies both multiple-DHCP and double-NAT configurations as potential sources of connectivity problems; deliberately coordinated DHCP designs are a separate case. (Apple: router configuration guidance)

Before changing bridge mode or disabling DHCP, establish which device is intended to provide routing and which provides Wi-Fi access.

VLANs: reaching the device and discovering it are separate requirements

A VLAN separates part of the network logically. A managed installation may place interfaces, automation equipment, cameras and guest devices on different networks.

For a failing integration, investigate two questions separately:

Can the actual controller exchange the required traffic with the device?

Can any required discovery traffic reach the correct network?

A discovery relay does not automatically authorize the subsequent control connection. Equally, allowing a control connection does not necessarily transport local discovery between subnets. mDNS, for example, is defined for local-link operation. (RFC 6762: Multicast DNS)

SDDP, SSDP and mDNS are not interchangeable

Control4’s published interface documentation lists these separately:

Those numbers identify protocols; they are not an instruction to forward these ports from the internet. The required internal communication depends on the installed products and drivers. (Control4: network interfaces and services)

For example, UniFi’s mDNS Proxy forwards selected mDNS services between networks. Its documentation does not describe it as a universal SDDP relay. Therefore, enabling an “mDNS” setting cannot be assumed to fix every Control4 discovery problem. (Ubiquiti: mDNS Proxy)

IGMP snooping is another distinct function: it affects multicast forwarding within switching infrastructure. It is not a replacement for routing or a universal discovery bridge. Investigate membership and forwarding behaviour rather than toggling it indiscriminately. (RFC 4541: IGMP and MLD snooping switches)

Local operation works, but remote access fails

Investigate the controller’s gateway, DNS and internet path separately from local device communication. Then verify the account and services applicable to that installation.

Control4 currently describes local operation without a subscription and additional remote capabilities through its service offerings. The applicable entitlement must be checked for the actual system rather than assuming every installation has the same plan. (Control4: service offerings)

Do not purchase a subscription—or expose the controller through port forwarding—simply because remote access stopped after a router replacement.

The professional section is not about changing more settings. It is about obtaining better evidence.

5.1 Preserve the project and identify the correct controller

Connect through authorized tools to the controller running Director, the Control4 system software, and confirm that it is the intended project. Record the installed OS and controller details.

Back up the current project before modifying it. Control4 explicitly recommends project backups before Composer Pro changes or system updates. A router configuration export is a separate backup. (Control4: project backups)

A router-related outage is not a reason to begin by clearing the project, replacing drivers or updating every subsystem.

5.2 Separate device identity from configured address

In Composer Pro → Connections → Network → IP Network, examine the identified devices and address information. (Control4: using the Network tab)

For each failed device, compare its actual network identity with the project entry and the driver’s documented connection method.

A particularly misleading fault occurs when an old address has been reassigned to a different device. A ping may succeed, yet the driver is contacting the wrong equipment. Confirm identity; do not stop at reachability.

Review connection state with operating mode in mind. Control4 notes that an identified sleeping remote can show an offline state, so status must be interpreted in context rather than used as an automatic instruction to re-identify equipment. (Control4: verifying network connections)

5.3 Test the real controller-to-device path

A successful test from a laptop does not prove that the controller has the same access. The laptop may use a different VLAN, route or firewall policy.

For a driver using TCP, test the documented device port, not an arbitrary “Control4 port.” Windows PowerShell provides:

$DeviceIP = Read-Host "Enter the confirmed device IP address"
$Port = [int](Read-Host "Enter the TCP port documented for this device or driver")

Test-NetConnection -ComputerName $DeviceIP `
    -Port $Port `
    -InformationLevel Detailed

Inspect the source address, interface, destination and TcpTestSucceeded.

This establishes whether a TCP connection can be opened from that test computer. It does not test UDP discovery, validate authentication or prove that the driver’s commands succeed. (Microsoft: Test-NetConnection)

Where policy depends on source location, verify the controller’s actual traffic using supported diagnostics and authorized network observation.

5.4 Use packet and log evidence to distinguish failures

For difficult cases, capture a timestamped failed action and compare it with driver and network evidence.

These are interpretations of transport behaviour, not automatic root-cause verdicts. TCP establishes and terminates connections through defined exchanges; application behaviour requires additional evidence. (RFC 9293: Transmission Control Protocol)

Capture location matters. On a switched network, a laptop does not automatically see unicast traffic exchanged between the controller and receiver. A correctly configured mirrored switch port or another suitable capture point may be necessary. Wireshark’s Ethernet guidance explains this limitation. (Wireshark: Ethernet capture setup)

Keep captures and logs private: they can reveal device identities and installation details.

5.5 Check Control/AV bindings only after separating communication from operation

If the device is reachable and its driver responds, verify the logical connections describing how sources, receivers, displays and rooms are connected.

A receiver responding to a direct command does not establish that a room’s “Watch” action selects the correct source and input. Control4 specifically instructs integrators to match Control/AV and room connections to the physical installation. (Control4: troubleshooting guidelines)

Do not alter a working connection map merely because the router changed. Establish what is wrong first.

These examples demonstrate diagnostic reasoning. They are not presented as actual Dana client projects.

Case A — The receiver stayed on the old subnet

Observation: The receiver works with its original remote. Control4 no longer controls it after the router replacement.

Evidence:

The receiver’s own network screen confirms the old setting. The new network has no configured path to that old subnet.

Correction: Deliberately reconcile the addressing plan. When migrating the receiver, verify its mask, gateway and driver identification—not just its IP.

Verification: Test power, volume, input selection and feedback. Then test again from standby.

The evidence supports an addressing repair, not a receiver replacement.

Case B — A powered touchscreen is on the wrong network

Observation: After a switch replacement, the touchscreen lights up but cannot connect.

Evidence: Its switch port and assigned address place it on a different network from the intended installation. The interface has power, but the required controller communication is unavailable.

Correction: Restore the documented port/network assignment and required policy. Do not disable segmentation across the entire home.

Verification: Confirm its new address, controller connection and room controls. Test intercom separately; a working screen is not proof that every service works.

Case C — Local commands work, but the controller has the wrong gateway

Observation: Local operation remains available, but remote services fail.

Evidence: The router was replaced without changing the subnet. Its address changed from .1 to .254; the manually configured controller still uses .1 as its default gateway.

Correction: Update the verified gateway configuration and confirm the appropriate DNS settings.

Verification: Test the controller’s external connectivity and the applicable remote service. A phone’s successful internet access was never sufficient evidence of the controller’s path.

Use a written acceptance test. Our recommended sequence is:

1. Repeat the original failure using the same room, source and interface.
2. Test alternate interfaces, including the app and relevant touchscreens or remotes.
3. Test full behaviour, not just power: input selection, volume, feedback and room-off actions.
4. Test dependent functions, such as grouped audio, scheduled scenes and intercom.
5. Test after standby and normal reconnection, using documented device procedures.
6. Record the final configuration, including addresses, reservations, network assignments and remaining issues.

For intermittent problems, extend observation across the conditions that previously triggered them. “It worked once after rebooting” is not an adequate acceptance criterion.

Keep the original symptom record, the change made and the final test results together. That creates a useful maintenance history rather than another undocumented repair.

Before replacing networking equipment, preserve the Control4 project and router configuration separately. Control4 recommends backing up before project changes; Apple likewise recommends saving router settings before changing them. (Control4: backups; Apple: router settings)

Our recommended handover record includes the equipment inventory, intended LAN ranges, reservations, manual addresses, important switch-port assignments and the integrations that depend on them.

Give the network installer a clear brief:

“This network supports an existing Control4 installation. Please review its addressing, Wi-Fi and managed-network requirements before changing the LAN design.”

Schedule the work when the system can be tested afterward. Preserve working security controls, and keep administrative credentials in a secure handover process—not an article comment or public enquiry form.

Will replacing my router erase Control4 programming?

No—not by itself. The project configuration is stored on the controller. A network replacement can interrupt access without deleting the project. Clearing or loading a project is a separate operation. (Control4: project operations)

Does every Control4 device need a static IP?

No. SDDP supports unique identification with DHCP. Other integrations may benefit from a stable reservation or require a documented address-based configuration. The installed driver and device requirements decide the appropriate method. (Control4: SDDP)

Can I fix this without a dealer?

Some faults are within a homeowner’s reach: incorrect phone network, denied local-network permission, changed Wi-Fi credentials or a clearly documented reservation. Apple provides a direct local-network permission control. Stop short of unidentified project or network-wide changes. (Apple: local-network access)

Why do the lights work while the television does not?

Those actions may use different communication paths. The successful lighting action narrows the investigation; it does not prove the television’s network connection, driver or Control/AV mapping works. (Control4: troubleshooting)

Should I open ports on the router?

Do not treat a list of device services as instructions for internet port forwarding. First identify whether the failure concerns internal device communication, discovery or a supported remote-access service. These are different functions. (Control4: network services)

Why does a device answer ping but still refuse Control4 commands?

Ping tests ICMP reachability. The driver may use a different protocol, port and authenticated application session. The answering address also needs to be verified as the intended device. (Microsoft: ping)

Can a technician resolve it remotely?

Possibly, when authorized access to the relevant equipment remains available. If the network fault removes that access, someone onsite may need to restore basic connectivity. Do not assume remote-service availability proves access to every affected device. Control4’s remote capabilities depend on the system and services. (Control4: services)

Should I update Control4 while repairing the network?

Our recommended sequence is to establish the network fault first. Treat an OS or driver update as a separate, justified change with compatibility review and backup—not an automatic response to replacing a router.

These instructions are intended to help you understand the fault and solve it yourself where practical. A successful homeowner repair is a good outcome.

Dana Smart Homes supports existing Control4 installations, including systems installed by another company. When professional assistance is needed, the assessment should distinguish network communication, device-driver operation and actual equipment faults before proposing replacements.

For a service enquiry, provide your location, controller model if known, affected rooms, recent network changes and the results of any checks above. Please do not send passwords or access codes through the enquiry form.

The goal is to restore reliable operation, preserve equipment that remains suitable, and leave you with a clear explanation of what failed and what corrected it.

Browse the Control4 Technical Knowledge Centre, explore support for your existing system, or learn about changing your Control4 dealer.