SDG&E LEAF TOU customers: Note about DST dates

My Nissan Leaf Forum

Help Support My Nissan Leaf Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

Randy

Well-known member
Joined
Apr 22, 2010
Messages
2,175
Location
San Diego, CA
There is an upcoming issue that I think LEAF owners in the SDG&E Service Territory would be interested to learn about. There should have been a small line item on customer bills that are affected, but it is easy to miss.

We are currently using GE meters for the EV TOU rates, and at some point next year those will be swapped out to Smart Meters. So this issue just relates to the GE meters that we have in place now for TOU rates and will go away next year as those are swapped out.

From October 30 through November 5, the on-peak, off-peak, and super off-peak time periods will begin and end one hour later. So customers will want to adjust their car/charger timers accordingly to keep within the rate periods and avoid higher charges.

This is because the GE meters are programmed with the “legacy” DST/PST dates, and they don’t know about the additional dates that the Federal Government added a few years ago. The same thing will occur in Spring at the DST/PST time change if we’re still using the GE meters.

Since our goal is to help drive local PEV charging to the super off-peak time period, I thought San Diego LEAF TOU customiers would want to know this information...

Thanks,

Randy
 
Randy said:
There is an upcoming issue that I think LEAF owners in the SDG&E Service Territory would be interested to learn about. There should have been a small line item on customer bills that are affected, but it is easy to miss...

Thanks Randy. jcesare had also posted about this (he actually saw the notice on his bill!), too, but I think it's worthwhile to give this as much visibility as possible.
 
My thread about this is here:
http://www.mynissanleaf.com/viewtopic.php?f=25&t=6510" onclick="window.open(this.href);return false;

Thanks for the clarification as to reason (embedded in GE meter). I did not know that.

I do have a question that was not answered in the thread. Will the Leaf and or Blink clocks change automatically on Nov 6?
 
jcesare said:
Will the Leaf and or Blink clocks change automatically on Nov 6?
From another thread it appears that the Leaf will change from/to DST automatically as long as you have that function toggled ON in the Nav system: Menu/Settings/Others/Clock/Daylight Savings Time. Don't know about the Blink, I don't use it for timed charging.

I got a confusing epistle from SDG&E in the mail yesterday trying to explain this DST issue. The written instructions on pg. 1 were fairly straightforward, but the color-coded 2011 calendar included as pg. 2 was completely confusing. It had a legend showing the two time periods (Extended DST Peak Periods and Existing Peak Periods), but BOTH of them were the same yellow color, and the accompanying calendar had EVERY SINGLE DAY OF THE YEAR also colored yellow. WTF!!! Did everyone else get this calendar in the same condition or is mine unusual? Did they run out of a different color ink to use or was this misprinted or something? Proofing error?

sdgecal.jpg


TT
 
Hi Tom,
Not sure what happened there. I did proof the mailing before it went out and I can assure you that there were different colors in the Fall and Spring extended DST periods...I haven't opened up my own mail yet, so let me go look....

Randy
 
Mine is all yellow as well....Not sure what happened, but thanks for pointing it out Tom.

Here is a jpg of what it should look like....

I'll take it up with the team tomorrow and see about fixing it...

Thanks, Randy
 

Attachments

  • calendar.jpg
    calendar.jpg
    158.9 KB · Views: 70
Same problem with the calendar. The written material is clear and easily understood. There is no need for SDG&E to send an new calender or further mailing on this. I appreciate receiving the information from the letter.
 
My calendar was also all-yellow, and I was befuddled as to what it was trying to show. :)

Really, though.. these GE kV2c meters are programmable and I'm puzzled as to why the meter reader doesn't just load a new program in. One that matches the new DST calendar and correctly reflects the wall clock. Probably easier than getting everyone to understand why it's "different" for a couple weeks out of the year.

This is more important now that people are trying to closely match the timer in their car with the meter, and this error requires manual adjustment four times a year.

While they're at it, maybe the new program can make the Rate A, B, and C time windows rates match the rate schedule as well. And, since we're dreaming, maybe even SHOW the totals on the GE LCD display. :)

That is, have the EVSE meter load something closer to Progarm ID 54, instead of Program ID 2 which hides the (incorrect) rate totals. The whole thing seems designed to hide the very information a customer needs to predict their own bill.

One has to wonder, without any way to see it on the meter or predict it before a bill, how many people in the EPEV rate study will suddenly "stop carrying about rate differential" for these few weeks and skew the study results?
 
Actually, the more I think about it, the more I believe this calendar business is totally bogus.

The meters collect 15-minute interval data for the whole month, and all the rate computation and time windows are performed at the "billing" office end, not the meter itself.

It would require NO meter reprogramming at all for SDG&E to match the true DST/PST clocks!

It's the very same reason that totally jacked Program ID 2 can be used for the EVSE meter, when the A/B/C windows don't match the rate schedule at all -- it's because it doesn't matter. The user can't see the TOU totals, and they're all computed based on the downloaded monthly history.

So this has more to do with SDG&E's back-end billing computation than anything to do with the meter itself.
 
I hear you, GL. There are many thousands of customers with these meters (mostly commercial and industrial).

