Atria - Data Verification, Notifications, and User Profiles

We are targeting 3 scopes of work in tandem.

User Profiles with accessibility Settings

https://milviangroup.atlassian.net/browse/AS-8

User-Selected Notification Emails & In-App Notifications

https://milviangroup.atlassian.net/browse/AS-10

This will involve developing a system of Chimes that can be assigned to a user. Each User can have many Chimes.

A Chime can be set for a ChimeType such as a “Site”, a “Sensor”, a “Gateway”, a “User” or an “Admin”. (Admin will be to solve issues like this ticket: https://milviangroup.atlassian.net/browse/AS-38 )

Chimes can monitor things like Battery Health (before they die, when they’re low) or Sensor Data (See Generic Data Validation). We should define what specifically is useful to add into a Clause.

These Chimes will each add a Clause to an email, or in-app NotificationBoard Page, to send fewer emails.

We should be able to toggle notifications to email or not by the Profile Page NotificationsBoard.

Be able to snooze notifications from Atria or per notification.

We might be able to Leverage a Logging System from AWS for these Clauses. Maybe read/pull from CloudWatch?

Generic Data Verification with an extensible setup in-platform.

https://milviangroup.atlassian.net/browse/AS-9

This will check that data is reaching key-points in the LoRaWAN infrastructure, while also checking for data consistency, reliability, and sensibility. This includes data that seems unlikely, is impossible, or may have been captured due to a misconfigured device.

If data stops, what were the last bits of information before the data stopped.

These criteria will be defined as part of the scope of work.

Timestream is the first place to check as a sanity check.

This data, once discovered to be misconfigured or data is down, or the device is dead, can send out a notification to users with a “Chime” that includes that device.