Hey ​@Firedog,

Did you manage to find any answers to your questions? Has it happened more than once or was this the first occasion? 

Hello Chris

Nope. But I’m beginning to wonder if it’s fumble-fingers on my part, although I can’t see why yet.
   

This was in fact the second. I rather assumed that after the first episode that I’d done something silly. It wasn’t until it happened again that I decided to ask whether the ALCS could be at fault. 

Having not heard anything from anybody (except you!), I’ve decided to leap out of bed tomorrow morning at 06:55 to see whether the switched circuit is still live. If it is, I’ve more troubleshooting to do at home. If it isn’t, I’ll be back to ask again whether Support can send a little 7.7 service request, which might return the ALCS settings including its calendar. I ask because it seems that not everyone who could retrieve meter readings (which includes support agents, I think) would also have permissions to retrieve ALCS settings.

Thanks!

Hey ​@Firedog,

I wouldn’t imagine you being the cause as you’re normally the solution right? 

Normally I believe the support agents will only have access to readings they’d have to make a request to a back office team to get the ALCS settings looked at. It might be worth asking support to submit the ticket and we can monitor the progress. Let me know if you need anything from me. 

You have too much faith in me!

I noticed that ALCS service requests need enhanced permissions*, so I’m not surprised that support agents can’t issue them. I’ll complete my investigations at home before pursuing that avenue. Of course, by the time my alarm snooze had roused me this morning, the window of opportunity to spot the offpeak signal had closed. I had instead another hour under the duvet, promising myself to do better tomorrow :)

I’ll be back if I decide it would be helpful to see what form retrieved ALCS settings would take. We see so many cases of customers who think theirs are not as they should be, and it’s a painful process to check the switching times at the meter itself.   
  
  

*   From DCC User Interface Services Schedule:
  
 

Just reviewing this timing ‘issue’ ​@Firedog and from your Bright table you will need to be a little careful. 
Depending on which of their tables you look at, it can show timing to be 1 hour out from actual (the glowmarkt forum did have a note on this).

Of course, what you’re looking at might be correct but you could double check maybe via a different source. 

Thanks for your concern! No, I know precisely what time the heater was switched on and started consuming, and that matches the Bright timings - which coincide exactly with OVO’s. 

I’m sure the general confusion about the half-hourly time slots and their labels arises from the fact that the meter counts drips into its bucket for half an hour, then stores the count along with the current time-stamp. Consumption in the period 04:30:00.000-04:59:59.999 will be recorded and time-stamped at 05:00:00.000. Applications are then variously good at presenting the data; most deduct half an hour from the time-stamp to produce what most users expects to see, and some even get it wrong when BST starts or ends. n3rgy sensibly doesn’t bother: it simply shows what it gets from the meter and leaves it to the user to sort out. Some suppliers offering ToU tariffs haven’t got it right yet.

My own problem lies elsewhere. I’m beginning to think that perhaps the heater is being intelligent, totting up the hours I’ve asked it to deliver heat for that day, taking account of the temperature I’ve set and guessing at what proportion of its maximum capacity it needs to store to meet the expected demand. I’ll now have to wait for the next overnight Power Up event to test this hypothesis by setting the heater’s controls to Home all day and 25°C, which should persuade it to store as much as it can. I’ll be back with the result as and when :)