OpenEnergyMonitor Development Plan Outline

(Trystan Lea) #1

To read our progress update on the last development plan and progress in 2018, see forum post here: 2018 Development Progress Update. The following outlines our development plan going forwards and will be an evolving document, updated over time.

EmonSD Image & Hub software stack

We have recently released the new image, full details and release notes can be read here: emonSD-30Oct18 (Raspbian Stretch Pi3B+ compatible).

Looking ahead we are interested in exploring a different approach for future image releases. Compiling an image update is currently very time consuming and the upgrade process across major image versions is overly complicated. We want to find a way to upgrade systems without asking to install the latest image and copy data across.

@beaylott at CarbonCoop has been working on an promising approach using Docker. A super lightweight base image is first installed which is then used to launch a docker container containing the OS, Apache, MySQL, Redis, Mosquitto and Emoncms. The data is stored separately to the software stack contained in the docker container, which can be easily changed in its entirety.

Examples of lightweight base images onto which a docker container/s can be installed:

Good example (thanks to jakezp) of an Emoncms self contained docker container with everything running in a single container. I tested this on a synology disk drive and it worked really well:

Alternatively, its possible to have multiple containers for the different system services:


  1. Inputs, feeds, device integration ongoing polishing, switch from beta after extensive testing.
  2. Indexed inputs, testing, complete, release, Development: Indexed Inputs
  3. Hierarchical settings: see github
  4. Work through issues raised and listed on github.

Remote access to EmonPi/EmonBase using MQTT broker on
We are particularly excited about this one. Emrys is making good progress, with a concept up and running that provides remote access to a local emoncms feed list without port forwarding etc using a mosquito MQTTs broker, secure websockets etc. Further details to share alongside demo soon. See original discussion of this idea here: Emoncms local vs remote

February 18th Update: Emoncms remote access concept using MQTTS

Emoncms org

  • Keeping up-to-date with the latest emoncms development.
  • Removal of inactive accounts, automated system for handling accounts that continue in negative balance.
  • Continued work on merging the and emoncms code bases, and documenting how to install the standard emoncms in a multi-server environment.
  • MQTT data upload method.

Current Hardware & Firmware

  • Use EmonLibCM as default EmonTx v3 firmware
    See forum post: EmonLibCM - Version 2.01
  • Explore what is involved with creating a calibration jig (see meeting with mods)

EmonEVSE & Demand side response

Outline of our proposed approach to demand side response: real-time and forecast based scheduling:

  1. Document OpenEVSE setup using the new device module.

  2. Document OpenEVSE electrical installation guidance.

  3. OpenEVSE: RaspberryPi version, @jeremypoulter has been working on a nodejs version of the ESP app, which is at feature parity.

  4. Nissan connect integration, pull in state of charge, calculate charge time based on target prc, current SOC and charge rate. Set OpenEVSE charge timer based on this. Prototype as service running on a RaspberryPi. Request SOC when vehicle is plugged in.

  5. Continued development on the demandshaper module. First steps towards integrating UK Grid Carbon Intensity and Agile Octopus tariff forecast has been implemented but needs further work:

    • fall back option where forecast is not available
    • how to handle schedules that cross from one days forecast into the next.
    • automated and regular schedule recalculation to attempt to improve schedule timing based on newer forecasts.
    • re-scheduling of schedules in progress, take into account time already run and time left to run in re-scheduled run period.
    • reporting of scheduling results, e.g this month on average you charged the car at 140gCO2/kWh or at 10 p/kWh. Graph of averaged daily charge profile to demonstrate reductions in peak-time consumption.
  6. Develop hybrid approach that combined forecasts with real-time solar data. Can forecasts be updated regularly in the case of weather forecasts, expected solar output over the next 6 hours?

  7. Remote control of OpenEVSE (mqtt broker on server, as above.)

  8. Stretch goals: Payment, RFID, Multi-car supply sharing

Integrations: nissan connect, open vehicles, tesla, renault


STM32 Development thread:

Goals of the project:

  • Higher resolution 12 bit ADCs
  • Higher sampling rate
  • Continuous sampling on all Voltage and Current channels
  • Shield/extension design
  • RaspberryPi core, local datastorage, visualisation
  • Learning resources on the STM32 platform to enable modification & customisation.


  1. Work through STM32 power supply, clock, programming sub circuits, check understanding, component sourcing. Put together base board design (equivalent of a STM blue pill, or Ken’s ARMIGO) potentially with a couple of CT and ACAC sensor inputs for initial testing.
    See github:
    29th Nov 2018: PCB Design sent for manufacture: STM32 Development

  2. Filter design for CT and ACAC voltage input circuits.

  3. Construct 3D model of enclosure options, visualise different stacking design options, connectors, raspberrypi location. Ease of manufacture & assembly.

  4. Verify MBUS reader running on STM32 alongside energy monitoring code.

  5. Understand @dBC one wire code and timing implications.

  6. Review base-board feature requirements:

    • STM32 core and pin count
    • Number of CT sensor inputs
    • CT sensor mapping to ADC channels
      sequential vs parallel sampling capabilities.
    • Number of ACAC Voltage inputs
    • DS18B20, pulse counting connector types and numbers.
    • MBUS
    • RaspberryPi connector and mounting
    • ESP8266 on board
    • RFM69 support
    • RTC
    • Display & push button

Evaluate cost implications of including on board vs requiring shield additions for items such as MBUS, RFM69 & ESP8266.

  1. Create PCB layout for first hardware design. Get prototypes, testing, fix issues, EMC prelim, design iteration and revaluation of next steps from this point.

Given the wide range of topics above, this thread will be locked in order to avoid multiple parallel conversations in a single discussion thread. See the following forum threads for discussion on particular items:

OpenEnergyMonitor Development Plan Outline - Base OS and Docker
Development Roadmap 2019 - Robust Backup Process
2018 Development Progress Update
emonSD next steps
(Trystan Lea) pinned globally #6

Emoncms Demand Shaper module