Meter-CAD-DCC communications architecture?
Hi,
Background: my supplier, Bulb, is no longer recording readings from our smart meters even though my Glowmarkt CAD works fine and I can read the meters just fine with the Bright app, whether or not at home. Active discussions with Bulb are ongoing.
In aid of those discussions, I'd like to understand more about the communications architecture of SMETS2 metering in conjunction with Glowmarkt's CAD. I know this much:
• The CAD is joined to the HAN and also to Glowmarkt via WiFi.
• Glowmarkt is a DCC "Other User", and can get current and historic data directly from the DCC.
• The Bright app on my phone can communicate only by Internet (WiFi or cellular) to Glowmarkt's cloud services.
• (MQTT relies on cloud services in some cases, and may be available locally in others.)
Given these, does Glowmarkt rely on the CAD for collecting data at all, or does Glowmarkt use only its DCC connection to get data?
The significance of this question is that if I can read my meters both with my CAD and Bright on my phone, whether or not I am home and Glowmarkt relies exclusively on the DCC for receiving data, then that proves my meters are fine, and the DCC is receiving, recording and relaying data just fine, too.
This in turn would prove that the problem exists between the DCC and Bulb.
Given the mess that Bulb is in, I wouldn't be surprised if they are, in fact, receiving data from the DCC but, for whatever reason, the data are not being associated with my account, therefore Bulb think they are not receiving data.
Their solution is to request a reboot of the meters and IHD via the DCC. They've tried this once and say they've requested a second reboot but, if somehow the link between Bulb and the DCC is broken (at least in relation to our account), that request is unlikely to get through. It stands to reason that if they cannot push tariff updates, pushing requests to reboot anything are not likely to work either.
(As an aside, it'd be interesting to know how customers and meters are related. The DCC and DNOs know how MPANs and MPRNs relate to specific dwellings by postal address. Suppliers associate a billing account (liable person) with an address and MPAN. How do suppliers relate smart data, via MPANs and MPRNs only? Or is there some other sort of ID involved?
That question is pretty deep in the weeds and may be answerable only by someone with detailed knowledge of the SMETS2 protocol, but it's worth asking all the same. I've skimmed through what's published in the technical specs and I see there are separate meter IDs independent of the MPAN and plus there are similar E2E cryptographic and anti-tamper provisions as are found in PCI DSS compliant payment card terminals and readers.
So long as the DCC don't lose the association between ESME and MPAN, then none of that detail matters. Again, knowing whether the Glowmarkt CAD relies wholly on the DCC for data collection would give a fair clue as to whether such association is still intact.
Comments
I'm not an expert but the DCC is the Data Communications Company, it is responsible for connecting your smart meter and IHD but not for any data storage, I believe the data is all encrypted so it can't actually see anything.
https://www.smartdcc.co.uk/
Glow needs to ask the DCC to connect to your smart meter so it can access the data stored within the meter. It also needs to ask to connect a new IHD. Your energy supplier has to go through the same process. There is an API but it's only available to authorised companies.
All the data Glow gets comes from the smart meter and nowhere else, it does store it in it's own servers so it can offer the services it does. Again your energy supplier does exactly the same.
The whole system seems enormously complicated which is possibly why things seem to take ages to fix when they go wrong. From my experience very few energy supplier support personal fully understand the system themselves which doesn't help.
In your case it could be that Bulb has lost it's connection to your meter and it may need to initiate a reconnect process to get connected again. The fact that Glow is receiving the data does mean the meter and DCC is all good. There is another layer called I think the DSS (Data Services Company) who may act on behalf of the supplier to look after the data. I think the link above will help explain some things but everything is in the public domain. Another reference is here
https://smartenergycodecompany.co.uk/
@gedger, thanks for your reply. It sounds like you are quite right on the important points, and I mistakenly assumed that Glow's DCC Other status meant that Glow could collect data from the DCC directly, but that appears not to be the case. Sounds like Hildebrand only use their DCC connection to join their CAD to your HAN.
All the data Glow gets comes from the smart meter and nowhere else, it does store it in it's own servers so it can offer the services it does. Again your energy supplier does exactly the same.
This is the crux of my question, whether data arrive at Glow via the CAD and one's broadband connection or via DCC, hence why I asked about the communications architecture that Glow uses.
In addition to what you said, this page says:
—
A Consumer Access Device or CAD is a cloud-connected secure smart meter gateway device that accesses real-time energy data from smart meters and sends that data to a designated cloud service.
The steps are:
and also
Importantly [Hildebrand's] CAD has a WiFi connection allowing data to be transferred to back to Hildebrand so that you can see it on their Glow app almost immediately. This also allows the electricity data to to shown on a minute by minute basis.
which supports what you suggest, that the data are read in realtime from the HAN by the CAD and relayed to Glow's backend via broadband. It just occurred to me that I could test this by turning off my CAD and see if data continued to flow. It did for a while, but then stopped. I guess that's the round-trip latency involved. It never reads more than 6 seconds out of date, but it simply says "no data". Data flow resumed shortly after turning the CAD back on and it reconnecting to the HAN.
So I guess that answers that question.
The fact that Glow is receiving the data does mean the meter and DCC is all good.
Not necessarily, it just proves the meters and HAN are okay (at least, the local radios), not that the DCC is receiving any data (if it's the case that it's the CAD that relays data to Hildebrand's service endpoints).
I had hoped that it would be as you say, that the fact that Glow/Bright are still working means that the connection from us to the DCC is still working, but it doesn't sound like it. I can think of half a dozen things that could explain what's going on, but no way of proving it one way or the other.
As you say, it may require an engineer visit to re-enrol or re-commission our meter. And yeah, the whole thing is absurdly complex.
If you turn your CAD off then I had presumed that glow would then go back to sourcing data from the meter rather than the CAD, it may take 24 hrs or more but that's something only glow can answer. Certainly If you don't have a glow CAD then data is retrieved directly from the meter every 30 minutes via the DCC so it's a good indication that everything is OK.
Are you exporting? If so the glow app shows the negative import for 24hrs and then replaces the import with the true import from the meter register, so you will still get an indication whether the meter is available via the DCC. Janet from glow confirmed this in one of my other posts which I can't find at the moment....