What is Condition in OPC UA?

Glossary · Alarms

Condition

In OPC UA, a Condition is a stateful event: an object of ConditionType, or a subtype such as AlarmConditionType, whose current state the server retains and can re-report, unlike a fire-and-forget event. Part 9 defines the hierarchy ConditionType, AcknowledgeableConditionType, AlarmConditionType, plus limit, discrete, off-normal and deviation alarms.

Events versus conditions

A plain event derived from BaseEventType is a notification of something that happened, delivered once. A Condition is a node in the address space with state: EnabledState, ActiveState, AckedState, Quality, Severity, LastSeverity, Retain and Comment. When the state changes the server sends an event carrying the whole condition, which is why the same ConditionId appears repeatedly with different EventIds.

The Retain flag and why it matters

A condition with Retain true is one the server considers currently interesting: active, or unacknowledged, or otherwise still requiring attention. Retained conditions are exactly what a new client needs to receive to build an alarm list, and they are what ConditionRefresh replays. If your alarm banner is empty after a reconnect, you have not asked for the retained set.

The type hierarchy in practice

ConditionType gives you enable and comment; AcknowledgeableConditionType adds Acknowledge and Confirm; AlarmConditionType adds ActiveState, suppression and shelving. Below that sit the concrete alarms you will actually subscribe to: ExclusiveLimitAlarmType and NonExclusiveLimitAlarmType for analog limits, DiscreteAlarmType and OffNormalAlarmType for digital states, DeviationAlarmType families for setpoint deviation. Modern server implementations extend this with latched and silenced alarms, alarm groups, a suppression engine and rate metrics.

Conditions as machine semantics

For downtime analysis a condition is far more useful than a sampled boolean. It carries a timestamp, a SourceNode identifying the equipment, a Severity, a Message, and a ConditionClassId saying what class of problem it is. That is a downtime record with attribution built in, which is why the practical advice is to get reasons as events and only state as sampled values.

Example

Fields of one condition event as an alarm client sees them

EventId          0x9F2C...            (unique per state change)
EventType        ExclusiveLimitAlarmType
ConditionName    TankLevel_HighHigh
SourceNode       ns=4;s=Line1/Tank3   (the equipment, not the tag)
SourceName       Tank3
Time             2026-09-07T06:14:22.118Z   (SourceTimestamp of the change)
Severity         700
Message          "Level above HighHigh limit"
ConditionClassId i=11163              (BaseConditionClassType, if unclassified)
EnabledState     Enabled
ActiveState      Active
AckedState       Unacknowledged
Retain           true

The mistake people make: Treating conditions like plain events and building the alarm list only from live notifications. Conditions already active when you connect are never re-sent on their own, so the list starts wrong and stays wrong until the next state change. Call ConditionRefresh after every connect and reconnect.

Defined in: Part 9 - Alarms and Conditions.

Related concepts

ConditionClassId ConditionRefresh EventFilter Acknowledge / Confirm Severity Select clause / Where clause

Status codes you will meet

BadNodeIdUnknown BadInvalidState BadNotSupported

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.