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.
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.