Octopus energy : Smart Meter Feed

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)

Agree 100%.

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. :grinning:

@borpin

The smart security behind the GB Smart Metering System

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.

1 Like

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/

1 Like

Hi Brian
In the order in your post

  1. 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
  2. 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.

Hi Clive, welcome and thanks.

What is the ‘comms hub’

What is the PAN?

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/

Still killing me with jargon :slightly_frowning_face:

  • CAD - Consumer Access Device
  • IHD - In Home Display (?)
  • Head End - SMSO or DCC
  • WAN - Wide Area Network - The method used to transfer Meter data to supplier (eventually) via Head End.
  • PAN - Personal Area Network - A zigbee network connecting the Meters, CAD/IHD?
  • Comms Hub - A device that creates / controls the PAN and access the WAN collecting the

Data flows

Meter → Comms Hub → WAN → Head End
Head End → WAN → Comms Hub
Meter → Comms Hub → CAD/IHD

If I’ve got this right then best explanation - Cheers

I was never really worried about that, more about how it is then handled by the SMSO/DCC/Supplier. I know they are not supposed to abuse it but…

1 Like

Yes - one type of CAD

Yes and other devices - the Smets2 standard mandates supporting up to 5 remote load control switches as well

All DCC users sign up to very strict privacy rules and are heavily audited annually including all companies that manage CAD data.

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.

Also interested.

Do CADs act as ZigBee repeaters to extend the range? At the moment I’m quite limited where I can put my IHD in the house due to distance to the meter.

How well do multiple Zigbee networks operate? I already have one for lighting. Is that likely to be part of my range issues?

Hi all,

This thread seems to have been a little quiet … i wondered if the suggested API/MQTT integration had been moved forward by anyone?

I’ve just bought a glowstick and got it set up (and pending the final config of my smart meter) … so happy to help in testing

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.

@joolster

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.