In this guide
- Failure is normal; how it fails is the design choice
- Faulty or just offline? Five checks first
- Device by device: what fails, and what keeps working
- Like-for-like replacement: re-pairing step by step
- Gateway failure and configuration backups
- Planning for failure on day one: records, spares and access
- How Pert delivers it (designed, not DIY)
- FAQs
This article is part of our wider coverage of home automation in Hyderabad. It goes deeper than our overview of home automation maintenance and support, and builds on what a smart home gateway does. If your system is misbehaving rather than failing outright, start with why home automation becomes unreliable.
Failure is normal; how it fails is the design choice
Engineers talk about systems that fail gracefully: when one part stops, the damage stays local and everything else carries on. A smart home should behave the same way. Three properties decide whether it does:
- Independence. In a Zigbee system, every keypad, module and sensor is its own node on the mesh. A failed bedroom dimmer should affect the bedroom lights it drives — not the living room, not the curtains, not the app.
- A self-healing network. Mains-powered Zigbee devices also act as routers, passing messages for their neighbours. If one router drops out, the mesh looks for another route. That only works if the mesh was planned with enough routers that no device depends on a single path; how a Zigbee mesh network works explains why.
- A recoverable configuration. Your scenes, button mappings, schedules and automations are data held by the gateway. If that data is documented and backed up, any device — even the gateway — can be replaced without losing how your home behaves.
The first two are decided at design stage. The third is decided by whoever commissions and maintains the system. None of them comes free in the box.
Faulty or just offline? Five checks first
Most devices that “stopped working” are not faulty at all. Before anything is unscrewed, it is worth ruling out the common non-faults. A good support team will run through these with you on the phone.
| Check | What it looks like | What it usually means |
|---|---|---|
| 1. Is there power at the board? | A whole room's keypad and lights are dead, but other rooms are fine | An MCB or RCCB has tripped at the distribution board. Reset it; if it trips again, that is an electrical fault for an electrician, not an automation fault |
| 2. Is anything switched off upstream? | One smart light shows offline in the app and ignores the keypad | An old conventional switch somewhere feeds that light and has been turned off. The device is fine; it simply has no power |
| 3. Is it battery-powered? | A door or motion sensor stopped triggering automations | Battery exhausted, or the sensor was knocked out of alignment. The app usually shows a low-battery warning first |
| 4. Do its neighbours respond? | One far-corner device is slow or misses commands, nearby devices are fine | A weak mesh link, often after a new wardrobe, mirror or metal partition went in. A routing problem, not a hardware one |
| 5. Does it come back after a power cycle? | Device has power but is unresponsive | Switch off its circuit for 30 seconds and restore. If it rejoins and works, note it and watch for a repeat; if it stays dead, it is a genuine fault |
A designed system shortens this list. If every device reports its state and the gateway sends an alert when a device goes quiet for, say, 15 minutes, the installer can see exactly which device dropped off and when — often before you notice. That is part of the feedback design described in how smart home status feedback works.
Device by device: what fails, and what keeps working
Different devices fail differently. This is what a family in a well-designed system should expect, and what recovery involves.
| Device | What you notice | What keeps working | Recovery |
|---|---|---|---|
| Wall keypad | Buttons on that keypad do nothing, or backlight is out | All the loads it controlled, from the app, other keypads, schedules and voice | Swap the keypad in the same back-box; re-map its buttons to the same scenes; re-check engraving matches |
| Relay / switching module | One light circuit, fan or socket will not switch | Everything else in the room | Replace the module; re-apply power-on behaviour; re-add to its groups and scenes |
| Dimmer or dimmable / tunable driver | One light layer will not dim, flickers, or stays off | Other layers in the same room | Replace like for like; re-apply minimum level, fade time and colour-temperature range so scenes look the same as before |
| Curtain motor | Curtain does not move, or stops part-way | Curtain can still be drawn by hand on most track systems; other curtains unaffected | Replace the motor on the existing track; reset end limits; re-check the open/closed positions used in scenes |
| Battery sensor (door, motion) | An automation stops firing; low-battery or offline alert | Everything except automations that depend on that sensor | Usually a battery change; if replaced, re-link it to its automations and alerts |
| A router device mid-mesh | Devices beyond it go briefly slow or offline | Most of the house; the mesh re-routes around the gap | Replace the device; if re-routing was slow, the mesh needed another router there anyway |
| Gateway | App cannot reach the home; schedules and multi-device scenes stop | Depends on the system’s architecture — ask your installer what still works locally | Replace and restore from configuration backup; see below |
Two points from the table are worth stressing. First, because control is spread across keypads, the app and schedules, a single failed keypad is an inconvenience, not a lock-out — which is one reason we recommend having both a keypad and the app. Second, every replacement involves settings, not just hardware. A new dimmer with factory defaults may switch the lights fine but make your Relax scene look completely different.
Like-for-like replacement: re-pairing step by step
Every Zigbee device has a unique hardware address. When a device is replaced, the new one joins the network with a new address, so the gateway sees it as a stranger. The job is to make the stranger take over the old device’s role everywhere. Done properly, it looks like this:
- Identify the device from the record. The device register (see below) tells the technician the exact model, its location, which circuit feeds it and which scenes, groups and automations use it. No guesswork, no opening the wrong board.
- Isolate and swap. Switch off the circuit at the board, remove the failed unit, fit the replacement in the same position and wiring, and restore power.
- Join the network deliberately. The gateway’s pairing window is opened only for this device and closed again straight after. Zigbee traffic is encrypted with the network key, and new devices can only join while pairing is open, so this step is controlled rather than automatic.
- Put it in the old device’s place. The new device is substituted for the old one in the gateway configuration — either with a replace function, or by re-adding it to every scene, group, button mapping and automation that referenced the old one. The record lists them, so none is missed.
- Re-apply device settings. Power-on behaviour after a power cut, minimum dim level, fade times, colour-temperature range, curtain end limits, sensor hold times, LED behaviour on keypads. These live on the device or against it in the gateway, and they reset with new hardware.
- Test every scene that includes it. Press each scene button that uses the device, run the schedules that touch it, trigger its automations, and check the app tile and keypad LED match reality.
- Remove the old entry and update the record. The dead device is deleted from the gateway so it does not raise offline alerts forever, and the register is updated with the new unit and date.
For a keypad, module or driver in an accessible location, this is typically under an hour on site. What makes it slow is not the swap but the unknowns: a driver buried in a sealed false ceiling with no service opening, an undocumented system where nobody knows which scenes used the old device, or no record of the settings it had.
Gateway failure and configuration backups
The gateway is the one device whose failure matters more than the rest. It is the Zigbee coordinator: it holds the network’s identity (its channel, network ID and security key), the list of every device, and every scene, schedule, mode and automation. Replace a gateway without that data, and the new one starts a brand-new, empty network.
| Situation | What replacing the gateway involves |
|---|---|
| Recent configuration backup exists | Fit the replacement, restore the backup, let devices reconnect to the network they already know, then test scenes and schedules. The household notices a short interruption, not a rebuild. |
| Old backup only | Restore it, then re-add any devices, scenes or changes made since. This is why backups should be refreshed after every change, not just at handover. |
| No backup | Every device may need to be factory reset and re-paired, often meaning a visit to every keypad and module in the home; every scene, schedule and automation rebuilt from memory or old notes. |
Because of this, the gateway deserves more care than any other device: placed centrally in a ventilated spot rather than shut in a hot DB cabinet, on surge-protected power and ideally on inverter backup, as covered in electrical safety and power protection for a smart home. The questions to put to any installer are simple: Is the configuration backed up? Where? How often? Who can restore it if you are not available? They belong on the list in best home automation companies in Hyderabad.
Planning for failure on day one: records, spares and access
The cheapest time to make a future repair easy is during design and handover. Four things make the difference.
1. A device register
One document, handed over with the system and kept up to date, listing every device. A typical row looks like this:
| Location | Device | Fed from | Used in | Key settings |
|---|---|---|---|---|
| Living — cove, above TV wall service opening | Tunable LED driver | DB-1, MCB 7 | Evening, Relax, Movie, Good Night, Master-off | Min level 5%, fade 2s, power-on: off |
| Master bedroom — window head | Curtain motor (blackout) | DB-2, MCB 3 | Morning, Good Night, Away | Limits set; Morning opens to 100% |
| Entrance | Stella keypad | DB-1, MCB 2 | Master-off, Arrive, Away | Night backlight dim from sunset |
The same document doubles as the system’s memory when you renovate, sell the home, or simply forget why the balcony light turns on at 6:40pm. It belongs alongside the checks in the home automation handover and testing checklist.
2. Access to every device
Drivers and modules above a false ceiling need a service opening or a removable panel near them. Curtain motors need a pelmet or ceiling pocket that can be opened without breaking plaster. The DB should be labelled circuit by circuit. A device you cannot reach turns a 30-minute swap into a carpentry job.
3. Sensible spares and standardisation
Using a small number of device types across the home — the same keypad, the same driver family, the same motor — means a replacement is always like for like and settings are familiar. In large villas, or homes outside the city where a visit takes longer, it can make sense to keep a spare of the most common module type on site.
4. Alerts and warranty records
Offline and low-battery alerts mean failures are caught early rather than discovered at 11pm. Keeping purchase and installation dates in the register makes warranty claims straightforward. And the owner, not the installer’s personal phone, should hold the main account, so access survives any change of support arrangement.
How Pert delivers it — a designed solution, not a DIY kit
Pert's Stella keypads, tunable and dimmable lighting, motorised curtains and sensors and security devices work together as one Zigbee system through the Pert gateway. Because we design and install the whole system rather than handing over a kit, recovery is planned in from the start: the mesh is laid out with enough routers that one failed device does not cut off its neighbours, drivers and motors are placed where they can be reached, the DB is labelled, and every device, setting and scene is recorded at handover. When something does need replacing, our support team works from that record — diagnosing over the phone first, then swapping like for like, restoring the device's settings and testing every scene it belongs to before we leave.
Planning home automation for a Hyderabad flat or villa? We will design a system that keeps working when one part does not — keypads, lighting, curtains and security, documented and supported for the long run. Request a consultation →
Frequently asked questions
If one smart keypad or switch stops working, does the whole system stop?
No. In a Zigbee system each device is a separate node, so one failed keypad or module affects only the loads and buttons it handles. Other keypads, the app and schedules keep working. If the failed device was also acting as a mesh router, nearby battery sensors may briefly look for a new route, which a well-planned mesh normally finds by itself within minutes.
Do I have to redo all my scenes when a device is replaced?
Not if the replacement is handled properly. The new device joins with a new identity, so the installer puts it in place of the old one in the gateway configuration, re-applies its settings such as power-on behaviour, minimum dim level and curtain limits, and tests every scene that uses it. Your scenes, button labels and routines stay exactly as they were.
What happens if the smart home gateway fails?
Features that depend on the gateway, such as app control, schedules and multi-device scenes, pause until it is replaced. With an up-to-date configuration backup, the replacement is restored and devices rejoin without being re-paired one by one. Without a backup, every device may need re-pairing and every scene rebuilding, so ask any installer how the gateway configuration is backed up and who can restore it.
How can I tell whether a smart device is faulty or just offline?
Most “dead” devices are not faulty. Check that the circuit has power at the board, that no old conventional switch upstream is off, that a battery sensor has charge, and whether nearby devices respond. If the device has power, ignores everything and does not return after a power cycle, it is likely a genuine fault. A designed system also sends an offline alert, so support can see which device stopped reporting and when.