Overview

The Alerts Interface exposes directives and events that are used to set, manage and cancel timers and alarms. While AVS sends directives to your client to set and manage timers and alarms, ultimately, your client must implement the logic necessary to manage timers and alarms if internet connectivity is lost or if the on-product clock is out of sync with NTP. 

This document covers the following topics:

• Alerts State Diagram
• Alerts Directives and Events

State Diagram

The following diagram illustrates state changes driven by the Alerts component. Boxes represent Alerts states and connectors indicate transitions.

Alerts supports the following states:

IDLE: Prior to a previously set alert going off, the Alerts component should be in the idle state. Alerts should also return to an idle state once an alert is stopped/finished. This can occur as the result of user speech, a physical button press, or GUI affordance.

FOREGROUND ALERT: Assuming an on-client alert has already been set, Alerts should transition from the idle state to the alert foreground state when an alert starts and the AlertStarted event is sent to the Alexa Voice Service.

This is only true if the Alerts channel is in the foreground, which implies the Dialog channel is inactive. For more information on channels and channel prioritization,

When an alert is stopped via speech, button press, or GUI affordance, the Alerts component should transition from the alert foreground state to the idle state.

If the Dialog channel becomes active while an alert is going off, your Alerts component should transition from the foreground alert state to the background alert state as long as the Dialog channel is active. When the Dialog channel becomes inactive, it should return to the foreground alert state until it is stopped/finished.

BACKGROUND ALERT: The Alerts component should only transition to the background alert state when the Dialog channel is active. For more information on channels and channel prioritization