The Device Keeps Dropping Offline

Why this matters

"It keeps going offline" is the connected-device complaint that eats the most return trips, because the device is almost always online when the tech arrives. A tech who swaps the module on the strength of the complaint is guessing, and the guess is wrong often enough that the second visit starts with a customer who now distrusts the part, the installer and the brand. This case follows one pool controller through six hypotheses, each killed by a specific measurement rather than an opinion, to show how an intermittent drop is actually pinned down. The method travels to thermostats, water heaters, garage openers and irrigation controllers unchanged.

The complaint

A pool service company installed an automation controller at a customer's equipment pad. About five weeks later the customer calls: the app shows the controller "offline" several times a week, each time for somewhere between under an hour and about three hours, then it comes back without anyone touching it. The pump and chlorinator keep running their schedule while offline, because the controller holds its schedule locally, but the customer cannot see or adjust anything from the app, and she is traveling next month.

Safety at this pad before anything else. The equipment pad is water and line voltage within arm's reach. The tech reads everything on this call from the controller's low-voltage display panel and the apps; he does not open the high-voltage compartment. If any reading had required it, the rule is: shut off the pad's breakers, confirm dead with a meter at the terminals before touching them, keep hands and tools dry, and restore power only with the compartment cover reinstalled.

Building the evidence before forming a theory

The tech's first move is not a theory. It is getting the drop times written down, because an intermittent fault you cannot timestamp cannot be correlated with anything. He pulls the controller app's connection history and, with the customer's permission and her hands on her phone, the router app's event log and the modem's status page. Fourteen days, seven drops:

DROP LOG - POOL CONTROLLER - 14 DAYS
day   offline  back    nearest router/modem event
Mon   02:59    04:41   2.4 GHz channel 6 -> 1, 02:57
Wed   03:02    05:10   2.4 GHz channel 1 -> 11, 03:00
Thu   14:20    15:01   modem: internet down 14:18-14:55
Sat   02:58    03:55   2.4 GHz channel 11 -> 6, 02:56
Tue   03:01    06:02   2.4 GHz channel 6 -> 1, 02:59
Thu   11:47    13:30   2.4 GHz channel 1 -> 6, 11:44
Sun   02:57    04:20   2.4 GHz channel 6 -> 11, 02:55
router log: 9 channel changes on 2.4 GHz in 14 days

He does not read the pattern yet. He writes down the six things that commonly cause a device to drop and kills them one at a time.

Hypothesis 1: weak signal at the pad

Why it was first. Equipment pads sit outside, often behind an exterior wall and low-emissivity glass, and weak signal is the most common cause of drops in general.

The measurement. A phone signal app at the controller, held at the module's height, read -69 dBm on 2.4 GHz at midday and -72 dBm at dusk. That is between solid and marginal (about -67 solid, -75 marginal), not great. But the controller's own diagnostic screen keeps a signal history, and in the readings logged before each of the seven drops it reported between -68 and -71 dBm. Signal did not dip before any drop.

What killed it. A coverage problem shows a falling signal before the drop, worse in bad weather or with a parked car in the path. This one was flat. He notes the margin is thin and moves on. A tech who stopped here would have installed a mesh node, the drops would have continued, and the node would have taken the blame.

Hypothesis 2: the address lease

Why it was on the list. The router lends each device an IP address for a set period called a lease. Some devices handle a lease renewal badly and drop when it comes due.

The measurement. The router's lease time was 24 hours. If renewals were the cause, drops would arrive at roughly the same clock time each day, offset by however the first lease landed. These do not. More decisively, the router's device list showed the controller back on the same address after each drop, with the lease timer reset only at the normal renewal times, not at the drops.

What killed it. No alignment between drops and renewals. See related: IP Addresses and Why a Device Disappears.

Hypothesis 3: the power supply

Why it was on the list. A failing low-voltage supply, or a controller sharing a circuit with a pump that sags it on start, can reboot the module.

The measurement. The controller's diagnostic screen shows an uptime counter, time since it last powered up. It read 23 days. A device that browns out or reboots resets that counter. Seven drops in fourteen days with an uptime of 23 days means the controller never lost power during any drop.

