Emoncms

An honest look at what you actually get when you self-host the OpenEnergyMonitor stack.

TL;DR

• What it is: Open-source (AGPL-3.0) web application for logging, processing, and visualising energy consumption, temperature, and other environmental sensor data — part of the broader OpenEnergyMonitor project [README].
• Who it’s for: Homeowners, small businesses, and sustainability-focused engineers who want to monitor real-time and historical energy data without paying ongoing SaaS fees, and who are comfortable with a Raspberry Pi or a Linux VPS [README][3].
• Cost savings: The emoncms.org managed cloud switched to a paid per-feed model in 2018 [1]. Self-hosted on a Raspberry Pi you likely already own (or a $5/mo VPS), the software itself costs nothing.
• Key strength: A decade-long purpose-built stack for energy time-series data. The storage engine (PHPFina, PHPTimeSeries) was written specifically for this use case — not bolted onto a generic database [README].
• Key weakness: Narrow scope by design. If you want dashboards, alerting, home automation, or data from arbitrary sources beyond energy sensors, you’ll be wiring Emoncms to other tools rather than using it as an all-in-one platform. AGPL-3.0 license also means commercial embedding requires open-sourcing your modifications [README].

---

What is Emoncms

Emoncms is a PHP web application that accepts time-series data from sensors — electricity clamps, temperature probes, solar inverters, heat pumps — stores it efficiently, and lets you visualise and act on it through dashboards, graphs, and application-specific views. It’s the software half of the OpenEnergyMonitor project; the hardware half is the emonPi (a Raspberry Pi-based energy monitor) and a family of sensor nodes that talk to it over RF or MQTT [README][3].

The core concept is simple: Inputs receive raw sensor values. Processes clean, transform, or compute derived values (kWh from watts, daily totals, rolling averages). Feeds store the resulting time-series to disk [README]. That pipeline — sensor → input → process → feed → visualisation — is what every Emoncms installation revolves around, whether you’re monitoring a single house or a community energy project.

The project has been active since at least 2013, based on the earliest blog posts in the source material [4]. It sits at 1,306 GitHub stars — a modest number that reflects a focused community rather than broad general-purpose appeal [merged profile]. The lead developer, Trystan Lea, appears to be the primary committer based on project history patterns visible in adjacent repositories [5].

What makes it worth considering over general-purpose tools like Grafana + InfluxDB is the built-in energy vocabulary. Emoncms ships with application dashboards purpose-built for MyElectric, MySolarPV, and heat pump monitoring [README][3]. It understands UK Octopus Agile tariffs out of the box [README]. It can calculate daily kWh, Economy 7 split-tariff costs, and pulse-count data from utility meters [README]. You don’t assemble these from scratch; they exist.

---

Why people choose it

The third-party review pool for Emoncms is thin compared to general-purpose SaaS alternatives — the primary published sources are the OpenEnergyMonitor community forum and the project’s own blog, which limits independent perspective. That said, the picture that emerges is consistent.

The OpenEnergyMonitor hardware ecosystem is the main pull. If you’ve bought an emonPi or emonTx sensor node from the OpenEnergyMonitor shop, Emoncms is what those devices are designed to feed into. The emonSD pre-built Raspberry Pi image ships with Emoncms pre-installed, so for that hardware path, self-hosting isn’t really a choice — it’s the default [3][README].

Long-term data sovereignty. The community forum thread from 2018 when emoncms.org introduced paid billing [1] shows users explicitly grateful that self-hosting existed as an escape hatch. Quote from that thread: “I’m self-hosted, so these changes will not affect me, but thanks guys for keeping emoncms.org a free service for so long” [1]. That reaction captures why people choose Emoncms over managed IoT monitoring SaaS — you own the database, and no billing decision by the vendor can cut off access to five years of your electricity data.

SD card longevity on Raspberry Pi. The README calls out Redis explicitly as reducing disk writes and prolonging SD card life [README]. This is the kind of detail that only appears in software built by people who’ve actually run it on Raspberry Pis long-term and watched SD cards die.

