Glossary · Alarms

ConditionRefresh

ConditionRefresh is a Method on ConditionType that makes a server re-send the current state of every retained Condition to one named subscription. Call it after connecting or reconnecting, otherwise your client sees only new state changes and starts with an empty alarm list while the plant is already in alarm.

Why it exists

Conditions are stateful, but the notification channel is not a snapshot. A subscription created now receives state changes from now on. Every alarm already active, unacknowledged or otherwise retained is invisible to you until it changes again, which for a stable long-running fault may be hours. ConditionRefresh closes that gap by replaying the retained set on demand.

How to call it

It is a Method on the ConditionType, normally called on the type node itself, and it takes the SubscriptionId you want refreshed as its input argument. ConditionRefresh2 refreshes a single MonitoredItem within a subscription instead of the whole subscription. The server frames the replay between a RefreshStartEventType and a RefreshEndEventType so your client knows which events are the snapshot and which are live.

Handle the start and end markers

The correct client pattern is: on RefreshStartEventType, mark the alarm list as rebuilding; between the markers, replace list entries by ConditionId rather than appending; on RefreshEndEventType, drop any entry not seen in the replay, because the server no longer retains it. Skipping the markers produces duplicated alarm rows and stale entries that no operator can clear.

When you must call it

After the initial subscription is created, after any reconnect, and after a subscription transfer. Note that transfer is the subtle one: TransferSubscriptions can move a subscription to a new session and return GoodSubscriptionTransferred, and the alarm state your client holds may have drifted while the session was down. Refresh unconditionally on reconnect; it is cheap compared with a wrong alarm list. Tools that cannot call methods sometimes substitute periodic condition snapshot reporting, which OPC Publisher supports.

Example

Call sequence and the event markers to expect

1. CreateSubscription                    -> subscriptionId = 42
2. CreateMonitoredItems on i=2253 / EventNotifier with an EventFilter
3. Call:
     ObjectId   = ConditionType node
     MethodId   = ConditionRefresh
     InputArgs  = [ 42 ]              (UInt32 SubscriptionId)

Then on subscription 42:
     RefreshStartEventType
     ExclusiveLimitAlarmType   Tank3 HighHigh   Retain=true
     OffNormalAlarmType        Pump7 Fault      Retain=true
     AcknowledgeableConditionType  Line1 Jam    Retain=true (unacked)
     RefreshEndEventType

After RefreshEnd: any locally held alarm not replayed is no longer retained.
On reconnect or after GoodSubscriptionTransferred, call it again.
The mistake people make: Calling ConditionRefresh but ignoring RefreshStartEventType and RefreshEndEventType. Without the markers the client cannot tell replay from live traffic, so it appends duplicates and never removes conditions the server has stopped retaining. Rebuild the list between the markers, keyed on ConditionId.

Defined in: Part 9 - Alarms and Conditions.

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.

Free download
OPC UA Server Acceptance Test Pack
A 40-check acceptance test you run against a vendor's server before commissioning sign-off. Weighted scoring, three hard gates, and a one-page verdict for the supplier meeting.
Get the free test pack →
Free, no course, no login