If you're gathering instantaneous time-series data such as electricity usage in Watts over specific time periods, then at some point you're going to want to convert this into usage data — i.e. kWh or suchlike. It's less obvious than it looks.
Converting instantaneous power (Watts) into energy (kWh) means treating each reading as flat across its time period, averaging over the hour, and dividing by 1,000. The subtlety is which window a timestamp applies to — start, middle or end of the period. Get that wrong and an "hourly" total can include 15 minutes of the previous hour and miss the last 15 of this one. It matters especially in time-series databases like InfluxDB.
Sometimes this can be a little confusing, primarily due to a number of factors:
Let’s address them all in turn.
Imagine we’re monitoring the power consumed by a single electrical appliance on a circuit, with a sensor that returns usage data in Watts every 15 minutes. Every 15 minutes we receive a data point — this is our “time period.” If we plot it on a chart, note that we don’t join the lines: they’re instantaneous values, and we have no information on how to interpolate between them.

It isn’t obvious at first, but it’s important to know what part of the 15-minute period the sample points apply to — the start, the middle, or the end. Remember, the instantaneous value isn’t returned until the time period it applies to is complete, so we’re not getting values for future events — it’s just whatever the sensor chooses as its default (or what it has been set to). This may not seem immediately important, but it can have real implications when calculating usage.
If we’re getting instantaneous values every 15 minutes (4 an hour) and want to convert to kWh, how do we do it? Take a simple example. Suppose one of the four readings in an hour is 100W. That one time period is 100W for 15 minutes (we assume usage is flat across the period, having no other information). If that were the only non-zero period, we’d have 100W for ¼ of an hour and nothing for the rest. So we divide the value by 4 to get an average over the hour (4 × 15-minute periods), giving Wh; to get kWh we divide by 1,000:
If all four readings were 100W:
Which makes perfect sense — it’s effectively a continual 100W for an hour, i.e. 100 Wh, or 0.1 kWh.
Why does it matter where the sample was taken relative to its time period? It becomes relevant if we ask for an average usage over a period of time. Say we ask for sample data between 00:00 and 00:59. If the sample data refers to the 15-minute period following the sample, we get one set of blocks. But if the sensor’s timestamp refers to the end of each period, we may have inadvertently requested data that includes 15 minutes of the previous hour and misses the last 15 minutes of this hour — simply because of how the data is presented by the sensor.

It’s important to know to which window of time the instantaneous data applies.
This becomes especially important when using time-series databases such as InfluxDB, where windowing calculations like aggregateWindow() (and timeSrc) in the Flux language have a parameter to specify which window a timestamp applies to when they generate aggregations.
Getting these fundamentals right is the difference between billing data you can trust and data you can’t — the kind of careful engineering behind our Advisor platform and our time-series data pipelines. If you’re building energy monitoring on instantaneous sensor data, we can help you get it right.
Related capability · Energy Asset Optimisation →
Getting the fundamentals right — windowing, aggregation, accurate kWh from instantaneous data — is what makes monitoring trustworthy. That's our engineering. Let's talk.