{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/choose-an-axis-pulse-or-interval-schedule-for-the-required-event-behavior/", "item": { "id": "https://update.dsesecurity.com/updates/choose-an-axis-pulse-or-interval-schedule-for-the-required-event-behavior/", "slug": "choose-an-axis-pulse-or-interval-schedule-for-the-required-event-behavior", "url": "https://update.dsesecurity.com/updates/choose-an-axis-pulse-or-interval-schedule-for-the-required-event-behavior/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/choose-an-axis-pulse-or-interval-schedule-for-the-required-event-behavior.md", "json": "https://update.dsesecurity.com/api/v1/posts/choose-an-axis-pulse-or-interval-schedule-for-the-required-event-behavior/" }, "title": "Choose an Axis pulse or interval schedule for the required event behavior", "summary": "Choose scheduled pulses for instant triggers or interval state for an active window, and verify the returned schedule type before connecting an Axis rule.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "image": { "theme": "physical-security", "label": "Physical security", "alt": "Integrated video surveillance and controlled entry at a modern commercial facility.", "card_url": "https://update.dsesecurity.com/assets/editorial/physical-security-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/physical-security-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "video-surveillance", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-29T17:41:33+00:00", "modified_at": "2026-10-29T17:41:37+00:00", "reviewed_on": "2026-10-29", "reading_minutes": 3, "word_count": 555, "potentially_affected": "Axis products exposing the documented Event schedules API interface; confirm actual device, hardware and software applicability before applying the proposed checks.", "dse_recommendation": "DSE recommends defining schedule acceptance in terms of the event consumed by the rule, as well as the saved calendar definition.", "primary_source": { "name": "Axis Communications — Event schedules API", "url": "https://developer.axis.com/vapix/device-configuration/event-schedules-api/", "published_on": null, "authority": "Axis Communications" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

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.

\n

Source fact: documented behavior

\n

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

\n

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

\n

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.

\n

What the source does not establish

\n

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.

\n

Applicability questions

\n\n

DSE recommendation: controlled next steps

\n

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

\n

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

\n
    \n
  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. \n
  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. \n
  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.
    4. \n
\n

Verification and evidence

\n

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.

\n

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.

\n

Official references

\n\n

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

\n", "content_text": "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.\nSource fact: documented behavior\nAxis’s Event schedules API describes pulse schedules as stateless events with no current value, representing a single instant in time.\nThe pulse-specific description includes schedules with no DTEND and schedules whose DTEND equals DTSTART.\nInterval 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.\nWhat the source does not establish\nDo 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.\nApplicability questions\n\nDoes the intended action need a momentary trigger or a condition that remains active during a window?\nWhich device and software expose the documented schedule interface?\nWhat should the consuming rule do before, during and after the scheduled window?\nWho will approve the test calendar, observation clock and cleanup of temporary schedules?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends defining schedule acceptance in terms of the event consumed by the rule, as well as the saved calendar definition.\n\nWrite 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.\nCreate 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.\nObserve 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.\n\nVerification and evidence\nRetain 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.\nFor 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.\nOfficial references\n\nEvent schedules API — Axis Communications; official VAPIX documentation.\n\nSource review completed October 29, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.", "content_markdown": "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.\n\n## Source fact: documented behavior\n\nAxis’s [Event schedules API](https://developer.axis.com/vapix/device-configuration/event-schedules-api/) describes pulse schedules as stateless events with no current value, representing a single instant in time.\n\nThe pulse-specific description includes schedules with no DTEND and schedules whose DTEND equals DTSTART.\n\nInterval 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.\n\n## What the source does not establish\n\nDo 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.\n\n## Applicability questions\n\n- Does the intended action need a momentary trigger or a condition that remains active during a window?\n\n- Which device and software expose the documented schedule interface?\n\n- What should the consuming rule do before, during and after the scheduled window?\n\n- Who will approve the test calendar, observation clock and cleanup of temporary schedules?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE recommends defining schedule acceptance in terms of the event consumed by the rule, as well as the saved calendar definition.\n\n- 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.\n\n- 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.\n\n- 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.\n\n## Verification and evidence\n\nRetain 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.\n\nFor 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.\n\n## Official references\n\n- [Event schedules API](https://developer.axis.com/vapix/device-configuration/event-schedules-api/) — Axis Communications; official VAPIX documentation.\n\nSource review completed October 29, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/choose-an-axis-pulse-or-interval-schedule-for-the-required-event-behavior/", "url": "https://update.dsesecurity.com/updates/choose-an-axis-pulse-or-interval-schedule-for-the-required-event-behavior/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/choose-an-axis-pulse-or-interval-schedule-for-the-required-event-behavior/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "IT", "item": "https://update.dsesecurity.com/topic/it/" }, { "@type": "ListItem", "position": 3, "name": "Choose an Axis pulse or interval schedule for the required event behavior", "item": "https://update.dsesecurity.com/updates/choose-an-axis-pulse-or-interval-schedule-for-the-required-event-behavior/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/choose-an-axis-pulse-or-interval-schedule-for-the-required-event-behavior/#article", "identifier": "https://update.dsesecurity.com/updates/choose-an-axis-pulse-or-interval-schedule-for-the-required-event-behavior/", "url": "https://update.dsesecurity.com/updates/choose-an-axis-pulse-or-interval-schedule-for-the-required-event-behavior/", "headline": "Choose an Axis pulse or interval schedule for the required event behavior", "description": "Choose scheduled pulses for instant triggers or interval state for an active window, and verify the returned schedule type before connecting an Axis rule.", "abstract": "Choose scheduled pulses for instant triggers or interval state for an active window, and verify the returned schedule type before connecting an Axis rule.", "articleBody": "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.\nSource fact: documented behavior\nAxis’s Event schedules API describes pulse schedules as stateless events with no current value, representing a single instant in time.\nThe pulse-specific description includes schedules with no DTEND and schedules whose DTEND equals DTSTART.\nInterval 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.\nWhat the source does not establish\nDo 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.\nApplicability questions\n\nDoes the intended action need a momentary trigger or a condition that remains active during a window?\nWhich device and software expose the documented schedule interface?\nWhat should the consuming rule do before, during and after the scheduled window?\nWho will approve the test calendar, observation clock and cleanup of temporary schedules?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends defining schedule acceptance in terms of the event consumed by the rule, as well as the saved calendar definition.\n\nWrite 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.\nCreate 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.\nObserve 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.\n\nVerification and evidence\nRetain 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.\nFor 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.\nOfficial references\n\nEvent schedules API — Axis Communications; official VAPIX documentation.\n\nSource review completed October 29, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.", "datePublished": "2026-10-29T17:41:33+00:00", "dateModified": "2026-10-29T17:41:37+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/choose-an-axis-pulse-or-interval-schedule-for-the-required-event-behavior/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/choose-an-axis-pulse-or-interval-schedule-for-the-required-event-behavior/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Choose an Axis pulse or interval schedule for the required event behavior" }, "articleSection": [ "IT", "Video Surveillance" ], "keywords": [ "IT", "Video Surveillance", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "wordCount": 555, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Axis Communications — Event schedules API", "url": "https://developer.axis.com/vapix/device-configuration/event-schedules-api/" } } ] } }