-
Notifications
You must be signed in to change notification settings - Fork 1
Alert Lifecycle
The lifecycle of an alert object is ruled by the schematic below:
This is the "off" state of the alert: no alert is raised, no sensor is in prealert state. This state continues until an enabled sensor gets triggered and moves the alert to Started.
This state corresponds to the initialization of the alert. It is entered when the first sensor is triggered and is running its prealert phase. During this phase, the alert is cancelable by switching to a mode in which the sensor is no more enabled.
This state ends when:
- a sensor reaches the end of its prealert phase. In that case, the alert switches to the Active status and all other sensors that were in prealert are joining the alert.
- mode is changed to a mode that does not enable any of the sensors currently in "prealert". The new status is then Stopped.
Note that other sensors may be triggered while the alert is in its started state. In that case, no alert status change occur and no event is raised. But depending on their respective prealertDuration those additional sensors may shorten the prealert phase because this status is reached when the first sensor reaches the end of its prealert.
This state is the true alert phase. The activated event is likely to be the best to implement the actions to do when the alert really takes place (trigger a siren, make lights blink, etc). When the alert gets active, all sensors that were in prealert leave their prealert state immediately to join the alert. In other words, the first sensor that enters alert make all other sensors join the alert.
During this phase, if a sensor is released and triggered again, it resets its alert timer, keeping the alert active.
This state ends when one of the following events occur:
- all sensors have reached the end of their alert phase, should they be released or triggered.
- the "persistent alert" feature is available and the persistent alert object has been switched off by an external source in Linknx (from a supervisor, from an external script that interacts with Linknx, from a physical device of the installation...)
For simplification reasons, the schematics only shows the sensor joined and sensor left events that surround the Activated status. But bear in mind that those events may be repeated if additional sensors join or leave the alert while the alert is already active. For instance, if an additional sensor gets triggered, a sensor joined event is raised to notify that. As a consequence, these events are not the right ones to implement actions that are expected to be executed only once per alert activation. Use activated and deactivated for that.
The Next state is one of:
- Paused if the persistent alert feature is available and the persistent alert object has not been switched off during the Active state.
- Stopped if the persistent alert feature is unavailable or if the persistent alert object has been switched off during Alert.
This state corresponds to a sleeping state of the alert, meaning that it has been fired, has been active for some time and is now in a standby mode because no sensor has been triggered for a while.
Note that the persistence alert feature must be available -i.e the persistenceObjectId attribute of the alert must be set to a valid Linknx object- for the Paused status to be usable. Otherwise, the alert would jump directly from Active to Stopped.
It ends when:
- a sensor gets triggered again. In that case, the alert is resumed and becomes active immediately. There is no initialization phase like during the Started status.
- the persistent alert object is switched off, which has the effect to stop the alert.
This event is fired when the alert was in the Stopped state and any of its related sensor gets triggered. This represents the beginning of the prealert phase, which lasts until a sensor reaches the end of its prealert delay.
This event is fired when the alert was in the Started state and is switched to Stopped before it could become active (i.e before the end of sensors' prealert phase). The only way to abort an alert while it is initializing is to change for a mode that does not involve any of the sensors in prealert. It is not to be confused with the reset event.
Those two events represent respectively the beginning and the end of the "true" alert phase. They are very likely to be the best ones to use to perform actions such like firing a siren or making lights blink.
Those two events are fired whenever a sensor respectively participates or leaves the current alert phase. Between those events, the sensor is active and therefore maintains the alert active. Those events do not necessarily indicate that the alert is becoming active / inactive as they are fired everytime a sensor enters or leaves the true alert phase. The alert becomes active when the first sensor joins and remains so until the last sensor leaves.
Those events are triggered only once if a set of sensors simultaneously join or leave the alert.
These events are raised whenever the alert respectively enters the Paused or Stopped statuses.
This event is raised when the alert stopped after it has been active at least once.
This event indicates that the alert is waking up after having been Paused.