Migration from Notifications V1 to V2

Background

Event notifications are alerts delivered to a recipient when a specified event occurs. For example, a branch manager might receive a push notification if a camera detects an object outside of business hours.

YourSix is changing how notifications are setup in the platform so they can be configured at the thing level (such as a specific barrier or peripheral) instead of only at the broader device level (e.g. a door controller or I/O module).

With the previous implementation (Notifications V1), notifications were created by subscribing to events at the device level (that is; device as the topic). For example, if a door controller reported a barrier forced open alarm, the notification would only indicate that the controller had an alarm — even if multiple barriers were connected to that controller.

In practice, it's often important to know exactly which thing triggered the event. By allowing subscriptions at the individual thing level, the new Notifications V2 provides this level of detailed granularity.

Benefits of Notifications V2

• Being able to alert on specific things instead of the entire controller.
• Being able to create alarm groups with specific things to allow disarming individual things rather than disarming the entire controller.
• Improved user experience when configuring and managing notifications.

Migration

As YourSix rolls out the new notification solution, organizations will need to migrate their existing notification rules to the new version. This means integrators or system administrators will need to recreate their current notification rules using the updated configuration process. Below is the recommended migration path and timeline for completing this transition.

WARNING

Please note that between Step 2 (removing a device from the device group) and Step 4 (creating the new notification rule), that device will not propagate events to any notification rule, meaning notifications from that device will be temporarily inactive.

Migration outline

1. Create an Alarm group schedule within the organization.
2. Remove devices from Device groups, as devices cannot belong to both a Device group and an Alarm group simultaneously.
3. Create Alarm group. See the reference article for detailed explanation on the alarm group concept.
4. Create Notification Rule using Notifications V2. See the reference article for detailed explanation on the event notifications concept.
5. Remove old Notification rules and Device groups.
6. Test notifications.

Migration timeline

Date	Milestone	Description
September 1, 2025	Notification V2 launch	Notification V2 rules and Alarm groups can now be created
September 15, 2025	Notifications V1 deprecation	Warnings will be shown when creating new Notification V1 rules and Device groups.
June 1, 2026	Notifications V1 EOL	Notification V1 rules and Device groups will be completely removed from YourSixOS. Date may be changed to an earlier date if no usage is no longer observed.

Further help

Please check out the video below

Known limitations

Notifications V2 is an important milestone in advancing YourSixOS toward our long-term vision. While the solution will continue to improve with future updates, we want to be transparent by outlining the current limitations you may encounter in this release.

Schedule limitation

In the new solution, alarm schedules are defined at the organization level, whereas in Notifications V1, each notification could have its own schedule. With V2, alarm schedules are applied to alarm groups, and things (devices, barriers, peripherals, etc.) are added to these groups. Since each thing can only belong to a single alarm group, it can only have one schedule applied at a time.

As a result, users cannot currently configure V2 to send notifications to one destination during a certain timeframe and to a different destination during another timeframe as previously configured in V1.

Example (not supported):

• Route notifications to the central station from 7:00 PM–7:00 AM
• Route notifications to a platform user from 8:00 AM–8:00 PM

As outlined above, this scenario is not supported because each alarm group can only have a single schedule applied.

For scenarios that require this type of notification setup, we recommend continuing with Notifications V1 or leveraging one of the alternative paths provided below.

Alternative 1: Simultaneous notifications

Scenario:

• Route notifications to the central station from 7:00 PM–7:00 AM
• Route notifications to a platform user all the time

How to Configure:

• Central Station notification: Use alarm schedules and alarm groups.
• Platform User notification: Create as a standalone notification not tied to an alarm group.

Alternative 2: Alarm group active filter

Notifications V2 introduces the Alarm group active filter. This option, available on the first page of the Add Notification Rule workflow, allows the system to send notifications to one destination when an alarm group is armed (active), and to another when it is disarmed (inactive).

Example Scenario:

• Route notifications to the central station from 7:00 PM–7:00 AM
• Route notifications to a platform user from 7:00 AM–7:00 PM

Because these schedules do not overlap, the Alarm group active filter can be used to achieve this configuration.

Configuration steps

1. Create an Alarm Schedule: 7:00 PM–7:00 AM
2. Create an Alarm Group: Apply the schedule from Step 1

Notification rule #1 (Central station):

• Alarm group active filter: True (Active)
• Scope: Use the created Alarm group
• Recipient: Central station

Notification rule #2 (Platform user):

• Alarm group active filter: False (Inactive)
• Scope: Use the created Alarm group
• Recipient: Platform user

WARNING

If the system is armed during the 7:00 PM–7:00 AM schedule (sending notifications to the central station), and a user manually disarms it via the platform, alerts will immediately begin flowing to the user instead (because it is now in a disarmed/inactive state).

Notifications will continue to route to the user until the system is manually placed back into an armed or scheduled state.