Power, Comms, or Device? Splitting a Dark Site
Almost every remote-site outage resolves to one of three layers - the site lost power, it lost its communication path, or its controller stopped answering - and each one dispatches a different response. Getting the fork right from the office is what turns a two-trip outage into a one-trip fix. This page is a focused tree on just that three-way decision, giving the specific discriminating tests that convict power, comms, or the device rather than leaving you guessing which truck to roll.
Power vs Comms vs Device in one line: To split power, comms, or device on a dark site, run three tests. Does anything at the site answer on any path (yes means power is present, so comms or device); did the pre-failure trend show a voltage decline (points at power) or a signal decline (points at comms) or a clean stop (points at device or an abrupt cut); and can you reach the gateway but not the controller (convicts the device). Each answer removes one layer.
First Checks: The Three Discriminating Questions
The first and most powerful discriminator is whether anything at the site still responds on any path at all. If the site's router, gateway, or modem still answers a ping or still shows registered on its carrier, then that device has power and at least part of the comms path is intact, which eliminates a total power loss and pushes the fault toward the controller or a partial comms fault. If absolutely nothing at the site answers on any interface, power becomes the leading suspect, because losing supply takes down the modem and the controller together and produces exactly this total silence.
The second discriminator is the pre-failure trend, which the site recorded for you before it went quiet. A battery-voltage or panel-voltage tag sliding downward in the minutes before the stop is a power failure describing its own onset - a discharging battery, a failing supply, a solar site running out of charge overnight. A comms-quality, signal-strength, or error-rate tag degrading before the stop points at the link deteriorating. Values that were perfectly healthy up to the instant they stopped, with no warning at all, point at an abrupt event - a tripped breaker, a cut line, or a controller crash - rather than a gradual decline.
The third discriminator is the scope across neighboring sites. If sites sharing the same carrier, repeater, or head end went dark at the same moment, the fault is upstream of any one site and is a comms or infrastructure event, not a site power or device fault. If only this site dropped while its path-mates kept reporting, the fault is local to this site and the power-versus-device question remains open. Reading the neighbors first can convict the comms layer without any test at the site at all, because a shared outage is visible entirely from the office.
The Tests That Convict Each Layer
To convict power, look for total silence plus a declining-voltage pre-trend, and confirm that no interface at the site responds. A site that has genuinely lost supply answers nothing, showed its battery or panel voltage falling beforehand where such a tag exists, and often correlates with a known event such as an overnight solar shortfall or a storm. The solar case has its own overnight signature, and the workflow for a solar site browning out overnight walks that specific pattern. Power is convicted when everything is dark and the last evidence before darkness was a voltage running down.
To convict comms, look for a live device that cannot reach you, or a shared outage across neighbors. If the site's gateway has power - it answers on a management path, or its own status shows it running - but the polled data stopped, the break is in the path between that gateway and the head end: the carrier, the antenna, the cable, or the network. A signal-strength decline in the pre-trend supports this. A group of sites dropping together convicts the shared comms element directly. Comms is convicted when the site clearly has power and a live interface but the data path to you is broken, which is the same class of fault as a cellular gateway that keeps dropping seen as a hard stop.
To convict the device, prove that power and comms are both present but the controller specifically will not answer. The signature is that you can reach the site's gateway or router, the link is confirmed up, but a read to the controller returns a connection with no valid response, an exception, or nothing from that one device while the network path is healthy. A controller that crashed, hung, or sits in fault mode does exactly this - the pipe to it is open but the box behind it is not serving data. A PLC in fault mode is the textbook version, and clearing it or power-cycling it is the fix. The device is convicted when everything around it works and only it is unresponsive.
Verifying the Verdict Before You Dispatch
Confirm the verdict with one decisive test that would fail if you picked the wrong layer. For a power verdict, if any remote power telemetry or switching exists, confirm the supply is truly absent rather than the reporting being lost. For a comms verdict, reach the gateway directly on a path that bypasses the normal poll; success proves comms partway and may re-open the device question. For a device verdict, confirm the network path is genuinely healthy right up to the controller before blaming the box, because a subtle comms fault can masquerade as an unresponsive device. The verification test is chosen to catch a wrong verdict, not just to agree with it.
Match the dispatch to the convicted layer and hand over the evidence. A power verdict sends someone with a meter, fuses, and possibly a battery, plus the voltage pre-trend. A comms verdict sends a comms tech with a spare modem, antenna, and cable, or triggers a carrier call before anyone drives, plus the signal pre-trend and the neighbor-scope map. A device verdict sends a controls technician who can power-cycle and reprogram the controller, plus the timestamp and the read-attempt result. The right person with the right parts and the recorded evidence is the entire payoff of getting the fork right.
A cloud SCADA such as Merobix supports this three-way decision by recording the pre-failure trend of power and signal tags, timestamping the stop, and showing at a glance whether neighboring sites failed together. Rather than assembling that picture from several tools under time pressure, an engineer reads the three discriminators in one place and reaches a defensible verdict. The platform does not restore the site, but it turns a guess about which truck to roll into an evidence-based call, which is what keeps a dark-site outage to a single trip.
When to Escalate
Escalate as a shared-infrastructure incident the moment the neighbor scope shows multiple sites dark together, because that is a comms or wide-area power event that must be worked upstream, with the carrier or the network or the utility, not one truck per site. Individually dispatching to sites during a shared outage is the most common way a crew burns a day on symptoms of a single cause.
Escalate a single dark site to a field dispatch once the fork is decided and remote recovery has failed or is unavailable, sending the person and parts that match the convicted layer. If the verdict is genuinely ambiguous after all three discriminators - which happens when the site went totally silent with no useful pre-trend - default to the layer that fails safe for that site type and carry parts for two layers, but say so explicitly so the responder is prepared. An honest ambiguous verdict, stated as such, still beats a confident wrong one.
Frequently Asked Questions
How do I tell if a dark site is power, comms, or a dead controller?
Run three discriminators. First, does anything at the site answer on any path: if the gateway responds, power is present and the fault is comms or the controller; if nothing answers, power leads. Second, what did the pre-failure trend show: a voltage decline points at power, a signal decline at comms, a clean stop at an abrupt cut or a device crash. Third, did neighbors on the same path drop too: a shared outage convicts comms upstream. Each answer removes one of the three layers until one remains.
The gateway pings but the data stopped. Is that comms or the device?
A gateway that pings has power and a working management path, so a total power loss is ruled out. The question is whether the break is between the gateway and you, or in the controller behind the gateway. Try a raw read to the controller: if the network path is healthy up to the controller but the device returns no valid response, an exception, or silence, the controller is convicted - it is crashed, hung, or in fault mode. If the path to the controller itself is broken while the gateway is fine, it is a partial comms fault. The test is whether the box behind a proven-healthy path answers.
Why does getting the power-comms-device fork right matter so much?
Because each layer dispatches a different person with different parts, and guessing wrong means a second trip. A power fault needs someone with a meter, fuses, and a battery; a comms fault needs a comms tech with a spare modem and antenna or a carrier call; a device fault needs a controls technician who can power-cycle and reprogram the controller. On a remote site a second trip can cost a full day. The fork exists to make the first dispatch the correct one, with the right parts and the recorded pre-failure evidence in hand.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.