For those interested, here’s a summary of the meeting last Friday (9th March 2018).
Present were: @glyn.hudson @Robert.Wall @pb66 @Paul @TrystanLea
The meeting started with a bite of lunch and a chance for each of us to say ~5-10 mins about ourselves, our background, how we got involved in OpenEnergyMonitor, how we use the system ourselves/or business use and what has kept us involved in the project over time.
Glyn and I then gave a short presentation of where we see the core OpenEnergyMonitor system going. We see there being two key configurations that we would like to support:
- The local hub configuration
- Lightweight local & remote data logging
The local hub configuration
The local hub system comes into its own where a setup consisting of a number of different sensor nodes and potentially control nodes are required, e.g: EmonTH temperature and humidity nodes in each room, Household, solar, sub-circuit electricity monitoring (EmonTx WIFI or RFM, IotaWatt) heat pump or heating system heat monitoring.
@glyn.hudson has been working on integrating solar pv monitoring with the OpenEVSE electric vehicle charge controller using the mosquito MQTT broker on the EmonPi/EmonBase. I have been working on Sonoff S20 smart plug scheduling for the EnergyLocal project, local decision making and coordination provided by an in-home hub is needed to provide a resilient system for situations where the internet connection goes down.
Another key benefit of the in-home hub configuration is local data storage and visualisation (which may become a more important benefit as remote server costs are factored in, see emoncms.org billing and scale).
A local hub, such as the EmonBase/EmonPi, runs a full emoncms stack locally as well as tools such as OpenHAB and NodeRed, which can be used for control applications. A hub may integrate with a complete mixture of devices/equipment including smart meter interfaces, inverters, heat meters etc.
Lightweight local & remote data logging
A lightweight local system can be useful where a more limited system fits the application, such as: remote monitoring of heat pumps or solar installations by an installer or a university research project.
The up front hardware cost can be lower than a hub based system although longer term remote server costs can switch the balance over time.
A key benefit of lightweight local and remote data logging is easier remote access to data, an often simpler hardware setup procedure and no need to maintain local data storage, backups etc.
It’s worth noting that the IotaWatt does provide significantly more local capability than an EmonTx with an ESP8266 adapter, as it provides data storage on its SD card and data visualisation, so it does mix some of the benefits of both categories.
Options Explorer Tool
A couple of weeks ago, I put together a table to try and compare different system configurations and costs, which is available here This is a work in progress. Thanks to @Bramco and @pb66 for the comment, I need to update on that.
http://openenergymonitor.org/optionexplorer
Discussion
We then aimed to have a two part discussion with the following agenda:
Discussion part 1: Improving the existing hardware and software:
- understanding accuracy
- sensor and component tolerance
- calibration jig
- Robert Wall: EmonLib developments, CM, PLL, unitless & calibration
- single, three, split phase
- Paul & Trystan: Summary of EmonHub development
- Trystan: Summary of hardware related emoncms developments: device module, inputnames
Discussion part 2: Ideas for the future?
- Related to accuracy, calibration points above, what is the value of improving ADC resolution and sample rate?
- ESP, PiZero, A more powerful processor e.g: STM32, Dedicated IC e.g: ATM90E26.
- MBUS module for the EmonTx, discontinuation of heat pump monitor prototype in favour of EmonTx modular approach.
As you can imagine we only had a chance to briefly skim through the above points and we ran out of time to discuss EmonHub and emoncms developments, we ended up focusing more on accuracy, calibration and increasing processing capability.
While a quick comparison of cumulative kWh between a billing meter (class 1) and an uncalibrated EmonTx may indicate a difference of ~2% (recent testing examples ranged from 1.2% to 2.4%), there is no guarantee that this will always be the case. The following page in Learn: Sources of error in the emonTx voltage and current inputs Learn | OpenEnergyMonitor written by Robert Wall documents how the maximum error due to sensor and component tolerance can be as high as 11.25% - this error does not take into account ADC resolution, or sampling rate.
In practice sensor and component values are unlikely to be all in maximum positive or negative error but that’s not to discount the possibility. Robert Wall recently carried out a rough Monte Carlo analysis with a ‘flat’ spread of tolerances using LTSpice, suggesting that:
45% of emonTx V3.4.4 production would be inside ½ %
82% of emonTx V3.4.4 production would be inside 1 %
“but this is no guarantee. Real components might not obey that rule.”
One batch of CT’s may be in error by +2% and the next -1%, we don’t know what the spread of tolerances are.
A monte carlo analysis and further work on understanding the accuracy implications of the ADC resolution and sampling rate is something we would like to expand further upon.
@pb66 raised a concern about rounding errors due to integer timestamps in emoncms which is also something that needs further investigation.
One way for us to improve accuracy would be to pre-calibrate sensors before we send them out. This was another suggestion by @pb66. A calibration jig could scan through a voltage range for the ACAC adapters and spit out a calibration value that could be printed on a label.
Accuracy is also affected by whether continuous or discrete sampling is used. The standard EmonPI and EmonTx currently use discrete sampling, where each CT channel is sampled sequentially, taking 200ms (10 50Hz wavelengths) per CT. This means that in a 10s reading period, the power value for each CT is only based on 2% of the time. This gives good results where loads don’t have fast changing current profiles but does not work so well where loads switch on and off multiple times within the reading window. E.g an induction cooker or triac based pv diverter.
Robert Wall has been working on continuous sampling firmware for the emontx which addresses this (currently in testing) however one of his concerns is that continuous sampling pushes the atmega328 to the limits of its processing capability especially as you add in other features such as reading from DS18B20 temperature sensors (a point echoed by Paul Burnell and Paul Reed).
Related to the above points is the question of what the value is of improving ADC resolution and sample rate, given that there are a number of other potential sources of error. Should we focus on improving calibration and firmware before improving the ADC and processing capability of the EmonTx and EmonPi, or is there value in doing both?
We discussed briefly the potential of the STM32 platform as a solution to the issue of running out of processor capability. A dedicated STM32 could perform the energy monitoring task and then communicate via serial or I2C with an esp8266, Pi Zero, RFMPi transceiver or directly with Pi3. Although an STM32 based monitor would not address the complete accuracy question by itself, it would make things easier by ensuring that there is enough processing to do full continuous monitoring as well as providing a sampling rate and resolution boost. We would, alongside this, still need to address calibration and/or provide or reference to ACAC voltage sensors and CT’s with lower tolerances.
All of the topics above really need expanding in more detail, hopefully this can provide a reference for more detailed discussion.
We finished the meeting with a brief discussion of forum moderation and categorisation. As well debating an idea of a ‘developers corner’.
All in all, it was a productive meeting and we covered a lot of ground although not in much detail given the time we had, and it was good to meet up after so many years of forum discussion. We agreed, that a similar in person meeting would be productive to organise in the future.