Jérôme's picture


Jérôme Lafréchoux

Software & Energy engineer

I used to work in embedded software. I've been working with Atmel microcontrollers for a while. Then I moved to the building/energy sector, and as a FOSS enthusiast, I like to play with OpenEnergyMonitor, learn and contribute.

Unfortunately, I don't have much time to spend on OpenEnergyMonitor right now. For any question regarding OpenEnergyMonitor and especially OEM Gateway / EmonHub, please post on the forums, you're much more likely to get an answer.

Setup / Note to self

What follows should be a more or less up-to-date description of my setup, in case it could be useful to anyone, along with notes that are not ready to be integrated in the Wiki, thoughts about ongoing work...


My first test was an emonTx running somewhere in the house (or outside, as it can run on battery):

emonTX open    emonTX closed

and a Raspberry Pi with a RFM12Pi in my living-room:


Raspberry Pi open

Raspberry Pi closed

The emonTX runs a temperature sensor. The Pi runs an instance of emoncms and forwards the data to a remote server running another instance of emoncms.


In order to use the TX to monitor gas consumption, it needs power autonomy.

I equipped mine with a LiPo battery.

EmonTX + LiPo

It has been running for a few weeks or months.

The range is a bit short and I had to move the Raspberry Pi closer, which was made possible by the Wi-Fi dongle.

Besides, with the cold temperatures, I lose a lot of data frames. At night, when temperature goes under 5°C, I can lose all information from 2 AM to 8 AM.

Other options:

  • AA batteries
  • Refillable AA batteries, but then the voltage is too low. It would need three of them, or a step-up regulator (can be 3.3 or 5 V).
  • Use a 9V battery

Discussion about the step-up regulator: http://openenergymonitor.org/emon/node/2331

I added a step-up regulator and the range is now even shorter.

We've been running a few tests with Trystan. His emonTXv3 could reach my emonBase. My emonTX could reach my emonBase when powered from a laptop USB socket. The range was a little shorter, but this could be due to the soldering of the antenna, which is not so good. On the same emonTXv2, the range falls when using the LiPo + step-up.

I lowered the bitrate to the lowest possible value (1200 bps) and now I'm receiving the packets.


  • See with Glyn about this possible step-up regulator problem, as he may have had the same kind of trouble when adding the step-up to the emonTH.
  • Add solder to the antenna on the TX
  • Try emonTH
  • Try other bitrates. In fact, ideally, modify the firmware of the RFM2Pi to allow for dynamic changing.

Gas monitoring

I'm trying to implement gas monitoring

See those threads on the forum:





My gas meter is an actaris g4 gallus 2000 (specs, installation guide).

Connection of a sensor

When facing the Honywell SS451A Hall effect sensor, the pinout is, from left to right : Vcc, GND, Output

The Pulse counting IRQ socket on the emonTX PCB is plugged this way (see rightmost part of schematics) :

Tip Vcc
Ring Output
Sleeve GND

Make sure the pins of the SS451A are connected correctly, that is, from left to right, Tip, Sleeve, Ring.

By default, the Tip is not connected to either 3.3V or 5V. A drip of soldering must be added to do so. This takes place a bit down the 3.5 mm sockets.

I chose 3.3 V to reduce power consumption, as the sensor is said to support it.

By the way, remember that the sensor is open drain, which means the internal pull-up resistor of the pin must be enabled. This is done with this code :

  pinMode(3, INPUT);   //set the interrupt0  pin3 to input
  digitalWrite(3, HIGH);   // and enable it's internal pull-up resistor

It's easy to check with a voltmeter: normally, ring will be at 3.3 V, and when approaching a magnet, the sensor will put it at 0 V.

The connection of a Reed switch is even simpler. Either connect it between GND and output and activate the pull-up resistor (tested), or just connect it between Vcc and output and don't activate the pull-up resistor (I suppose).

First test : basic falling edge counting

Load following code :

volatile unsigned int count;

void setup()
  Serial.println ("Start");     // signal initalization done

  pinMode(3, INPUT);   //set the interrupt0  pin3 to input
  digitalWrite(3, HIGH);   // and enable it's internal pull-up resistor

  attachInterrupt(1, countP, FALLING);  // device signals a low when active

void loop()

void countP()
   Serial.println (count);

The serial port monitor should print the counter, incrementing every time a magnet passes by the sensor.

Second test : interrupt based pulse counter

See here. Remember to activate the internal pull-up resistor :

  pinMode(3, INPUT);   //set the interrupt0  pin3 to input
  digitalWrite(3, HIGH);   // and enable it's internal pull-up resistor

Feedback on sensors

I've tested my setup with several sensors, both Hall effect sensors and Reed switches. All of them would be triggered by a magnet as expected (a fridge magnet, for instance), but not all of them could detect the meter's wheel. Status here:

