@transparent thanks for the mention and to someone here on this forum mentioning this discussion to me.

I can't necessarily answer all the questions and points made as some of this hasn't been decided or isn't public yet or is still evolving in the industry but I'll comment as best as I can.

Q on tariffs tied to a device.  I simply can't say if this will be the case with RED or any heat pumps we install, but if we did it wouldn't be the first time as for example we have the Tesla tariff that's specific to the Tesla Powerwall.  But in general the broader the better - we want to encourage the fastest path to a greed grid so the less restricted the better.  

Q on Works With. None of the products listed on that page have any proprietary tech from us installed in them but rather they've made APIs available that we've experimented with and we're able to work with them on getting the most benefit from grid flexibility with either using time of use tariffs (Go, Go Faster, Agile import/export, etc) or figuring out how they work with grid flexibility markets such as we're about to do with Powerloop.  Keep an eye on that page as there will be more to come.

Q on comparing cost efficiency between suppliers.  This is hard and there isn't an easy solution but BEIS did run a competition in this area although I've not seen much more happen since then https://www.gov.uk/government/publications/smart-meter-enabled-tariffs-comparison-project-smarter-tariffs-smarter-comparisons .  

Q on financial guarantees.  On our Agile page, some of our blogs and the Agile Ts & Cs we mention the risk.  But we don't offer any guarantee.  However none of the tariffs have an exit fee and most tariffs can be changed same-day by the customer without even needing to contact us.  

Q on foreign ownership. Lots of smart energy tech is owned by foreign as well as UK businesses.  Even smart meter manufacturers are a mix.  We're part owned by foreign investors already.  

Q on control and regulation. This is beginning to be addressed by government policy such as EV chargers being smart.  One example is the BSI written PAS 1878/79 standard which could become mandated.  These sorts of policies and standards are where we might see those sorts of risk being mitigated but it's very early days.  Also well aware too much regulation here restricts innovation so a balancing act.

Phil (yes, this Phil Steele)

Posted by: @philiprsteele

@transparent thanks for the mention and to someone here on this forum mentioning this discussion to me.

Q on tariffs tied to a device.  I simply can't say if this will be the case with RED or any heat pumps we install, but if we did it wouldn't be the first time as for example we have the Tesla tariff that's specific to the Tesla Powerwall.  But in general the broader the better - we want to encourage the fastest path to a greed grid so the less restricted the better.  

Phil (yes, this Phil Steele)

 

A Freudian slip perhaps?  I hope not! (my bold)

Tesla powerwalls are a bit different; they are a premium product for people who probably won't have any problems paying their electricity bills. 

What I'd be concerned about is locking people into an expensive tariff/monthly payments to pay for expensive hardware they don't really need.  A bit like the mobile phone market.  

@kev-m ooh crikey yes that should of course say green. Agreed - I hate lock-in too. 

@philiprsteele, welcome to the forums and we hope to hear more of your insights and thoughts.

A Greed Grid is an appropriate metaphor to describe the underlying reasons for the current energy crisis.

Posted by: @philiprsteele

control and regulation. This is beginning to be addressed by government policy such as EV chargers being smart.  One example is the BSI written PAS 1878/79 standard which could become mandated.

I'd like to pick up this point about the development of standards for Smart Devices which operate within the framework of Demand Side Response.

I'm puzzled as to why Octopus (and others) don't want to use the existing Auxiliary Load Control Switch (ALCS) system which already exists in our Smart Meters. Indeed this is now being extended to an Auxiliary Proportional Controller to facilitate the connection of variable-demand devices such as EV chargers.

In order to keep everyone in touch with this technical point, may I please first set up the basic background detail behind my question?

Our UK Smart Meters are connected to Energy Suppliers via a Wide Area Network (WAN) which includes a wireless section and the Data Communications Company (DCC)

The Comms Hub receives encrypted commands and sends back encrypted data. This provides the level of security required to prevent malicious attacks on the UK energy supply system.

There are about 100 possible commands, a summary of which are listed here on the Smart Me website.

A Comms Hub stores 13 months of data obtained from your electricity meter (and gas meter if you have one). This meter reading data is in (memory) registers for each half-hour. Our Energy Suppliers obtain that data, which is used to generate our bills.

The Energy Supplier cannot see the interim usage which is visible on our IHDs, and updated at intervals of around 10 secs or so.

Each Comms Hub has a minimum of 5 channels of ALCS, which operate across the Home Area Network (HAN). This is laid down in the specification which received Parliamentary approval in 2013.

The following diagram shows a range of domestic devices which could theoretically be governed via ALCS

It is highly unlikely that some of these will ever be available with an ALCS-aware control interface. For example, the Energy specialists, Regen, have demonstrated that the cost of implementing ALCS is not financially viable for washing machines and dish washers. But EV chargers and storage batteries would benefit:

There is one obvious drawback of deploying ALCS. The minimum interval for polling a Smart Meter is set at 30-mins. So if the tariff/management system being offered by an Energy Supplier requires an exchange of data or messaging at shorter intervals, then a different communications path must be used (ie Internet).

However, apart from security, there is one other advantage of using ALCS. Each Comms Hub has a defined, but random, time offset. The half-hour intervals which it defines, do not coincide with UTC/GMT etc.

Thus ALCS-enabled devices won't all suddenly draw power at midnight, even if those EV chargers have all been sent the command to start charging at that time. That's important because such a sudden demand would crash the National Grid.

I don't know what is the permissible range of that time-offset, but in theory it could as much as -15mins to +15mins.

The important thing to realise is that the meter readings being stored in the Comms Hub registers are for half-hour time-intervals which your Energy Supplier doesn't know!

