When you change routers or Wi-Fi networks, Google Home devices often lose control of smart bulbs, switches, and other devices even though they work fine in their native apps. This happens because Google Assistant caches the old IP addresses from your previous network, so it's sending commands to devices that no longer exist at those locations.
Quick answer
- Root cause: Google Home has outdated IP address information for your smart devices after network changes
- Primary fix: Say "Hey Google, sync my devices" to refresh the IP address cache
- Alternative fix: Unlink and relink the device manufacturer's service in Google Home settings
- iOS users: Ensure Google Home app has "Local Network" permission enabled
Symptoms
- You changed Wi-Fi networks, router, or network passwords recently
- Smart devices work perfectly in their manufacturer apps (Kasa, Hue, etc.)
- Google Home responds "Sorry, I can't reach the [device name]" to voice commands
- Device controls in Google Home app show loading spinners or timeout errors
- Devices appear online in Google Home but don't respond to commands
Quick checks
Verify device connectivity: Open the manufacturer's app (Kasa, Hue, SmartThings) and confirm all devices respond normally. If they don't work there, the problem is with the device connection, not Google Home.
Check network subnet: Note if your new router uses a different IP range (like 192.168.1.x vs 10.0.0.x). This confirms Google is likely sending commands to the wrong address space.
Test one device: Try controlling a single smart device through Google Home to isolate whether the issue affects all devices or just specific ones.
Step-by-step fix
Method 1: Force device sync
- Say to any Google device: "Hey Google, sync my devices"
- Wait for confirmation: Google will respond with something like "Alright, syncing devices for Kasa, Hue, and Tuya"
- Wait 60 seconds for the sync to complete fully
- Test a voice command on a previously broken device
Method 2: Reconnect manufacturer services
- Open Google Home app on your phone
- Navigate to: Settings → Works with Google
- Find the problematic service (like TP-Link Kasa or Philips Hue)
- Tap the service → Unlink account
- Tap "Link account" and sign in again with your credentials
- Wait for device discovery to complete
- Test voice commands after setup finishes
Method 3: Fix iOS local network permissions
- Go to iPhone Settings → Google Home
- Enable "Local Network" permission
- Return to Google Home app and try Method 1 again
If it still isn't working
Check for client isolation: Some routers enable "AP isolation" or "Client isolation" by default, preventing devices from communicating with each other. Disable this setting in your router's wireless security options.
Factory reset stubborn devices: Remove the device from both Google Home and the manufacturer app, factory reset the hardware, and set it up as a completely new device. This eliminates any cached device IDs causing conflicts.
Switch to cloud control: Some manufacturer integrations can fall back to cloud-based control instead of local IP communication. This is slower but more reliable after network changes.
Verify subnet compatibility: Ensure your Google Home devices and smart devices are on the same network segment and can communicate with each other.
FAQ
Why do some devices work while others don't after changing networks? Different smart home brands use different communication methods. Devices using "Local Fulfillment" (direct IP communication) break when IP addresses change, while purely cloud-based devices continue working normally.
How long does device syncing take to complete? The initial sync command completes in 10-15 seconds, but it can take up to 5 minutes for all device IP addresses to fully update in Google's system.
Will I lose my device names and room assignments? Using "sync my devices" preserves all your custom names and room groupings. Unlinking and relinking services may require you to reassign some devices to rooms.
Why does this happen more with certain router brands? Routers that dramatically change default IP ranges (like switching from 192.168.x.x to 10.0.x.x) or those with aggressive client isolation features cause this issue more frequently.