The dataset<\/h2>\n
\nThe data is a public release from the UCI Machine Learning Repository: 2,075,259 one-minute measurements from a single home. Each row carries the whole-house active power draw in kilowatts, plus voltage, current, and three sub-meters:\n<\/p>\n
- \n
- Sub-meter 1, kitchen:<\/strong> dishwasher, oven, microwave<\/li>\n
- Sub-meter 2, laundry:<\/strong> washing machine, tumble dryer, fridge, a light<\/li>\n
- Sub-meter 3, climate:<\/strong> an electric water heater and an air conditioner<\/li>\n<\/ul>\n
\nTwo million minute-level rows is finer than we need to see daily and seasonal behaviour, so a short resampling step (in the repo) rolls them up to hourly: the mean for the instantaneous quantities, and the sum for the sub-meter energy counters. That leaves 34,168 clean hourly rows, which is what lands in GridDB.\n<\/p>\n
The data lives in GridDB<\/h2>\n
\nLoading is two calls against the Web API: create a TIME_SERIES container with a schema, then PUT the rows in batches. On the free Cloud tier there is no driver to install; Java’s built-in
HttpClient<\/code> sends JSON over HTTPS.\n<\/p>\n\nclient.createTimeSeriesContainer("home_power_hourly", List.of(\r\n new Column("ts", "TIMESTAMP"),\r\n new Column("active_power_kw", "DOUBLE"),\r\n new Column("voltage_v", "DOUBLE"),\r\n \/\/ ...current and the three sub-meters\r\n));\r\nclient.putRows("home_power_hourly", rows, 2000); \/\/ 34k rows, ~18 requests<\/code><\/pre>\n<\/div>\n\nFrom there the analysis reads the series back out of the database. A single SQL
SELECT<\/code> streams every row into a list of typed records, and one TQL call asks GridDB for a time-weighted average without pulling anything client-side:\n<\/p>\n\npublic List<Reading> fetchAll(String container) throws Exception {\r\n JsonNode results = sqlSelect("SELECT * FROM " + container + " ORDER BY ts")\r\n .get(0).get("results");\r\n List<Reading> readings = new ArrayList<>(results.size());\r\n for (JsonNode r : results) {\r\n readings.add(new Reading(Instant.parse(r.get(0).asText()),\r\n r.get(1).asDouble(), r.get(2).asDouble(), r.get(3).asDouble(),\r\n r.get(4).asDouble(), r.get(5).asDouble(), r.get(6).asDouble()));\r\n }\r\n return readings;\r\n}<\/code><\/pre>\n<\/div>\n\nclient.tql("home_power_hourly", "select TIME_AVG(active_power_kw)");\r\n\/\/ -> 1.092 (kW, time-weighted across the full four years)<\/code><\/pre>\n<\/div>\n\nSo over four years this home pulled about 1.1 kW<\/strong> on average. That single number hides everything interesting, though, and the hourly detail is where the story lives.\n<\/p>\n
Why a database, not a flat file<\/h2>\n
\nYou could read the CSV straight into memory, so it is fair to ask what GridDB buys you here. The answer shows up when the dataset stops being one home. A TIME_SERIES container keeps rows ordered by their timestamp, so a query for “every reading in March 2008” or “the hourly average for this meter” reads only the slice it needs instead of walking a file end to end, and an aggregate like the average above is computed inside the database rather than in the JVM. This one home is two million raw readings over four years; a thousand of them reporting every minute would add more than a million rows a day. That is the scale where flat files stop being an option, and the code you write against one home is the code you run against a thousand.\n<\/p>\n
Charting with JFreeChart<\/h2>\n
\nEach chart is the same handful of steps: group the readings that GridDB handed back, drop the numbers into a JFreeChart dataset, and save a PNG. The daily load curve, for instance:\n<\/p>\n
\ndouble[] mean = meanByHour(readings, Reading::activePowerKw); \/\/ plain loop over the records\r\nXYSeries s = new XYSeries("Mean active power");\r\nfor (int h = 0; h < 24; h++) s.add(h, mean[h]);\r\nJFreeChart chart = ChartFactory.createXYLineChart(\r\n "Average electricity demand by hour of day", "Hour of day",\r\n "Mean active power (kW)", new XYSeriesCollection(s),\r\n PlotOrientation.VERTICAL, false, false, false);\r\nChartUtils.saveChartAsPNG(new File("images\/daily_load_curve.png"), chart, 800, 450);<\/code><\/pre>\n<\/div>\n\nWith that pattern in place, here is what four years of this home looks like.\n<\/p>\n
The daily rhythm<\/h2>\n
![\"\"](\"\/wp-content\/uploads\/2026\/10\/daily_load_curve.png\")
<\/a><\/p>\n\nGroup every hour by its position in the day and you get the household’s average load curve, and it reads like a daily routine. Demand bottoms out at 0.44 kW around 4 AM<\/strong>, when little more than the fridge and standby loads are running. It climbs through a morning bump just after 7 AM (about 1.5 kW), eases off through the working day, then builds to a hard evening peak of 1.90 kW at 8 PM<\/strong>: dinner, appliances, lights, everyone home. That is a 4.3x swing<\/strong> between the quietest and busiest hours of an average day, and it is exactly the kind of peak that utilities build their pricing around.\n<\/p>\n
Weekdays versus weekends<\/h2>\n
![\"\"](\"\/wp-content\/uploads\/2026\/10\/weekday_vs_weekend.png\")
<\/a><\/p>\n\nSplitting the week apart separates two routines. Weekdays show the sharper, later evening spike you would expect from people arriving home from work, at 1.85 kW around 9 PM<\/strong>. Weekends run higher overall and peak earlier, at 2.05 kW near 7 PM<\/strong>, and they never sink into the flat mid-day lull that weekdays have, because someone is home using the house all afternoon.\n<\/p>\n
The seasons<\/h2>\n
![\"\"](\"\/wp-content\/uploads\/2026\/10\/monthly_trend.png\")
<\/a><\/p>\n\nZoom out to a monthly average and the seasons take over. Winter months average 1.44 kW against 0.73 kW in summer<\/strong>, very nearly double. In a home whose largest metered load is an electric water heater, that fits: cold incoming water takes far more energy to bring up to temperature, and the darker months add lighting on top.\n<\/p>\n
![\"\"](\"\/wp-content\/uploads\/2026\/10\/hour_month_heatmap.png\")
<\/a><\/p>\n\nThe hour-by-month heatmap is my favourite view of the whole dataset. Each column is a calendar month, each row an hour of the day, and colour is average power. The bright evening band across hours 19 to 21 is present all year but blazes from November through March. Then look at month 8: August is dark at every single hour.<\/strong> This household effectively switched off for the month, the classic summer holiday written straight into the electricity.\n<\/p>\n
Where the power actually goes<\/h2>\n
![\"\"](\"\/wp-content\/uploads\/2026\/10\/submetering_by_hour.png\")
<\/a><\/p>\n\nStacking the three sub-meters by hour shows which circuits drive the day. The climate circuit (water heater and AC) dominates, with a big morning surge as the tank reheats after overnight use. The kitchen spikes at the obvious moments, a small bump at lunch and a larger one at dinner. Laundry stays spread across the day and peaks in the early afternoon, since the always-on fridge sits on that circuit too.\n<\/p>\n
\nThe most revealing figure, though, is the one that is not on any chart. Add up all three sub-meters across four years and they account for only 48.8% of the home’s total energy<\/strong>. The other 51.2%<\/strong>, which is lighting, wall sockets, electronics, and everything not on a named circuit, is simply invisible to the sub-meters. If you are building anything that reasons about home energy, that number is worth remembering: the circuits you can see may be the minority of what you are trying to explain. Of the metered half, the climate circuit alone is roughly 13,200 kWh<\/strong>, against about 2,700 for laundry and 2,300 for the kitchen.\n<\/p>\n
Wrapping up<\/h2>\n
\nNone of this analysis is exotic; it is grouping and averaging a few arrays. It works cleanly only because the data sits somewhere that makes time-slicing cheap. GridDB held the four-year series as one TIME_SERIES container, handed the whole thing back in a single query, and computed the time-weighted average server-side, leaving Java to do the grouping and JFreeChart the drawing. From here the same container feeds the obvious next steps, none of which need the raw file again: a short-term load forecast, an anomaly detector that flags an hour drawing far more than its usual for that time of day and season, or a live dashboard that reads the most recent hours straight from GridDB.\n<\/p>\n
\nThe complete project, from the resampled data to the five charts, is on GitHub. Point it at your own free GridDB Cloud instance, set three environment variables, and you will get the same charts.\n<\/p>\n
Full source and data:<\/strong> github.com\/radiantmind125\/griddb-energy-java<\/a><\/p>\n
- Sub-meter 2, laundry:<\/strong> washing machine, tumble dryer, fridge, a light<\/li>\n