OpenEnergyMonitor Development Plan Outline

Organisation
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

Updated October 2019

emonSD-17Oct19 has now been released based on the EmonScripts automated build script process and running on latest Raspbian Buster.

This years development discussion for reference:

Emoncms

18th February 2019: Remote access to EmonPi/EmonBase using MQTT: Emoncms remote access concept using MQTTS

1st of May 2019: Emoncms V10 Release
Emoncms V10.0.0-beta master branch release

1st of October 2019: Emoncms hierarchical settings V10.1.8: Emoncms release v10.1.8

Ongoing

Emoncms org

  • Keeping emoncms.org 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 emoncms.org and emoncms code bases, and documenting how to install the standard emoncms in a multi-server environment.
  • MQTT data upload method.

Current Hardware & Firmware

21st of November 2018: EmonLibCM Library Version 2.01 release:
EmonLibCM - Version 2.2.1 (Released 30/10/2021)

4th of July 2019: EmonTxV3 Continuous Monitoring Firmware release v1.0-beta:
EmonTxV3 Continuous Monitoring Firmware (v1.0-beta)

2nd of October 2019: EmonTxV3CM Firmware updated & new emonhub node decoders installed automatically.

18th of October 2019: EmonTxV3CM installed as standard on EmonTx units shipped from our shop:
EmonTxV3 Continuous Monitoring Firmware (v1.0-beta) - #30 by TrystanLea

  • 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:
https://community.openenergymonitor.org/t/openenergymonitor-demand-side-response-development/9095

  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 emoncms.org server, as above.)

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

Integrations: nissan connect, open vehicles, tesla, renault

March 2019: DemandShaper module forum post update:
https://community.openenergymonitor.org/t/emoncms-demand-shaper-module/9097

14th of July 2019: DemandShaper module v1.1 release
https://community.openenergymonitor.org/t/emoncms-demand-shaper-module/9097/21

3rd September 2019: Support for all Octopus Agile regions
https://community.openenergymonitor.org/t/emoncms-demand-shaper-module/9097/22

STM32

STM32 Development thread: https://community.openenergymonitor.org/t/stm32-development/6815/242

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.

Steps:

  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: STM32/stm32notes.md at master · openenergymonitor/STM32 · GitHub
    29th Nov 2018: PCB Design sent for manufacture: STM32 Development - #260 by TrystanLea

  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:

6 Likes