Two of the operational bits in the DNP3 internal indication field change what your commands will actually do, which makes them worth understanding on their own. Local Control warns that one or more points are in local or hand mode and will refuse remote commands, and Device Trouble warns that the outstation has some device-specific abnormal condition. Between them they explain a frustratingly common scenario: an operator sends a control, gets no effect, and blames SCADA when the real cause is a switch left in HAND out in the field. This page explains what each flag means, why Local Control silently defeats commanding, why Device Trouble is a catch-all, and how to triage both.
DNP3 Device Trouble and Local Control Flags in one line: The DNP3 Local Control flag, IIN1.5, means one or more of the outstation's points are in a local or hand operating mode and will reject remote commands, so a control you send may be silently refused at the point even though the message succeeded. The Device Trouble flag, IIN1.6, is a device-specific abnormal condition the outstation is reporting through the internal indication field, and its exact meaning depends on the device, so you have to consult the device's documentation to decode it. Both are IIN1 operational flags that affect commanding and equipment status rather than communications, and each needs its own triage.
Local Control, IIN1.5, tells the master that at least one point in the outstation is currently under local operation rather than remote control. In the field this usually corresponds to a hand-off-auto switch, a local control panel, or a maintenance mode that has been engaged so that a technician can operate equipment directly without SCADA interfering. When a point is in this local or hand state, the outstation is designed to reject remote operate commands aimed at it, because allowing a distant operator to move a valve or breaker while someone is working on it locally would be dangerous. The flag is the outstation's way of warning the master, in advance, that not everything it might command is actually commandable right now.
The trap is how quietly this defeats commanding. When you issue a control over DNP3 you typically use a select-before-operate sequence: you select the point, the outstation confirms the select, and then you operate. If the point is in local control, the operate can fail or the select can be refused, and unless the operator is watching the response codes closely, the symptom is simply that the command had no effect. Nothing looks broken, the communication succeeded, and yet the equipment did not move. An operator who does not know a field switch is in HAND naturally concludes that SCADA is malfunctioning, when in fact SCADA did exactly what it should and the point correctly refused a remote command.
Triaging Local Control starts with recognizing that the flag is set at all, then finding which point is in local. Because IIN1.5 is a device-wide flag, it tells you something is in local but not necessarily which point, so you may need to check individual control status or the device's own indication. The resolution is almost always physical: someone needs to confirm at the field device whether a switch is in hand or maintenance mode and return it to remote or auto when work is complete. Until that happens, remote commands to the affected point will keep failing by design, and the correct operator action is to stop retrying from SCADA and instead resolve the local mode in the field.
Device Trouble, IIN1.6, is a deliberately general flag. Where most IIN bits have a precise, protocol-defined meaning, Device Trouble is the outstation saying that it has detected some abnormal internal condition that the standard bits do not specifically cover. What that condition is depends entirely on the device: it might be a failed self-test, an out-of-range internal parameter, a hardware fault, a configuration problem, or any vendor-specific health issue the manufacturer chose to surface through this bit. The flag tells you that the device is not fully healthy, but it does not, by itself, tell you why.
This makes the device manual essential. To decode a Device Trouble indication you generally have to look at the outstation's own diagnostic points, error registers, or status objects, because the vendor defines what conditions raise the bit and where the detail lives. Two devices from different manufacturers can both raise IIN1.6 for completely different reasons, so there is no universal interpretation. The correct instinct on seeing Device Trouble is not to guess but to consult the specific device's documentation and read its detailed diagnostics, which is where the actionable cause will be found.
Because it is a catch-all, Device Trouble spans a wide severity range. In some cases it flags a minor, self-clearing condition; in others it indicates a fault serious enough that the device's measurements or controls should not be trusted. The flag's persistence is a useful clue, a Device Trouble that appears briefly and clears may be a transient self-test hiccup, while one that stays set warrants investigation before you rely on that outstation for control or data. Either way, the flag should be treated as a prompt to look deeper at the specific device rather than as a complete diagnosis in itself.
A simple triage flow keeps these two flags from turning into wasted troubleshooting. When a remote command fails to take effect, the first check is whether Local Control is set, because that immediately points to a point in hand mode and redirects the effort from SCADA into the field rather than into endless command retries. If Local Control is clear but the device is behaving abnormally or its data looks wrong, the check shifts to Device Trouble, which sends you to the device's own diagnostics and manual to identify the specific fault. Separating the two questions, is a command being refused versus is the device unhealthy, routes each symptom to the right place quickly.
The reason these flags cause so much friction is that the root cause lives in the field while the symptom appears in the control room. An operator sees a command fail on a screen; the actual cause is a switch in HAND on a skid miles away, or a fault register inside a distant RTU. Without a way to connect the two, the natural but wrong conclusion is that the SCADA system is at fault, and time gets spent chasing the wrong problem. Making the IIN operational flags visible to the operator at the moment they command a point is what closes that gap.
This is where continuous monitoring of the IIN field pays off. Because a platform like Merobix records Local Control and Device Trouble as monitored states over time, an operator can see immediately that a control refusal corresponds to a point in local mode rather than a communications or software problem, and a maintenance planner can see which sites are sitting with Device Trouble set and for how long. Trending these flags also surfaces patterns, such as a site that is routinely left in hand after maintenance and forgotten, or a device that repeatedly raises Device Trouble, turning individual operator frustrations into a maintenance signal that can actually be addressed.
Local Control, IIN1.5, means the target point is in a local or hand mode, so the outstation is designed to reject remote commands to it, often without producing an obvious failure that a busy operator notices. The communication succeeds and the message is delivered, but the operate is refused at the point because someone is controlling it locally. The fix is in the field: confirm whether a hand-off-auto switch or maintenance mode is engaged and return the point to remote when it is safe to do so.
Device Trouble, IIN1.6, is a device-specific catch-all, so its meaning is defined by the manufacturer rather than by the protocol. To decode it you need to consult the device's documentation and read its detailed diagnostic points, error registers, or status objects, because that is where the vendor exposes the actual condition. Two different devices can raise the same bit for completely different reasons, so there is no universal interpretation.
Yes. They are independent bits in the IIN1 field and report different things, so an outstation can have a point in local mode and an abnormal device condition simultaneously. When triaging, treat them separately: Local Control explains why a command is being refused, while Device Trouble tells you the device itself is reporting a fault you need to investigate through its own diagnostics. Checking both, rather than assuming one explains the other, avoids chasing the wrong cause.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.