I understand, @transparent, but there's a bit of a disconnect going on here. You talked about smart meters as the delivery platform for "all 'smart' devices which are required to respond to ToU tariffs". Using home automation systems is not about devices that are required to respond but about deciding how you want them to respond. There is no mechanism within the smart meter system for end users to make their own choices about how they want different devices to interact.

For instance, I have an integration with two separate weather forecasts and a solar generation forecast as well. That means I can make an informed prediction about what the likely home-grown energy production will be and I can tie that prediction with known day-ahead prices to decide whether or not to control my ASHP (and battery when I get Modbus working 😉 - thanks for nothing, Growatt) in one way or another. None of that would be possible if the smart meter network did the delivering.

As for the specifications themselves, they have been admirably forward-thinking but were still put together in the full knowledge that progress marches on. Some of the aspirations in those specifications are now obsolete in the face of what is now both practical and commonplace that wasn't when the discussions were being had. The security involved in Octopus' API, for instance, is perfectly adequate for the actual data being transferred. Is it perfect? No. Is it proportionate? Yes.

I agree that ToU tariffs, where offered, should be downloaded to customers' smart meters so the delivery mechanism can be used where wanted. However, I do not feel that a one-use-fits-all strategy should be imposed on customers; it should still be a choice. My choice is to set up a central "hub" that I have control over and that I can configure to get my kit acting the way I want it to.

@transparent At 76 YOA, I am hoping to see 100 YOA, that should be time for the various and disparate groups to co-operate and come up with a solid system, perhaps based around the smartmeter as the hub.😉 Regards, Toodles.

Posted by: @majordennisbloodnok

↑

You talked about smart meters as the delivery platform for "all 'smart' devices which are required to respond to ToU tariffs". Using home automation systems is not about devices that are required to respond but about deciding how you want them to respond.

Erm... no.
I mean exactly the same as you.

If I want/require a device in my home to switch on/off according to price triggers from a ToU tariff, then I should be able to pick up that data via the Smart Meter.

That strategy comes straight from the 2015 Government Policy "Demand Side Response"

I too am combining this price data with other sources.
Weather is an obvious one. Predicted outdoor temperatures and anticipated hours of sunlight for solar panels are fed into the mix.

In my case I can also receive data, up to 6 days ahead, showing the proportion of my electricity which comes from fossil fuel sources, and when there will be excess generation being discarded in my area. That can be used to calculate, for example, the charge-current to be applied to my storage batteries, spread across the number of half-hour periods in the next low-cost ToU session. If I know how much solar can be harvested from my roof throughout the next day, then the 'system' can apportion the joules being imported from the grid during the preceding night.

However, we differ in our interpretation of the internet being 'secure'.
I'm using it in the same sense as DESNZ, where it should better be understood as 'resilience'.

I'm not considering it from the viewpoint of the consumer, or how 'private' you think your energy data should be.

There are a number of wider issues to consider. Amongst these are

• the likelihood of a server being out of commission due to attack from a 'hostile actor'; ie sudden loss of data affecting all customers of that Supplier
• incorrect data being input to the API which you're relying on to receive your tariff information; There are sanity checks on the Smart Meter route to reduce susceptibility
• the time offset between internet time (UTC) and the internal clock of your Smart Meter; leading to incorrect billing

@transparent, thanks for the clarification; I understand.

Nonetheless, there are still a few points worth discussing.

Firstly, the issue of using the tariff information held on the smart meter. Whilst I agree that suppliers should be downloading that data onto the smart meters so they could be used as outlined in the strategy, the reality is that accessing that data requires a separate box - a Consumer Access Device - to bridge between the home network and the smart meter. Although some in house displays are capable of doing this, in most cases this means buying more kit. This leaves the home owner with a choice; spending on more hardware or use the Internet at no extra cost. I can't see a reason for spending unnecessarily.

Secondly, your list of issues.

Posted by: @transparent

↑

...

However, we differ in our interpretation of the internet being 'secure'.
I'm using it in the same sense as DESNZ, where it should better be understood as 'resilience'.

I'm not considering it from the viewpoint of the consumer, or how 'private' you think your energy data should be.

There are a number of wider issues to consider. Amongst these are

• the likelihood of a server being out of commission due to attack from a 'hostile actor'; ie sudden loss of data affecting all customers of that Supplier
• incorrect data being input to the API which you're relying on to receive your tariff information; There are sanity checks on the Smart Meter route to reduce susceptibility
• the time offset between internet time (UTC) and the internal clock of your Smart Meter; leading to incorrect billing

The smart meter home area network is basically a lot of devices talking via a mobile provider. Since I'm in the South East, that provider is O2. Realistically, I have seen more mobile provider outages than losses of service with Octopus. Moreover, if a hostile actor managed to hit O2 the resilience you're talking about would be hit just as severely as if Octopus were hit. It's not about a server being taken out of commission (physical hardware redundancy is taken as a given these days) but about attacks on a whole company's systems or on their data and the infrastructure of the Smart Meter Home Area Network is just another target.

