Correct. I understand that the Smart Meter regulations are such that users cannot directly interface with there own HAN unless they are registered with the DCC. Hildebrand have registered and can therefore make the data available. I understand registration costs are in the tens of thousands of pounds.
I personally think lack of user access to their own energy HAN network is wrong but typical of governments. I guess security is an issue but I don’t think my energy usage is likely to be of interest to anyone other than me. (My meters are external and publicly accessible anyway)
Giving the data to a third party and then getting it back is likely to be a bigger security risk! Hardly any different to having a home router with the password stamped on the back of it.
Typical of technology illiterate government officials and ministers.
Hildebrand advised that the data from the meter to them is encrypted as part of the licensing provisions.
Presumably also encrypted back to their APP.
However the MQTT data is just subscribed with a username and password. The API is also needs username and password but provides a token for data access which changes every few days.
I’d have thought it is the IHD/CAD that does the encryption and not the meter itself (I could be wrong). Although, having said that Octopus identified that a CAD can only ever be paired to a meter once - where the pairing was tested in the factory, those devices would never connect to a meter. So it could be a one time key creation at initial pairing so the data between the meter and the CAD is encrypted. If so, the whole thing makes more sense.
I’m going to contradict myself, if the CAD can’t decode the data, how does the IHD know what the current consumption is. I can’t believe the data goes Meter → CAD → central store → IHD.
Having said that, it is quite possibly the way is had been thrown together, so yes I can believe it. I’m going back to my position of ‘over my dead body’ or when financially I have to, to get a decent tariff.
Thanks @ian. Not come across that before. If NCSC have been involved then my confidence rises significantly - they do actually know what they are doing. If they say the scurity issues can be managed then no one should question that. It’d be like telling your surgeon what to do.
Sorry for the delay in getting back to you Trystan - you are correct, if your underlying meters aren’t performant then we can’t perform the final miracle… much as we’d like to! Once they are working then all is fine - and if you didn’t want real-time and granular, we can also provide half-hourly data on a delay because we are a DCC Other User, approved by SECAS. This is through our own DCC connector. Hope Octopus are able to get you sorted out soon.
Hi Ian, you are welcome to share the Zigbee documentation, it is publicly available information and is the Zigbee Smart energy profile specification. To make it easier - here is the link - hosted on our own secure servers https://oc2.energyhive.com/owncloud/s/fGCW460aFmtm3JA.
For those who quite rightly express concerns about our security credentials, we are ISO 27001 certified and also passed the Smart Energy Code Administrator’s Privacy and Security Audits which are mandatory before you can be approved as a DCC Other User. The process is described here: https://smartenergycodecompany.co.uk/about-security-and-privacy-obligations/
There are TWO directions of travel for meter data - meter → comms hub → wan (gprs or 3g) → head end (smets1 an smso, smets2 DCC) and then onwards to the supplier - in the smets 2 world not only is the data encrypted over the wan link as you would expect where readings are involved they are further encrypted with individual meter/requesting party specific public/private key pair - so even if the payload in intercepted en route the important data cannot be recovered by anyone other than the requesting party.
The second direction is over the PAN from comms hub to CADs - this is encrypted using SEP with zigbee keys being burned into the CAD, notified via the head end to the coms hub - an initial join takes place using these keys and then new random keys are generated and exchanged between the comms hub and the CAD - this is repeated periodically and it means that the only possible way of sniffing the traffic is to a) know the initial CAD key and b) intercepting traffic during the initial join
CADs can be repaired as often as required - you have to complete the process of removing them from the old meter set and then they are free to join a new set - most unlike Octopus to get that wrong
The upshot is that in either direction your data is secure.
comms hub is a plugin in the electricity meter that contains the sim and so on for the wan connection, and the zigbee controller for talking to the electricity and gas meters as well as other devices like load control switches and any CAD. In smets1 they are manufactured by the electricity meter manuf, in Smets 2 they are procured by the DCC and supplied to the Energy Supplier for use in any Smets2 meter. (There is different WAN technology in the north of England and Scotland to the rest of the UK so there cannot be a single model of comms hub).
PAN is personal area network and each zigbee pan has a specific ID https://www.eetimes.com/zigbee-applications-part-3-zigbee-pans/
To which you can add CAD/IHD → 3rd party such as Hildebrand who are licensed by DCC to collect data which they can then provide to their users via the Bright App, API and mqtt.
You must have a Glow CAD (in the case of Hildebrand) which has a wifi connection to provide the data path to their servers.
Do you have a citation for that? It seems pretty fundamental to the debate on this thread.
Looking at the Electricity Supply Regulations (section 49.4, parts (d) and (e)), the supplier has an obligation to allow the consumer access to their data:
(d) on request of the Customer at the relevant premises, it both establishes and thereafter maintains a connection through the HAN Interfaces between the Smart Metering System and each Relevant Consumer Device that is located within a part of the premises to which the HAN extends and is the subject of the request; and
(e) the connection established in accordance with paragraph (d) enables that Customer to access (at any time and, in the case of the Domestic Customer, free of charge) by means of each
Relevant Consumer Device, the Customer Information that:
(i) is capable of being stored in or held by the Smart Metering System (or any part of it); and
(ii) the Smart Metering System (or any part of it) is capable of sending to the Relevant Consumer
Device.
From that it appears that the supplier has to grant free of charge access to any data the meter can produce and the CAD can receive. If the CAD receives real-time data, the supplier has to make it available. It doesn’t mention anything about cloud services for this purpose and in-fact such a provision could discriminate against users who have no internet access (or have shared provision to which they are not allowed to connect new devices) so there has to be a non-cloud of providing access to your own data.
I’ve just stumbled across yr post dated 12 Aug and by now you may have a solution re API/MQTT.
If not take a look at a post I made on 7 Sep …
My script has been running for weeks now. The Hildebrand GlowStick has replaced an emonTx, RPi, AC/AC adapter, pulse counter & CT’s I previously had installed.
