OpenEnergyMonitor Community

Creating an RaspberryPi EmonHub gateway install using EmonScripts

I’ve been putting a little RaspberryPi 3A+ MBUS Reader together for a heat metering project. The project does not necessarily need the full emonsd image so I though I’d use EmonScripts to build a basic EmonHub gateway to forward the data on to a separate emoncms server. Thought I would share this as it might be useful for others.

Building the gateway image

Download RaspberryPi OS Lite and write to SD card (e.g using a tool like Balena Etcher):

Open boot partition on SD card and add a file called ‘ssh’ in order to enable SSH. To boot straight onto your WiFi network follow the guide here:

Once the Pi has powered up, SSH into the pi via it’s IP address, use a tool such as the Android app Fing to find the Pi’s IP address.

ssh [email protected] (password: raspberry)

Once in, start the installation procedure with:

chmod +x && ./

After a short period the script will ask to review configuration, enter ‘y’ for yes. I’ve added a emonhub_gateway config file that can be copied in place:

cd /opt/openenergymonitor/EmonScripts/install/
cp emonhub_gateway.config.ini config.ini

In the top section of config.ini, most of the components are set to false, apart from apt_get_upgrade_and_clean, install_emonhub and install_emonsd:


# Components enabled

Start the installation:


The installation takes quite a bit of time, in particular the system update steps at the start.

Once complete reboot the pi and SSH back in.

You can now configure emonhub.conf to read from the connected devices and forward the data to the correct location. Here’s an example of reading from the MBUS reader pictured above posting to an emonpi elsewhere in the house via MQTT.

loglevel = DEBUG


    Type = EmonHubMBUSInterfacer
        device = /dev/ttyUSB0
        baud = 2400
        pubchannels = ToEmonCMS,
        address = 92
        pages = 0
        read_interval = 10
        nodename = MBUS


    Type = EmonHubMqttInterfacer
        mqtt_host = emonpi.local
        mqtt_port = 1883
        mqtt_user = emonpi
        mqtt_passwd = emonpimqtt2016

        pubchannels = ToRFM12,
        subchannels = ToEmonCMS,
        node_format_enable = 0
        node_format_basetopic = emonhub/
        nodevar_format_enable = 1
        nodevar_format_basetopic = emon/
        node_JSON_enable = 0
        node_JSON_basetopic = emon/


I posted separately about the option to use overlayFS to make the image read-only here:
OverlayFS RaspberryPi read-only file system

This appears to work with the above installation fine, however I assume it will disable the persistence of the log2ram logging data so may not be desirable?

Why not just clone emonhub repo and run the

Why not just use a PiZeroW?

I was thinking that the logrotate and log2ram components from EmonScripts might be useful… and the wificheck script? Your right Im not using much from EmonScripts, is it worth it Im not sure? Perhaps just cloning emonhub and using overlayFS is a simpler better approach?

I was just interested to try the Pi3A+

1 Like

Logrotate, yes possibly - log2ram possibly but I’ve been running an old Pi for years with just emonhub so I think it is overkill.

OverlayFS - again, overkill IMHO.

It is an ‘ain’t broke; don’t fix’ system.


If you were deploying 10 of these in customer houses and want to minimise chance of SD issues what would you do?

1 Like

Just emonhub? Then yes, perhaps I’d use overlay, but that is then fire and forget - no updates.

I’d also fix the issue with emonhub that causes it to crash when there is no network before deployment :laughing::laughing:.

Yes just emonhub. Ok thanks.

Ok I will take a look at that, this issue I assume

1 Like

Yes. I agree with Paul the HTTP should actually be in the interfacer.

1 Like

What I have suddenly remembered is that that emonhub Pi is running DietPi so using the builtin DietPi-RAMlog plus all the other tweaks that make it really stable.

It is a great distribution for a Pi.

1 Like

I have deployed dozens, years ago and have not had any failures to date. I used the Raspbian lite image of the day. I think it might have even been wheezy, in RO mode with just emonhub and a couple of minor utilities installed.

I’d be interested to see how your tests go, I still think the best OEM images to date were the old “rock solid gateway” with OEMGateway and a RO OS. When I get emonhub and log2ram working as I want I will look to see about making Buster lite RO and make a modern “rock solid gateway” image that can be used on any Pi (inc Zero) with rfm2pi or gpio connected emontx and/or usb connected emontx’s, or even just pulse counters or temp sensors a sort of “emonhub” device.

I would however add an interfacer that records all data locally, to compliment/persist the buffers and add a function like the iotawatt has to repost all data from a certain date or the even beginning. This could in realtime to a usbstick or my preference would be to have a small battery backup that allows the Pi to shutdown gracefully, that way the archived data could be written to disc once every hour when L2R mounts the OS as RW to persist the logs and mounts it back as RO immediately after. that way the period since the last hourly write isn’t at risk when power is removed.

1 Like

Have you looked at DietPi? It has it’s own RAM logging and I think a RO option. Very optimised image.

Yes I know all about dietPi, you have been a big fan for a long time, this isn’t the first time you’ve sung it’s praises.

No, I haven’t tried it, in fact it’s because it’s “Very optimised” that I’m not keen. I’ve corrected my post above as it came to me that I did not use the lite version of Raspian, I always prefer the full version, especially now they have another “fuller” version with all the recommended stuff like nodered etc. I only use “lite” during development because it’s smaller to keep writing to sdcard and I get to see what isn’t installed by default so my install scripts for lite users too.

The “rock-solid gateway” I refer to above was originally based on a RO distro based on “optimised” raspbian and I wasn’t keen but it did the job very well until we worked out how to RO raspbian wheezy and that became the OS of choice for the “rock solid gateway” and then the emonPi images at a later date.

I prefer a full OS with all the tools and utilities there whether they’re needed day to day or not, I hate starting to assist someone with debugging or helping someone use something for the first time with “have you installed blah blah blah”

1 Like