Keep Axis casing and window tamper events distinct

Bottom line: Keep the two event types and their reported sources separate. An alert should let an operator identify the condition and affected component before deciding what inspection is required.

Source fact: documented behavior

The Open Casing and Faulty Front Window describes separate events for an opened device casing and a front window that has been removed, vandalized or otherwise malfunctioned.

The casing event uses an Open state, while the window event uses Faulty; each description assigns one to its active condition and zero to an inactive event.

Both declarations include a Name source item for the affected device, with source examples distinguishing a camera or junction box from a housing.

What the source does not establish

This article defines an alert-mapping review, not a universal tamper detector or confirmation of vandalism. Check supported event declarations on the actual device. Keep a reported event, the physical inspection and any incident conclusion as separate evidence, and avoid an unsafe physical exercise merely to activate an alarm.

Applicability questions

• Which of the two event types does the actual device expose?
• What source Name does each supported declaration report?
• Does the consumer preserve both event identity and active or inactive state?
• Who can authorize a safe inspection or test arrangement?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends separate mapping entries for event type, source name and state before enabling an operational tamper alert.

1. Retrieve the actual supported declarations through the documented event workflow and preserve the relevant source and state fields. Match each declaration to the installed camera, housing or other reported component with the equipment owner. Do not assign the example source names to every product or rename all incoming messages to a single undifferentiated tamper flag.
2. Write the receiving application’s intended mapping without changing the device. Use proposed message fixtures for an active casing state, an inactive casing state and an active faulty-window state. Ask the reviewer to identify which event and component each fixture represents. Preserve unexpected names for investigation rather than silently redirecting them to a familiar camera record.
3. Review the operational response with the responsible owner. Keep the initial task limited to checking the reported condition and equipment identity. Where an actual supported test is authorized, use an attended procedure suitable for that product and stop if it would expose wiring, damage seals or create an unsafe condition. Keep physical intervention separate from the consumer mapping exercise.

Verification and evidence

Proposed verification: feed the approved nonproduction fixtures through the receiving workflow and compare the resulting alert labels and retained state values. Confirm that an inactive observation is not displayed as a new active condition and that the two event types remain distinguishable in the operator record. Record actual outcomes without substituting an expected result.

Have another reviewer trace each alert back to its declared source and original state. Retain sanitized message evidence and the mapping version. Mark unsupported events and untested equipment explicitly. No casing was opened, front window disturbed or live tamper event generated for this article.

Official references

• Open Casing and Faulty Front Window — Axis Communications; official VAPIX documentation.

Source review completed October 30, 2026. Recheck the official source and deployment-specific applicability before changing production settings.