As for ensuring correct data, I'm quite happy to accept there are checks on the Smart Meter route, but that is only relevant if those checks are not made on the API route. Is there any information available about how many times the Smart Meter checks have found an error? I wouldn't want to lose the double checks but if they're never triggered then it's not really an issue.

The time offset is an issue. No doubt about it. A big issue? No idea.

Posted by: @majordennisbloodnok

↑

the reality is that accessing that data requires a separate box - a Consumer Access Device - to bridge between the home network and the smart meter. Although some in house displays are capable of doing this, in most cases this means buying more kit.

Erm, I agree only partially.

You're seeing this from the viewpoint of an individual consumer...
... a nerd with enough technical knowledge to want to integrate this tariff data into their own system. 😎 

I'm thinking far wider than that.
No commercial company or developer can design a smart EV-charger or Storage Battery to use tariff period costings because their product would be unable to obtain that data from a Smart Meter.

It would cost about £5 to incorporate the Zigbee chip and HAN Aerial into such a product.
That's almost insignificant. You'd recoup that outlay in the first day of using the product!

I'm a member of the SEC.
I know exactly what costs and protocols are required for a company wishing to obtain a licence to communicate with a Smart Meter in this way.
But there's no point in pursuing that strategy until Energy Suppliers are required by the regulator to comply with the SMETS2 Specifications.

Yes and no. I'm certainly seeing it from the viewpoint of the customer but not just as someone who can do it himself. I'm also not ignoring the commercial side since that is how the non-nerds will eventually get the same capabilities as the tech-savvy.

Posted by: @transparent

↑

...

I'm thinking far wider than that.
No commercial company or developer can design a smart EV-charger or Storage Battery to use tariff period costings because their product would be unable to obtain that data from a Smart Meter.

...

Commercial companies can and have designed smart storage batteries to use tariff period costings. They might not be able to get the data from a smart meter but they can get it from APIs and that won't change unless the regulator not only requires energy companies to download tariff data to smart meters but also prohibits them from providing the data in any other way.

What commercial company will install an extra £5 of components (plus the extra R&D for integrating the software to use said components) if they don't have to? I'm happy to admit that each API will provide the data in a company-specific way, but the delivery mechanism is basically the same and therefore easy enough to programme for. What is, of course, being hampered by energy companies not downloading their tariffs to smart meters is the ability for smart device manufacturers to get the TOU data in a standard and provider-independent format. Whether that is significantly detrimental to customers is a separate question.

One issue that has not been mentioned, though, is that one or two energy companies are truly innovating and if someone comes up with a new way of pricing (e.g. some kind of TOU tariff that is also on a sliding scale based on previous consumption) then it may well not be possible to shoe-horn that logic into a smart meter standard format. I don't know exactly how flexible the smart meter is in the way it can hold tariff information but I do know that an API is only limited by the energy company's imagination.

I'm not against smart meters as a vehicle for disseminating data but I am very much for market choice. I think that if the regulator can require companies to make their tariffs available to the smart meters then the regulator should enforce just that, but I would strongly defend the use of APIs by the customers, the smart device manufacturers, the energy companies and anyone else who might wish to.

Posted by: @majordennisbloodnok

↑

if someone comes up with a new way of pricing (e.g. some kind of TOU tariff that is also on a sliding scale based on previous consumption) then it may well not be possible to shoe-horn that logic into a smart meter standard format.

Au contraire.

The SMETS2 specification has a standard feature called Block Tariffs which already provides such functionality.

There are many ways in which it could be implemented.

Personally I favour it being deployed such that households who are profligate with energy use (especially during times of peak demand) will be charged at a higher rate. That could then be used to subsidise costs for households in energy poverty and/or with pre-payment meters.

Let's remember that we are a few months away from energy strategy being devolved to a new Independent body (ISOP), which is to be held to account by regional bodies who have democratic accountability. If we citizens want changes to the way things are done in Britain, then we have a fresh route through which we can be heard.

Posted by: @transparent

↑

Posted by: @majordennisbloodnok

↑

if someone comes up with a new way of pricing (e.g. some kind of TOU tariff that is also on a sliding scale based on previous consumption) then it may well not be possible to shoe-horn that logic into a smart meter standard format.

Au contraire.

The SMETS2 specification has a standard feature called Block Tariffs which already provides such functionality.

There are many ways in which it could be implemented.

...

The point I was trying to raise is that of the complete flexibility of an API vs fitting into a standard. What you're telling me about block tariffs makes me believe the SMETS2 standard is laudably more flexible and forward thinking that many other standards I have had to battle with and that is a good thing. If, and here I have to venture into waters unknown, smart meters can contain tariff information that is based on any kind of logic one could think of then this is all a non-issue. Is that the case? Could they provide a TOU tariff linked to customers with an R in their name who have given their contact number as a mobile and have biblical first names? I'm not seriously suggesting that, of course, but it's more a matter of we don't know what will be relevant to take into account until some bright spark decides it might be useful. APIs can handle that and if smart meters can too, that's ideal.

