BadMonitoringModeInvalid
BadMonitoring mode
BadMonitoringModeInvalid means the MonitoringMode you asked for is not valid or not accepted for that item. The three legal values are Disabled, Sampling and Reporting. It usually means an out-of-range enum value on the wire, or a server that will not put an event item or a triggered item into the mode you chose.
What you actually see
SetMonitoringMode or CreateMonitoredItems rejects the item with this code, and the item either never reports or stays in whatever mode it already had.
Why it happens
- Value outside the three defined modesMonitoringMode has exactly three values: Disabled, Sampling and Reporting. Hand-built requests, generated code from an out-of-date model, or an integer read from a configuration file without validation can send a fourth value. The server has no choice but to reject it.
- Sampling mode requested where the server only supports Disabled and ReportingSampling means the server samples and queues but does not send notifications until something triggers the item. It exists mainly to support SetTriggering. A server with no triggering support may refuse Sampling outright rather than silently treating it as Reporting.
- Mode not meaningful for an event itemEvent monitored items are not sampled in the data-change sense. Putting an event item into Sampling produces an item that queues events nobody drains, and some servers reject the combination instead of accepting a configuration that cannot deliver.
- Mode conflicts with a triggering relationshipIn an N:M triggering set the triggering item is normally Reporting and the triggered items are Sampling. Changing a linked item's mode in a way that breaks that arrangement can be rejected, and the rejection surfaces here rather than on the SetTriggering call.
- Enum encoding mismatch across a gatewayAn aggregating server or protocol bridge that maps modes between an upstream and a downstream server can produce a value the downstream server does not recognise. This shows up as the code appearing only for items behind the gateway.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Confirm which of the three modes you are actually sendingLog the enum by name, not as an integer, at the point of the call. Disabled stops sampling entirely, Sampling samples and queues without reporting, Reporting samples and delivers. Anything else in your code path is a bug regardless of what the server says.
- Default to Reporting unless you are using triggeringReporting is the mode you want for ordinary data collection and is universally supported. Only use Sampling when the item is the target of a SetTriggering link, and only use Disabled when you deliberately want to stop sampling load at the server without deleting the item.
- Set the mode at creation and verify the per-item resultCreateMonitoredItems takes the monitoring mode directly, so you often do not need a separate SetMonitoringMode call. Check the returned status per item; a rejection there is easier to attribute than one on a later batch call.
- Test triggering support before designing around itCreate one triggering item in Reporting and one target in Sampling, call SetTriggering, and confirm both the call and a subsequent trigger event work. Server-side triggering support is uneven, and some collectors do not use it at all, so verify on the specific server rather than assuming.
- Use Disabled instead of delete for temporary suppressionWhere you want to mute an item during maintenance, Disabled keeps the item and its configuration while removing the sampling cost. This is safer than deleting and recreating, which reissues ids and invalidates your handle map.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UA-.NETStandard (C#) | MonitoredItem.MonitoringMode is the enum and takes effect on ApplyChanges. Setting it to Sampling on an item you expect data from is a common cause of an item that looks configured but never delivers. |
| node-opcua | monitoringMode is passed in the item to create and can be changed with setMonitoringMode. The enum is exported by the library; using a raw number invites exactly this error. |
| asyncua (Python) | ua.MonitoringMode.Reporting is the value you want for normal subscriptions. The high-level subscribe_data_change uses Reporting for you, so this code usually means hand-built CreateMonitoredItems parameters. |
| open62541 (C) | The monitored item request struct carries UA_MONITORINGMODE_REPORTING and friends. Triggering is supported, so Sampling is genuinely usable here, but check the response status per item. |
| UaExpert | The Data Access View creates items in Reporting. If you see this code, it is coming from your own client rather than from the tool, which is a useful way to isolate the fault. |
| OPC Publisher | It does not use server-side triggering, so items are created in Reporting. Configurations imported from a system that relied on Sampling plus triggering will behave differently here and need reviewing. |
What it looks like in the log
SetMonitoringMode(subscription=2, item=44, mode=3) -> BadMonitoringModeInvalid
CreateMonitoredItems: item ns=3;s=Motor1.Speed rejected, BadMonitoringModeInvalid
Monitoring mode Sampling not accepted for event item on ns=0;i=2253Confirm the fix
Re-issue the call with Reporting and confirm the per-item status is Good and that notifications arrive within one or two publishing intervals; for a triggered design, confirm the target item reports only after the triggering item fires.
Stop it happening again
Use the SDK's named enum rather than integers, validate any mode read from configuration against the three legal values, and standardise on Reporting for collection items so Sampling only appears where a verified triggering relationship needs it.
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.