OPQ Data Architecture

This is a working document which explains our data architecture between OPQView and OPQHub.

Data from our backend (OPQHub) is generally going to be noisy and non-intuitive for the average user. The backend is responsible for creating digestible data products for the front end to consume. The following is a list of data objects and roles we see playing a part in our data design between these two components.

OPQView DB Model BoxEventType (enum type)

• temp interruption
• sag / under-voltage
• swell / overvoltage
• transient / impulse / spike
• notch
• noise
• harmonic

Group

• Some sort of composite collections of boxes
• Recursively layered
• Group level access control vs box level access group
• Group level events

GridEventType

• long-term outage

BoxEvent

• access modifier?
• timestamp
• Box
• duration
• BoxEventType
• value
• data

Box

• id
• createdOn
• secretKey
• location (lat/lng)
• access modifier
• last seen
• BoxEvents

BoxMessage

• id
• deviceId
• timestamp
• message
• active

GridEvent

• id
• BoxEvents
• GridEventType

User

• auth (What's the best way of doing this? where does this get stored)
• createdOn
• e-mail
• slack endpoint
• owned OPQBoxes
• subscribed OBQBoxes