I've recently had a Smart Meter installed - How long until its fully provisioned and my usage data available via third party usage apps?

  • 11 January 2022
  • 3 replies

Hey everyone,

First thing to say, I'm not with OVO yet - as I was with Green and could only get a smart meter installed since Shell took over, and obviously can’t switch yet - but based on my googling for smart meter issues, this is the forum to come to - so I'm hoping you can help on a technical understanding level:

I had a smart meter installed last Tuesday. From 11:30 that night, the DCC started receiving data correctly and everything seemed fine… until Saturday morning at 9:30, when the DCC stopped providing data (I’m using Hildebrand’s Glow API, and n3rgy’s access as DCC Other Users to validate all this)

As a software developer, I've been working on a library to let other devs read smart data via n3rgy or glow, hence why I had access to data well before my provider even processed the smart meter.

All the lights on my meter (SW, WAN and HAN) are flashing once every 5 seconds, which suggests everything is normal in that regard and the signal strength is reported as -10dbm (which I believe is good?) - so does anyone have any ideas why the DCC thinks it’s not getting any data, when everything meter side suggests it is?


Best answer by Blastoise186 11 January 2022, 13:54

View original

3 replies

Userlevel 7
Badge +3

Howdy @lgladdy !

It sounds like you’ve got some good plans there. Don’t worry about not being with OVO, as this forum is open to everyone and we can definitely help you out either way.

And a technical question, I love these ones! I’m no developer myself, but I know quite a lot when it comes to smart meters.

I think what’s probably happening here, is that your meters are still in the commissioning process which can take up to six weeks to fully complete. During that time, things can be unstable and this is expected - especially with all the testing, config downloads and software/firmware updates being pulled down during the commissioning flow. After the first six weeks, you should find the connection stabilises and becomes more reliable once it’s fully activated.

It definitely sounds like your site is healthy though - five second flashes (aka the Slow Flash) on the Comms Hub for SW, WAN and HAN is exactly what you want to be seeing and that’s a good sign. The -10dBm on the meter is probably for the the ZigBee HAN connection that it’s using to communicate with the Comms Hub. I would be stunned if it wasn’t as good as that, given the close proximity, so that’s all fine too.

From what I’ve heard though, if you try to use your DCC Other User access this early in the commissioning process, you’ll suffer these kinds of issues far more often than you would for a fully commissioned site. I’m not sure if there’s a way to detect the status reliably outside of Yes or No, but you might want to see if you can handle that in your library if possible.

DCC also doesn’t have direct access to the actual meter data that passes through, as it’s all encrypted and they just act as a gateway. To actually be able to access the data, you have to set up your security keys and encryption keys (among other things) on each meter you want to connect to individually, once you’ve been given permission to use the services (such as by becoming a DCC Other User), or offload that to something else that’s able to handle it for you.

To get the best results, you’ll also want to make sure the meter is in either Daily or Half-Hourly Mode, as I think Monthly Mode also impacts third-party services using DCC Other User. I remember reading it all somewhere once, but forgot to bookmark it and can’t find it anymore.

In the meantime, definitely feel free to keep working on your library and testing it out anytime you can get a connection. You should get it all working properly soon!

Oh, and this is probably worth mentioning as well. You might not need to handle this yourself, but just in case, it’s good to know. If certain SMETS Commands such as Restrict access for Change of Tenancy or Decommission Device are issued to any meter you’re currently connected, to, you will almost certainly be booted out and your encryption keys may be wiped from the meters, along with your access to them. It’s probably a good idea to factor in this possibility and handle it gracefully, such as terminating further access attempts and consider cleaning up user data related to that Site in response to these events. :)

@Blastoise186 Thanks so much for the reply - that all makes sense!

I’ve asked Hildebrand for more info on what actually happens when people register for Glow (via the Bright app) before they’re able to get data. Whilst I'm in that state now because I made a new account to debug this state, I can only know that by there not being any resources available on the meter MPAN, but I'm not sure how often they retry to get that access. Also interesting that since Saturday, neither Glow or n3rgy are able to get “any” data for the meter, including before Saturday - but that could be something to do with their activation process, which validates based on current data.

It’s also interesting that the meter appeared on my Shell account this morning, but with no live data, and their data also only goes up until Saturday morning (though, I only know that through the “cost since 1st January” measure, as they’re not presenting any other data to me yet)

It’s interesting what you said about the DCC not having direct data access. I kinda assumed it all lived in a giant database at the DCC who provided read access to providers and DCC Other Users. Does this mean DCC doesn’t actively store data at all and it’s just passed on to subscribers as a push system, or is it a pull system from “consumer” (be it provider, or Other User) to meter?

I definitely set the meter up to half hourly - though by all accounts, that seems to be the case by default. Given Glow’s API seems to always have access to 30m data, I guess this is more about what level the provider reads the data, rather than what periods the meter logs it for internally.

Anyway! I’ll keep checking every day to see if anything changes. One of the issues I've got is the IHD doesn’t work for me as the meter is in the basement so I don’t think that will ever provision correctly, and the battery only lasts 2 hours so I can’t just leave it down next to the meter for a couple of days for all the provisioning to kick off correctly. It’s provisioned enough for me to walk past the meter room with it in my pocket when taking the bins down and it load all the data, but not enough to appear as a device provisioned on the MPAN at the DCC (which Glow tell me should happen)

Thanks again :)

Edit: Oh also, given you’ve brought up SMETS commands and I know you’ll understand what I'm talking about: a 0x8154 (HAN command completed successfully) was logged at the point the data stopped on Saturday… so it definitely seems like something sent to the meter (by the DCC? Or Shell? I’m not sure who handles that) triggered this.

Userlevel 7
Badge +3

Muhahahahahahaha! No worries. My evil genius plans for World Domination can wait until another day. :stuck_out_tongue:

Anyway, let me see…

Yeah, Hildebrand are probably better placed to answer questions about their API access than we are on this forum. But if they’re having trouble getting data through, then you won’t get much out of the API either. It’s good to hear it’s appeared on your account with Shell at least - that’s exactly what I’d expect at this stage, even if no data is coming through yet.

Trust me, DCC is a mysterious beast that’s very complicated and not the easiest to understand. They do have giant databases, but it's mostly records used to manage their systems and keep track of registered devices for example. That sort of thing really, not much more interesting than anything else stored by an ISP for example. And even all that lot is usually pretty boring. But yeah, they also keep records of all known users as well. Smart Meters are actually designed with security in mind, so they have a sort of “Speak only when you’re spoken to first” framework and individual meters will only (usually) light up the WAN connection in response to a valid SMETS Command targeting that specific meter. Everything else is discarded. But I think the meter will break silence and make outbound requests under certain scenarios, such as tamper detection - depending on how it’s designed and configured. Think Android Push Notification style and you’re pretty much on the right track.

There are also future developments in Comms Hubs, such as Dual-Band Comms Hubs in development which will help solve HAN range issues for almost everyone in the UK. Consider them as Coming Soon, since they’re only just starting to launch.

As for how you can retrieve those log events. WOW! You have some seriously overpowered access rights! XD

And yeah, I’m not sure what that particular event would have related to, nor who sent it. That sort of thing comes under the category of stuff which I can’t find out. Sorry!