BadNotReadable
BadAccess level
BadNotReadable means the node's AccessLevel or UserAccessLevel withholds the CurrentRead bit, so neither Read nor a data-change subscription will return a value. Check UserAccessLevel against AccessLevel: a write-only command node is denied by design, an anonymous session is denied by policy.
What you actually see
Browsing shows the node and its attributes fine, but every Read of the Value attribute and every attempt to add it to a subscription returns BadNotReadable.
Why it happens
- Write-only node by designSome models expose command or setpoint nodes with CurrentWrite but not CurrentRead, so a client cannot read back what was commanded. This is deliberate in models where the value has no meaningful readback, and it means subscribing to the node is impossible, not just inconvenient.
- Anonymous session denied read accessUserAccessLevel filters AccessLevel by identity. A server that exposes its address space anonymously but gates values behind a named user returns Good on Browse and BadNotReadable on Read. Browsing succeeding is what makes this confusing.
- Role permissions deny Read at the node or its parentPart 18 RolePermissions can withhold the Read permission independently of AccessLevel. Because permissions are commonly set on a containing Object, an entire branch can become unreadable at once while the folder structure stays visible.
- Security-sensitive node deliberately gatedCertificate stores, user credential nodes and some diagnostic nodes are readable only on a session with a sufficient security mode or a specific role. Connecting on a None security policy endpoint will fail these reads even with a valid user.
- Subscription created against a non-readable nodeCreateMonitoredItems evaluates read access at creation time. The service call itself succeeds while the per-item status is BadNotReadable, so a client that only checks the service-level result thinks the subscription is healthy and simply never receives that item.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Read AccessLevel and UserAccessLevelIf AccessLevel lacks CurrentRead the node is write-only in the model and no credential will change that. If AccessLevel has it and UserAccessLevel does not, the session identity is the problem.
- Reconnect with a named identity on a secured endpointMove from an anonymous token to a username identity token, and from a None security policy to a signed or signed-and-encrypted endpoint. Some servers only grant read permissions on secured channels, so changing the identity alone is not enough.
- Check per-item status on CreateMonitoredItems, not just the service resultIterate the results array and log every item whose StatusCode is bad. An item created with BadNotReadable stays in the subscription doing nothing, so this is the only place the failure is visible.
- Inspect role permissions on the node and its ancestorsRead RolePermissions and UserRolePermissions where exposed, and walk up the hierarchy. A deny inherited from a parent Object is the usual explanation for a whole folder becoming unreadable after a security configuration change.
- Confirm the node is meant to be read at allBrowse to its type definition. A companion-specification method input or a command node may have no readable state by design, in which case the integration should be reading a separate status variable instead.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UaExpert | The Attributes pane decodes AccessLevel and UserAccessLevel side by side. If a node added to the Data Access View shows BadNotReadable in the Status column while other nodes are Good, compare those two attributes first. |
| asyncua (Python) | Read the UserAccessLevel attribute to get the effective set. When creating a subscription, always log the per-item status list returned by the subscribe call - a bad creation status is otherwise silent. |
| node-opcua | createMonitoredItems returns a results array with a per-item statusCode. The monitored item emits an error event for a bad creation status; without a handler on that event the failure is invisible. |
| UA-.NETStandard (C#) | After Subscription.ApplyChanges, check MonitoredItem.Status.Error on each item. Items that failed to create remain in the collection and never raise a notification, which reads as a data problem rather than a permissions problem. |
| Prosys | The client shows per-item status in the subscription view. Adding a write-only node produces an item that stays in a bad state rather than being rejected outright, which mirrors the server behaviour. |
| Ignition | A tag bound to a non-readable OPC item shows a bad quality overlay permanently. Changing the device connection to a user with read rights, rather than editing the tag, is the fix. |
What it looks like in the log
Read ns=4;s=Command.Start returned BadNotReadable
CreateMonitoredItems: 1 of 40 items returned BadNotReadable, subscription created anyway
UserAccessLevel=CurrentWrite for anonymous session on ns=4;s=Command.StartConfirm the fix
Read the node on the corrected session and confirm a Good status, then check that a monitored item on the same node produces at least the initial value the server always sends when an item is added.
Stop it happening again
Validate every configured node with a single Read at commissioning time and fail the deployment on any bad status, rather than discovering unreadable items when a dashboard stays blank. Keep the collector's identity and security mode identical between test and production.
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.