Flux

bringing balance to power.

Explore Flux

Overview

In September 2020, I was selected as one of eight students across the United States to work in BitCamp Serverless. After working with Microsoft engineers to learn about serverless architecture design and development, I created Flux.

Problem: Fluctuations in renewable energy risk access to power, and causes us to use dirtier electricity.

Solution: Flux aims to reduce a user's carbon footprint and mitigate fluctuations in demand by periodically informing them of their regional power grid's demand through SMS text messaging.

    How Flux Works

  1. Azure Static Web Apps hosts the remote website that takes in basic user data through an HTML5 form.
  2. Azure Cosmos DataBases receives and stores the inputted data as a document.
  3. The Azure Function periodically shoots a signal every hour to request power demand data from the U.S. Energy Information Administration API, and returns it to the Function.
  4. The Function calculates the quartiles of the average demand over the past 24 hours, and determines if the most recent demand data is an anomaly.
  5. If the demand from the previous hour is considered an outlier AND a change from the previous demand state, the Azure Function will send the message to the Twilio API.
  6. Finally, Twilio accepts the array of messages for each user and sends them to each mobile number.

Balancing Usability

The main obstacle was figuring out how often to text users of the power demand. The more texts sent, the more annoying it became. The less texts sent, the more useless Flux would be. To find the correct balance of frequency, I tested three outlier rules of basic statistics.

Rules and Frequencies

  1. Z-Score (or Extreme Value Analysis): 0 texts/day
  2. 1.5 Quartile Rule: 3 texts/day
  3. Outside Q1 and Q3 bounds: 8 texts/day

Thus, the 1.5 Quartile Rule became the threshold preset for outlier identification of power demand.

Go to Flux Github