Posted by: @transparent

↑

It's commonplace for Suppliers to remove customer comments about billing accuracy from their blog pages, and say that these cannot be discussed due to client confidentiality.

Culture of secrecy and denial?

Posted by: @transparent

↑

the Office of the Energy Ombudsman is restricted to settling only individual cases from that customer.
They don't have the remit to cross-check billing issues affecting multiple customers.

Lack of oversight over a complex project handling large amounts of money? Where have I heard this before?

Posted by: @transparent

↑

Suppliers who have occasionally stated how their billing system works are saying that it applies the costs retrospectively.
That means they receive the 48 half-hour readings for the previous day, and their in-house software applies the price which should apply to each period.

The smart in smart meter system seems to be too fragile/tricky to be of use for billing. What hope for load shedding? Perhaps this was designed before the ubiquity of home broadband, but putting lots of logic in the meters (and having different meters and software contained within) looks rather complex from today's perspective.

How have other countries approached making their metering smarter? Do any use internet connections for relaying meter readings (and load shedding commands)?

@transparent everything I have read on the Octopus website and elsewhere mentions the IHD doesn't correctly display any tou cost data including Go.

https://octopus.energy/help-and-faqs/articles/i-m-on-a-smart-tariff-and-my-meter-s-in-home-display-ihd-screen-isn-t-working-properly/

Do you know any more about this? For example is this due to smart meter or comms hub limitations or IHD or supplier or something else?

So I would be tempted to ignore any price data on your IHD? Is that what you do normally?

It is interesting your kWh data isn't correct on your IHD, have you figured out why? Was the smart meter also incorrect? 

I think all suppliers also caveat we shouldn't rely on cost data we see on the IHD or meter, rather we should check the kWh and costs on our bills. I find it interesting even for non tou tariff the tariff information on the IHD and meter can sometimes be incorrect, especially every quarter when the standard variable rate changes, but also at other times. Am never sure if this is suppliers not transmitting the data or other issues.

Has anyone ever mentioned any capacity limitions in the DCC setup to pumping out tou tariff tables every day to smart meters? It it viable currently with the technology available?

Posted by: @chickenbig

↑

Culture of secrecy and denial?

[...]

Lack of oversight over a complex project handling large amounts of money? Where have I heard this before?

This Smart Meter issue is more similar to Post Office 'Horizon' than it is to HS2.

Our equivalent of HS2 in the energy sector is the proposed massive upgrade of the electricity grid, which is far beyond what GB can afford.
I'll pick that up on a separate topic. This one on National Grid upgrade strategy would be most appropriate.

Posted by: @chickenbig

↑

The smart in smart meter system seems to be too fragile/tricky to be of use for billing.

Not so. The Smart Meter design is excellent and well thought through.

It's the choice of Energy Suppliers to retrospectively apply the charges without the price-points being downloaded into the ESMEs.
From their perspective that should still be OK.

If that was all they were doing, then it would still produce correct billing.

The issue they've overlooked is that Smart Meters don't operate according to UTC (the internet clock).
Smart Meter timing for the start of the half-hour period is subject to a randomised offset between 1-sec to 1799-secs.

Can we leave that point to the side for the moment, and keep focused on whether ToU tariff pricing is or isn't in our meters?
I promise I will return to the Randomised Offset shortly, but it would too confusing to unravel both issues at the same time.

Posted by: @jeff

↑

everything I have read on the Octopus website and elsewhere mentions the IHD doesn't correctly display any tou cost data

I agree.