Back in 2005 when the DST calendar was changed by the Energy Policy Act, management made a cost decision to not reprogram or swap out the meters or to spend a considerable amount of money to modify the backend billing system. At the time, no one knew if the Feds would change the DST calendar again after a year or two...

So the approach that was taken was to modify the tariffs to include the langugage about the semi-annual time changes and the effects for TOU customers, and an advice letter was filed with the CPUC in 2005 about the changes and how the company would handle them.

http://www.sdge.com/tm2/pdf/1746-E.pdf" onclick="window.open(this.href);return false;

The CPUC approved this in 2006, and it has been that way now for a while. The good news is that at some point in the future, newly programmed Smart Meters will be swapped in for those GE meters and the problem will go away. I've heard this will happen next year, but no specific date.

Randy
 
I understand Randy, and it's always easiest to leave things as-is and adjust the paperwork to match.

But it's a bit.. incomplete to blame the GE Meter or programming for our EV TOU calendar shifting.
Specifically:
This is because the GE meters are programmed with the “legacy” DST/PST dates, and they don’t know about the additional dates that the Federal Government added a few years ago. The same thing will occur in Spring at the DST/PST time change if we’re still using the GE meters.
This appears to be unrelated. The DST/PST dates in the GE meters has absolutely nothing at all to do with billing. The only relevant thing collected from the meters is the 15-minute interval data, regardless of DST or rate windows. The Seasons and Holiday programming in the meter just isn't used.

There might be some back-office billing connundrum with software and meter timestamps, but it's not in the meter. The meter is already TOTALLY wrong about days, rate periods, and DST, and nobody seems to mind.

So this part of the CPUC 2005 Advice Letter:
The vast majority of current TOU meters use
internal electronic clocks programmed to determine how energy consumption will be
recorded by TOU period. Adjusting clocks in all of the current meters to account for the
DST change would require sending personnel to each site for either re-programming the
meter or replacing it with a meter that has been re-programmed to account for the revised
DST schedule.
might be true for domestic TOU, if billing uses the Rate A/B/C/D totalizers in the meter, but it's not true for the EV TOU meters which do none of that.

I say this because it's a bit of a sore spot that the meter displays are currently useless to the consumer. (ie, there is no way to know/confirm my billed usage before I get my bill.) So now to say that the DST schedule has to conform to some wacky four-phase calendar because of the unused meter sums, well, that's more than I can let go without comment.

SDG&E should have conformed to 2005 Energy Policy DST, programmed the GE meters accordingly (to present usable sums on the display) or at least adjusted their billing software for the correct dates. Then EV drivers could stick to one calendar year-round, and avoid confusing off-peak/peak discrepancies. I bet you dollars to donuts SDG&E will see a spike in "off-peak" vs "super-off-peak" charging in the EV Study this month, and it's not intentional, or visible by meter display.
 
GroundLoop said:
SDG&E should have conformed to 2005 Energy Policy DST, programmed the GE meters accordingly (to present usable sums on the display) or at least adjusted their billing software for the correct dates. Then EV drivers could stick to one calendar year-round, and avoid confusing off-peak/peak discrepancies. I bet you dollars to donuts SDG&E will see a spike in "off-peak" vs "super-off-peak" charging in the EV Study this month, and it's not intentional, or visible by meter display.

I agree that it would have been cleaner to take care of this back when it started. It'll be nice to have the Smart Meters rolled out to take care of the issue, and will also be interesting to see if they also take care of the "Readable data" issue that you wrote about....

Randy
 
Programming issues aside, I really like the GE meter. :) Nicer than the Itron OpenWay ones, anyway.

I just wish they would put Program 54 into both meters, with A/B/C time windows set correctly to match the TOU schedule. Then the customer could confirm their own bill, and monitor mid-month.
 
Randy said:
I agree that it would have been cleaner to take care of this back when it started. It'll be nice to have the Smart Meters rolled out to take care of the issue, and will also be interesting to see if they also take care of the "Readable data" issue that you wrote about...
It would be great if the Smart Meters finally let us see our own data. I had thought that EnergyWaves might have let us view our data, but I haven't figured out how to interpret it yet :-(

It looks to me like this timer set and reset was forced on SDG&E by a regulatory anachronism, itself a response to the legal anachronism of Daylight Savings Time. Wouldn't it be nice if they'd just leave the clocks alone? Keep them PST year round, or keep them PDT year round (my favorite.)

Study: Daylight saving time a waste of energy
http://www.physorg.com/news187946326.html
 
walterbays said:
It would be great if the Smart Meters finally let us see our own data. I had thought that EnergyWaves might have let us view our data, but I haven't figured out how to interpret it yet :-(
It's most useful if the interval data is downloaded and then pasted into your own spreadsheets for analysis. Unfortunately, it's only accurate to 0.1 kWh / 15 minute period which severely limits it's usability. +- 0.1 kWh / 15 minutes means the reading could be as much as 400W high or low. One more significant digit (+-4W) should be much more useful.

walterbays said:
Wouldn't it be nice if they'd just leave the clocks alone? Keep them PST year round, or keep them PDT year round (my favorite.)

Study: Daylight saving time a waste of energy
http://www.physorg.com/news187946326.html
Sure would! We should start a petition...
 
Back
Top