Home automation integration. The emonPi running Emoncms also ships with Node-RED, OpenHAB, and MQTT — making it a credible home automation hub as well as an energy monitor [3]. One blog post from the project lead demonstrates using it to control central heating via Google Home, with the full pipeline running locally without internet dependency [3].

---

Features

Core data pipeline:

• Inputs with configurable process lists (unit conversion, calibration, math operations, feed routing) [README]
• PHPFina (fixed-interval) and PHPTimeSeries (variable-interval) custom time-series storage, both written for this project [README]
• Buffered writes via Redis to reduce disk I/O [README]
• Input processing runs server-side on every data receipt [README]

Visualisation and dashboards:

• Graph module with multi-feed overlay, dual-axis support [2]
• Dashboard builder for custom layouts [README]
• Application dashboards: MyElectric, MySolarPV, heat pump monitoring [README][3]
• Octopus Agile tariff integration [README]
• Histogram views and daily/average calculations [README]

Data handling:

• REST API for posting and querying data [README]
• MQTT input support [README]
• Encrypted input support [README]
• CSV export [README]
• Post-process module for re-running calculations on historical data [README]
• DemandShaper module for smart scheduling (e.g., EV charging around tariff windows) [README]

Infrastructure:

• Docker support [merged profile][README]
• Mobile app (Android, at minimum) [merged profile][3]
• Backup and import/export utilities [README]
• Multi-user support with account linking for billing administration [1]
• Remote access support [README]

What’s absent:

• No alerting or notification system in core (you’d wire Node-RED or external tooling for that)
• No native integration with non-energy data sources beyond what you build yourself
• Dashboard builder requires manual layout work — there’s no auto-generated “overview” from sensor data

---

Pricing: SaaS vs self-hosted math

Emoncms.org (managed cloud): The platform switched from fully free to a paid per-feed model in July 2018 [1]. The exact current per-feed pricing isn’t published in the data available for this review — the pricing page exists at emoncms.org/site/pricing but the scraped content didn’t capture tier details. Based on the 2018 community announcement [1], accounts can run a negative balance for one month before posting is disabled, three months before archiving, and six to twelve months before permanent deletion. This graduated model suggests pricing is low enough that lapse management, not immediate cutoff, is the concern.

Self-hosted:

• Software: $0 (AGPL-3.0)
• Hardware: A Raspberry Pi 4 you likely already have, or $5–10/mo on a VPS
• Time to set up: 30 minutes on the emonSD image for Raspberry Pi; 1–3 hours on a fresh Linux VPS following the documentation

What you’re escaping: Commercial energy monitoring SaaS (Sense, Emporia, utility-provided dashboards) typically runs $10–30/mo and locks your historical data behind their platform. If you’ve been running emonPi hardware for five years, that historical dataset has real value — it exists on your disk, not someone else’s server [1][3].

The financial case for self-hosting Emoncms specifically isn’t the same as escaping Zapier’s per-task pricing. The emoncms.org cloud isn’t expensive. The real case is data ownership and the ability to run local integrations (Node-RED, OpenHAB, Ollama for analysis) without routing energy data through third-party servers [1][3].

---

Deployment reality check

Raspberry Pi path (easiest): The emonSD pre-built image is the recommended path if you have OpenEnergyMonitor hardware. Flash the image, boot, done. Emoncms, Node-RED, OpenHAB, and MQTT all run pre-configured [3]. This is genuinely non-technical-founder accessible if you’ve ever set up a Raspberry Pi before.

Linux VPS path: The README specifies Ubuntu Linux or Raspberry Pi OS as tested platforms. The stack is PHP + MySQL/MariaDB + Apache + Redis — a LAMP variant [README]. This is functional but dated infrastructure. If you’re deploying in 2026 and comfortable with Docker, the Docker path is cleaner.

Docker path: Docker support exists [merged profile], though the README’s primary install documentation points to the native stack. The Docker Compose path should work on any modern Linux host.

What can go wrong:

• Redis is “recommended” but not strictly required — however, some input processors fail silently without it [README]. Silent failures in data collection are particularly bad because you may not notice missed readings until you look at a gap in a graph weeks later.
• The stack requires PHP, which rules out minimal container setups without additional configuration.
• Shared hosting and XAMPP are explicitly unsupported [README].
• Windows is not a supported platform [README].
• The graph module has had historical UI bugs reported by the community — colour picking issues, legend rendering problems with dual-axis graphs [2]. These appear to be older issues, but the community forum being the primary bug tracker means you need to search there to understand current state.

