Posted by: @ianmk13

↑

I believe that n3rgy and Octopus both get their meter data from the DCC, so the data should be identical (bear in mind potential 1 hour offsets as the DCC uses UTC time).

From a purely technical point of view time offsets ought to be irrelevant since everyone should be using UTC. Whether they are or not is a separate question.

Strictly speaking a date/time value stored in a database is a number equating to the number of time periods (typically seconds) since a pre-agreed point in time (typically midnight on 1st January 1900). Applications then interpret this absolute date and time and display it in a convenient format to the user (e.g. showing local time with or without daylight savings). When companies are throwing data around, however, they are sharing unambiguous date/time values so 15:37 on 4th July 2023 UTC means exactly the same thing to all parties whether it really meant 16:37 4th July 2023 in the UK with daylight savings factored in, 17:37 4th July 2023 in Germany with daylight savings factored in or any number of other local times with or without daylight adjustments. Any company trying to share date/time data in any other format than the UTC absolute (or assume unilaterally that what they're receiving is anything other than UTC) is just asking for trouble. I won't say it doesn't happen but this is the whole reason the IT standard for sharing dates is the ISO format of year, month, day, hour, minute, second, millisecond and then hours offset; it describes a date and time independently of locality and daylight savings. I would be absolutely flabberghasted if any of the energy companies were deviating from this.

Posted by: @korwraith

↑

Indeed, for any future readers, UTC matches the 'clock' time during winter, my EDF off-peak period is 12am-5am in winter and 1am-6am in summer. Therefore, when looking at my HH data I always use the 12am-5am fields. When the clocks change in March I adjust my EV and battery charger schedules forward an hour but as the clocks also move forward an hour this keeps it in the same 12am-5am UTC offpeak cells (despite the charge schedule now being between 1am and 6am).

This rather proves that EDF's offpeak period doesn't change at all. It's 12am-5am UTC throughout the year and only looks like it changes to 1am-6am when the time is interpreted to show in local daylight savings format. The fact your EV and battery charger schedules need to be adjusted surprises me somewhat and feels to me like a design flaw. I can understand why users might want to align their schedules with their daily routine (and therefore the apparent clock time) but at very least any schedules set up would be better to come with the choice of being adjusted for daylight savings or not.

Posted by: @majordennisbloodnok

↑

From a purely technical point of view time offsets ought to be irrelevant since everyone should be using UTC

I'll leave this post here. But it transpires that @majordennisbloodnok and I are talking at cross purposes.
See his clarification here below.

The time offsets are mandated by

1. the Smart Meter specifications which were ratified by Parliament in 2014
2. the Electric Vehicles (Smart Charge Points) Regulations 2021 

The offsets are required in order to stagger the time when Demand Side Response mechanisms kick-in, and hence avoid surges on the electricity grid.

The problem we now have is that these two pieces of legislation are in conflict with each other.

Electricity Suppliers are billing customers based on the consumption reported by their Smart Meters,
whilst they are required to implement a different/unrelated time offset for EV Smart Chargers.

The regulations are being upgraded and enhanced to include other devices such as electrically operated heating (heat pumps, heat batteries, storage radiators etc).
The proposals are described in the Smart Secure Electricity Systems Programme: Energy Smart Appliances paper.
However the closing date for the consultation is midnight tomorrow (Tue 11th June'24), and you've got 74 pages to read!

On this forum we spend considerable effort telling people to keep their heat pumps running continuously, and not use external controls. That's because we understand the physics and how much energy gets used every time you start the compressor.

Meanwhile the DESNZ is busy enshrining legislation to ensure that your heat pump can be turned on/off by a remote 3rd party to avoid use when there's heavy demand on the grid, for example. 🤔 

Posted by: @bxman

↑

  From what I can see all the problems so far identified  have occurred with people that were with Octopus Energy and had been on their Go tariff .

For some reason OE changed the timing period of  the R1 & R2 registers to coincide with the Go time period .

And failed to switch it back when the customer either left the company or as in my case they moved me on to their  Eco7 tariff .

On second thoughts, EDF's technical team themselves confirmed to me that the registers on their tariffs run "a few minutes before or after the start of the off-peak period", which would, I believe, suggest it is universal across their TOU customer base, rather than my meter being an exception.

Additionally, it has been referenced previously that this same issue reared its head in the OVO V2G trial.

@korwraith This suggests that it is a very large can of worms… Toodles.

Posted by: @transparent

↑

Posted by: @majordennisbloodnok

↑

From a purely technical point of view time offsets ought to be irrelevant since everyone should be using UTC

The time offsets are mandated by

1. the Smart Meter specifications which were ratified by Parliament in 2014
2. the Electric Vehicles (Smart Charge Points) Regulations 2021 

The offsets are required in order to stagger the time when Demand Side Response mechanisms kick-in, and hence avoid surges on the electricity grid.

 

The problem we now have is that these two pieces of legislation are in conflict with each other.

Electricity Suppliers are billing customers based on the consumption reported by their Smart Meters,
whilst they are required to implement a different/unrelated time offset for EV Smart Chargers.

The regulations are being upgraded and enhanced to include other devices such as electrically operated heating (heat pumps, heat batteries, storage radiators etc).
The proposals are described in the Smart Secure Electricity Systems Programme: Energy Smart Appliances paper.
However the closing date for the consultation is midnight tomorrow (Tue 11th June'24), and you've got 74 pages to read!

On this forum we spend considerable effort telling people to keep their heat pumps running continuously, and not use external controls. That's because we understand the physics and how much energy gets used every time you start the compressor.

Meanwhile the DESNZ is busy enshrining legislation to ensure that your heat pump can be turned on/off by a remote 3rd party to avoid use when there's heavy demand on the grid, for example. 🤔 

Oops, talking at cross purposes.

Everything in my post was using the term "offset" to mean offsets from UTC to get to a particular time zone, so an offset of zero hours would be BST, an offset of one hour would be CET and so on. It was only when you posted the above that you reminded me we're also talking about the smart meters adding or subtracting a randomised offset to the actual time to give a "meter time". My apologies for accidentally injecting confusion.

Nonetheless, @ianmk13 and @korwraith were talking (or at least I think they were) about offsets of multiple whole hours for time zones since they were seemingly concerned about whether or not a given date/time was UTC or not. The point I was making is that no companies sending and receiving date data should be doing anything other than using the ISO standard of UTC with a time zone offset hence making their point of query in practice not a concern.

Net result is that any billing to the customer should be described in terms of a "meter time" in UTC date/time format which will differ by a randomised offset from the actual time in UTC date/time format.

Posted by: @majordennisbloodnok

↑

Everything in my post was using the term "offset" to mean offsets from UTC to get to a particular time zone, so an offset of zero hours would be BST, an offset of one hour would be CET and so on.

Err, I think BST (used in summer) is one hour in advance of UTC as is CET (used in winter). GMT (used in winter) is the same as UTC and CEST (used in summer) is two hours ahead of UTC.

As regards, which time zone is used to communicate with customers I can't speak for electricity since I have a 'dumb' meter and they just use dates to communicate with me. I have an E7 tariff and in my case it follows UTC (approximately) all year though I understand that some E7 tariffs follow local clock time.

My car though is more complicated. It displays GMT unless and until I tick a little box in the interface to tell it to use summertime, which I do for convenience in the summer. But it's charging circuitry uses a clock thatis apparently tied to the displayed time so I also have to change the set times for charging twice a year. There's no facility to tell it to stay with UTC. A shortcoming IMHO.

Posted by: @djh

↑

My car though is more complicated. It displays GMT unless and until I tick a little box in the interface to tell it to use summertime, which I do for convenience in the summer. But it's charging circuitry uses a clock thatis apparently tied to the displayed time so I also have to change the set times for charging twice a year. There's no facility to tell it to stay with UTC.

And that's precisely the sort of feedback that DESNZ need to hear in their consultation on Delivering a Smart and Secure Electricity System.

There's an email address at the bottom of that page. Instead of struggling to answer the three-part questionaire by midnight tomorrow, you could simple send in your own comment.

Just tell them that all Energy Smart Appliances (ESAs) should keep to a common clock system (probably defined by the Smart Meter).
It's not something they've considered in the accompanying proposal documents.
But since the intention is to define standards which manufacturers will need to follow in order to supply smart devices (incl EVs) in the UK, then the car manufacturers will have to address it. They won't be able to suggest that it's up to the charger, but doesn't apply to the car!

This is very much 'on-topic'.

We're having these discussions precisely because we have two pieces of UK legislation with conflicting opinions on the matter of time.

@majordennisbloodnok  I’ll try and untangle my comment. 
I was referring to my attempt to determine my ‘meter time’ random time offset by comparing  OE (DCC) data with my local EV (HA) records. I mentioned the GMT/BST issue as I have to consider this when correlating my data sets.

Regarding ‘time standardisation’, the fly in the ointment is that Joe Public generally isn’t aware of UTC, and the ToU tariff data is publicised for GMT or BST as far as I know - at least it is for Octopus Agile. I’m sure you realise this but I’m just adding this for clarity for any future visitors to this (potentially confusing) thread 😉 

Yes, time standardisation and offsets are very difficult for most people to imagine.

If there are 'future visitors' arriving here, then please go back to the diagrams I uploaded across several posts, starting here back on page-1 of this topic.

Just so everyone's aware, the link to this topic is now known to DESNZ and the staff of the Commons Select Committee on Energy.
Please can we continue to post relevant evidence and insights, and avoid meandering off topic. Thanks.

Posted by: @djh

↑

Posted by: @majordennisbloodnok

↑

Everything in my post was using the term "offset" to mean offsets from UTC to get to a particular time zone, so an offset of zero hours would be BST, an offset of one hour would be CET and so on.

Err, I think BST (used in summer) is one hour in advance of UTC as is CET (used in winter). GMT (used in winter) is the same as UTC and CEST (used in summer) is two hours ahead of UTC.

...

Yup, absolutely. Note to self not to post whilst in a hurry; I was getting my acronyms mixed up, which is not an uncommon occurrence.

Posted by: @djh

↑

...

My car though is more complicated. It displays GMT unless and until I tick a little box in the interface to tell it to use summertime, which I do for convenience in the summer. But it's charging circuitry uses a clock thatis apparently tied to the displayed time so I also have to change the set times for charging twice a year. There's no facility to tell it to stay with UTC. A shortcoming IMHO.

Absolutely agree. There's no reason why that should be other than someone needing to code it and there's plenty of good reason to do so.

@transparent 

I have a 4 port  Landis & Gyr  E470  and I can hear the contacts making and breaking   the 5th port is only energized when the contact is made the terminal is not available but the display switches still switches from the one to the other in time with this occurrence . I suspect other makes do the same .

You can download your data and put it into excel with the appropriate hours and send it to your energy company and ask them to  compare it with your invoice I think you will find they have no option but to accept the Half Hourly data.

@bxmman - here's a block diagram of a 5-port ESME.

Are you telling us that your L&G E470 has the Timed Contactor present, even tho' the casing doesn't have the position which would allow the switched output to be used?

Posted by: @bxman

↑

You can download your data and put it into excel with the appropriate hours and send it to your energy company and ask them to  compare it with your invoice I think you will find they have no option but to accept the Half Hourly data.

We're talking about different things.

The problem being discussed in this particular topic is that the Supplier is indeed picking up the 48 HH readings for the day.
However those 30-min periods are actually delayed by a Randomised Offset within the ESME.

Thus the first reading of the day won't coincide with midnight, but will be several minutes later.

The Supplier's Billing Software doesn't include a parameter to allow for that offset.

So, for example, the Supplier turns on the customers EV Smart Charger at midnight, but they still get billed at the higher rate until the Smart Meter starts the 1st time period.
Have a look at the time-graph I posted here on p.1 of this topic and it should become clearer.