BadNotConnected
BadUnderlying device
BadNotConnected means the node exists in the address space but has never been wired to a source. It is a configuration state, not a runtime failure: a tag defined without an item path, an alias never bound, or a placeholder node in a model. Fix it in the server configuration, not in the client.
What you actually see
A node browses normally and has a sensible DisplayName and DataType, but every read returns a bad status and no value has ever arrived - not even once at startup.
Why it happens
- Tag created without a source addressIn a gateway or configurable server, a tag can be added to the address space with a name and a data type before its device item path is filled in. It browses and subscribes cleanly and never produces a value, which makes it look like a communication problem rather than an unfinished configuration.
- Model instance created from a type without binding its variablesInstantiating an ObjectType creates every mandatory variable declared by the type. If the server implementation does not bind those variables to real data, they stay unconnected. Companion-specification implementations that are only partly complete look exactly like this.
- Alias or reference to another variable never resolvedWhere a variable is defined to take its value from another node, and the link was never configured or points at something that no longer exists, the variable has no source. Nothing in the address space shows the missing link, only the status.
- Imported NodeSet without a data binding layerLoading a NodeSet2 file gives you the full structure of a model with default or absent values. Unless the server implementation also binds each variable to a data source, the structure is present and the data is not.
- Device or channel deleted while the tag remainedRemoving a device from a gateway configuration without removing the tags that referenced it leaves orphaned nodes. They persist in the address space with no source behind them.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Confirm the node has never had a valueRead the node and look at the timestamps. A node that never connected typically returns no SourceTimestamp or an epoch value, where a node that lost communication carries the timestamp of its last good value. That distinction separates this code from a link failure.
- Open the server configuration and inspect the tag definitionLook for an empty address, item path or source binding on that specific tag. This is a configuration-tool task; nothing you do from the client will populate a source that was never entered.
- Compare against a working sibling nodeFind a neighbouring tag that does return data and compare their definitions field by field. The difference is usually a single empty field or a mistyped item path.
- For model-based servers, check whether the implementation binds the variableA mandatory variable required by a companion specification may exist purely to satisfy the model. Ask the vendor which nodes of the model are actually populated - partial implementation of companion specifications is common and legitimate.
- Remove orphaned nodes rather than leaving them badNodes that will never be connected should be deleted from the configuration. Leaving them creates permanent bad-quality noise that trains operators to ignore quality overlays.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| KEPServerEX | A tag with an empty or invalid address shows in the project as configured but produces no data. The address validation in the tag editor catches most of these at configuration time if you use it. |
| Ignition | An OPC tag whose OPC item path points at nothing shows a bad quality that never clears. Compare the item path against a browse of the live server rather than against the original design document. |
| UaExpert | Add the node to the Data Access View and look at the Timestamp columns as well as Status. Empty timestamps with a bad status strongly suggest a node that was never connected to anything. |
| asyncua (Python) | When building a server, a Variable added with add_variable holds whatever initial value you gave it. If you intended it to be driven by external data and never wired the write path, clients see a stale or absent value rather than an error - decide deliberately which behaviour you want. |
| node-opcua | Server-side variables bound with a getter produce live values; variables added without one keep their initial value forever. An unbound variable in a hand-built model is the server-side equivalent of this status. |
| OPC Publisher | A published node that never yields a value logs a bad status at monitored item creation or on the first publish. Treat it as a configuration defect to fix before deployment rather than a runtime condition to tolerate. |
What it looks like in the log
Read ns=2;s=Line2.Spare01 returned BadNotConnected
Tag has no source address configured; value will never update
MonitoredItem created, initial value status BadNotConnectedConfirm the fix
Bind the source, then confirm the node returns a value with a SourceTimestamp that advances. A single value with a fixed timestamp means the node was given a constant, not a live source.
Stop it happening again
Validate the whole tag list at commissioning with one Read per node and fail on any bad status, and delete placeholder nodes rather than shipping them. For model-driven servers, document which parts of the model are actually populated.
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.