Time estimates:

• emonSD on Raspberry Pi with OpenEnergyMonitor hardware: 30–60 minutes
• Native LAMP install on Ubuntu VPS: 2–4 hours following documentation
• Docker on VPS: 1–2 hours if you’re comfortable with Docker Compose
• Non-technical founder, no Linux experience, no helper: not recommended without a deployment service

The documentation lives at docs.openenergymonitor.org and is reasonably thorough — the README links to 20+ specific guide pages covering MQTT, graphs, dashboards, pulse counting, CSV export, and troubleshooting [README]. That breadth suggests a project that has been actively maintained and documented over time, even if the UI and stack feel dated.

---

Pros and Cons

Pros

• Purpose-built time-series storage. PHPFina and PHPTimeSeries were designed specifically for energy monitoring data — fixed and variable interval, with write buffering via Redis [README]. You’re not fighting a general-purpose database to store millions of timestamped sensor readings efficiently.
• OpenEnergyMonitor hardware integration. If you’re already in the emonPi ecosystem, Emoncms is the native target — zero integration effort, pre-built SD images, RF sensor support [3].
• Application dashboards that actually mean something. MyElectric, MySolarPV, heat pump monitoring — not generic charts, but views that answer energy-specific questions [README][3].
• MQTT-native. First-class MQTT support means it integrates cleanly into existing home automation stacks [3][README].
• Long project history. Active since at least 2013, documented upgrade paths, backup utilities [README][4]. For something that’s going to sit logging data for years, longevity matters.
• Data export exists. CSV export and backup scripts are documented [README][1]. You’re not trapped.
• Local-first by design. The entire stack can run without internet. MQTT, Node-RED, OpenHAB, and Emoncms on a single Pi, no cloud dependency [3].

Cons

• AGPL-3.0, not MIT. If you want to embed Emoncms in a commercial product or service, AGPL requires open-sourcing your modifications. This is a real constraint for anyone building on top of it [merged profile][README].
• Dated stack. PHP + Apache + MySQL is functional but not what you’d choose in 2026. Docker helps, but the underlying architecture shows its age.
• Silent failures. The README explicitly notes that some input processors “fail silently” if Redis isn’t installed [README]. In a data logging tool, silent data loss is a serious reliability concern.
• Narrow scope. Emoncms is an energy monitor, not a general-purpose sensor platform or IoT hub. Expanding beyond energy data requires custom modules or external tooling [README].
• Small star count relative to alternatives. 1,306 GitHub stars [merged profile] means a smaller community than Grafana, Home Assistant, or even more specialised tools. Fewer eyes on bugs, fewer community integrations, more niche support.
• Graph module bugs reported. The community forum has documented UI issues in the graph module — legend rendering, dual-axis colour picking — suggesting the frontend receives less development attention than the backend [2].
• No built-in alerting. If you want to be notified when solar production drops or consumption spikes, you wire in Node-RED or another tool. Not included.
• Installation complexity for non-LAMP users. The native install path is a full LAMP stack, which is non-trivial to set up correctly and maintain securely on a VPS.

---

Who should use this / who shouldn’t

Use Emoncms if:

• You have OpenEnergyMonitor hardware (emonPi, emonTx) and want the native software stack.
• You’re monitoring home or small business energy consumption and want five-plus years of historical data on your own hardware, not a vendor’s server.
• You’re building a heat pump monitoring setup and want the purpose-built dashboard rather than assembling one from generic tools.
• You’re integrating with Node-RED or OpenHAB via MQTT and want Emoncms as the data layer.
• You care about running everything locally, including the dashboard, with no internet dependency.

Skip it (use Home Assistant Energy instead) if:

• You’re a non-technical founder with no Linux experience. Home Assistant has better non-technical onboarding and an active commercial support ecosystem.
• You need alerting, notifications, or automation built into the same tool.
• You want a modern UI and are not married to the OpenEnergyMonitor hardware ecosystem.

