It is available though via DCC. We get tariff and consumption data for the smart meters we are connected too. It’s also available for most SMETS1. You would also be able to get this via a CAD but in that case it is the same data.
@beaylott
Just to clarify as far as I have been told it is only fixed tariff data that is available from the meter. Half hour TOU tariff data is not stored in the meter and the indication I got that this may never be possible. Do you know if this is the case?
This is super interesting!
How does it work in practice, what’s the process with Hildebrand to open the binding window in the HAN and connect the CAD?
I haven’t been through the process yet, but my impression is once the meters are installed you just ask Hildebrand to connect their IHD/CAD. They then have to verify that you’re actually authorised to request it ( i.e. it’s your HAN they’re connecting to ) and that’s about it. Once authorised, they handle it directly.
not sure if I’m just being dense, but with the Hildebrand CAD, is the realtime usage data via MQTT messages available directly from the CAD on the local wifi network, or is MQTT reliant on subscribing to a Hildebrand server on the internet?
There was a discussion about the communication channels with Smart Meters here Octopus energy : Smart Meter Feed - #29 by clive
[edit]
Re-reading all this, the bit I think I had missed was that you can buy your own CAD/IHD (from Glow for instance) and connect it to your PAN (so you will have more than one CAD connected) as an alternative means to access the meter/tariff data.
The bit that I still see as missing, is the ability to connect something like this stick to a RaspberryPi and then being able to locally use the instantaneous consumption data in your own way. @JaneatGlow care to comment?
My impression is that the only data stream from the Hildebrand CAD directly is to their servers, hence the MQTT will also require subscription to their server. The main reason for this seems to be to keep the IHD/CAD hardware and software as simple as possible, though IMHO it’s not THAT complicated to also have a mechanism to supply locally. Since this data path is directly from the CAD to their servers on the Internet ( i.e. not via the DCC ) we can’t really infer anything about the security of the link other than I’d imagine it has to pass certain standards for the device to be approved and for Hildebrand to connect to the DCC ( which they do to enable pairing etc. )
Again, this is all just my impression and I don’t know with absolute certainty ( yet ) this is how it all fits together. I’ll know more once I actually have one to play with.
1 Like
Would it be useful to wait for @JaneatGlow or @clive to notice these questions and answer them authoritatively?
Yes that other link and the comment from @JaneatGlow suggest that the data must be encrypted.
In the other thread these sorts of data transmissions were described as being to a “Head End”.
I’ll also repeat my comment in that thread (and update it a bit) - this is my understanding of the topology;
Terms
- CAD - Consumer Access Device
- IHD - In Home Display (a type of CAD)
- 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 and up to 5 remote load control switches.
- Comms Hub - A device that creates / controls the PAN and access the WAN collecting the
Data flows
Meter → PAN → Comms Hub → WAN → Head End
Head End → WAN → Comms Hub
Meter → PAN → Comms Hub → PAN → CAD/IHD
Meter → PAN → Comms Hub → PAN → CAD/IHD → WAN → 3rd Party (Glow device)
I suspect the Comms Hub may well be built into the CAD/IHD in many cases.
That particular stick is just a headless CAD and the fact it has a USB connector is a red herring - it’s only used for power, not comms. I’ve been bugging @JaneatGlow via email and she’s said they don’t provide data locally nor do they have any plans to. Providing their cloud servers ( or “Head End” which is just a generic term for a server in the cloud supporting many clients ) remains active, and providing you have a stable Internet connection, practically there’s not THAT much difference technically between local access and getting data from the cloud. You can still use their API or MQTT server to get your data onto your PI. ( Obviously there are LOTS of arguments about reliability, security, reliance on others for support, etc etc. )
Head End in this context refers specifically to the SMSO or DCC as Brian noted, I believe. I agree it can be used more generally but here it isn’t. Specifically it distinguishes between the ‘official’ infrastructure and any servers Hildebrand or others may have.
I still think they need to be an approved company (DCC Other User?), but I could be wrong. I modified my data flows to refer to ‘3rd Party’ as that may be more accurate.
Most solutions currently available in UK don’t have local data access. It’s not compatible with their business models. I’m sure someone will come along and do it soon.
1 Like
We have been testing the Rainforest Automation CAD from Canada but its only SMETS1 not SMETS2 compatible atm. It has local data accesss.
1 Like
Half hour TOU tariff data (or traditional block tariff data) is stored in SMETS2 meter registers for the 24 hour period. There is a DUIS function (Read Tariff ) which ‘Other User’ DCC users can access which allows them to read it out. If you used this function as Other User every 12 hours you would be able to capture all the tariff information for a given user.
(SMETS1 is different)
1 Like
This might be of interest to others on this thread.
The comms hub is supplied by the DCC for Smets 2 and for Elec or Dual fuel plugs into a slot on the Electricity meter and for Gas only is a standalone unit.
For smet1 they are supplied with the elecetricty meter by the meter manufacturer.
That is best case - a lot of the time for whatever reason the tariff does not make it to the meter.
Also the DCC network is not reliable that you can do this every 12 hours and expect to get 14 answers a week. - e.g. it was down for some hours last night for ‘system upgrades’.
Our (glow) IHD/CAD is running on an embedded device running an rtos to keep costs down.
There is no scope for running ‘servers’ of any sort on it.
It will respond to ICMP but that, as far as open ports, is it.
I think that is a cop out personally but other opinions are available 
.