Creating an RaspberryPi EmonHub gateway install using EmonScripts

emonSD
1

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.

pi3a_mbus_reader
pi3a_mbus_reader1860×872 707 KB

Building the gateway image

Download RaspberryPi OS Lite and write to SD card (e.g using a tool like Balena Etcher):
https://www.raspberrypi.org/software/operating-systems/

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: Raspberry Pi Documentation - Configuration

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:

wget https://raw.githubusercontent.com/openenergymonitor/EmonScripts/stable/install/init.sh
chmod +x init.sh && ./init.sh

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:

user=pi
hostname=ehgateway
emonSD_pi_env=1

# Components enabled
apt_get_upgrade_and_clean=true
install_apache=false
install_mysql=false
install_php=false
install_redis=false
install_mosquitto=false
install_mosquitto_server=false
install_mosquitto_client=false
install_emoncms_core=false
install_emoncms_modules=false
install_emonhub=true
install_emoncms_emonpi_modules=false
install_firmware=false
install_emonpilcd=false
install_emonsd=true
install_wifiap=false

Start the installation:

./main.sh

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.

[hub]
loglevel = DEBUG

[interfacers]

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

[[MQTT]]

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

    [[[runtimesettings]]]
        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/

[nodes]

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?

2

Why not just clone emonhub repo and run the install.sh?

[edit]
Why not just use a PiZeroW?

3

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?

4

I was just interested to try the Pi3A+

1 Like
5

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.

2 Likes
6

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

1 Like
7

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:.

8

Yes just emonhub. Ok thanks.

Ok I will take a look at that, this issue I assume http interfacer "UnboundLocalError: local variable 'reply' referenced before assignment" · Issue #144 · openenergymonitor/emonhub · GitHub?

1 Like
9

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

1 Like
10

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
11

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
12

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

13

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