Alarms: a client Acknowledge/Confirm/AddComment emits no condition event (AutoReportStateChanges false + delta-gate) #587

New Issue

2026-10-07T23:51:29-04:00

dohertj2 commented

2026-10-07 23:51:29 -04:00

Found by the independent review of the #586 fix (pre-existing — reproduced identically on master 35152fca and the #586 branch).

What is wrong: a client Acknowledge (and likely Confirm / AddComment / Shelve) on a Part 9 condition emits no condition event to any subscriber.

The SDK's OnAcknowledgeCalled applies AckedState itself, but its own state-change event is gated on ConditionState.AutoReportStateChanges, which this repo never sets (false).
The engine/driver re-projection then reaches WriteAlarmCondition's delta-gate, sees the node already Acked, and suppresses the event.
Code comments asserting "SDK auto-fires its own event (E2)" (OtOpcUaNodeManager.cs ~826 and ~1286) are wrong.

Observed: Acknowledge succeeded (the audit event carried Status=True), yet no Acked=true condition event reached either an equipment-folder item or a Server-object (i=2253) item. A client that tracks alarm state from events never sees the ack transition; only ConditionRefresh shows it.

Consumer impact: any HMI that acks over OPC UA and follows events. ScadaBridge does not ack over OPC UA, so it is not directly affected.

To do:

Emit exactly one condition event per method-driven transition (Acknowledge, Confirm, AddComment, OneShotShelve/TimedShelve/Unshelve, Enable/Disable) — either enable AutoReportStateChanges and make the re-projection delta-gate not double-report, or report explicitly from the method handlers. Exactly once, both native and scripted alarms.
Keep AreEventsMonitored bookkeeping correct for Server-object-only subscribers (see #586 review finding 2) so the auto-report path actually fires.
Over-the-wire tests: a folder item and an i=2253 item each receive exactly one Acked=true event after Acknowledge; same for Confirm/AddComment/Shelve.
Fix the wrong code comments.

Found by the independent review of the #586 fix (pre-existing — reproduced identically on master `35152fca` and the #586 branch). **What is wrong:** a client **Acknowledge** (and likely Confirm / AddComment / Shelve) on a Part 9 condition emits **no condition event** to any subscriber. - The SDK's `OnAcknowledgeCalled` applies `AckedState` itself, but its own state-change event is gated on `ConditionState.AutoReportStateChanges`, which this repo never sets (false). - The engine/driver re-projection then reaches `WriteAlarmCondition`'s delta-gate, sees the node already Acked, and suppresses the event. - Code comments asserting "SDK auto-fires its own event (E2)" (`OtOpcUaNodeManager.cs` ~826 and ~1286) are wrong. **Observed:** Acknowledge succeeded (the audit event carried `Status=True`), yet no `Acked=true` condition event reached either an equipment-folder item or a Server-object (i=2253) item. A client that tracks alarm state from events never sees the ack transition; only `ConditionRefresh` shows it. **Consumer impact:** any HMI that acks over OPC UA and follows events. ScadaBridge does not ack over OPC UA, so it is not directly affected. **To do:** - [ ] Emit exactly one condition event per method-driven transition (Acknowledge, Confirm, AddComment, OneShotShelve/TimedShelve/Unshelve, Enable/Disable) — either enable `AutoReportStateChanges` and make the re-projection delta-gate not double-report, or report explicitly from the method handlers. Exactly once, both native and scripted alarms. - [ ] Keep `AreEventsMonitored` bookkeeping correct for Server-object-only subscribers (see #586 review finding 2) so the auto-report path actually fires. - [ ] Over-the-wire tests: a folder item and an i=2253 item each receive exactly one `Acked=true` event after Acknowledge; same for Confirm/AddComment/Shelve. - [ ] Fix the wrong code comments.

dohertj2 referenced this issue from a commit

2026-10-08 01:53:39 -04:00

fix(alarms,acl): one condition event per Part 9 method call; gate Server-object model-change/audit events (#587, #588)

dohertj2 referenced this issue from a commit

2026-10-08 01:53:39 -04:00

fix(alarms): native conditions support Acknowledge/AddComment only; report only real method changes (#587 review)

dohertj2 commented

2026-10-08 01:53:58 -04:00

Fixed: each successful method-driven transition reports exactly one condition event (Acknowledge, Confirm, AddComment, Enable/Disable, OneShotShelve/TimedShelve/Unshelve) for scripted alarms; native alarms support Acknowledge + AddComment only (Confirm/Shelve → BadNotSupported, no event) and stay ConfirmedState=true; no-op re-acks emit nothing; TimedShelve works over OPC UA (MaxTimeShelved). Reviewed twice (FIX-FIRST → APPROVE). Note: a scripted TimedShelve's UnshelveTime field reads ~24.8 days though the engine expires it on time (pre-existing). (merge 3803df04 on master, pushed 2026-10-08)

Fixed: each successful method-driven transition reports exactly one condition event (Acknowledge, Confirm, AddComment, Enable/Disable, OneShotShelve/TimedShelve/Unshelve) for scripted alarms; native alarms support Acknowledge + AddComment only (Confirm/Shelve → BadNotSupported, no event) and stay ConfirmedState=true; no-op re-acks emit nothing; TimedShelve works over OPC UA (MaxTimeShelved). Reviewed twice (FIX-FIRST → APPROVE). Note: a scripted TimedShelve's UnshelveTime field reads ~24.8 days though the engine expires it on time (pre-existing). (merge `3803df04` on master, pushed 2026-10-08)

dohertj2 closed this issue

2026-10-08 01:53:59 -04:00

dohertj2 referenced this issue

2026-10-08 02:31:10 -04:00

Alarms: residuals from the #587/#586 reviews #597

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dohertj2/lmxopcua#587