Choose an Axis pulse or interval schedule for the required event behavior

Bottom line: Choose the event behavior before writing the schedule. Use an explicit test of the returned type and event state rather than accepting a calendar string solely because its times look right.

Source fact: documented behavior

Axis’s Event schedules API describes pulse schedules as stateless events with no current value, representing a single instant in time.

The pulse-specific description includes schedules with no DTEND and schedules whose DTEND equals DTSTART.

Interval schedules are stateful, with a field set to 1 within their bounds and 0 outside; DTSTART and DTEND define an interval duration and RRULE defines its recurrence.

What the source does not establish

Do not infer the required behavior from a schedule’s display name. Keep this article’s pulse-versus-window decision separate from daylight-saving policy, clock synchronization and execution guarantees. Resolve the equal-start/end case against the actual returned schedule type before using it in an operational rule; do not silently flatten it into a general presence-only test for DTEND.

Applicability questions

• Does the intended action need a momentary trigger or a condition that remains active during a window?
• Which device and software expose the documented schedule interface?
• What should the consuming rule do before, during and after the scheduled window?
• Who will approve the test calendar, observation clock and cleanup of temporary schedules?

DSE recommendation: controlled next steps

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

DSE recommends defining schedule acceptance in terms of the event consumed by the rule, as well as the saved calendar definition.

1. Write two proposed requirements in ordinary language: a single recurring reminder, and a bounded period during which a condition should remain active. Label these as test scenarios rather than site requirements. Identify the intended recipient or rule for each without enabling a production action. Choose a short authorized observation period so the exercise can include both a beginning and an end.
2. Create isolated test schedules through the supported interface and read back their definitions and reported types. Compare a pulse definition without an end time, the documented equal-start/end pulse form if needed, and a nonzero interval. Keep every submitted definition beside its returned representation. If the type differs from the requirement, stop and resolve that mismatch before connecting an action.
3. Observe the proposed reminder and active-window cases with a harmless test consumer. Check the interval before its start, inside its bounds and after its end; check the pulse at its intended instant. Record unexpected repeats, missing observations or an unexplained state as unresolved. Remove temporary schedules and confirm the production rule remains on its approved configuration.

Verification and evidence

Retain the exact definitions, returned type, device/software identity and timestamped observations from the test consumer. Ask another reviewer to explain which evidence demonstrates an instant and which demonstrates a continuing condition. Require an explicit disposition for the equal-start/end case if the integration will generate it.

For a later schedule change, reuse the same acceptance cases before reconnecting operational actions. Check the saved requirement against the final definition instead of relying on the programmer’s intent. Treat this as a proposed commissioning exercise; enter real observations only after the authorized test has been performed.

Official references

• Event schedules API — Axis Communications; official VAPIX documentation.

Source review completed October 29, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.