EnergyAI Configuration options

👍

It is essential to agree on the specific set of notifications and configuration options that will be available. EnergyAI supports a variety of notifications, but the exact selection and configurations must be established in advance between NET2GRID and the Customer.

Examples with different notifications & configuration options below:

• Battery level alert can be triggered as PUSH notification and as long as it doesn't get resolved it gets repeated every day during working hours, and
• Device offline - OL001.1 can be triggered both as PUSH and as an EMAIL notification and is sent immediately once received.

Supported Notifications

The customer needs to select which notifications will be utilized by the application, from the Supported Notifications.

Supported Channels

• email: notifications will be delivered to the email address of the user.
• PUSH: notifications will be delivered as a mobile PUSH notification to the user.
• inbox: notifications will be delivered to the in-app inbox of the user.
• REST API: notifications will be sent directly to the customer's REST API to be managed accordingly. More information can be found here

📘

Users can enable or disable notifications on specific channels. Detailed information on managing channels can be found in the next section.

Category/topics

Topics is an optional configuration and a way to categorize notifications so that they can be muted/unmuted independently from other notifications. For example, if a topic is setup for energy usage related notifications, the customer can give the ability to end-users to switch off all energy usage related notifications, while other notifications remain enabled.

Other configuration options

For each notification that will be enabled there are additional optional configurations that can be used to further tailor the notifications.

Delay rules

Delay rules allow customers to delay the dispatching of notifications until the configured requirements are met. The following delay rules are supported:

• Send notifications during daytime period (the daytime period is configurable and applies to EnergyAI)
• Send notifications after a predefined fixed timespan.
• Send notifications at the start of a month.

The configuration of delay rules are optional. By default no delay rules are configured and notifications are dispatched as soon as they are triggered.

Follow ups

The follow up action allows scheduling another notification after a fixed timespan. This can be used for sending repetitive notifications.

Follow up rules are optional and are not configured by default.

Suppressors

Suppressors can be used as an additional constraint on whether a notification should be sent or not. Supported suppression rules are:

• Notifications present only once in the recipient's inbox. This means that if a notification of the same type already exists (and not yet deleted) in the recipient's inbox a new notification will not be delivered.
• Notification sent only if triggered at the start of a month. Meaning notifications are only delivered to the recipient if they are triggered by the Insight during the first or second day of the month.

Suppression rules are also optional and are disabled by default.

The diagram below gives an overview of how notifications are treated based on the various clauses:

Customer prerequisites

PUSH Notifications

🚧

For PUSH notifications, the following information is required from the Customer/App developers in order for NET2GRID to setup push notifications for each app:

1. Google API key for Android applications
2. TLS certificate for iOS applications. The certificate needs to be in .p12 format and the private key needs to be provided (if setup)

Once the setup is complete, NET2GRID will provide to the customer the app_identifier that can be used to trigger notifications in the relevant app.

Email Notifications

Email notifications can either be sent with the generic and default templates or can be customized accordingly to fit the customers' needs (e.g., brand, personalization etc.).

High level overview

A high-level Architectural overview below: