Status code · Uncertain
UncertainNoCommunicationLastUsableValue
UncertainStale data
UncertainNoCommunicationLastUsableValue is not a failure of your client. It names the cause explicitly: communication with the source is down and this is the last usable reading. Treat the value as historical, check SourceTimestamp for age, and go and look at the device link rather than at the OPC UA layer.
Defined behaviour: Communication with the source has failed and the value returned is the last one that was usable. (our description of the condition this code reports)
What you actually see
One device's tags all freeze at plausible values with an uncertain status at the same instant, while tags from other devices on the same server keep updating normally.
Why it happens
- Field-level communication loss to one deviceThe server can still be reached, but its link to the PLC, instrument or field bus segment has failed. Because the loss is per device, the signature is a whole block of tags degrading together at one timestamp while the rest of the address space is unaffected.
- Network path to the device brokenA switch port, cable, VLAN change or firewall rule between the server and the device produces exactly this. The server is on the office-facing side and reachable; the device on the plant-facing side is not. Nothing in the OPC UA session gives it away.
- Device powered down or in a maintenance stateA PLC in stop, a drive powered off for a mechanical job, or a controller mid-download stops answering. This is expected during planned work and is precisely the window that must be excluded from performance figures rather than counted as production.
- Upstream OPC UA server unreachable from an aggregatorIn a chained topology the aggregating server reports this for values whose downstream server it cannot reach. Your client sees an intact session and stale values, and the real fault is one or two hops away in a system you may not be monitoring.
- Device overloaded and timing out rather than refusingA controller under heavy load or serving too many clients may fail to answer polls within the timeout without ever refusing a connection. The result is intermittent runs of this status rather than a clean outage, which is harder to spot and often blamed on the network.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Confirm the scope of the lossList which tags degraded and at what timestamp. If they all belong to one device or channel, the fault is at that device link. If they span devices, look at the server host or its network interface. This one step usually settles where to go next.
- Read the server's own connection status nodesMost gateway and PLC-facing servers expose a per-device or per-channel status object in the address space. Read it rather than inferring. Device models from companion specifications commonly carry a state or health variable next to the data, which names the condition directly.
- Check the age against your toleranceUse SourceTimestamp to decide whether this is a transient or an outage. A rule of a few sampling intervals separates a dropped poll from a real disconnection and stops noisy alarming on marginal links.
- Test the device path independentlyFrom the server host, ping or otherwise reach the device address and check the switch port counters for errors and link flaps. A rising error count on a port explains intermittent runs of this status better than anything in the OPC UA logs.
- Exclude the outage from production figuresPropagate the status so the analytics layer marks the window as no-data. A machine that appears to be running steadily because its counter is held is worse than a machine that appears to be down, because the first produces confident wrong numbers.
- Review timeout and retry settings on the server's device driverWhere the link is marginal, driver timeout, retry count and demotion behaviour decide how quickly a tag degrades and how long it stays degraded. Tune them so the status reflects reality promptly instead of oscillating.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| KEPServerEX | Device demotion and timeout settings control how quickly tags for an unresponsive device degrade and how long the server waits before retrying. The channel diagnostics show the failing device directly rather than by inference. |
| Ignition | The device connection status is visible per device in the gateway, and the tags show an uncertain quality overlay. Correlating the device status change timestamp with the tag quality change confirms the cause in seconds. |
| Siemens S7-1500 | Where the CPU itself is the server, this status usually reflects a loss between the CPU and a distributed I/O or a partner controller rather than a loss of the OPC UA link, which would fail the session instead. |
| UaExpert | Adding the server's diagnostic and device status nodes to the same Data Access View as the data tags makes the correlation visible in one window, which is the fastest manual diagnosis available. |
| asyncua (Python) | Branch on the status class in the data change callback and record the SourceTimestamp of the last Good value per node, so you can report outage duration rather than only current state. |
| OPC Publisher | The status is carried into the telemetry message, so a cloud consumer can exclude the window. Configure your downstream pipeline to treat any non-Good status as an explicit gap rather than filtering the messages out. |
What it looks like in the log
Device Line3_PLC communication failure; 214 tags now UncertainNoCommunicationLastUsableValue
ns=4;s=Line3.GoodCount held at 18422, source age 312 s
Channel Ethernet1 device 192.0.2.51 timeout, demotingConfirm the fix
Confirm every affected tag returns to Good with an advancing SourceTimestamp, then confirm the counters resumed from where they left off rather than resetting, which changes how the outage window must be handled downstream.
Stop it happening again
Monitor the server's device and channel status nodes as first-class tags, alarm on uncertain duration per device, store quality with history, and watch switch port error counters on plant-side links where intermittent runs of this status appear.
Related status codes
Concepts on this page
Stuck on more than one of these? The troubleshooting clinic works through broken configurations end to end, on camera.
Troubleshooting clinic →Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.