That Octopus article is clear and helpful (although I don't understand the hamburger reference).
I'm well aware that (neither of) my IHD(s) are working correctly.

Whilst I'm so busy looking into the issues on the Smart Meters themselves, I've been completely ignoring my IHD.
There's only so many errors that I can cope with tracking at the same time.

[Aside] I don't like the current approach to IHDs.
They are geared around displaying only the data of what has already just happened... up to 13-months ago.

Think of this from the viewpoint of a consumer with a pre-payment meter.
They are likely to be tracking their usage more closely than those of us on monthly credit accounts.
But what they really want to see is a forwards projection as to when their money will run out.

Yes, I'm working on this.
But yet again, can I please ask that we don't get sidetracked on that issue immediately?
I promise I'll return to it... and probably on a new topic.

Posted by: @jeff

↑

Has anyone ever mentioned any capacity limitions in the DCC setup to pumping out tou tariff tables every day to smart meters? It it viable currently with the technology available?

There's no capacity constraint with this being handled by DCC.
The amount of data to be transferred is trivial.
I imagine they'll give it a lower priority than recovering the previous day's consumption registers, and therefore won't be doing it straight after midnight!

The ToU tariff is a 48x1 matrix each day.
I'll have to recheck the SMETS2 specification to see how the price data is defined.
It's unlikely to be any more complex than an integer value in tenths of a pence, don't you think?

Posted by: @transparent

↑

The issue they've overlooked is that Smart Meters don't operate according to UTC (the internet clock).
Smart Meter timing for the start of the half-hour period is subject to a randomised offset between 1-sec to 1799-secs.

Can we leave that point to the side for the moment, and keep focused on whether ToU tariff pricing is or isn't in our meters?
I promise I will return to the Randomised Offset shortly, but it would too confusing to unravel both issues at the same time.

Sorry about my side-tracking. Isn't this the crux of the issue of why energy companies do not upload tariffs into the smart meter? The smart meter would "bill" according to the per-meter offset rather than the consumer-understandable UTC. How would you explain to the person on the street that their smart meter has an (random but consistent?) offset that might materially affect their energy bill. Some lucky people would be able to heat up their can of beans and make toast with non-peak electricity whereas the person next door might be charged n% more while heating it up at the same time. Instead the energy suppliers have sensibly decided to bill according to wall-clock time (modulo daylight savings and leap second offsets) and ignore this complication.

Well it's not so much of a side-track, but a separate entity.
I'll explain the issue, but let's try not to muddle them together.

To make smart use of a ToU tariff I also need to know both the ToU price matrix and the Randomised Offset for my particular meter.
They are two separate, but inter-related, features of a Smart Meter.

There are two random numbers within the calculation for the Randomised Offset.
One of these (the Randomised Offset Limit) is programmed into the ESME at the time of manufacture. It's fixed for that meter.
The other (the Randomised Offset Number) could theoretically be (re-)set by DCC. It too is set to 'something' at manufacture because it cannot be zero.

The outcome is that the time periods in a Smart Meter are delayed by a number of whole seconds between 1 to 1799.

For this illustration I'm going to imagine the following scenario.
I have a ToU tariff with a standard rate of 43p (per kWh) and a cheap rate of 12p which starts at midnight.

Unknown to me, my Smart Meter has a Randomised offset of 460-secs (which is statistically close the average possible delay).

I look at my watch and manually turn on a device at midnight for 30mins.

When my Energy Supplier collects the consumption data, he'll bill me for 7mins 40 seconds at standard rate, and 22mins 20secs at cheap rate.

Alternatively, if my Energy Supplier had used the inbuilt features of the Smart Meter to turn on the same device, it wouldn't actually switch on until 00:07:40, but the bill would be correct.

For the moment ignore how that is technically achieved and just concentrate on the timings.
When the Supplier collects the 48 consumption readings for the day he has no idea that Register-1 didn't actually start until 00:07:40.
They are just a set of 48 numbers which get fed into the Billing System software.

According to DESNZ, the Supplier can actually pick up the Randomised Offset.
But the SMETS2 specification doesn't state that.
Nor do we know if any Supplier is sufficiently aware of the potential for billing errors that they bother to retrieve that Offset Delay when they read the meter.

For the record, Incorrect Billing is regarded by Ofgem as one of the most egregious breaches of Licence T&Cs.
Fines (or voluntary donations in respect of an admission by the Supplier) run into many £millions.

Posted by: @transparent

↑

When the Supplier collects the 48 consumption readings for the day he has no idea that Register-1 didn't actually start until 00:07:40.

What did the supplier promise to the consumer? Cheaper rate from midnight (local time)? This division of the day into 48 buckets with a deterministic offset gets in the way of correct billing, from a customer perspective.

In the Victorian days each town had a local time, but the arrival of the railways pushed for a unified time zone to simplify operations and consumer interactions. Yes the per-town offsets made sense, since measuring mid-day relied on the sun or stars. But at least they didn't have per-house times.

Posted by: @transparent

↑

if my Energy Supplier had used the inbuilt features of the Smart Meter to turn on the same device

This line of thought rather shifts responsibility for correct time of use onto the consumer (as well as the Supplier to program the tariff transitions, depending on where the transition signals come from, taking us back to the starting point of this separate entity).

It's important to see this from the viewpoint of the grid rather than individual consumers.

We can't afford to build a grid or power-generation facilities which can cope with demand surges based on 'absolute time'.
That's why the SMETS2 designers created the Randomised Offset feature.
The surges need quenching by staggering demand across time.

The actual offsets have to be made random throughout every part of the electricity network.
You can't have locational-based timing or phase-based timing or any other type.

I would love to be able to offer device-controllers which utilised the ToU matrix within the Smart Meter.
But I can't do so if the Suppliers themselves won't populate that matrix with the prices.

... and that brings the discussion full circle!

First we need Suppliers to implement the Smart Meter specification, and then the smart technology will follow.

Posted by: @transparent

↑

...

I would love to be able to offer device-controllers which utilised the ToU matrix within the Smart Meter.
But I can't do so if the Suppliers themselves won't populate that matrix with the prices.

... and that brings the discussion full circle!

...

I agree on all counts. Yes, we're back full circle and the smartest part of smart meters is essentially unusable without the suppliers populating the data. If the regulator has the teeth to oblige the suppliers to do this, the regulator should be enforcing it.

Posted by: @transparent

↑

First we need Suppliers to implement the Smart Meter specification, and then the smart technology will follow.

Agree with the first part but not necessarily the second. I believe the smart tech using smart meters as their tariff data source will only follow if there is a benefit to the manufacturers.

As far as I can see, the whole reason for the time offset is to benefit the grid. I understand the reason for it, but there is no direct benefit to the consumer, to the energy supplier or to the smart tech manufacturer. If that's the case, I would expect the following to be true:

• Given the freedom to do so, the energy supplier will take the path of least resistance and greatest benefit and will make the tariff data available via an API. If required to do so they will also download tariff data to the smart meter.
• The manufacturer will avoid unnecessary costs and will therefore only add the tech necessary to read smart meter data if they are convinced the consumer will wear the extra cost and not doing so will damage sales.
• Most consumers will continue to use electricity when they want it rather than planning ahead. If they have smart devices they will simply expect those devices to take ToU prices into account and an approximation that's easy to set up will be good enough.

If, given all this, the consumers are then told the smart meter time offset is costing them money they will either not care much or likely see the attempt to enforce a smart-meter-centric ecosystem as another example of costly Government interference. Doesn't mean it's right, but that won't affect the perception of it all.

If anything is to move towards greater involvement of smart meters I believe the following things have to happen:

• The regulators have to enforce that tariffs are provided to the smart meters as per the specifications by the energy suppliers.
• The general public have to become convinced that the way smart meters work is a good thing generally and provides a benefit to each individual user (i.e. that the Government isn't an interfering villain, but that the techie way smart meters have been designed is a little financial guardian angel doing its stuff for us all without us having to understand it).
• The smart meter coverage area needs to be close to 100% of the country. Without that, an alternative (i.e. APIs) will always be essential and even then any strategy will just be seen as a plan for the lucky ones.

Posted by: @transparent

↑

It's important to see this from the viewpoint of the grid rather than individual consumers.

...

Why, though? The grid is there to serve the customers, not to exist in its own right. I would argue it's essential to see this from the viewpoint of individual consumer and, if there is detriment to the grid, to see that too from the viewpoint of the consumer. Any peak load issues are only important if they cost consumers money, cause consumers loss or degradation of service or have knock-on consequences consumers would view as bad (e.g. having to fire up fossil fuel power plants).

Eventually, people don't like arguments that are synonyms for "it's for your own good". They want to know the effect on them personally, even the compromises.

Posted by: @transparent

↑

...

That Octopus article is clear and helpful (although I don't understand the hamburger reference).

...

If you follow the link, the Octopus page has a button at the top left saying "Menu" next to three horizontal lines. Those horizontal lines form a symbol that is very common on web pages and is called a Hamburger.

@majordennisbloodnok

Or alternatively they could just tell consumers what offset has been applied to their meter. The consumer would then be able to set the correct times to obtain maximum benefit from their TOU tariff. Simples. 😎

The grid would be happy since everyone would not be starting to charging their EV's and battery storage systems at the same time. The consumers would be happy since once the timing has been set they could be confident that they are making the best use of their TOU tariff. The energy suppliers and equipment suppliers would be happy since they don't have to do anything.

Posted by: @majordennisbloodnok

↑

Posted by: @transparent

↑

...

That Octopus article is clear and helpful (although I don't understand the hamburger reference).

...

If you follow the link, the Octopus page has a button at the top left saying "Menu" next to three horizontal lines. Those horizontal lines form a symbol that is very common on web pages and is called a Hamburger.

 

I learn something new almost every day. 🙄