What killed it. The uptime counter. This is the single most useful number on any device that shows one, and it is worth looking for before anything else on the next call. The 23 days becomes important again under hypothesis 6.

Hypothesis 4: the router rebooting itself

Why it was on the list. Some routers reboot nightly on a schedule, or crash, and every device drops with them.

The measurement. Router uptime in its own app: 37 days. No scheduled restart enabled. And the customer's two cameras and her thermostat stayed online through the drops, per their own app histories.

What killed it. A router reboot drops everything at once. Only the controller dropped.

Hypothesis 5: the internet connection

Why it was on the list. If the house loses its internet connection, the app shows every cloud-connected device as offline, even though the local network is fine.

The measurement. The modem's status page logged one internet outage in the period, 14:18 to 14:55 on the first Thursday. That lines up with the Thursday 14:20 drop. None of the other six drops coincided with an outage.

What killed it, mostly. The internet explains one of seven drops, which is worth recording as genuine and separate. It does not explain the other six. The tech keeps the Thursday drop out of the remaining analysis rather than letting it muddy the pattern.

Hypothesis 6: firmware

Why it was last. It is the hardest to prove and the easiest to blame, so it goes last.

The measurement. Two facts. First, the controller's update history showed a firmware update installed 23 days earlier, matching the uptime counter exactly: the update was the last reboot. The customer's recollection was that the drops began "a week or so after the pool was opened", which fits. Second, the drop log. Of the six drops not explained by the internet outage, all six began within two to three minutes after the router changed its 2.4 GHz channel. The router uses an automatic channel selection feature that moves to a quieter channel when it detects interference, usually in the small hours. It made nine such changes in the fourteen days. Six were followed by a drop, three were not.

What it means. When a router changes channel, connected devices are supposed to notice and follow, or reconnect within seconds. This controller, on its current firmware, was losing the network on a channel change and only rescanning on a long retry timer, which is why recovery took anything from under an hour to about three. That three of nine changes produced no drop is consistent with the device sometimes catching the change before giving up, which is typical of a timing fault rather than a hard incompatibility.

The fix and the confirmation

Two options, and they are the customer's to choose because both touch her network or her device:

• Pin the 2.4 GHz channel. In her router app, she set the 2.4 GHz band to a fixed channel (channel 6, the least crowded per the signal app's neighbor scan) instead of automatic. No channel changes, no trigger. Cost to her: if a neighbor later floods channel 6, nothing moves automatically.
• Wait for, or roll back, firmware. The tech reported the behavior to the manufacturer's dealer support line with the log, the router event times and the firmware version. Rollback was not offered by the manufacturer.

She pinned the channel the same day. Over the following 21 days the controller logged zero drops, against seven in the 14 days before, six of them on channel changes. The tech also recorded the thin signal margin at the pad (-69 to -72 dBm) as a separate, open item: not the cause here, but the next thing likely to bite if anything in the path changes.

What would have flipped the conclusion. Had the uptime counter reset at each drop, hypothesis 3 would have survived, and the cause would have been power, not network. Had the cameras dropped at the same times, the router or the channel itself would be suspect for everyone, not the controller's firmware. Had the signal history dipped before drops, coverage would have been the lead. Each of those is one reading, and each reading is available on the first visit.

What carries to the next call

The pattern that solved this was not cleverness; it was refusing to theorise until drop times were on paper next to every other event log in the house. A drop that lines up with a router event, a modem event or a power event is a network or power fault, whatever the app says. A drop that lines up with nothing, on a device whose firmware just changed, is the case firmware updates get blamed for, and here it was earned.

References

• Device manufacturer diagnostic documentation (uptime counter, signal history, update history)
• Router and modem documentation for event logs and channel settings
• See related: Firmware Updates, the Silent Change to Installed Equipment; It Worked Until Last Tuesday and Nobody Touched It
• See related: Measuring Wi-Fi Signal Where the Equipment Lives; IP Addresses and Why a Device Disappears; The Customer Network Change Authorization SOP