Economy7 clock wrong

lohr500

For persons A & B it should work like scenario A. The ALCS and the tariff change should be synchronised.

Have you been able to conduct the tests I described in my last post?

Whilst the in house display may show countdown information, it would be better to observe and photograph what is going on at the actual meter.

In my case, our Eco7 hours are 00:36 to 07:36 and these are always based on GMT.
The ALCS contactor also now operates between 00:36 and 07:36 GMT.

BUT when we switched to Utility Warehouse (our ECO7 supplier) I had to get them to remotely sort out the synchronisation because the ALCS schedule was still set to an old legacy EDF tariff we used to have.

Scot_39

Akustik said:

I've stayed up the night of the post and a few times before that and I am seeing the appliances turn on at 00:06 while the smart meter  still has a nearly 30 minute countdown to the tariff change. This is also indicated in the graphs show, thought apparently those are estimates. During that time, the smart meter "usage now" gives me the cost at what the day rate is.

Just for my own understanding about this staggering of switching ... in the example below with 3 people, does it act like scenario A or scenario B?

Scenario A:

Person A (18 minutes earlier):
Night tariff changes at 00:12.
ACL turns on night circuit at 00:12.

Me (on time):
Night tariff changes at 00:30
ACL turns on night circuit at 00:06 (26 minutes before tariff change)

Person B (10 minutes later):
Night tariff changes at 00:40
ACL turns on night circuit at 00:40

Scenario B:

Person A (18 minutes earlier):
Night tariff changes at 00:30
ACL turns on night circuit at 00:12 (18 minutes before tariff change)

Me (on time):
Night tariff changes at 00:30
ACL turns on night circuit at 00:06 (26 minutes before tariff change)

Person B (10 minutes later):
Night tariff changes at 00:30
ACL turns on night circuit at 00:40 (10 minutes after tariff change)

Q1 tariff nearly 30 min at 0006 as text or 24 mins so exactly 0030 as scenarios ?

If actually 30min remaining - The most likely explaination as above is your alcs calander set to 0000 0700, and your tariff 0030 to 0730, with a 6 min preset.

Heater supply via alcs port 5 - on 0006 0706
Tariff off peak 0036 to 0736


Regarding your scenarios - assuming the tariff timing table for meter  really was off peak 0030 to 0730 ( before any meter offset preset delay)

Scenario A Person B is the correct operation with a meter preset 10min offset and a 0030 to 0730 set off peak in tariff timing tables and an 0030 to 0730 set alcs calander.

Its important you realise thats 2 seperate meter settings sent be supplier - and some have only updated tariff times in past - e.g. on supplier switch for instance as above.

Another user had her tariff and alcs set to e10 at install - but 3 weeks later on a cap price change - the supplier resent an e7 tariff and e7 timing tables - her meter was giving 5 hrs of heating at peak tariff rate afternoon and evening as per e10 alcs calander.

Scenario A Person A for instance doesnt exist - the meter offset is positive on smets - it cannot advance the switching ot tariff or alcs - only ever delay - and works on both - so Scenario B Person B shouldnt happen either - IF BOTH TIMINGS SET TO MATCH

Octopus metering team likely can recover both sets of data from your meter to check,  but its probably easier just to get them to send a matched set - for both - as lohr500 experience.

Report to them you believe your alcs calander and tariff timings are mismatched  - leading to heating activating at peak rate  - and so meter alcs needs to be configured to match tariff off peak timing.  Evidence from meter photos as above etc would be great - but really shouldnt be necessary. The terms - even alcs - might well go over the head of average cs rep - but it will be very meaningful to their meter support teams.

ive said it before - ordinary customers shouldnt have to jump through hoops to prove faults like this or understand how they could arise - but suppliers CS just sadly isnt up to the task at times.  And Ofgem hasnt penalised them for poor support to force them too - for meters in general - but specifically complex metering and multirate metering.

And yes Id expect ask for some compensation for tge 24 / I think 30 mins - if rhey do in fact have them wrong.

So if one 3 kW hw immersion element - 1.5kWh for immersion heater xxx days a year x tariff rate diff - say 14-16p ON E7 - and say max NSH power draw/2 for 4 or 5 months the year.  At least since 2024 report not resolved.  Your 1 example above  over 2.5kWh in first half hour - but that would only be missbilled use to 0030 not 0036 - so likely over 3kWh if 0036 tariff timing..

You could in theory - or they could recover 13m data from meter - but a couple of snapshot examples from summer (no nsh on) and winter (HW and NSH on)  - might help persuade Ombudsman to  back a claim for long term  loss in light of initial 2024 report - if needs to be escalated.

Ildhund

Your attempted analysis misses the mark, I think. It's been pointed out several times that it may be that there is a mismatch between the timings of the Tariff Switching Table (TST) and of the ALCS Calendar. For an ordinary E7 plan, the nominal and actual timings should be identical. The actual timings will be delayed by the length of your meter's Randomized Offset, which appears to be about 6 minutes (~360 seconds).

Your IHD helpfully shows a countdown to the next tariff change. However, the timing of this change is taken direct from the TST, so it will differ from the actual change time by the amount of the Randomized Offset.  

There is no easy way to check the tariff change time. Your meter's display may help, but because the display menu options are configurable, there's no guarantee that your display will behave in the same way as anyone else's, like mine (which happens to be the same model as yours - Aclara SGM 1416-B). You might try and make a note of the options available to you. So long as the orange button B isn't sealed, you can press it repeatedly to switch from one menu to the next until you've seen them all, at which time the display will start again from the beginning.