This is why Smart Meter readings for the day shouldn't be requested by the Supplier just after midnight. If this were so, then the Comms Hubs on some sites wouldn't yet contain the final (48th) reading of the day because that time-interval wasn't yet completed.

This issue was discussed by OVO customers during 2020/21 when there was clearly a problem of 'missing data' which then got estimated in order for Bills to be issued.

Most of that very technical analysis was done via a private area of the OVO Forum to which customers could be invited. However, you can catch a glimpse of the level of detailed feedback by reading the public thread about Missing Data.

There's also an interesting followup thread 'We've had to correct your balance' which was started when OVO's in-house programmers caught up with some of the software bugs and changed the billing algorithm. This reworked the historical data which had been obtained from customers' smart meters and attempted to correct the latest bills to cope with the anomaly.

The detail of those discussions need not matter much. The actual values of the errors weren't very large because all of the customers were on annual contracts (not Time-of-Use tariffs). But it does illustrate why it's important to align customers' bills with the time-periods set by their Comms Hubs rather than UTC.

Let me pause at that point before I dive in and use this background knowledge in my question to @philiprsteele

@transparent Hah, fair play - witness the oil and gas producers booking record profits.

@transparent You know your stuff - very well described.  ALCS is fairly complex to use even though the result is really simple as well as depending if you've got the ALCS wiring connections available on your smart meter. It's in use today with storage heaters. We're trying out proportional ALCS on EV chargers with Trojan https://www.trojanenergyltd.com/projects/smartstep but too early to share how well it works and if it could ever get past the research step.  I'll be writing a blog article on SmartSTEP in a few months time.

You can also see some of the thinking in the BSI PAS 1878/79 standard too - no mandate to use the smart meter infrastructure but it's written about as one option.  I'm a little wary of going that path just for the sake of security and time randomisation when there's plenty of examples of great IOT networks and service running on the internet.  But perhaps the biggest advantage of not going via the DCC is greater innovation than being constrained to a very specific design.

Agreed, HH data timestamps are billed to the meter time not UTC.  Interestingly that sort of randomisation and varied meter time causes issues if you're using a smart EV charger, or other smart device, that's relying on UTC.  For example setting that device to start at 00.30 (Go start period) but that's actually 00.25 meter-time.

Posted by: @philiprsteele

...if you've got the ALCS wiring connections available on your smart meter. It's in use today with storage heaters.

To allow others to follow this discussion in future, let me point out that Smart Meters can have two sorts of hardware control over external loads.

The one which @philiprsteele is referring to here is the 5-terminal SMETS2 meter. This has two live output terminals, each having its own 100A relay.

The 5th terminal is switched by the Energy Supplier using the ALCS software control channel. This is most commonly used to turn on storage radiators under an Economy-7 tariff.

The concept of 'Economy 7' will need to change shortly. At present it makes use of 'cheaper' electricity during the small hours of the morning when demand is lowest. However, the uptake in EV chargers means that this period is destined to become much more heavily loaded.

Although Energy Suppliers, such as Octopus, may wish to continue offering an overnight E7 storage radiator tariff, in practice they will be forced to abandon it. The majority of underground substation feed cables in residential areas aren't able to carry the additional current required for EV chargers without overheating. The subsequent increase in fault-levels and transformer losses run counter to the RIIO-ED2 obligations which Ofgem requires the DNOs to implement.

Posted by: @philiprsteele

Agreed, HH data timestamps are billed to the meter time not UTC.  Interestingly that sort of randomisation and varied meter time causes issues if you're using a smart EV charger, or other smart device, that's relying on UTC.  For example setting that device to start at 00.30 (Go start period) but that's actually 00.25 meter-time.

So we are in agreement about how this offset works. I'm glad to have that confirmed.

I'm assuming that the 'issues' which @philiprsteele refers to are being caused precisely because Octopus is indeed using the internet to send its command signals to an EV charger. It's that use of the internet which makes the charger 'rely on UTC' rather than anything in the charger design per se.

Let me illustrate this with a diagram with a theoretical lower-cost slot between midnight and 00:30, during which a device is to be switched on:

In this scenario I've assumed that the Comms Hub has a random offset which happens to be minus 4m 40s.

The 'Turn-on' command is sent across the internet at midnight, 4m40s after the electricity meter has already started the slot being charged at 19p/kWh.

When the device is switched off it therefore uses a few minutes of the following time-slot, being charged at 28p.

Octopus can't detect this because Comms Hubs don't report what their internal timing is. So the customer ends up with a bill that's 12.5% higher than it should be... and presumably in breach of their Ofgem licence.

Have I interpreted the situation correctly, Phil?

There are solutions and workarounds for this problem. But the way in which this is achieved is important. It can leave a consumer locked into an Octopus product, which is precisely what Phil and @kev-m said they don't like.

@transparent

I appreciate that the Smart meter providers have to stagger the switching on of time relevant events such as Octopus Go at 00:30, from all occurring at actually 00:30 and possibly causing overloading of the grid. For obvious reasons they cannot inform customers of their particular offset, otherwise it would defeat the object of staggering the timing in the first place.

If the staggering is being performed within +/- 15 minutes of the specified time, then to be on the safe side, Octopus Go customers would need to switch on their device no earlier than 00:45 and switch it off no later than 04:15. This of course reduces the guaranteed low rate period from 4 hours to only 3.5 hours. Either Octopus and the other providers of lower rate overnight tariffs need to adjust the billing to prevent overcharging, or at least make their customers aware that overcharging may be occurring.

As more EV's and battery storage systems are installed, how much longer with lower rate overnight tariffs still be available?

@derek-m It would be more relevant to saving co2 if the tariff was directly related to the mix of renewables at any given time, rather than the time of day.