Echelon/NES Smart Meters – the beginning

Echelon logo

This will be a multi part post as we spent the last year in collecting all the pieces of the puzzle to connect to and get data from our Echelon Type 83331-3IAAD meter. Like others trying to do this, we hit a lot of “red tape”, lack of knowledge from involved partners, confusions and even deliberate mis-information. But in the end we actually succeeded and now have all the pieces to complete the puzzle. We are working on finalizing a tinker solution, but are still under a NDA (Non-Disclosure Agreement from the current technology owner NES (Networked Energy Services). Luckily NES is working hard on releasing the required information as open source through OSGP Alliance (OSGP is short of Open Smart Grid Protocol). We have been promised this will happen “soon” (and have received drafts of the documents – so we are pretty sure it will happen soon). This is the start of the process that hopefully will make it possible to share the knowledge with you.

Shoutout to the guys and girls at the just finished Thank for a great gathering and for listening to our Echelon stories… And an additional shoutout to Georg Sluyterman, who is running BefriDinElmå and is beta-testing our prototype in his Echelon Power Meter.

For a few years Graves and Gert have been trying to create a solution to read out our power consumption from our so-called Smart Meter: Echelon Type 83331-3IAAD.

Initially we hoped to be able to read the meter data through the IR (Infra Red) “eye” on the meter. This seems to be possible on meters from other manufacturers, (i.e. Kamstrup) and HAL9K even shared the required hardware for it.

We spent quite some time on this “rabbit hole”, but eventually found internet sources mentioning this interface is encrypted and you need to obtain a key from your power network provider to decrypt this interface on our Echelon meter. It seems this interface is used during production of the meter and have a bunch of features. Unfortunately our guess is also that the security of this port has been compromised as our power network provider N1 simply refuses to hand over the required keys. We have not found any real evidence of this, but if you have any information regarding this, please enlighten us in the comments :-).

At this point in time we reached out to our power company, which referred us to N1. We started pushing N1 for information on how to integrate with the meter (as you are supposed to be able to do this by law) and keys for the IR port, but is seemed like a dead end. Others have tried with no success – and we did expect kind of the same result… We thought that the guys at N1 withheld information from us on purpose… Today we know it is more likely they simply did not have much usable information and only knew that they would/could not hand out the IR encryption keys.

The obvious next step was to start counting the LEDs blinking on the meter. Other have successfully implemented this very simple interface, and we know it is possible to follow the power consumption by counting the LED blinks, and maybe even get the real time consumption by measuring the blinking frequency. Although this will work and we also went down this path for a while, it is not really a nice solution. You cannot read the exact counter shown on the meter and get other available information etc.

During our research we also found that our power network provider (N1) at least at some point might have offered an electrical interface pulsing the same way as the LED. Apparently you had to rent it for a monthly fee… In other words, not for tinkeres like us….

The ironic part is that the meter in fact have screw terminals for different interfaces (M-Bus and something called “MEP” – we’ll discuss that in our next post), but on our meter they are hidden behind a protected/sealed cover. And you are NOT allowed to break the seals in any way. It is simply illegal for consumers to do that in Denmark.

At this point in time we kind of gave up… Apparently it is not possible to get to the meter data in a real usable/electronic way. And N1 is not providing much help….

…or rather – we gave up for a while – stay tuned for our next post :-)…

Echelon/NES Smart Meters – rebooted


We have been quiet for a while. Not because we have not been tinkering, but because we’ve been very busy tinkering.

To be precise we’ve been tinkering with our Echelon type 83331-3IAAD Smart Meters (power meters) and how to read out the consumption in a nice way…

Echelon type 83331-3IAAD Smart Meters (power meter)

At the Danish gathering 2021 we’ll be presenting a session (Friday @ 16:00 CET) about our process and the current state of this project. See you there?

It is yet to be determined how much details we can share because we are currently under NDA (Non-Disclosure Agreement) with the product owner NES (Networked Energy Services) about the details… But that will hopefully change soon.

Are you interested in communicating with your Echelon Smart Meter?

Stay tuned for more info. on how to do it… coming to very soon now…

Arduino IDE v1.8.9, esp32 v1.0.2 and ulptool v2.3.0

Arduino logo

Are you messing with ultra low power esp32 code and have tried to setup the ulptool example from duff2013s GitHub in Arduino IDE v1.8.9 with Espressif Systems esp32 v1.0.2?

Maybe you got a lot of strange compile errors like these?

Traceback (most recent call last):
 File "C:\Users\<your user name>\AppData\Local\Arduino15\packages\esp32\tools\ulptool\src/", line 506, in 
 File "C:\Users\
<your user name>\AppData\Local\Arduino15\packages\esp32\tools\ulptool\src/", line 106, in main
 build_ulp(PATHS, ulp_files, board_options, True)
 File "C:\Users\
<your user name>\AppData\Local\Arduino15\packages\esp32\tools\ulptool\src/", line 136, in build_ulp
 proc = subprocess.Popen(cmd[1],stdout=subprocess.PIPE,stderr=subprocess.PIPE,shell=False)
 File "C:\Python27\lib\", line 394, in init
 errread, errwrite)
 File "C:\Python27\lib\", line 644, in _execute_child
 WindowsError: [Error 2] The system cannot find the file specified
 exit status 1
 Error compiling for board ESP32 Dev Module.

Note: This error is also reported here:

It is quite a simple fix: The error is probably caused by Espressif Systems moving around some files in esp32 v.1.0.2 – or actually renaming a catalog.

You just need to edit a single file in ulptool v2.3.0. Simply open your platform.local.txt file and change the line:




…and you are “back in business” :-).