In my area of Sweden, the electric utility Mälarenergi is replacing all electricity meters with new “smart” meters that have a so called HAN interface for the customer to access data. This interface is a form of M-Bus. Believe that the same standard is used in more parts of Sweden and in Norway (and perhaps also some other country). Would be interested to know if anyone has integrated such an interface with OpenEnergyMonitor? Or would anyone be interested to do so (for example on Raspberry Pi)?
Can anyone give advice how such an integration would best be done, so it could in the future perhaps be part of OpenEnergyMonitor (for example as an alternative to CTs etc on emonPi)? I believe hardware is already available to connect HAN via USB, but are there any guidelines how the software should be best be written in order to possibly merge it with the other software?
A smart meter HAN - Home Area Network uses the Zigbee smart home wireless networking standard, however it seems to use a different ‘profile’ to most other uses of Zigbee and this I believe prevents directly accessing it.
There are some dedicated devices that use the same ZigBee Smart Energy 2.0 profile and hence can in theory connect. (This may or may not be restricted by the energy and meter supplier.) An example is this one Product Page - EAGLE-200 - Automated Energy Management | Rainforest Automation
These connect to the HAN using Zigbee and then convert the data to a form that can be accessed over your home LAN. (RainForest have their own API for this.)
In fact this type of device has its own abbreviation which is CAD - Consumer Access Device. You may be familiar with some smart meter devices which provide associated device with an LCD display you can view in real time on your table, these are called IHD - In Home Display devices and also use the same HAN. In fact some IHD devices now also have CAD capabilities as well. See - Smarter energy - Green Energy Options : Green Energy Options
Issues to be aware of.
SMETS1 and SMETS2 are obviously different. Some IHD/CAD devices may only support SMETS1 others may support both.
I believe that whilst the most common radio frequency for Zigbee is 2.4GHz that some SMETS meters may use different frequencies e.g. 868MHz. This is because these alternate frequencies have a longer range and with meters often being hidden away in a cupboard or even outside the house the greater range can be vital. Obviously you need to be compatible in this respect as well.
Thank you for your reply John. As I understand, ZigBee wireless is used for this purpose in the UK. In my area it is instead a form of M-Bus using RJ45, which can be used also to supply power to a slave. Below are some links regarding open-source solutions for the HAN interface used in Norway, which I believe is similar to what I have in this part of Sweden:
https://www.nek.no/wp-content/uploads/2018/10/AMS-HAN-Port-Smart-Hus-og-Smart-Bygg-Gjør-det-selv-og-Pilotprosjekter-ver-1.16.pdf (in Norwegian)
GitHub - roarfred/AmsToMqttBridge: Minimalistic system to read AMS/HAN data from electrical meter (however, I was very sad to read on Facebook that the developer is dead)
Using the instructions in Norwegian on one of the links I provided before, I’m reading data from the meter on a Raspberry Pi. Now looking for ways how to integrate it with OpenEnergyMonitor, view data in Emoncms and if possible also communicate data locally to a PLC using Modbus TCP.
Hi Sven
How are you reading the meter on the Pi?
I have a similar set up. I get the data using MQTT so I have NodeRed on the pi subscribing and then posting to Emoncms using MQTT. It also enables me to format data before posting to Emoncms.
Hi Ian
The Pi presently runs the software, which you can read about in Norwegian on the first link I provided before. It gets the data from the meter through a USB interface, which I purchased on the web. As I understand, an alternative software written in Python is available on GitHub - Danielhiversen/AMSreader: AMS reader, which can use MQTT (but I have not tried that yet).
There is a related discussion in Norwegian on Lesing av HAN - The Easy Way (TM) - WIP - Strømsparing og strøm-overvåkning - Hjemmeautomasjon, which includes for example information about different attempts to use Python
As well as using MQTT to send the data to an emoncms system, another possibility is to post the data over HTTP using the Feed API. To see how to do that, go to the Feed List page of your emoncms system and near the top of the page towards the right hand side there is a link ‘Feed API Help’. Click on that for details and examples.
In Portugal we have smart meters with HAN ports. They are RJ12 providing 5v and RS485 with modbus.
Is this something similar to other countries in europe?
I’m designing a small device with wifi that plugs directly to the meter to sends data to emoncms, that may have usage on other countries.
As I understand it, RJ45 and RJ12 are used in Sweden and Norway. I live
in Sweden and in my area the Norwegian version is used. There is some
information about the protocols on https://hanporten.se/. At least in
some cases, Mbus is used.
Chaverio, if you would make your device so it ca be used here in
Sweden/Norway, I would be interested to hear.
ESPHome and HA have already done this - Energy Management in Home Assistant - Home Assistant
That’s interesting, thanks. Does any of it work in the UK to allow access to any data from a smart meter other than the flashing light data I can see from a dumb meter?
No, as the UK spec doesn’t include the RJ11/12/45 output socket.
On the prototype I’m using Tasmota with scripting that supports modbus (and other protocols) for interfacing smart meters.
I’ve just compared the pinouts and the Swedish uses P1 proprietary protocol. The Norwegian uses M-Bus and the Portuguese uses Modbus RTU over RS485.
How about other countries?
Portuguese (RJ12 RS485 Modbus)
Swedish (RJ12 P1)
Norwegian (RJ45 M-Bus)
Is power available on the other pins?
OK thanks. I suspected not. It seems a typical UK cock-up, at least from the consumers’ point of view.
1 Like
Indeed yes we get shafted again.
The only options in the UK seem to be.
- Use an API to access the 30 minute interval updated data from the DCC network - this is possible free of charge and should work with all energy providers
- Use an API to access the same data from your energy provider - not supported by all providers
- Get a CAD - Consumer Access Device which can do much more frequent updates. The CAD resides in your house and in theory should be accessible locally but none of the CAD devices available in the UK allow this and instead you have to access the data via the CAD makers API and the CAD makers cloud servers. Here there has been some progress. Originally you could not buy CAD devices as an end-user and then for a period there was literally just one product available, now there are - gasp! at least three available.
Really scraping the bottom of the barrel - there might be optical sensors available but most if not all cannot cope with reading the LCD display of smart meters, and finally an energy clamp to measure yourself electrical current draw.
Note: There is a US company making a CAD which does support local access but it is not approved for UK use and not fully compatible with SMETS2 and sadly the manufacturer is showing no interest in addressing UK market requirements. It would admittedly cost a fair amount to get UK certification. Without certification it cannot be paired to your HAN - Home Area Network.
Note: In the UK the HAN is a Zigbee wireless network used to link the smart electricity meter, the smart gas meter (if you have one), the IHD - In Home Display (the gadget shown in the adverts), and if you have one the CAD - Consumer Access Device. The HAN is locked down using a special energy standard - not the same as used by e.g. Zigbee smart light bulbs. Only approved devices can be connected to the HAN. There was originally some talk of home appliances also being linked directly to the HAN so they could be set to run at cheaper i.e. lower demand times of the day or be turned off automatically.
If the government had a clue (they don’t) they would require the CAD makers to allow local data access. This would be simple to implement the - CAD device already has a web interface as this is used to connect to your home WiFi so it can then upload the data over the Internet to the CAD makers cloud servers - just so you can then redownload the same data back to your computer. 
Due to the fact that all UK CAD devices only allow access via their cloud servers - if the CAD maker goes bust or decides to charge you for access you are screwed. There have been several cases of smart home products being effectively killed when the maker either goes bust or shuts down the service. I know of at least two smart lighting brands which went bust resulting in all the smart light switches stopping functioning completely and having to be ripped out. This is one of the main advantages of HomeKit since the spec requires that HomeKit work purely locally with no-need for a cloud service. (Unfortunately Apple has done a terrible job marketing and expanding HomeKit.)
1 Like
This is no longer True. Glow have recently introduced an update to their CAD to enable local MQTT so you can get 10s data locally now.
But I agree the UK spec is FUBAR.
2 Likes
That sounds hopeful. Do you have a link please?
edit: I found Glow — Local MQTT. Here at last … free upgrade in version… | by Joshua Cooper | Medium Is there any emoncms integration yet? Do people actually have it working?
Will need a little Node Red to extract just the power/energy data.
Might be a job for an emonhub interfacer - @TrystanLea @glyn.hudson in the longer term.
I have one here but need my meters to reconnect properly before I switch it on and see the data format.
The other way would be to use HA or Telegraf to extract the power/energy elements of the JSON.