Simulating a Solar Panel Data Stream with Overseed

Introduction

This post introduces the specification for time weights This spec allows you to model data using weights. The spec is great for modeling devices. To illustrate this feature, we built a schema of a solar panel that emits energy production data hourly.

Use Case

Assume we are an energy IoT company. We want to generate data to test our energy monitoring mobile application. Here are a few questions we want to address:

1. How should our application display incoming solar energy data?
2. How do we analyze these data to provide actionable suggestions to our users?
3. How will our system handle streams from many devices?
   

We can prototype, validate and demo all of these features using Overseed. Ultimately, we will design the data and connect to a stream that generates real-time data based on that design.

Overseed at work

First, we define the attributes along with the product, engineering, and data science teams.

1. Device ID: Each message has a UUID that uniquely identifies the device.
2. Timestamp: Each message provides a timestamp marking the hour.
3. kWh: Each message contains a decimal field with the measurement of energy production in Kilowatts.

Second, we list the behavior of the data we want:

1. Solar energy production is 0 after 6 PM and before 6 AM.
2. Solar energy production follows a bell curve shape starting at 6 AM and ending at 6 PM.
3. Solar energy production is usually highest at noon.
4. We need variability in our bell curve to model daily changes in the amount of solar energy produced.

Third, we can build the first version of our schema!

device_id: "b99be0b2-59fe-4f08-8a76-ed3c15231144"
timestamp: #SpecTimeStep & {
	value: "2021-08-24T00:00:00.000Z"
	step: { h: 1 }
}
kwh: #SpecTimeWeights & {
	time: #SpecTimeStep & {
		value: "2021-08-24T00:00:00.000Z"
		step: { h: 1 }
	},
	weights: {
		h: [
			{ hour: 6, scalar: 10, min: 30, max: 60 },
			{ hour: 7, scalar: 10, min: 60, max: 90 },
			{ hour: 8, scalar: 10, min: 90, max: 120 },
			{ hour: 9, scalar: 10, min: 120, max: 180 },
			{ hour: 10, scalar: 10, min: 150, max: 150 },
			{ hour: 11, scalar: 10, min: 150, max: 180 },
			{ hour: 12, scalar: 10, min: 210, max: 300 },
			{ hour: 13, scalar: 10, min: 180, max: 300 },
			{ hour: 14, scalar: 10, min: 150, max: 210 },
			{ hour: 15, scalar: 10, min: 120, max: 180 },
			{ hour: 16, scalar: 10, min: 60, max: 120 },
			{ hour: 17, scalar: 10, min: 60, max: 60 },
			{ hour: 18, scalar: 10, min: 30, max: 60 },
		]
	}
}

In the above schema we defined weights for the applicable hours. For example, { hour: 12, min: 210, max: 300 } indicates to use a weight between 210 and 300 when our timestamp is at noon. Subsequently the value for the output field weighted will be equal to that random weight (i.e. 300) multiplied by the hour itself 12 which results in an output for weighted as 3600.

You can learn more about this specification in the doc.

Lastly, we create a stream using our schema to produce records at a chosen rate (e.g. 1 second) Then we connect the application to our Overseed data generator using one of the SDKs.

We can now test our display with extreme values, validate our user action suggestions and stress test the application with lots of streams. Further, the data science team can use the schema to download a large batch of data to prototype learning features.

Summary

Using Overseed's time weights specification, we simulated a device that outputs solar energy production and used it to prototype, validate and test our application. In Addition, we can update the schema as we add more features or find new edge-cases.

We look forward to how you use this feature and any feedback you have!

Sign-up here.

The code for the embedded chart can be found in this GitHub repository.

‍