OpenEnergyMonitor Emoncms

Last reviewed Sep 13, 2026 · 941 words

The thing to understand about Emoncms before you install it is the pipeline: data arrives as an input, passes through a chain of processes, and lands in a feed. Every dashboard, every kWh figure, every heat pump COP graph is built on that chain, and most first-week frustration comes from expecting Emoncms to work like Home Assistant, where a sensor simply appears. It does not. You configure what each incoming value becomes, and once you do, the software has been quietly logging energy data since 2011 and is very good at it.

Inputs, processes, feeds: learn this first

An input is a raw value posted by a device, say power1 from a CT clamp. A feed is stored time series. Between them sits a process list you build in the web UI: log to feed, power to kWh, accumulator, calibration, publish to MQTT, and so on. A single power reading typically fans out into 3 feeds: instantaneous watts, cumulative kWh, and a daily kWh bar. Feeds are stored in Emoncms's own fixed-interval engines (PHPFina for regular data, PHPTimeSeries for irregular), which is why a year of 10-second readings takes a few hundred MB rather than filling a MariaDB table.

Get this model right in the first hour and everything else is configuration. Get it wrong and you end up with 20 orphaned feeds and no idea which one the dashboard is reading.

Hardware decides whether it is worth it

Emoncms is the software half of the OpenEnergyMonitor project, and the listing's "best with OpenEnergyMonitor hardware" is the truth, not a caveat. The emonPi and emonTx boards post to it natively, emonHub handles the radio and serial plumbing, and the shop-bought bundle just works. If you instead have a Shelly EM, an IoTaWatt, a smart meter P1 port, or a heat pump with Modbus, you can still get the data in over HTTP or MQTT, but you are writing the glue yourself, and at that point Home Assistant with its energy dashboard will feel like less work for whole-house totals.

Where Emoncms still earns its place with third-party hardware is analysis depth: long-term half-hourly data, comparison across years, and the specialised apps, which is where the next section comes in.

The heat pump case is where it shines now

The MyHeatpump app inside Emoncms is the reason a lot of people install it in 2026. Feed it flow temperature, return temperature, flow rate and electrical input, and it computes real-time and cumulative COP, plots it against outside temperature, and produces the kind of daily and monthly efficiency figures installers argue about. The public HeatpumpMonitor.org site is built on exactly this, with hundreds of real UK systems reporting through Emoncms. Nothing in the home automation category does this analysis as well out of the box, and Home Assistant users usually end up running both.

Docker install and the three services underneath

Emoncms is PHP, and it needs MariaDB for user and metadata storage plus Redis for the input buffer. The emoncms-docker repository on GitHub provides a compose file that runs the web container, the database and Redis together; on bare metal the EmonScripts installer does the same on a Raspberry Pi or Debian box. The 256 MB RAM floor in the listing is genuine, and a Pi 3 handles a household's worth of feeds without effort.

Three settings matter after first login. Create a user and note both the read and write API keys, because every device posts with the write key and every dashboard embed uses the read key. Enable the MQTT service if you plan to publish feeds elsewhere. And set the feed data directory on real storage, not the SD card, if this is a Pi you expect to run for years; feed engines write constantly, and worn cards are the number one cause of "Emoncms lost my data" posts.

Backups are two things: a mysqldump of the small metadata database and a copy of the feed data directory. The built-in backup module bundles both into a tarball, and I would ship that off the machine weekly.

Pair it with Home Assistant, do not fight it

Home Assistant has a native Emoncms integration that pulls feeds in as sensors, and Emoncms can subscribe to any MQTT topic from a Mosquitto broker you already run. The clean pattern is: devices publish to MQTT, Emoncms logs and analyses, Home Assistant automates. If you want prettier graphs than Emoncms's own, the feeds are readable through a simple HTTP API and people pipe them into Grafana via InfluxDB, though for pure energy data Emoncms's dashboards, dated as they look, are more purpose-built.

The hosted emoncms.org service charges per feed per year, about 1 pound at last check, which is cheap, but self-hosting removes any feed limit and keeps years of half-hourly data on your own disk.

What I'd do

If you own OpenEnergyMonitor hardware or you are monitoring a heat pump, run Emoncms on a small Debian box or a Pi with an SSD, via the compose file, with MQTT enabled and the backup module scheduled. Feed the same data into Home Assistant for automations and use Emoncms for the analysis it was built for. If you have neither the hardware nor a heat pump and just want a monthly kWh number, skip it and use Home Assistant's energy dashboard on its own; Emoncms is the specialist, and specialists are worth the setup only when you have their kind of problem.