A taste of things to come? - UK smart meter data access

It’s also down to economics. The number of people that would actually make use of being able to locally access the data is small, very small. Add in the cost of supporting the small number of people using it, it just doesn’t make sense to do.

Today n3rgy collects data from the meter once a day. i.e. it downloads your data in the early hours of the morning and makes it available to those who have been granted permission to access it. We’re also piloting increasing this collection frequency to every 2 hours (and potentially more frequently in the future) . With regards to CAD pairing, we would be happy to also offer this service when and if a market of CADs becomes available but as previously mentioned, there’s very few CADs available on the market today which aren’t already part of a closed system.

Out of interested, what do you guys believe the imperative for real time data is? If you have the tariffs (which always need to be published the day before) you already have the mechanism to automatically minimise the cost of power hungry appliances!?

This argument is a cop out.

Whilst I agree it might be small, you could build a smaller device, no (pretty useless) display, and allow devices to connect via WiFi (like a massive number of smart switches do) to get the info. You could even then do updates to fix bugs and allowing API access to the data is easy.

Octopus provide API access to probably a small part of their user base. Are you suggesting they shouldn’t?

My point is, it should have been built into the specification to provide local access. Commercially, no one is going to do it unless they have to generally as they have too much self interest.

1 Like

Should I export, import or send to battery/charge EV.

This whole forum is based on users wanting real time energy use gathering!!!

3 Likes

The main interest is to measure exports/imports for renewables generators.

Admittedly that is going to be a bigger market in other countries with better solar resource or subsidies, and it seems each country is implementing something different for its smart meters, with the only common interfaces being the LED display and the pulsing LED.

1 Like

I would tend to agree that the near-real-time data isnt needed for a lot of things. But I think one clear use case for a CAD is if you want to adjust power usage of a smart appliance (battery/EV charger/diverter) according to actual generation output (or some other control signal) then you need near real-time data from the grid feed. A lot of current energy smart appliances come with these grid feed monitors which use CT clips for this purpose (and in some cases G98 compliance purposes). But most are not interoperable and we are increasingly seeing situations in our work now where our members have a battery from one manufacturer, diverter from another, EV charger from yet another and they all have a CT clip watching the grid feed so they can follow PV output etc. but then racing each other to grab any excess with no coordination or prioritisation possible. Seems like an interoperable CAD+energy management system would be better to sit in middle here dealing with the control priority issues as well as maybe reducing costs by not having multiple of these devices clipped on (and one would hope a basic Zigbee SEP CAD would end up being a bit cheaper than a CT monitor).

1 Like

No it’s the harshness of commercial reality, the more features you add, the bigger impact you have on the profit margin for all involved.
There’s also the security aspect, once you provide the ability to do firmware updates you open up devices to potential abuse / intrusion.

They key here is Octopus built systems from the ground up, without having to bring with them years work of legacy. The API that we as consumers are exposed to is just a small rework on what they’ll be using internally. It’s great that they are the leading disruptor to the sector, and long may it continue.

1 Like

I asked this question because I’ve been working with an advanced system provider that does exactly this. Based on ToU import and export tariffs it decides what to do with the energy. The system takes the real time information from the hybrid inverter (not smart meter) because it needs information of domestic load, solar generation and battery status. The ‘intelligence’ combines this with information with the ToU tariffs, weather forecasts and predicted domestic usage patterns then chooses to run from battery/solar or import/export/neutral the grid. It will also export the remaining capacity of the battery before the max £ export ToU (SEG) runs out.

None of this needs real time data from the smart meter but it does take historic consumption information form the meter (to check it’s working correctly) and export information (to calculation SEG revenue). It also takes the tariffs from the meter which are available the day before (when it’s calculating solar generation based on weather forecasts)

It also does a bunch of other things but, from an energy perspective, it’s very impressive.

EDIT. My basic argument is the smart meter only shows import and export from the grid which isn’t that useful for effective energy management. You need solar generation, domestic load, battery status and a bunch of other things first. Smart meter data helps you tune the system, not operate it.

EDIT2: Yes it has an integration with Octopus Agile tariffs (both import and export)

1 Like

It is a cop out. If a £15 smart switch can provide an API, a £60 IHD should be able to do the same especially as every user is actually paying for these things (green levy). As I said, it should have been written into the spec. The IHDs are as much use as a chocolate fireguard. I bet most end up in a kitchen drawer. If we actually had to pay for one, no one would bother. This means the ‘commercial reality’ is they can design something useless, charge a fortune for it (probably) because the energy companies have to use them and make a fat profit off us poor souls. Can I send mine back for a refund?

