Energy storage and sustainability are big issues in Hawaii, where oil tankers are shipped in everyday, just to keep the lights on. Resiliency in the energy grid, due to threat of natural disaster, is critical. Energy storage is needed to manage how much solar energy is coming into the market or into the grid. Properly managing the power entering the grid is vital for grid stability since Hawaii has intermittent energy that floods the grid. It’s to solve the Hawaii market’s energy storage problem that Blue Planet Energy was founded.
Blue Planet Energy sells an energy storage unit that allows residential and commercial buildings equipped with solar panels to store unused solar energy. The company tasked Sudokrew — a Hawaii-based full stack development shop and software consultancy — with developing a clean energy storage device management and battery intelligence software solution.
The solution required a time series database able to scale with increasing devices and registers, support an HTTP API and basic aggregation methods, and provide dedicated hosting. Sudokrew leveraged InfluxDB Cloud to create a solution to gather metrics that help monitor and control the storage units remotely, extending the life of the battery, improving the experience of the user, and offering superior customer service. Here’s an overview of the solution, which can best be understood in the context of the energy storage problem it set out to solve.
Tackling the solar energy storage challenge
The largest barrier in solar is that its sources are intermittent and difficult to predict. Blue Planet Energy is solving the problem of intermittent energy generation by providing a suite of storage solutions, from residential to utility grade lithium iron phosphate batteries. The software suite that Blue Planet Energy tasked Sudokrew with building had to manage sales, deploy devices, monitor energy usage, and provide a unified infrastructure to connect every user and vertical of the business.
Prior to deploying InfluxDB Cloud, Sudokrew had no visibility into what was executing on their servers and often relied on guesswork. “The database that we were using was like a black box system,” says Tony Gaskell, developer at Sudokrew. “We didn’t have much visibility into it. The only thing that we could tell was: is the main process still running?”
Though they had monitoring configured, alerts weren’t set to the correct levels for their storage usage. They needed to track information that is vital to maintaining batteries or big storage units, such as battery status and cycle count. Sudokrew first defined the end-user’s energy visibility needs and then set out to determine the applications and infrastructure necessary to meet them. They needed to set up data visualization, but first, they needed a way to receive that data.
Blue Planet Energy, as a battery manufacturer, had the forethought to allow data from their inverter to be transmitted, but it was still missing an endpoint to receive and store all that data as well as consumption data from facilities and individual devices. This meant building endpoints that connected energy hardware to software, along with the infrastructure necessary to manage a never-ending flow of data that could be archived, recalled and indexed to users, dealers and administrators. They had to solve these technical challenges:
- Scaling issues were being reported by all users – Admins and dealers were unable to see device status, and end-users faced graphs that were slow-rendering or not showing at all. Further, the issues reported were inconsistent.
- Data was unavailable – Sudokrew had to reconsider their existing database, which failed to provide the data visibility they sought. With their existing infrastructure, data needed to be manually migrated if they ran out of space. As a single instance, backups were their only line of defense.
- Query performance fell short – Sudokrew needed a solution to meet the different data aggregation requirements of mobile and desktop views.
The above challenges hindered visibility and thereby Blue Planet Energy’s ability to implement features.
InfluxDB for Sudokrew’s solution for Blue Planet Energy
Understanding their use case and limitations was key to choosing a time series database, as were the design decisions they had to consider up front and the resulting possibilities. After Googling the top ten time series databases and getting leads, Sudokrew selected InfluxDB, which met their database criteria:
- Must be able to scale as more devices and registers are added to the system
- Should be able to support an HTTP API (which is how they were currently interfacing with the existing database)
- Should be able to support basic aggregation methods
- Preferable to have a hosted solution (available as a managed database as a service, InfluxDB Cloud)
Sudokrew architected a benchmarking process, set up a trial version of InfluxDB Cloud, and imported some of the data from their production database into that instance. They used Bees With Machine Guns — an open source tool built on ApacheBench and Amazon EC2 — that allows you to spin up a lot of EC2 instances and DDoS your own servers.
This infrastructure met Sudokrew’s requirement to simulate a system of distributed devices that could scale a system to any number of devices with a variable amount of registers. InfluxDB passed their benchmark test with flying colors, delivering considerable performance gains. It also easily fit into the many services that Sudokrew had built for their existing database.
After deploying InfluxDB, Sudokrew was able to focus on the application and system. They were able to convert data from an XML payload that they were getting from eGauge devices (the sensors on the batteries) into InfluxDB schema. Sudokrew had collaborated with eGauge Systems (a manufacturer of utility-grade energy monitoring systems that can receive production data of solar systems as well as energy consumption data of common devices) to integrate eGauge devices into the Blue Planet Energy application. eGauge devices have a password-protected built-in dashboard and built-in internet connection. Sudokrew have a data pipeline set up with eGauge, through which they can assign eGauge to people within that system.
To keep data under control and avoid running out of storage space, they asked themselves while configuring the database: “How much data are we expecting to come in? How long should we hold onto that data? What format should that be? Do we want to keep averages, or do we want to keep a running total?” They could now answer these questions because they gained control over how the data was handled by using InfluxDB’s flexible, built-in retention policies.
The IoT monitoring software powered by InfluxDB
The IoT monitoring software built by Sudokrew for Blue Planet Energy has an admin portal that can commission devices and dealers and assign those devices to dealers. InfluxDB enabled Sudokrew to store energy production and consumption data and amounts stored over time, and then display them in user-friendly graphs.
The solution’s design includes:
- eGauge devices used as the data logger
- APIs to pull the data into InfluxDB, then serve it up into their applications
- Tags such as register, unit, and serial to identify data pulled into InfluxDB
- Chronograf (InfluxDB’s native dashboarding engine) which is used for the aggregated view (that Blue Planet Energy see) of all the devices out there
Visibility gained and transparency achieved
Gaining visibility into their servers gave Sudokrew the layer of transparency they sought. The open source nature of InfluxDB gave them visibility into the issues raised, the responses, and the developers responding to issues raised. With the warranty values coming in, Sudokrew could view the average cycle count across all devices, which they couldn’t do before.
Sudokrew built their monitoring apps to create value for all stakeholders as they realized that transparency is essential for building customer relationships. For Blue Planet Energy, these monitoring apps presented an opportunity to create a more harmonious relationship with their customers by providing them with the same data that they see. Visibility into usage patterns and people’s energy habits in turn helps project owners make decisions.
Sudokrew valued the dedicated support that came with InfluxDB Cloud, as it allowed them to focus on the application rather than on their infrastructure. “From here, we have a lot of places that we can go forward with InfluxDB,“ says Sudokrew developer Tony Gaskell. “There are a lot of opportunities that are available to us now that we have control over our data. That was probably one of the best things that we got out of this so far.” Learn more about this IoT and sensor monitoring use case by reading the full case study.
If you’re interested in sharing your InfluxDB story, click here.