BadMonitoredItemIdInvalid

BadLifecycle

What you actually see

ModifyMonitoredItems, SetMonitoringMode, SetTriggering or DeleteMonitoredItems returns this code for some items while other items in the same call succeed.

Why it happens

• Item ids cached across a subscription rebuildMonitored item ids are scoped to a subscription and are reissued when the subscription is recreated. Client code that stores ids in a configuration table or a long-lived dictionary, then reconnects, sends the old numbers into a new subscription. Every id is then invalid even though the nodes are fine.
• Creation failed but the client recorded the id anywayCreateMonitoredItems returns a per-item result. If an item failed with BadNodeIdUnknown or a filter error, the returned monitored item id is not usable. Client code that reads the results array positionally without checking each StatusCode records a phantom item and then fails on the first modify.
• Handle used against the wrong subscriptionWith several subscriptions on one session - which is normal once you have multiple publishing intervals - it is easy to send an item from subscription A in a request naming subscription B. The ids are small integers and often collide numerically, so the mistake produces this code rather than an obvious mismatch.
• Item already deletedA delete that succeeded, or a server-side removal when the underlying node disappeared after a model change, leaves the client with a handle to nothing. Reconfiguration code that deletes then modifies in the same pass hits this routinely.
• Client-side handle confused with server-side idEach monitored item has a client handle you choose and a server-assigned monitored item id. Passing the client handle where the service expects the server id is a common wiring bug in hand-rolled clients and produces this code for every item.

How to fix it

In diagnostic order: work down, do not skip ahead.

1. Check every per-item result from CreateMonitoredItemsWalk the results array and pair each StatusCode with the request you sent. Only store the monitored item id where the status is Good. Log the failures with the NodeId so you can see which items never existed rather than discovering it later on a modify.
2. Rebuild the local handle map whenever the subscription is rebuiltMake the id map a child of the subscription object so it cannot outlive it. On reconnect or recreate, discard the map and repopulate it from the fresh CreateMonitoredItems results. Never write these ids to persistent configuration.
3. Separate client handle from server id in your data structuresKeep both, name them distinctly, and use the server id only in service calls. Route incoming notifications by client handle, which is what the notification carries, and use the server id for ModifyMonitoredItems, SetMonitoringMode, SetTriggering and delete.
4. Verify you are naming the right subscriptionLog subscription id and item id together on every modify. Where a client holds many subscriptions because it has many publishing intervals, an index off by one in your subscription list is a more likely explanation than anything server-side.
5. Recreate rather than modify when in doubtDeleting and recreating an item is cheap compared with debugging a stale handle. Where a modify returns this code for a node you know exists, drop the local entry and create the item again, then confirm the new id arrives Good.

Where it shows up, by tool and stack

What it looks like in the log

SetMonitoringMode: item 217 in subscription 3 returned BadMonitoredItemIdInvalid
CreateMonitoredItems: 4 of 512 items failed; ids not recorded
ModifyMonitoredItems failed for cached handle 91 after subscription rebuild

Confirm the fix

Re-issue the same modify or delete after rebuilding the map and confirm every per-item status is Good, then confirm the affected nodes resume reporting notifications at the expected interval.

Stop it happening again

Scope monitored item ids strictly to the lifetime of their subscription object, never persist them, and make per-item result checking mandatory in the code path that records handles so a failed creation can never enter the map.

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.