Notifications

Event notifications are messages sent to a recipient when an event of interest has occurred. An example is to send a push notification to the branch manager whenever there's an object detected by a camera outside office hours.

Notification recipients

User

Users may choose to receive notifications either via mobile push notifications or via email. They find these settings under their account settings, located in the top-right corner of the web application.

Organization webhook

An organization webhook is a recipient that sends HTTP requests to a third-party system. This can be utilized to build event-driven integrations with YourSixOS.

Webhooks are sent using HTTPS POST, and with the event serialized as JSON in request data. The JSON schema is completely derived from the event structure and examples of each event are available in the event catalog. For more details on how the webhooks are sent, review the dataflows.

Organization webhooks are defined on- and global to the organization.

Organization email

An organization email is a recipient that sends human readable emails to a shared email, typically a distribution list, a Microsoft Teams-channel or a ticketing system. In many ways used for the same reasons as a webhook, but in human-readable format delivered over SMTP.

Organization emails are defined on- and global to the organization.

Central station

The central station is a special kind of recipient. If an integrator has been authorized to work with a central station, an administrator can select that central station to receive notifications from YourSixOS.

Be aware that the integrator needs to authorize the central station to access individual sites before the central station will receive any notifications.

Notification rules

In order to receive a notification upon relevant events, an administrator needs to set up a notification rule to subscribe to relevant events. A notification rule consists of four components:

• Event selection: what events from which topics are you subscribing to?
• Scope matchers: inclusion based on attributes
• Filter matchers: exclusion based on attributes
• Recipients: who should receive a notifications for the filtered selection?

Event selection

The first component of a notification rule is the event selection. This is simply a set of event types the rule should subscribe to. Event types are categorized by their respective topics.

For information on available events, see the event catalog.

Attribute matchers

An attribute matcher is a function that compares the value of an attribute of an event with the value selected with the matcher. The user interface typically shows the name of various resources (e.g. a site name), but the matched attribute is the ID of that resource (e.g. the site id).

Two kinds of matchers exist: scope matchers and filter matchers.

Scope matchers

Available scope matchers include:

• Site: siteId
• Alarm group: groupId
• Device: deviceId
• Barrier: barrierId

A scope matcher's function is easy to understand: if an event's data model has the attribute matched by the matcher, the rule will pass through the event to the filter matchers.

In order to know what attributes an event has, check the event catalog. If an event has deviceId as an attribute, one can use the Device matcher to match that event.

WARNING

Scope matchers are combined using OR-logics; the more scope matchers you include on the rule, the wider the scope is.

Filter matchers

Available filter matchers include:

• Group active: groupActive
• Access point direction: accessPointDirection

A filter matcher's function is easy to understand: if an event's data model has the attribute by the matcher, the rule will pass through the event to the recipient.

In order to know what attributes an event has, check the event catalog. If an event has deviceId as an attribute, one can use the Device matcher to match that event.

WARNING

Filter matchers are combined using AND-logics; the more filter matchers you include on the rule, the narrower the filter is.

INFO

If the matched attribute is not available on an event, the rule will not perform the matcher's logic, and the rule will pass the event through.

Example: if matching for access point direction on a device disconnected event, the event will be passed through because the device disconnected event does not have the accessPointDirection attribute.

Recipients

The third component of a notification rule is the recipient selection. The recipient selection is simply a list of recipients that should receive a notification whenever the rule is passing through an event.

See the list of recipients for more information on recipient types.

Further explanation

Group active filter matcher

The groupActive filter matcher requires further explanation. If an alarm group is either forcefully armed or within its schedule, the alarm group is considered active. In other words: the group is armed; manually by user or automatically by schedule.

If you're only interested in receiving events from devices and things whenever their parent group is armed, select the events of interest, add the scope matchers for the resources of interest and add the Group Active filter matcher.