Economy 10 & Smart Meters

Yarrows

Bright do apply BST in that they've told me the app takes the time zone of the device you're running it on.

I am on a fixed E10 tariff but I've put 3 manual tariffs in, one till the last Sunday of October in BST times, one from then till the end of March in GMT, then again from then till the end of the fix in BST.

Previously I tried to force the app to stay on GMT but that didn't seem to work, hence the workaround.

(I actually have the Bright IHD but the DCC seems to report my tariff as only on peak rate 1630-2030. If only! So I delete the DCC tariff whenever it reappears, about twice a week, and use my manual tariffs. I don't find it very onerous and the cost calculations end up within a penny of the supplier's IHD - and sometimes more accurate because I've seen the supplier's one show a different cost for the day around midnight and then correct itself to similar to the Bright value by later the next day. Bright would be even more accurate if the manual tariff entry let me put in the real times my meter changes rate and not the nominal times - luckily my offset is only 5 minutes.)

debitcardmayhem

@PZ19 Does EDF app/web site show half hour data ? I would assume that you’re not getting HH anywhere 

Scot_39

As in the Rosie1001 example the ALCS calendar timings and the tariff timings got out of sync - even in a single element - and it's possible your's are out of sync - on the secondary at least - given the 5/4 kWh split in the 9kWh total overnight.

I was guessing your 9kWh over 5 hours meant a small medium sized heater around c1.8kWh - do you kow the actual input power ?

On for 5 hours doesnt mean charging for 5 hours - even from cold.

The Aclara spec refers to separate TOU matrix parameters for secondary element - page 40.41 - if someone more familiar with meter operation could look and see if I'm just completely misinterpreting that section.  But different timings would perhaps explain the 5/4 split.

I wonder if they have set one set of tariff times to E7 - and maybe EDF have set secondary if its even possible - one to those timings - as we have your offpeak to peak rate observations in the end of ALCS window for the primary rate 1.

And the ALCS start could overlap with the 00:00 to 02:00 as well - so 00:15 to 02:15 - or if were GMT --> 01:15 ->0315 in your actual DST case and the end (the 07:15 to 10:15 or again is that 08:15 to 11:15?).

Phones4Chris

Yarrows said:

Bright do apply BST in that they've told me the app takes the time zone of the device you're running it on.

I am on a fixed E10 tariff but I've put 3 manual tariffs in, one till the last Sunday of October in BST times, one from then till the end of March in GMT, then again from then till the end of the fix in BST.

Previously I tried to force the app to stay on GMT but that didn't seem to work, hence the workaround.

Bright can be confusing in that respect.
It shows the Tariff rates on the Home page (taken from the meter) in GMT.
If you are displaying Energy (not Cost) then during BST periods if eg. your off-peak is due to start at 0030 GMT then the App usage will show it starting at 0130 BST. However if you change to show cost, it is wrong as it calculates that using the GMT timings. Eg. at the end of the E7 off-peak at say 0730 GMT ie 0830 BST, it's calculated the cost of those last two half hour slots at peak rate! That's always been the case which is why I do NOT rely on the costs the App shows, just Energy, and do my own calculations if I really want to look at cost.
The last time I tried to manually change the Tariff settings to BST, they would not stick as other users also discovered (there's a thread from a while back mentioning that). The App has supposedly been updated since then and I haven't tried again with the tariff times, may do if I'm feeling bored.
My recommendation to people is not to rely on the cost figures for accuracy as they also don't take into account any meter off-set which cannot be obtained by the App (nor the supplier AFAIK), you have to check your own timings.

Phones4Chris

Scot_39 said:

The Aclara spec refers to separate TOU matrix parameters for secondary element - page 40.41 - if someone more familiar with meter operation could look and see if I'm just completely misinterpreting that section.  But different timings would perhaps explain the 5/4 split.

Correct. Different parameters can be applied to the secondary element.
There's nothing in the manual that suggests the ALCS timings have to be identical to the tariff rate timings !! Indeed we know that there are instances where they certainly haven't been (as quoted).

If a customer has a bog standard E7 tariff, then even on the 1422-B, there's no reason why the tariff rates of both the Primary and Secondary elements shouldn't be identical and consistent with the ALCS timings.
On a more complex tariff (who knows if EDF are regarding say E10 as more complex), or indeed if they decide that for some customers wanting extra hours for heating, that they may decide to charge different rates for/because of the "extra" hours BUT then one might expect the ALCS timings to be consistent with the relevant Secondary Tariff rates?
We don't know at this point if the ALCS is actually set correctly for what EDF intend to provide or if the secondary Tariff rates are set correctly. Until EDF get back to @PZ19 and tell him how they are going to be charging for what, the rest is pure speculation.

Phones4Chris

PZ19 said:
I also now have access to bright app and data is Being sent to them so that’s handy, although the cost seems a little on low side but that’s probably because I don’t do midnight to midnight calculations.. on bright they say off peak is 0030-0730.  Although it does appear on further investigation Bright is getting the water/heat readings

Be careful how you interpret the Bright data as noted in my other post. I'd stick to Energy usage, so as not to get confused (should be easier to tally with meter register readings as well).

The data you've got is interesting, what I can't be certain of, is which "registers" Bright get the tariff data from. Whatever, the 0030-0730 will be GMT and doesn't take account of your 15 minute offset (another reason cost calculations may be somewhat inaccurate). When you say it's getting the water/heat readings, are you matching that with the 9kWh Secondary usage? Note, you didn't say what the overnight Primary usage was, which is why it'll be much better to have all 4 register readings.
I've no idea (yet!) how Bright is going to cope with this twin element meter and what usage registers it will look at. In case you didn't know it doesn't(can't) look at the meter reading registers (only suppliers can look at them).
Also remember the App won't always be fully up-to-date, sometimes there's a delay of a day or two if their servers are busy doing whatever they do rather than collecting user data.