I'm not against having APIs for accessing tariff information via the internet.

But I do believe that Energy Suppliers should be required to implement the standards for the Smart Meters which they install.

The current situation is holding back the development of commercial products for handling energy in a 'smart' manner.
A commercial company would be taking an unnecessary risk by releasing a universal product which relied on accessing tariff data via an API.

Whenever the Energy Supplier decided to change the protocol or format,
or when the customer elected to change supplier, then a software upgrade would be required.

Any commercial energy product which has the capability for its code to be upgraded remotely via the internet has a security loophole which will be exploited some day.

Three months ago I received a visit from representatives of a manufacturer of energy products, based in a Far East country.
Until that point they had expected to make it a requirement within the warranty terms that all their products to be sold in Europe, USA & Canada must be open to receive code updates from (insecure) remote sites.

I talked them through the Consumer Rights Act, and what is/isn't fair terms & conditions for warranty/guarantee purposes.

Within their culture those concepts genuinely don't exist.
They simply accept that such products will be subjected to attack anyway, and that customers are expected to trust the manufacturer.

The UK energy supply system already has (a few) such products operating on it.
From time to time a security loophole is found, and appropriate action is taken.

Within the energy sector this is usually done without any publicity.
But other sectors have come to the attention of Western media:

• dolls with microphones and cameras in them
• 'security' cameras which require access to cloud-storage outside of UK jurisdiction
• Huawei digital switches within the UK telecoms network

We cannot afford to have products connected to our energy networks which allow opportunity for remote access, and where that access compromises the energy supply.

@transparent do Octopus make an effort to update their Agile tariff data on actual smart meters every day?

That's a very obvious and straightforward question @jeff 
but the answer is clouded in mist.

I'm not an Agile customer.
I'm currently using Go, so there should be two ToU price settings in my meter.
But there's only one.

The IHD does, however seem to reflect the right costs, and I'm unsure how that is achieved.
We should note that it receives its data from the Comms Hub rather than the electricity meter.

Today it says I've used 71.5kWh at a cost of £6.16
Go has the cheap rate between 00:30-ish and 04:30-ish.
As I have 56kWh of battery storage and an EV, almost all the household demand is during those hours. [see footnote]

Here's a typical day's histogram:

Could I ask for others here who are on ToU tariffs to go to their electricity meter (not the IHD) and press the button (usually 'A') to cycle through the registers.
If the meter 'knows' about a ToU tariff then there should be data present when the legend says ToU.

Insiders within the energy sector have told me that Suppliers don't put ToU prices within the Smart Meter registers.
But that's anecdotal, and not evidence.

Getting evidence is very difficult, even if we're just talking about an Economy-7 tariff.
Attempts to do so have resulted in a widespread obfuscation from Supplier staff at senior level (I'm not referring to Octopus here).
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.

As you know, Jeff, I've been 'investigating' Smart Meter implementation for several years.
One thing I've learned is that I've wasted far too much time being pernickety about using fair tests and scientific methods.

Now I'm more inclined to start with the smell test.
Does it smell right?

In other words, am I being misled, or supplied with official explanations which are incorrect?

If you open the barrel and it smells of fish, then there are three possibilities:

• there's something 'off' about the contents
• the barrel really does contain fish, so everything's ok
• the barrel shouldn't contain fish, but someone's been filling it with red herrings

I have previously switched Suppliers when I find such tactics, but 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.
I understand that. They've been extremely helpful to me over the years, and they did choose to take one of my cases to Ofgem, who withdrew that Supplier's licence.

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.

That means (from their perspective) that they don't need to have downloaded the price points into our Smart Meters.

At this stage I'm deliberately avoiding any discussion about whether the resulting bill is correct.
We're only looking at whether the ToU data really is in the electricity meter (known as the ESME), which is where the specification says it should be.

And in Section 5.7 it specifies the Data Requirements:

[footnote] I've subsequently discovered that we didn't charge our EV last night.
So that figure of 71.5kWh consumption by mid morning is totally fictitious!
Let's leave IHDs out of the equation for the moment.
The issue is whether our electricity meter has the ToU registers populated with figures.

@transparent Sorry, I can’t read the meter due to sight problems but am with Octopus and am awaiting delivery of an Octopus Mini which should enable me to see in ‘almost real time’ my consumption and I think the applicable rate of the tariff at that time. I do of course have the old IHD supplied with the SMETS1 meter but this does not work at all well and does not cope with tariffs - only consumption. After the event readings are available through the Octopus app so I am able to check things but 2 days later. Regards, Toodles.