In this guide
- First, find out where it fails: device, network or rule
- Mesh gaps: when the signal has no good path
- 2.4GHz congestion: Zigbee and Wi-Fi channel planning
- Lights that switch one by one: groups vs individual commands
- Rules that fight, and rules that need the internet
- After a power cut: what should recover, and what often doesn't
- A troubleshooting checklist, in order
- How Pert delivers it (designed, not DIY)
- FAQs
This article is part of our wider coverage of home automation in Hyderabad. It builds on how a Zigbee mesh network works, which explains coordinators, routers and end devices, and sensor-triggered automation, which explains how rules are written. This one is about what to do when a system built on both stops behaving.
First, find out where it fails: device, network or rule
Every automated action passes through three layers. A trigger or button press creates a command (the rule layer), the command travels to the device (the network layer), and the device acts on it (the device layer). A problem in any one looks the same from the sofa: "it didn't work." The fastest way to find it is to bypass layers one at a time.
| Test | If it works | If it fails |
|---|---|---|
| 1. Control the device directly, from its own keypad button or the app's device page | Device and network are fine; the problem is in the rule or scene. Go to test 3. | Go to test 2. |
| 2. Control it standing next to the gateway, or check the link quality the system reports for that device | The device is fine but its path through the mesh is weak. Look at mesh gaps and congestion. | The device itself, its wiring, its power supply or its pairing is the problem. |
| 3. Run the scene or rule manually, then check the system's event log for when it last ran | The actions are right, but the trigger or a condition isn't firing. Check modes, time windows and overrides. | The scene or rule contains the wrong device, the wrong level, or a step that waits on something that never happens. |
| 4. Note when it fails: time of day, after a power cut, only when guests are over | Failures at a fixed time point to another schedule acting on the same device. Failures after power cuts point to recovery. Failures in the evening, when every neighbour is streaming, point to radio congestion. | |
Write down what failed, when, and what the family did just before. Three or four entries like that usually point at one layer, and it saves hours of changing things at random.
Mesh gaps: when the signal has no good path
In a Zigbee system the gateway coordinates the network, mains-powered devices such as keypads, light controllers and curtain motors act as routers that pass messages on, and battery sensors are end devices that sleep and talk through a nearby router. A device that responds slowly or only some of the time usually has a thin path: one weak hop, or a route that depends on a single router.
Where the gaps come from in Hyderabad homes
- RCC walls and slabs. Each concrete wall between two devices costs a lot of signal. A duplex or a villa with a staircase core often has a floor that reaches the gateway through a single router near the stairs.
- Metal enclosures. A gateway or controller placed inside a metal distribution board, a steel rack or behind a TV wall with a metal bracket loses much of its range.
- Routers that get switched off. A smart plug that gets unplugged, or smart bulbs that someone switches off at an old wall switch, remove routers from the mesh. Every device that was routing through them has to find a new path, and until it does, it misses commands. This is one reason a designed system uses wall keypads and in-wall controllers that stay powered rather than bulbs on ordinary switches.
- Sensors at the edge. A door sensor on the far balcony, reachable through only one router, will report late or not at all when that router is busy or off.
- Furniture that arrived after the handover. A new mirrored wardrobe or a large metal-backed cabinet can shade a device that tested well in an empty flat.
What fixes it
Aim for every device, and especially every battery sensor, to have at least two good routes to the gateway. Put the gateway centrally and in the open, not in the DB or a cupboard. Add a mains-powered router in the weak zone rather than relying on one path across a staircase. After adding routers, give the network time to settle, or re-pair edge sensors so they choose a nearer parent. And make sure no router in the design can be switched off by an ordinary switch. The Zigbee mesh guide has the planning rules we use from the start.
2.4GHz congestion: Zigbee and Wi-Fi channel planning
Zigbee, 2.4GHz Wi-Fi and Bluetooth all share the same 2.4GHz band. In a gated community or a high-rise tower in Gachibowli or Kokapet, a phone can often see twenty or more Wi-Fi networks, and in the evening they are all busy. Zigbee messages are small and the protocol retries when a message is lost, so light interference shows up first as delay, not failure. Heavy interference shows up as missed commands.
The key fact is that the channels are different widths. Zigbee uses sixteen narrow channels (11 to 26), each about 2MHz wide and 5MHz apart. A 2.4GHz Wi-Fi channel is about 20–22MHz wide, so one Wi-Fi channel covers several Zigbee channels.
| Wi-Fi channel (2.4GHz) | Zigbee channels it roughly overlaps | Zigbee channels in the gaps |
|---|---|---|
| 1 | 11–14 | 15, 20 and 25 sit between Wi-Fi channels 1, 6 and 11; 26 sits above 11 (though some devices transmit at lower power on 26) |
| 6 | 16–19 | |
| 11 | 21–24 |
What we do on site:
- Survey the 2.4GHz band with a Wi-Fi analyser, in the evening, from the rooms where problems appear.
- Set the home router's 2.4GHz channel deliberately to 1, 6 or 11, never "auto", so it doesn't wander on top of the Zigbee channel after a restart. Set the 2.4GHz channel width to 20MHz rather than 40MHz, which would cover half the band.
- Choose the Zigbee channel in a gap away from the busiest Wi-Fi channels. Changing it on a finished installation is possible but disruptive, so it is best decided before pairing.
- Separate the radios physically. Keep the gateway at least a metre from the Wi-Fi router and mesh Wi-Fi nodes, and away from USB 3.0 hard drives and ports, which are a known source of 2.4GHz noise.
- Move what can move to 5GHz. Phones, TVs and laptops on 5GHz leave the 2.4GHz band quieter for everything else. Our Wi-Fi and network planning guide covers router and access-point placement.
Lights that switch one by one: groups vs individual commands
If a room's lights come on in a ripple, one after the other, the network is usually fine. The scene is built the slow way. A scene that sends a separate command to each of twelve downlights puts twelve messages on the network one after another, and each can be delayed or retried. Installers call the result the "popcorn effect".
Zigbee has a better tool: group commands. Lights that always act together are put in a group, and one message addresses the whole group, so they change together. The trade-off is that group messages are broadcast-style and aren't individually acknowledged, so a well-designed system uses groups for "the whole room together" and individual commands where each device needs its own level, then keeps the total number of messages per button press small. Scenes that change forty devices across a house in one press, all addressed individually, are a common cause of a slow Good Night.
Two related causes of a scene that "half works": a scene that was edited from the app after a device was replaced, so it still points at the old device; and a curtain or light that was added to the house but never to the scene. Both are rule-layer problems that look like network problems.
Rules that fight, and rules that need the internet
When a device responds perfectly to its keypad but misbehaves "by itself", look at the rules. The most common patterns we find:
| Symptom | Likely cause | Fix |
|---|---|---|
| Curtains close again a few minutes after you open them | A sunset or time rule re-applies without checking for manual control | Add a manual-override condition: skip if the room was controlled by hand in the last 30 minutes |
| Lights switch on at odd times | Two rules own the same load; or an old schedule from a previous setup is still active | List every rule per load; give each load one automatic owner; delete orphans |
| A light flickers on and off repeatedly | A loop: rule A's action triggers rule B, whose action triggers rule A | Break the loop; never use a device's own state change as the trigger for a rule that changes it |
| Night path doesn't work some nights | Its condition is Night mode, and nobody pressed Good Night | Add a time-based fallback that sets Night mode late at night if the house is still in Home mode |
| Sunset rules run at the wrong time | Gateway location or time zone set wrongly, or clock drifted after a long outage | Set location to Hyderabad and time zone to IST; check the clock after power restoration |
| Automations stop when the internet is down | The rule runs in a cloud service or a voice assistant's routine, not on the local gateway | Move everyday rules to the gateway; keep cloud and voice for extras |
The last row deserves emphasis. A home that mixes a local system with apps from several brands, each with its own cloud, often has everyday lighting logic spread across three services that nobody can see in one place. When the internet or one of those services has a bad evening, rules fail in ways that look random. Consolidating everyday logic on the local gateway is often the single biggest reliability gain in a home that grew one device at a time.
After a power cut: what should recover, and what often doesn't
Hyderabad homes see short outages through the summer, and many unreliability complaints start "after the power came back". A well-designed system recovers on its own. These are the usual reasons it doesn't:
- The gateway isn't on the inverter, but the lights are. During the outage the lights work from keypads that control them locally, but no rule runs. Put the gateway, the Wi-Fi router and the modem on inverter-backed circuits.
- The gateway got a new network address. When the home router restarts, it may give the gateway a different IP address, and the app or a voice assistant can't find it. Reserve a fixed address for the gateway in the router (a DHCP reservation).
- The mesh is rebuilding. When routers lose power and come back, battery sensors may need time to reconnect through a new parent. A mesh with two good routes per device recovers in moments; a thin mesh takes longer and drops messages meanwhile.
- Devices come back in the wrong state. Each light's power-on behaviour (off, on, or last state) should be decided per room. Bedrooms that blaze on at full brightness when power returns at 3am are a design choice that was never made.
We cover each outage scenario in detail in do smart homes work during power cuts and internet outages?
A troubleshooting checklist, in order
- Write down the failure: which device, which button or rule, what time, what happened before.
- Control the device directly from its keypad and the app. Instant and reliable? It's the rule. Slow or unreliable? Continue.
- Check power: is every router near the device powered, and not on a switch someone uses?
- Check the path: link quality to the device, number of routes, anything new (furniture, mirrors, metal) near it or the gateway.
- Check the band: evening Wi-Fi survey; router channel fixed at 1, 6 or 11 and 20MHz wide; gateway away from the router and USB 3.0 devices.
- Check the scene: does it use groups where lights act together? Does it still point at the right devices?
- Check the rules: one owner per load, a manual-override condition, the right mode conditions, no loops, local rather than cloud.
- Check recovery: gateway and router on the inverter, fixed IP for the gateway, correct time zone, power-on state per room.
- Test at the time it fails, not in the afternoon when the band is quiet and the house is in a different mode.
Most homes need only two or three of these steps. The value of doing them in order is that you stop fixing the network when the problem was a rule, which is the most common wasted effort we see.
How Pert delivers it — a designed solution, not a DIY kit
Reliability is designed in before a device is paired, not added afterwards. On every project our team places the Pert gateway centrally and in the open, plans the Zigbee mesh so every keypad, lighting controller, curtain motor and sensor has more than one good route, and uses in-wall devices that stay powered so no router can be switched off by accident. We survey the 2.4GHz band at the site and set the Zigbee and Wi-Fi channels together. We build room scenes around groups, write every rule in trigger / conditions / actions form with one owner per load, and keep everyday logic running locally. We put the gateway and network on inverter-backed circuits and set each room's power-on behaviour. At handover we test scenes and rules at night as well as by day, including a simulated power cut. When something does misbehave later, our support team works through the same device-network-rule checks. Keypads, lighting, curtains and security are all designed as one system, which is what lets us find the cause instead of guessing.
If you are comparing who should design and install yours, best home automation companies in Hyderabad sets out what to ask, including how they test reliability and support a system after handover.
Is your smart home unreliable, or are you planning one that shouldn't be? We will check where it fails, whether in the devices, the network or the rules, and design keypads, lighting, curtains and security to work together reliably for years. Request a consultation →
Frequently asked questions
Why do my smart lights sometimes respond late or miss a command?
The usual causes are a weak path through the mesh (too few mains-powered routers between the gateway and the device, or a router switched off at the wall), congestion in the 2.4GHz band from neighbouring Wi-Fi, and scenes that send a separate command to every light instead of one group command. The fixes are to add routers where the path is thin, move the Zigbee channel away from the busiest Wi-Fi channels, and rebuild room scenes around groups.
Can Wi-Fi interfere with Zigbee?
Yes, because both use the 2.4GHz band. One Wi-Fi channel is about 20–22MHz wide and covers several of the sixteen narrow Zigbee channels: Wi-Fi 1, 6 and 11 overlap roughly Zigbee 11–14, 16–19 and 21–24, while Zigbee 15, 20 and 25 sit in the gaps. Survey the busiest Wi-Fi channels, fix the router's 2.4GHz channel and width, choose a Zigbee channel in a gap and keep the gateway a metre or more from the router.
Why did my automations stop working after a power cut?
Often the gateway or Wi-Fi router isn't on the inverter, so the logic stopped while the lights stayed powered; or the router gave the gateway a new address when it restarted; or battery sensors took time to reconnect because the mesh was thin. Put the gateway and router on inverter-backed circuits, reserve a fixed address for the gateway and run everyday rules locally.
How can I tell whether the problem is the network or the automation rule?
Test the device directly. If it switches instantly from its own keypad button and from the app, the device and network are fine and the rule is the problem: a missing condition, an unset mode, an override lockout or a dependence on the internet. If it is slow even when controlled directly, look at the mesh path, interference and power to nearby routers. If it fails only at certain times, look for another rule acting on the same device.