Why do my Philips Hue bulbs turn on by themselves after a power outage, even when I set them to “PowerOn Behavior: Last State”?

When you move your Home Assistant instance from Ethernet to Wi‑Fi and IFTTT webhooks suddenly start timing out, it is almost never an “IFTTT problem” or a “Home Assistant bug”.

It is a network‑level issue: IFTTT’s servers are no longer able to reach your Home Assistant at the URL you configured, or responses are too slow to arrive within IFTTT’s timeout window.

This article explains why that happens and how to fix it reliably.

How IFTTT Webhooks Reach Home Assistant

An IFTTT Webhook works like this:

1. IFTTT sends an HTTPS request to a URL you configured, for example:
   https://your-domain.example.com/api/webhook/SECRET_ID
2. Your domain resolves to your public IP address.
3. Your router receives the request on a given port (usually 443 or 8123).
4. Port forwarding/NAT rules in the router send that request to the internal IP of your Home Assistant machine (e.g. 192.168.1.50:8123).
5. Home Assistant processes the webhook and returns an HTTP response.
6. IFTTT returns “OK” if it receives a valid response within a few seconds.

If any step between 2 and 5 fails or is too slow, IFTTT shows a timeout.

When you switch from Ethernet to Wi‑Fi, you are changing the network interface and often the network path. That commonly breaks steps 3–4.

1. The Primary Culprit: IP Address Change and Broken Port Forwarding

On most home networks, your router assigns IP addresses via DHCP. Changing from Ethernet to Wi‑Fi usually means:

• The device receives a different internal IP address on the Wi‑Fi interface.
• Your existing port forwarding rule still points to the old Ethernet IP.

Example:

• Before (Ethernet)
• Home Assistant: 192.168.1.10 (Ethernet)
• Port forwarding:
• WAN:443 → 192.168.1.10:8123
• IFTTT → Internet → Router → 192.168.1.10 → Works.
• After (Wi‑Fi)
• Home Assistant: 192.168.1.25 (Wi‑Fi)
• Port forwarding still points to: 192.168.1.10:8123
• Router forwards IFTTT requests to a device that no longer runs Home Assistant → No response → IFTTT timeout.

How to fix this

11. Give Home Assistant a fixed IP on Wi‑Fi
• In your router’s DHCP settings, create a reservation for the MAC address of the Wi‑Fi interface.
• Assign a stable address, for example 192.168.1.50.
12. Update port forwarding
• Change the existing rule to forward the relevant port (443/8123) to the new IP:
• WAN:443 (or 8123) → 192.168.1.50:8123.
13. Test from outside your network
• Turn off Wi‑Fi on your phone (use 4G/5G).
• Open the same URL used by your IFTTT Webhook.
• If Home Assistant’s login page opens, external access is working again.

If this step alone fixes the timeouts, you have confirmed that the issue was broken port forwarding due to an IP change.

2. Guest Wi‑Fi, Double NAT, and Isolated Networks

Sometimes the problem is not just the IP, but that the Wi‑Fi network behaves differently from the wired LAN.

Common scenarios:

• The Wi‑Fi SSID you used for Home Assistant is actually a Guest network, isolated from the main LAN.
• A second router or Wi‑Fi extender is running in router mode instead of access point / bridge mode, creating another NAT layer (Double NAT).
• The Wi‑Fi network uses a different subnet (e.g. 192.168.2.x instead of 192.168.1.x).

In these cases, the main router may:

• Not be able to reach devices behind the second NAT.
• Not be able to port‑forward from the Internet to the Wi‑Fi client’s IP.
• Or have firewall rules that block cross‑subnet traffic.

What to check

• Confirm that the Home Assistant Wi‑Fi IP is in the same subnet as other LAN devices that work with port forwarding (e.g. everything in 192.168.1.x).
• If you are using a secondary router/extender:
• Set it to Access Point / Bridge Mode, not router mode.
• This ensures that Wi‑Fi clients get IPs from the main router and sit on the same LAN.
• Disable AP Isolation / Client Isolation / Guest Isolation for the Wi‑Fi network that Home Assistant uses.

After making changes, repeat the external access test from mobile data.

3. Operating System Firewall and Interface Policies

If Home Assistant runs on a general‑purpose OS (Linux, Windows, Synology, etc.), that OS might:

• Allow incoming traffic on the Ethernet interface.
• Treat the Wi‑Fi interface as “Public” and block inbound connections.

Symptoms:

• You can sometimes access Home Assistant locally.
• But external requests (after NAT) are rejected or dropped, causing timeouts.

How to address this

27. Ensure Home Assistant is listening on all interfaces, not just Ethernet.
    You typically want it bound to 0.0.0.0:8123.
28. Check your system firewall:
• Linux (ufw/firewalld/iptables)
• Allow incoming connections on port 8123 from the LAN and from the router.
• Windows
• Mark your home Wi‑Fi as a Private/Trusted network, not Public.
• Allow the Home Assistant process or port in “Inbound Rules”.
29. After changes, test:
• http://<Wi-Fi-IP-of-HA>:8123 from another device on the same LAN.
• If local access is solid, test again from outside (mobile data).

