That's fairly low as these things go but to achieve that I had to be very careful, not to mention choosy about who I let come and stay with me over that the critical period. Heaters and that kind of thing are all locked away out of reach!
On a more serious note it probably also helped that there were only three relevant periods of load controlling for my meter last winter. The number of qualifying measurement periods was a lot higher (43) in the previous year and my demand from that period was also correspondingly higher at 1.135 kW.
By comparison, "the formula" (2011 version at least) comes up with a 1.84 kW load based on my 1 June to 30 September 2010 consumption. However the previous year's formula (based on higher winter consumption from the preceding winter) actually produced a lower demand than that at 1.70 kW.
Yes, you read that right!
If I had been on the formula, I would have been another of TLC's customers who reduced their average daily consumption in the winter of 2010 as compared to the previous winter but who still ended up with an increased kW load estimate. The reverse kind of silliness can also happen at the higher end where you can still be "rewarded" with a lower kW load value despite actually increasing your average daily consumption in the 2010 winter. This can happen because of the way "the formula" has been changed this year. Doesn't really make sense does it? However I will definitely be interested to hear from TLC if it makes more cents to them!
On the other hand, if my peak load came via the formula I'd be a lot more relaxed about the occasional blow-out and visitors. In fact I could go completely "crazy" with my electricity usage in the middle of a big fat load controlling period and it wouldn't make diddly squat difference to my formula based demand/kW load (as long I also didn't do that too often).
Anyway, here's a graph showing the half hour data for the full day from where this 0.89 kW peak 3 hour load (also during a load controlling period, June through September 2010) came from.
Each bar represents a half hour period - one recording from the meter. The green bars are those that were completely "uncontrolled" so these really have nothing to do with any peak kW load calculations. The orange bars are those where load controlling started or stopped partway through. These don't get used either, otherwise some "controllable load" from your water cylinder heating and similar could be included and that's not meant to happen.
You may have noticed a period of high load just after midnight. Okay, so you're curious. Turns out I'm a night owl and usually shower just before going to bed. So, my hot water cylinder then has to do its thing for a few hours to heat up the very cold water that will have just flowed in. You may also note some fairly regular "spikes" across the day. Yep, it's that inefficient old water cylinder again, still trying to keep the water nice and hot because a fair bit of the heat has leaked out into my clothes drying cupboard instead!
The red bars indicate the "danger zone" as these are the times that fell completely within a load controlled period (and also meaning in my case that my hot water cylinder should be turned off). The real "danger" is when there are six of those in a row as that means there is a three hour long block that will be processed to get an average load. The six half hours that correspond to my single highest three hour average load (kW) are overlaid with a larger shaded bar and the dotted horizontal line level with the top of that shows the average load over that three hour period, 0.89 kW in this case.
Note also how the times on the x-axis start one minute later than what you might expect. That's because a one minute clock correction was applied to the "raw data" from the meter. If you want to know more there's more on this and other "technical details" below.
Following this paragraph you can read the section of the "log file" generated by my software as it processed the data from my meter - the only change is that I have removed my ICP number for privacy reasons. The log file is generated mainly for diagnostic purposes but it's also a good way to illustrate some of what goes on "underneath the hood" if you happen to be interested in that kind of thing.
Processing meter 2902959
ICP: _NONE_OF_YOUR_BUSINESS!_
Meter 2902959 (controlled) is assigned channel 6 which maps to 156 using ../ongarue-map.csv
We will allow for a maximum time error of 5 minutes.
Discarding data before a pre-winter clock adjustment (2010-06-01 12:09:00 -> 2010-06-01 12:11:00) for meter 2902959.
Time adjustment +0:01:00 (2010-12-02 13:22:00 -> 2010-12-02 13:23:00) will be applied for meter 2902959.
Ignoring "On" without a matching "Off" at 2010-01-04 06:07:35
Ignoring "On" without a matching "Off" at 2010-03-20 10:31:20
Ignoring "On" without a matching "Off" at 2010-04-21 09:02:26
Ignoring "On" without a matching "Off" at 2010-04-21 14:50:32
Ignoring "On" without a matching "Off" at 2010-05-12 11:48:29
Ignoring "On" without a matching "Off" at 2010-05-12 12:00:06
Ignoring "On" without a matching "Off" at 2010-06-16 00:32:11
Ignoring "On" without a matching "Off" at 2010-07-20 00:37:56
378 controlled periods read from relay times file (../control/cntrl-156.csv)
Using raw controlled load times:
Longest controlled period was 4:08:19
Total controlled time was 12 days, 11:39:31
There are 12 qualifying controlled periods
After clipping:
Longest clipped controlled period was 3:30:00
Total clipped controlled time was 5 days, 1:30:00
There are 3 qualifying clipped controlled periods
13524 records used from usage file (2902959.csv)
1 records skipped (power factor data, etc.)
Adding one hour to times for the week starting 2010-09-26 02:00:00 for meter 2902959.
Subtracting one hour from records for the week starting 2010-04-04 02:00:00 for meter 2902959.
Total usage is 2658.767 kWh
Winter usage is 1844.162 kWh (load detected on 122 different dates)
Incomplete data! (Covers 2010-06-01 12:31:00 to 2010-12-02 11:31:00)
243 controlled intervals, resulting in 5 blocks of time for demand calculations
Max winter 30 minute demand ended at 2010-08-26 19:01:00 and was 3.406 kW.
Max 24/7 winter 180 minute demand ended at 2010-06-12 03:31:00 and was 1.849 kW.
Max controlled winter 180 minute demand ended at 2010-07-26 20:31:00 and was 0.891 kW.
Min controlled winter demand value : 0.369
Median controlled winter demand value: 0.738
Mean controlled winter demand value : 0.666
Standard deviation of winter demands : 0.219
Sorted list of top non-overlapping demand figures:
2010-07-26 20:31:00: 0.891 kW (180 minutes from 2010-07-26 17:31:00)
2010-07-13 20:31:00: 0.738 kW (180 minutes from 2010-07-13 17:31:00)
2010-07-14 21:01:00: 0.369 kW (180 minutes from 2010-07-14 18:01:00)
There were only three times (last winter, in my area, on my channel) where there was a period suitable for measurement according to the rules being applied and the highest average three hour load from each of those appears at the end of log file entries above.
Now, you may want to check that my working is correct! Actually I really do hope so because I don't want to be accusing of "diddling the data", "feathering my own nest", or anything else in that vein! The more eyes that look the more likely it is that any bugs or mistakes will be found. Please let me know if you can't manage to reproduce my results and think I'm not on the level!
The data is in CSV files and is fairly straightforward to understand so it's quite possible to "manually" check if you're reasonably familiar with a suitable spreadsheet program or similar. Even without that you could open the files in any text editor (e.g. Notepad) and at least check the date/times and kW load values listed above are correct with a few simple calculations.
There are some things to bear in mind though:
1. There are two files, 2902959.csv contains the half hour data and cntrl-156.csv contains the times my ripple control channel was turned off and on according to TLC's systems. There are some "On" statements without a matching "Off". These are apparently caused by resets of some kind and are ignored by my processing software (apart from spitting out a warning to the log file).
2. The dates and times in the half hour data file from the meter refer to the end time of the relevant half hour. There are a number of fields in each record but the only ones that really matter are the date, time, and kWh consumption value.
3. Someone from TLC came and checked the clock on my meter on 1 June 2010 and made a small adjustment. (My records show it was about 25-30 seconds slow before this adjustment and about 14 seconds fast afterwards. This doesn't actually match very well with the clock adjustment information I got from TLC but in any case data from before that point is discarded if it fell in the 1 June to 30 September period. This applies to all cases where such an adjustment was made late (the checks were meant to be done before winter) but it didn't make any difference to my results anyway.
4. The clock in my meter was checked (and perhaps adjusted again) when the data was downloaded (on 2 Dec 2010 in my case). My own records show no adjustment was actually made at all although the information received from TLC later indicated the meter clock was adjusted forward by one minute. I believe this small discrepancy was due to the way the person checking and recording the information did it - including only recording times to a one minute precision as displayed on the meter. (I watched over his shoulder. :-)
5. In any case the processing also allows for a five minute residual error in the times so small remaining inaccuracies in the various clocks shouldn't have any effect. The same five minute allowance was applied to all processing of 2010 winter data from TOU meters. Effectively this means the start and end times of each controlled period are trimmed back by five minutes to create a small "safety buffer".
6. As noted in my last post, my meter is also one of the many that has incorrect daylight saving information programmed into it and this means that in 2010 (and this year also) it transitioned to and from daylight saving time a week later than it was supposed to. The dates and times from the meter (and in the load control switching data) are all in "local time" so therefore a correction has to be made for the one week following the official start and end of daylight saving. This didn't make any difference in my case but it could in others. If you look at the half hour data in the early morning of 11 April and 3 October you will see the meter doing its version of daylight saving time adjustments (albeit a week late). Stupid smart meter! :-)
7. After trimming the five minutes from the start and end times of controlled periods, correcting for the daylight saving glitch and applying any clock adjustment recorded from after the winter to all the remaining times in the data, the processing then looks at all the three hour periods (six consecutive half hour blocks from the corrected meter data) that fall completely within a single period of load controlling. For each it adds up all the consumption data (kWh) and divides by three (duration in hours) to get an average load (kW) over that period. The highest such period is where my 0.891 kW figure comes from.
No comments:
Post a Comment