Hall effect sensors
Honeywell SS451 No
Diodes Inc. AH180-PL-B No
Diodes Inc. AH180N-ZG-7 No
Reed switches
Standex ORD324-1015 Yes
Coto tech. 15-40 AT SPST No


Software and results

The method used is to send the TX in deeper sleep with the watchdog as a timer, so as to save battery. Downside is we can't compute power on the TX.

The TX sends a counter each time the wheel goes through zero, or if a minute has passed. Sending a counter instead of a pulse is better since the dataframe can be lost on the RF link.

The TX also send a temperature measurement in each frame (which is much more than needed).

Ongoing work. Still stuff to fix in the code.


Add a bit of code to monitor battery status as well ?

Fix power/range issue.

Fix post-processing code. More complicated than I anticipated.

Water metering

Water metering can be done using  pulse counter as well.

My meter is apparently an Altair v3 from Diehl (used to be Sappel). It does not seem to have a magnet that could be used to trigger a Hall effect sensor. It does interfere with a common compass, but I think this is due to the internal magnet the spec refers to. However, it has a sort of tin half circle that turns around, along with a red needle, close to the least significant wheel.

lunarok pointed me to this page [fr] presenting a way to monitor such a meter.

See here: http://www.brultech.com/community/viewtopic.php?f=2&t=480

Water meter


RFM2Pi Gateway

What and why

The gateway is the software running on the Raspberry Pi that reads from the COM port (serial port) of the RFM2Pi board and sends data to a local, and optionally a remote, emonCMS instance.

The historical implementation is a php script: raspberry_run.php that was called once every minute through crontab to make sure it was started again in case of crash. There was a discussion about how to improve this (see here). From emonCMS v5, a script is included to make it run as a daemon.

In the meantime, I wrote an alternative python script. It aims at being more robust, easier to extend, and it features better logging.

Installation and troubleshooting

Since this is still work in progress, you should use the latest version of emonCMS and its raspberrypi module (at least v5). For installation and usage, follow instructions in readme file.

To try it, make sure you've got the parameters right in the Raspberry Pi config tab of your local emonCMS installation. If you are using legacy crontab-launched php script (raspberry_run.php), first remove the crontab line that launches it and terminate any running instance (or reboot if you don't know how to kill a process). We don't want the two gateways to work at the same time.

If anything goes wrong, launch the script manually and see what happens (I would do that even before setting it to run on startup):


All the logging is output to the console and you can check everything works as expected.

In case of failure, it is possible to check the settings with the dedicated command line option:

/var/www/emoncms/Modules/raspberrypi/rfm2pigateway.py --show-settings

Note that since the standalone OEM Gateway, we may question the pertinence of maintaining the python gateway in the Raspberry Pi module. I advise to use the OEM Gateway instead.

OEM Gateway

The RFM2Pi gateway python script was designed as a copy of the php script. It has a few limitations :

  • It is parametered via emonCMS GUI, which is nice, but takes a whole emonCMS installation on the Pi
  • It is limited to RFM2Pi inputs

Starting from this, I wrote a standalone gateway : OEM Gateway.

  • It can be configured through the GUI or through a configuration file, in which case there is no need for a database, and it is easier to extend (no need for a GUI modification).
  • It can listen not only to a RFM2Pi board, but to anything on the serial port or on a socket, which allows easy communication with any local or remote program.
  • It can repeat on the RF link the frames that are received on a socket.
  • The samples are stored when the network is down (work in progress).
  • Its object oriented design makes it relatively easy to extend (add support for different sources of data, or different storage and display servers).
  • It allows the use of the base for forwarding only, which may preserve the SD cards:

The OEM Gateway is now included in the so-called "Rock solid" SD card. This ready-made card allows the RPi to act as a base, but it is read-only to preserve the SD card from wearing off, and therefore it does not embed the emoncms installation. It only acts as a repeater.

There are limits to this object oriented approach. For instance, while being able to send to different types of display servers sounds nice, in practice, most of them don't expect the same kind of data. For instance, they don't do post-processing like in emoncms. Currently, no other display backend is implemented.

RaspberryPi Wi-Fi

When thunder struck my house, the modem was burnt, and since then, the ethernet interface of my Pi is broken. I had to get a Wi-Fi dongle. I got myself an Edimax EW-7811 UN.

It is quite small and works almost out of the box with Raspbian. The driver is free software but it takes a non-free firmware included in the package firmware-realtek included, already installed in default Raspbian installation. See here.

For the configuration, the credits go mainly to Maurice Svay, for his blog post. I had a quite unstable setup, with regular disconnections and no way to reconnect, and the tricks in "Keep the connection alive" set this up. I now have a reliable link.

Website / blog


Member for
4 years 21 weeks