Is my In Home Display (IHD) displaying the wrong time?

Perhaps it’s all relative.

If you throw the IHD close to the speed of light, does it slow down? 

…. I think I need a weekend break.

Erm, @Tim_OVO I don’t think @Jon Langford has provided the “Answer” to this Topic. He’s just said “me too”!

We’re still waiting with baited breath to hear what @BenS_OVO has to say.

Hey - Sorry in this world of working from home, it’s taking a bit longer than usual to find the right people. I’m usually found running around the office hunting people down. 

As soon as I have something I’ll post it here. 

As @Transparent said, the issue is that this question is now marked as solved when it isn’t!

For the benefit of others who are wondering why I’m wading into this discussion, may I point out that the issue of time is going to become increasingly important.

At the moment the only device that we have hanging off the Home Area Network (Zigbee) is the IHD.

However, the whole strategy of these Smart Meters is that they are able to issue commands to other devices within the home, such as Battery Storage, Immersion Heater, Storage Radiators etc. Thus we will be able to set up parameters based on time and cost-per-unit, according to our own preferences for when we want to use gas and electricity.

If the Time feature cannot be relied on, then the whole Demand Side Response strategy falls apart.

So it’s important that we verify what’s happening now (March 2020) before we start deploying such smart devices.

We might try a full device unpairing and repairing. I will need a guinea pig for this though so either @Jon Langford or @jewelie if you’re happy to give this a go, let me know. 

Thanks @BenS_OVO 

If you want to tinker with IHD code, please remember that I have a second Chameleon IHD here (CAD) that hasn’t yet been paired. So apart from you investigating the two that are showing incorrect time, I’m obviously happy for you to throw any test code in my direction.

It intrigues me that both of the two which are displaying the wrong time are both a multiple of 30-mins out of sync. @jewelie’s is 3½ hours.

So if I was looking for a likely source of the error, I’d be heading for the code that handles TOU tariffs in the Communications Hub.

Hi

Monkeying about with tech is my idea of relaxation and fun, so absolutely yes!  :)  (tbh It’s the main reason we got a smart meter…  gadget-lust!)

:)

x

Hi @Transparent 

I work it out to be 2hrs 45mins for me (but I didn't sleep last night and have just attempted to do a radio show so my brain is now entirely frazzled!)   But even then, that’d be 15 mins, which still sounds like an unusually neat unit of time.

EDIT:  Curiousity got the better of me.  I needed to know if it was *exactly* 2hrs 45mins, to the second. So I went to the meter with the IHD and saw the minutes update in synchronicity.  So yes, it is!

Great. Thanks for clarifying that @jewelie

So I still think this is more likely to be due to an error in the code that handles TOU slots. It’s just too neat a figure to be anything else.

Although these are half-hour slots, the SMETS system requires that the actual placing of the slot incorporates a randomised offset. If it were not so, there’d be a massive surge as thousands of us had devices pre-programmed to start simultaneously.

This random period then propagates across all successive time-slots for that particular Communications Hub. So if I choose to use a low-cost slot at 11am, but the randomisation period delays that by 7mins and 22secs, then the end of that slot for me will be at 11:37:22. Thus I still gain 30-mins of lower-cost electricity.

Equally, a  time slot I configure for 18:00 the same day will actually start at 18:07:22

Let me make a couple of broad assumptions:

1. It’s possible that the time displayed on our SMETS gas and electricity meters is actually derived from a time-signal picked up from the WAN, rather than internal clock hardware/software
2. The time displayed on our IHD’s might be calculated independently from within the Comms Hub.

That would mean the Comms Hub contains software which is able to handle a clock which is independent of the master-signal, and it is that clock which is used to apply the random offsets.

Now that’s pure conjecture… but it would fit with the symptoms we’re now discussing.