Yarrows

Phones4Chris said:

Bright can be confusing in that respect.

It shows the Tariff rates on the Home page (taken from the meter) in GMT.
If you are displaying Energy (not Cost) then during BST periods if eg. your off-peak is due to start at 0030 GMT then the App usage will show it starting at 0130 BST. However if you change to show cost, it is wrong as it calculates that using the GMT timings. Eg. at the end of the E7 off-peak at say 0730 GMT ie 0830 BST, it's calculated the cost of those last two half hour slots at peak rate! That's always been the case which is why I do NOT rely on the costs the App shows, just Energy, and do my own calculations if I really want to look at cost.
The last time I tried to manually change the Tariff settings to BST, they would not stick as other users also discovered (there's a thread from a while back mentioning that). The App has supposedly been updated since then and I haven't tried again with the tariff times, may do if I'm feeling bored.
My recommendation to people is not to rely on the cost figures for accuracy as they also don't take into account any meter off-set which cannot be obtained by the App (nor the supplier AFAIK), you have to check your own timings.

Hm, on closer inspection and comparing to my supplier's app, the kWh values during BST are out by an hour ie to get the Bright value for a given day to match the supplier's info, I need to take away that day's midnight hour usage from the Bright app and add the usage from the next day's midnight hour. 

But because I've entered the rates on Bright using BST times, at least the cost that hour is correctly being calculated at the right rate, even if it's being attributed to the wrong day - I've just checked that too against the supplier's app (allowing for VAT and the standing charge which my supplier doesn't add in to the usage data...). It will be a bit out over the weekend the clocks change though.

Basically, for longer periods like months or years, Bright looks to be accurate enough with E10 for my purposes when configured manually (given my meter's small offset as well).

(Sorry for continuing the tangent!)

Ildhund

Phones4Chris said:
The data you've got is interesting, what I can't be certain of, is which "registers" Bright get the tariff data from. 

It is really frustrating not being able to see all the settings the supplier may have applied to our meters. It would make in-home troubleshooting so much simpler in many cases.

There is at least one source available to the determined sleuth: n3rgy's adapter gives access not only to half-hourly usage data, but also to the tariff switching table. I say 'determined', because there are a few hoops to jump through to get there:

• Sign up for a 'consumer' account at n3rgy - Unified access to smart energy data;
• Sign up with one of n3rgy's business customers, who will see to authorization for n3rgy to retrieve data from your meter (I signed up with Equiwatt - it's free, but they do expect some participation in their DFS events);
• Sign in to n3rgy as a consumer;
• Follow the prompts to access and download your tariff data.

This should result in a text file containing the meter's tariff switching table in JSON format. I can't imagine what this looks like for a twin-element meter; it's complicated enough for my own simple arrangement (ordinary 5-port SMETS2 Aclara configured for E7 with both tiers set to the same single rate). I don't know if @PZ19 is at all interested in looking into this, but it might be fascinating for some of us.

One really important set of information the customer seems absolutely barred from accessing is the ALCS calendar. It's only a subset of suppliers' staff who have the elevated permissions needed to amend this calendar, that controls when the restricted feed is switched on and off. This is why it's a real problem for those in a no- (or poor-) WAN situation whose ALCS needs attention, because it can't be changed locally. 

We'd perhaps have to ask Bright to find out how they cope with twin-element metering systems.

Scot_39

@PZ19, Just a quick check.

RE - Your reference to a light on the water heater.

It twigged last night about an error made in another thread.

I went through a couple of posts in another thread assuming the reference to a red led light on the off peak timer and peak boost switch meant the off peak supply was active.  (Maybe another reason ivd got a bit of a block about asking about LEDs)

Turned out it was only connected to the live feed - and that off peak led on the unit was just an indication of programmed times.

The OP property had a Horstman water timer

https://forums.moneysavingexpert.com/discussion/6613730/economy-7-and-energy-usage-concerns-in-new-flat

So to clarify when @Phones4Chris was talking about an led on a switch - that was to get a true indication of off peak supply live. 

Which can be the case for wall switches with a neon indicator built in e.g. so think more like

https://www.screwfix.com/p/lap-13a-switched-fused-spur-with-neon-white/79474

But that only 13A  - that site has a few 13A examples,  not sure if othees have similar for the higher rated 16A Id expect for an immersion heater switch or a nsh (my largest nsh pulls c3.6kWh - 15A at 240V -its fuse box breaker 20A)

Scot_39

Ildhund said:

Phones4Chris said:
The data you've got is interesting, what I can't be certain of, is which "registers" Bright get the tariff data from. 

It is really frustrating not being able to see all the settings the supplier may have applied to our meters. It would make in-home troubleshooting so much simpler in many cases.

There is at least one source available to the determined sleuth: n3rgy's adapter gives access not only to half-hourly usage data, but also to the tariff switching table. I say 'determined', because there are a few hoops to jump through to get there:

• Sign up for a 'consumer' account at n3rgy - Unified access to smart energy data;
• Sign up with one of n3rgy's business customers, who will see to authorization for n3rgy to retrieve data from your meter (I signed up with Equiwatt - it's free, but they do expect some participation in their DFS events);
• Sign in to n3rgy as a consumer;
• Follow the prompts to access and download your tariff data.

This should result in a text file containing the meter's tariff switching table in JSON format. I can't imagine what this looks like for a twin-element meter; it's complicated enough for my own simple arrangement (ordinary 5-port SMETS2 Aclara configured for E7 with both tiers set to the same single rate). I don't know if @PZ19 is at all interested in looking into this, but it might be fascinating for some of us.

One really important set of information the customer seems absolutely barred from accessing is the ALCS calendar. It's only a subset of suppliers' staff who have the elevated permissions needed to amend this calendar, that controls when the restricted feed is switched on and off. This is why it's a real problem for those in a no- (or poor-) WAN situation whose ALCS needs attention, because it can't be changed locally. 

We'd perhaps have to ask Bright to find out how they cope with twin-element metering systems.

Wow thats a lot of steps.
Or to get others to help you do so - like here or even at suppliers.
As even what CS think has been sent often hasnt a la Rosie1001 threads.
I can see my spot active rate for instance but not the table times - i seem to remember some meters would display that - meaning id potentially have to look at rates around the precise time  - by several narrowing windows - not fun if say middle of night even with the ihd echoing tge p/kWh rate - and worsd on meter itself if outside or a communal block cabinet.

My ihd makes it easier on rste switching but not everyone gets those - and for alcs if quiet I can even hear my 4 port driven external proteus click despite it being in an outside cabinet even if no devices active (off or on but in thermostat cut off).

Interesting that ALCS cannot be programmed locally.

Re bright - Think PZ19 said couldn't see the 9kWh // secondary readings in the app in his later update.