Asterisk ARI device state is stuck, missing or wrong

Freeze one transition and every state layer

Choose one authorized transition and preserve timestamp and timezone, Asterisk version, loaded modules, ARI application and WebSocket, logical device name and encoded path, prior and requested values, update response, explicit read-back, application subscription state, received events, mapped hint, extension state, NOTIFY or application consumer and final display or routing decision.

Classify the symptom: the write is rejected, the resource reads the old value, the value changes but no event arrives, the event arrives with the wrong resource, the hint disagrees, a NOTIFY is absent or the downstream application or lamp shows another state.

Prove that ARI owns the named resource

List ARI-controlled device states and compare the exact case-sensitive name. The list is not every Asterisk provider. If the name belongs to PJSIP, ConfBridge or another module-owned provider, do not force it into the ARI collection or shadow it with a similar spelling.

Retain 404 for a missing name and 409 for an uncontrolled device on update or delete. Correct the resource owner and application namespace rather than retrying an operation that Asterisk rejected by design.

Compare the write with an immediate explicit read

Record the PUT value and response, then GET the same encoded name. Use only the documented write values; preserve UNKNOWN as an observed model state rather than sending it as an undocumented update. Confirm that a later writer, startup reconciler or dialplan action did not overwrite the value between those operations.

If the read-back is already wrong, stay with naming, ownership, value validation or competing writers. If the read-back is correct, stop changing the resource and move to event delivery and the consumer.

Reconcile the event subscription and WebSocket

Inspect the current ARI application and confirm a subscription to deviceState:{deviceName}. Resolve 400, 404 or 422 against the missing parameter, application or event source. Confirm the event WebSocket remained attached to the same application and preserve application replacement, reconnect or filtering evidence.

Match DeviceStateChanged by application, timestamp and DeviceState name, not by state value alone. If another device changed to BUSY at the same time, that event is not a substitute. Re-establish only the missing bounded subscription instead of enabling every event globally.

Follow the hint, NOTIFY or application consumer

If ARI reads and events are correct, inspect the exact hint context and every device joined in its aggregate. A second provider can keep an extension busy after the custom resource returns idle. Then trace the accepted SIP subscription and NOTIFY body or the application rule that consumes the state.

Use the BLF diagnostic when the fault has crossed into hint or phone notification. A repaired lamp does not prove registration, qualification, queue eligibility or call completion, and an ARI value should not be changed merely to force a preferred colour.

Handle restart, concurrency and deletion explicitly

Identify every process allowed to write the resource and compare timestamps, desired-state version and restart history. Reconcile once from an authoritative store rather than replaying a stale cached value. If the resource should survive application restart, define how it is recreated and how consumers behave before restoration.

Delete only an application-owned resource whose lifecycle has ended. Confirm that hints and consumers tolerate its absence and that the application is not still subscribed or scheduled to rewrite it. An accepted DELETE is resource cleanup, not proof that a downstream lamp or route reset.

Correct one owner and retest the complete chain

Change only the demonstrated owner: resource name, ARI versus provider ownership, accepted value, competing writer, application subscription, event filter, WebSocket, hint mapping, SIP subscription or consumer logic. Repeat one transition plus a nearby control and retain update, read, event and consumer evidence.

Remove temporary event and SIP traces, restrict credentials and redact operational identifiers according to policy. No host, device state, hint, subscription, endpoint, display, routing decision or call was inspected or tested for this diagnostic.

Check whether the state actually arrived through AMI

The AMI device-state diagnostic distinguishes an ARI-owned resource from a remote AMI synchronization path before correcting either one.