Skip it (use Grafana + InfluxDB or Prometheus) if:

• You need to monitor more than energy — servers, applications, network equipment — alongside your energy data.
• Your team has existing Grafana or Prometheus infrastructure.
• You need enterprise features: access control, SSO, team management.

Skip it (stay on emoncms.org cloud) if:

• You’re not comfortable managing a Linux server or Raspberry Pi.
• You don’t want responsibility for backups and updates.
• Your dataset is small and the per-feed pricing is not a meaningful cost.

---

Alternatives worth considering

• Home Assistant — broader home automation platform with a growing Energy monitoring module. Better non-technical onboarding, larger community, active commercial ecosystem (Home Assistant Cloud, Yellow hardware). The energy dashboard is less specialised than Emoncms but covers most residential use cases. Apache 2.0 license.
• Grafana + InfluxDB — the general-purpose alternative for anyone who wants maximum flexibility. Steeper setup, but handles any data source and has enterprise features. Grafana is AGPL-3.0 for the open-source edition.
• Volkszähler — German open-source energy monitoring project. Similar niche to Emoncms, less internationally documented.
• ioBroker — home automation hub with energy monitoring adapters. More of a Home Assistant competitor than a direct Emoncms replacement, but worth comparing for German-market users.
• emoncms.org cloud — the managed version of the same software. Costs money per feed but removes all infrastructure responsibility.
• Sense — commercial energy monitor with proprietary cloud. Better non-technical experience, device-level disaggregation that Emoncms doesn’t do. $299 hardware + ongoing subscription.

For the core use case — a homeowner or small business with OpenEnergyMonitor hardware wanting offline, local, long-term energy data — the realistic shortlist is Emoncms vs Home Assistant Energy. Emoncms wins on energy-specific features and data storage efficiency. Home Assistant wins on UI modernity, non-technical accessibility, and breadth.

---

Bottom line

Emoncms is a well-worn, narrowly-focused tool that does one thing well: log and visualise energy and environmental sensor data with no cloud dependency. It’s not trying to be Zapier or a general-purpose IoT platform. If you’re in the OpenEnergyMonitor hardware ecosystem, it’s the natural choice and the path of least resistance. If you’re not, the LAMP stack setup, AGPL license, and narrow scope make it harder to recommend over alternatives like Home Assistant unless you specifically need its time-series storage design or energy-specific application dashboards.

The honest pitch for self-hosting it: your five years of electricity consumption data sits on a disk you control, costs you nothing beyond the hardware you already own, and isn’t subject to any vendor’s billing decisions or server shutdowns. That’s the value proposition — not cost savings at scale, but permanence and ownership. For the kind of data that only becomes meaningful over years of accumulation, that matters.

If setting up and maintaining the stack is the blocker, that’s a one-time deployment job — exactly what upready.dev handles for clients.

---

Sources

1. TrystanLea, OpenEnergyMonitor Community Forum — “Emoncms.org billing” (Apr 2018). https://community.openenergymonitor.org/t/emoncms-org-billing/7187
2. OpenEnergyMonitor Community Forum — “Emoncms Graph module developments” (Aug 2016). https://community.openenergymonitor.org/t/emoncms-graph-module-developments/1380
3. Glyn Hudson, OpenEnergyMonitor Blog — “emonPi as a Home Automation Hub” (May 2017). https://blog.openenergymonitor.org/2017/05/emonpi-mqtt-googlehome/
4. Trystan Lea, OpenEnergyMonitor Blog — “Building Energy Modelling part 3 - Carbon Coop and Open Source SAP 2012” (Jun 2013). https://blog.openenergymonitor.org/2013/06/building-energy-modelling-carbon-coop/
5. Open Sustainable Technology — “HeatpumpMonitor.org project listing”. https://ost.ecosyste.ms/projects/32214

Primary sources:

• GitHub repository and README: https://github.com/emoncms/emoncms (1,306 stars, AGPL-3.0)
• Official website: https://emoncms.org
• Pricing page: https://emoncms.org/site/pricing
• Documentation: https://docs.openenergymonitor.org/emoncms