3 Likes

You’re forgetting the onerous initial and on going security requirements authorised devices have, plus the customisations to international standards the UK have performed.

Nope I’m not, but is one company can do, so could others.

Bit like DemandShaper :slight_smile:

1 Like

I have solar panels on a feed in tariff - I understand that smart meters should record energy feeding back into the grid from the panels
Does your API have a field for this energy feed?

Does anyone here have any insight into the DCC network roll out? I’m very keen to use a variable price tarrif - I have a SMETS2 meter installed but no DCC coverage in my area!

Supposedly it’s meant to have 99% coverage by 2020 but I’m guessing it’s nowhere near that.

Where are you? ‘Scotland and the North of England’ or ‘Rest of England and Wales’? According to Technical information on Smart Meters: Smart Metering - The full story both networks will have over 99% coverage ‘by 2021’ (whatever that means!)

You probably need to ask your electricity supplier and/or whichever of Telefonica or Arqiva is relevant.

I’m in the Southwest so looks like I should be covered by Telefonica and their cellular network. Given the lack of mobile coverage where I am, I don’t think it bodes that well.

Thanks for the link though, really interesting read.

1 Like

It was written into the spec for smart meters. They need a Home Area Network (EU requirement) and the UK Govern,ment decided that zigbee would be the standard. Hence it would cost zero in extra hardware to provide a real time MQQT output - just like every zigbee plug has.

The suppliers could argue there is a security risk, though I’m not sure how secure real time import/export needs to be, and zigbee includes full security once pairing is done. The WAN has more onerous security concerns including OTA updates. I suspect the issue was that the spec just said “zigbee” and didn’t require it to actually work with open devices.

On a related note, does anyone know how electricity suppliers purchases of electricity will change with smart meters?

With a traditional tariff, if the supplier supplies 5,000 KWh of electricity in the year, they will then need to buy 5,000 KWh on the wholesale markets. I assume this is going to be at an annual average price, as they have no idea when the electricity is actually consumed at a household level - just two meter points.

With a smart meter, does the supplier have to pay for the whole sale price during the half hour slot of consumption? That would be logical. It would also mean that suppliers have an incentive to either:

  • Try and encourage consumers to consume when electricity is cheap (some incentives, or software to consume electricity at 15p when the wholesale price is 1p and not 30p…), or
  • Introduce flexible pricing like Agile Octopus and pass the incentive - and the risk - over to the consumer.

If wholesale pricing moves to an “time of consumption” basis, then I reckon tariffs with variable pricing will become widespread.

If not, most suppliers will stick with traditional tariffs, and let the industry as a whole bear the risk of people consuming electricity at expensive times.

With respect, that’s a self-defeating line of argument. Taken to its logical conclusion, don’t add any features or do anything decent, because the profit gets hit. Aim low, ship mundanity, hope not to lose too much to more innovative competitors before going bust.

From a consumer perspective, if the device ‘does good stuff’ and is priced fairly (for what it offers), I’m happy, and you get your profit.

OTOH, make a pig’s ear of its feature set, and try to sell it to me for too much, and I’ll turn my back on the company and all its future offerings once I’ve experienced the thing that is no doubt now an unused white elephant in my drawer.

Good features are worth buying, but bad features will hit the profits far more than just ‘more features’, per se.

Not necessarily. If the device ‘polls’ for updates on a regular cycle (in the same way that my FritzBox router does, for example), then there is no ‘pokeable hole’ on the outside interface of the device that poses a security risk. The company just needs to ensure that the ‘mothership’ firmware-deployment server is alive at least most of the time, and my box-o-tricks will check in and eventually find when it’s time to be updated. Heck, you can even make it flash a light, and require user-intervention/authorisation for update, with a recommendation to check a website for a changelog, to confirm that the newly-presented update is ‘proper’.

At least that way around (polling, rather than pushing), if there ever is any ‘funny business’, it would have to happen on the corporate server initially, not at the device-end, and would (hopefully) be much more easily protected against (tbh, only a wholesale DNS rape and a mass MITM style attack would do much, and if the devices were properly handshaking with the mothership before trusting any code sent up the pipe, there’d be virtually no chance of shenanigans). Similarly, such a centralised exploit would be much more likely to be detected, and more quickly, than would be the case if the firmware updates were ‘pushed’ to the devices via any kind of ‘update-hole’ in those devices’ firewalls.

Where there’s a will, there’s a way… and a market, for the willing entrepreneur.

Actually, at worst, you could make push only USB port that sends serial data much like the emonTX does. That is better than nothing and at minimal cost or security.