Bad_EventIdUnknown: Client Mapping Bug, Not SDK Fault

Acknowledgement succeeds after the client passes the selected alarm's current EventId as a valid ByteString. For the affected Prosys graphical client 3.x releases, the primary branch is a client-side mapping defect, not an SDK or server fault. If another client also fails, test whether the selected event has already been replaced by a newer alarm occurrence.

Initial acknowledgement decision path

1. Reproduce the failure by selecting the current event, opening its context menu, and invoking Acknowledge. Record the complete status. The relevant failure is Bad_EventIdUnknown (0x809A0000), reported as “The specified event id is not recognized.” Do not move on until the status code is captured rather than inferred from the dialog title.
2. Read the per-argument results. In the reported case, both entries were GOOD (0x00000000). This means the call arguments passed basic argument-level validation; it does not mean that the server recognized the event instance represented by the supplied identifier.
3. Repeat the acknowledgement against the same server with a client known to preserve the event identifier correctly, such as UaExpert. If that call succeeds, follow the client-mapping branch. If it fails with the same status, follow the event-freshness branch.
4. Repeat the test using the newest event occurrence for the alarm. If the current event succeeds while an older event fails, the server has advanced to a new alarm instance and no longer recognizes the older identifier.

Event identifier integrity check

An OPC UA alarm acknowledgement targets a particular event occurrence, not merely the alarm source shown in the user interface. The server uses EventId to locate that occurrence. A null, altered, or obsolete value therefore produces Bad_EventIdUnknown even when the selected row still looks valid.

1. Capture the EventId when the event notification arrives at the client. Record its data type, null state, length, and byte content without converting it to text.
2. Capture the value immediately before the acknowledgement method call. Compare it byte for byte with the received value.
3. If the outgoing value is null or differs, stop server-side troubleshooting. Trace the client model, table-row storage, context-menu selection, and method-call conversion until the same bytes reach the call.
4. If the values match, check whether a newer event for the same alarm arrived between selection and acknowledgement. Continue with the freshness check.

A displayed alarm row is not proof that its identifier remains usable. Sorting, refreshing, or reusing a row object can separate the visible event fields from the binary identifier retained for the method call. Keep the identifier attached to the exact received event record.

Client and server isolation

The reported fault appeared with SampleConsoleServer and with a custom OPC UA server, while the common component was the Prosys OPC UA Client graphical application. That pattern points to the caller before it points to either server implementation.

1. Connect UaExpert and the affected graphical client to the same server.
2. Wait for one new alarm occurrence and select that occurrence in both clients.
3. Acknowledge it first from one client. For a clean comparison, generate another occurrence before testing the second client; acknowledgements change alarm state and can invalidate a direct second attempt.
4. If UaExpert succeeds and the Prosys graphical client returns 0x809A0000, classify the fault as client-specific. If both fail on fresh occurrences, inspect the server's event retention and method handling.

Testing two server applications is also useful. The same failure across SampleConsoleServer and a custom server reduces the probability of a server-specific implementation error. A successful independent-client test then completes the isolation.

Version 3 mapping mechanism

SDK version 3 changed the UA ByteString mapping from byte[] to a concrete ByteString class. The graphical client was not updated correctly for that change in its 3.x versions. During acknowledgement, it resolved EventId as a Null NodeId; the server consequently received no recognizable event identifier and returned Bad_EventIdUnknown.

This distinction matters when a custom application uses the SDK. The SDK type change itself is not the acknowledgement defect. Application code must store and forward the concrete ByteString without applying obsolete array assumptions or converting it through a node-identifier field.

Resolving branches

1. For the Prosys graphical client 3.x branch, use UaExpert for acknowledgement testing or install an application release containing the planned graphical-client correction. Changing the server does not repair the client conversion path.
2. For a custom SDK version 3 client, change the event-record field and method-call preparation to retain the received concrete ByteString. Remove any path that expects byte[] or resolves the event value as a NodeId.
3. For the stale-event branch, refresh the alarm view, select the newest occurrence, and invoke Acknowledge again. Do not retry a cached row after the server has published a replacement event.
4. For an unresolved server-side branch, log the received identifier at the method boundary and compare it with the identifiers currently retained by the alarm subsystem. A matching fresh identifier shifts the investigation to server event-state handling; a mismatch returns it to the client or transport-side data path.

Acceptance verification

1. Generate or wait for a new alarm occurrence and capture its EventId.
2. Acknowledge that exact occurrence from the corrected or alternate client.
3. Confirm that the method call returns a successful overall status, not merely GOOD entries in InputArgumentResults.
4. Confirm that the server reports the alarm as acknowledged.
5. Generate a second occurrence and repeat the test. Compare the newly received and transmitted identifiers byte for byte to prove that the repair handles changing event instances rather than one cached value.

FAQ