4. Wi‑Fi Latency, Packet Loss, and Power‑Saving

IFTTT waits only a short time (a few seconds) for your webhook endpoint to respond. Weak or unstable Wi‑Fi can easily push total response time beyond this limit.

Contributors to slow response:

• Weak signal (long distance, multiple walls, interference from neighbors).
• Overcrowded 2.4 GHz channels.
• Aggressive power‑saving modes on the device’s Wi‑Fi card causing delays in waking up.
• High packet loss leading to repeated retransmissions and delayed TCP/TLS handshakes.

How to evaluate Wi‑Fi quality

34. From another device on the same Wi‑Fi:
• ping <Wi-Fi-IP-of-HA> repeatedly.
• Latency should be low and stable; packet loss should be 0%.
35. Try temporarily:
• Moving the Home Assistant device closer to the access point.
• Switching to a less crowded channel.
• Using 5 GHz instead of 2.4 GHz if available.
36. If timeouts disappear when signal quality improves, the issue was Wi‑Fi stability, not configuration.

5. DNS, External URL, and SSL Misconfiguration

If you use a domain with HTTPS (e.g. via DuckDNS + Let’s Encrypt), misconfiguration can cause connection failures that look like timeouts.

Validate the following:

37. DNS points to your current public IP
• Check your public IP (from a browser: “what is my IP”) and confirm that your domain resolves to that IP.
• If it has changed (dynamic IP), renew your DDNS settings.
38. Correct external URL in Home Assistant
• In configuration.yaml or system settings, ensure external_url matches the domain and protocol you actually use with IFTTT.
39. Valid SSL certificate
• Expired or mismatched certificates can cause connection failures or long negotiation times.
• Test your URL in a browser over mobile data and confirm there are no HTTPS errors.

If DNS/SSL is incorrect, IFTTT’s request may never complete successfully, and the log will show timeouts or generic connection errors.

6. Step‑by‑Step Troubleshooting Checklist

Use this checklist to systematically identify the root cause:

40. Local access test (LAN)
• On a device on the same Wi‑Fi, open http://<Wi-Fi-IP-of-HA>:8123.
• If this fails: fix local networking and firewall first.
41. External access test (mobile data)
• Turn off Wi‑Fi on your phone.
• Open the IFTTT Webhook URL in a browser.
• If you cannot reach Home Assistant, the problem is port forwarding/DNS/firewall.
42. Verify public port
• Use a tool like canyouseeme.org and check the port you forward to HA (e.g. 443 or 8123).
• If the port is closed, correct your port forwarding target IP and firewall rules.
43. Confirm IP and network segment
• Ensure Home Assistant’s Wi‑Fi IP is:
• Static or DHCP‑reserved.
• In the same subnet as other LAN devices.
44. Review router features
• Disable guest isolation or AP isolation on the Wi‑Fi.
• Eliminate double NAT by using access point mode where appropriate.
45. Inspect OS firewall
• Allow incoming connections on port 8123 on the Wi‑Fi interface.

After each change, retest from mobile data and then from IFTTT.

7. Why Ethernet Still Works When Wi‑Fi Fails

If you plug Home Assistant back into Ethernet and everything instantly starts working again:

• The external URL, IFTTT configuration, and general integration are correct.
• The difference is entirely in the network path from your router to the Home Assistant host.

That points directly to one or more of:

• Wrong internal IP in port forwarding,
• Different subnets / double NAT,
• Wi‑Fi‑specific firewall behavior,
• Or Wi‑Fi stability issues.

You can use the working Ethernet configuration as a reference to mirror the same behavior on Wi‑Fi (same IP range, same forwarding target, same firewall allowances).

8. Using Home Assistant Cloud (Nabu Casa) with IFTTT

If you prefer not to deal with:

• Port forwarding,
• Dynamic DNS,
• Firewalls and NAT,

consider Home Assistant Cloud (Nabu Casa):

• It provides a secure, cloud‑hosted URL for your Home Assistant instance.
• IFTTT talks to the cloud endpoint.
• The cloud service maintains a secure tunnel back to your Home Assistant over your internal network.

This effectively removes the need for exposing your Home Assistant directly to the Internet and eliminates most Wi‑Fi/Ethernet routing issues.

9. Best Practices to Avoid Future Webhook Timeouts

• Use static or DHCP‑reserved IPs for key servers (Home Assistant, NAS, etc.).
• Keep all smart home infrastructure on the same LAN/subnet.
• Avoid double NAT; use Access Point / Bridge mode for secondary devices.
• Regularly check that your DDNS and SSL certificates are up to date.
• Position your Home Assistant hardware where Wi‑Fi signal is strong and stable, or keep it on Ethernet if possible.
• Monitor Home Assistant logs for connection and webhook errors.