A press or two on my button B changes the display text to Credit Mode. When in this mode, I can cycle through a number of options; the interesting one just now is Active TOU Number. With the meter configured for E7 like yours and mine, the display will show a large 1 for Rate 1 and ... errr, a large 2 for Rate 2. These should be for the peak and offpeak registers respectively; if they're not, that's a different problem equally easily remedied OTA (Over The Air, i.e. remotely) by a competent meter tech. 

You've learnt that the little oˉo icon in the bottom right-hand corner of the display changes when the ALCS activates, so you should see this happening at ~6 minutes past the nominal time. Before it does, navigate if you can to the Active TOU Number screen and note what it reports. When the icon changes, return to the Active TOU Number screen and note what it reads. If the TOU Number has changed, there is no mismatch. If it hasn't, there is, and you could then hang around for half an hour to see the precise time when the TOU Rate does change.

If you establish by this that there is a mismatch, your complaint to the supplier could follow the template I suggested in this post. The belt-and-braces approach would involve reinforcing those 'observations' by time-stamped before-and-after photos of the meter display. 

I hope this makes sense.

Scot_39

Ildhund said:

Your attempted analysis misses the mark, I think. It's been pointed out several times that it may be that there is a mismatch between the timings of the Tariff Switching Table (TST) and of the ALCS Calendar. For an ordinary E7 plan, the nominal and actual timings should be identical. The actual timings will be delayed by the length of your meter's Randomized Offset, which appears to be about 6 minutes (~360 seconds).

Your IHD helpfully shows a countdown to the next tariff change. However, the timing of this change is taken direct from the TST, so it will differ from the actual change time by the amount of the Randomized Offset.  

There is no easy way to check the tariff change time. 
I hope this makes sense.

How can they be identical yet delayed ?

Are you saying all e7 meters have 0 preset delay ?

If supplier scheduled tine set as 0030 and the preset c6m so switches at 0036 thats a fundamental difference - the 0036 should be universal - to tariff rate as billed, all tariff related information presented to users and of cource the load switching alcs 

If what you say about ihd countdown ignoring preset is true - I wonder how many pc2 smart meters have non zero randomized offsets - making that essentially a countdown to nothing meaningful.

A your tariff is going to change in the next 0-30min - is likely not to please those who have trusted it to be accurate and used it to set own timers, time shift loads like washing etc.

On some 2 off +2 peak +5 off peak split times and my e10  - with 3 off peaks 5hrs, 3 hrs aft and 2 hrs evening.  That upto 30m in as little as 2 hour slots and incrementing errors 2 or 3 times a day if preset error so could for many be non trivial.

That surely has to be a coding fault of hopefully the ihd interface - as the smets spec iirc makes it clear the randomizing offset should apply to both tariff and alcs.

But given my smets1 ihd cannot cope with two rate two register display, it doesnt surprise me if has other multirate limitations.

And is it really then an isolated fault on an ihd countdown - or do we have to question other info on meters and/or ihd - like active registers, active tariff rate in p/kWh (on my ihd for instance the only other indication of tariff rate 1 / 2 in use) etc ?

Ildhund

Scot_39 said:
How can they be identical yet delayed ?

Are you saying all e7 meters have 0 preset delay ?
... I wonder how many pc2 smart meters have non zero randomized offsets - making that essentially a countdown to nothing meaningful.

TST Nominal ≡ ALCS Nominal, TST Actual ≡ ALCS Actual.

All SMETS2 meters have null preset delay:
 
  
The Randomized Offset Number (0<RON<1) is randomly-generated and stored in the meter on manufacture. The Randomized Offset Limit (0<ROL<1799) is entered by the meter engineer on installation. I suspect that (a) each engineer has his own unique number to enter, and (b) it's only three digits long. That would explain why we never (?) see delays of more than 999 seconds (=  16' 39"). A supplier tech with appropriate permissions can retrieve a meter's RO on request (SR 6.2.2, I think).

Yes, the countdown isn't really helpful for millimeter precision of manual switching times. I make a habit of trying to persuade customers to establish and record what their meter's RO is. It only involves camping out with a torch and a flask of something refreshing once in each meter's lifetime. Those on E10 are lucky in that respect.

Scot_39 said:
And is it really then an isolated fault on an ihd countdown - or do we have to question other info on meters and/or ihd - like active registers, active tariff rate in p/kWh (on my ihd for instance the only other indication of tariff rate 1 / 2 in use) etc ?

It's not so much a fault as a shortcoming. The IHD extracts some of the meter configuration details - just not the RO. It could be a permissions thing - we'd have to ask the IHD manufacturers. I can't see any requirement in the SEC for an IHD to do anything other than retrieve the current tariff price. That being the case, with updates made every 10 seconds, I wonder if there's a mismatch in that the 'active' tariff price display also like the countdown follows the nominal TST so that during the delay period, the price shown is the one about to take effect instead of the one actually being applied. We'd need someone with a PC02 dual-rate tariff and a SMETS2 meter with a working IHD to check.

PZ19

QrizB said:

squirrelpie said:

QrizB said:

Akustik said:

My Economy 7 night rate is from 00:30 to 07:30, 

It almost certainly isn't.

I'm curious why you say that? I have an E7 tariff and UKPN are my DNO. My E7 times are 00:30 to 07:30 and that has been confirmed by Octopus to the Ombudsman.

I say that because every smart meter (and OP has a smart meter) has an offset to the half-hourly start times.

While it's possible that the OP, or you, have a zero-minute offset it's definitely not the norm.

Whenever anyone says "my Economy 7 period is .." and it's not got this offset, it means they're just quoting a nominal period rather than their actual switching times.

You say yout switching times have been "confirmed by Octopus to the Ombudsman". Have you actually checked them yourself? If you stay up until 0030, or wake before 0730, and check exactly what time your meter switches, there's a high chance it won't be 0030-0730 at all.

0037 to 0737 mine..watched it numerous times (very sadly!)