Syndicate content
Open-source tools for energy monitoring and visualisation
Updated: 26 min 3 sec ago

3CH WiFi Relay Control Board

Sat, 22/08/2015 - 13:38

We have recently started stocking in the shop a Three Channel WiFi Relay / Thermostat Board designed by our friend Martin Harizanov.
The board has been well designed to physically separate high voltage AC mains from the low voltage logic. The board has an optional power supply to enable the board to be powered directly from 100-240V AC. A wall-mountable plastic enclosure is included. 
The board can be used to control a heating / AC / humidifier via local control loop from on-board sensor. The unit can be programmed with a schedule and or manually controlled via web UI via WIFI. Sensor data and relay status can be posted to Emoncms for logging and graphing. 
NOTE: The board connects to and controls high voltage, knowledge and attention is required when installing to prevent electrical shock.
The relay board is a open software/hardware multi-purpose relay board based on the ESP8266 WiFi SoC. It can control up to three AC or DC loads over the Internet using web UI or MQTT.
  • Powerd direct from 230V AC via isolated on-board PSU (optional extra) or 5V DC via micro USB
  • Built-in web server with mobile device friendly UI and HTTP API to control the relays
  • Thermostat function with weekly scheduling
  • Manual relay control via the UI
  • NTP for network time and scheduling functionality
  • Web server settings, including HTTP port and basic HTTP authentication setup
  • Broadcast relay/sensor data using HTTP GET to services like ThingSpeak or Emoncms
    • Integration with ThingSpeak for charting/analytics visualization
  • Temperature sensor support (one of them, not both at the same time) - (optional extra)
    • DS18B20 one-wire temperature: supports multiple sensors
    • DHT22 (AM2302) Humidity & Temperature
Shop:The relay board can now be purchased direct from our shop: & Set-up: Full technical details and set-up guide are available on Martin's Wiki:
Related Blog Posts:DIY Internet Connected Smart HumidifierWIFI Thermostat with weekly schedulerWiFi IoT 3 channel relay board with MQTT and HTTP API using ESP8266ESP8266 OTA Update 
Overview demo of the board in action by Paul Reed: 

Posting status & sensor readings to Emoncms

Categories: Blog

Understanding zero carbon energy systems: Energy storage (part 1)

Sun, 02/08/2015 - 09:37
The last zero carbon energy model example in the series investigating the matching between different energy demands and a variable renewable supply reached 89% supply/demand matching with a mixture of solar and wind supply, traditional electricity demand, space heating with heatpumps, electric vehicles with smart charging and two small stores one 7 kWh li-ion store and one 10 kWh heatstore.

Blog post: Open source hourly zero carbon energy model, combining traditional electric, heating and electric vehicle demand.

How do we achieve that final 10% of supply/demand matching? Is it possible to just scale up the li-ion storage or do we need something else? What is the nature of that final unmet demand and the final storage requirement?

One of the good things about having the model written as a program rather than spreadsheet is that its really easy to run the model iteratively for different input values, you can quickly go through hundreds of model runs. You don’t need to manually run the model for each value.

The following graph shows how the percentage of supply/demand matching increases as the storage size increases. The python source code for the model used to produce this can be found here:

In order to capture all of the storage requirement in this analysis the heatstore was removed from the last model and the EV charging was set to a constant charge profile rather than smart charging. This configuration achieves 78.3% supply/demand matching with no storage, an unmet electricity demand of 13,628 kWh over 10 years out of a total of 62,771 kWh.

% Supply/demand matching vs storage size in kWh:
We can see clearly that the degree of supply/demand matching increases very quickly as we add the first kWh's of storage but then the gains taper off quickly requiring orders of magnitude more storage to reach the final 5%.

The first 10% of supply/demand matching, bringing us up to 90% needs around 25 kWh of storage. The next 5% up to 95% requires an additional 120 kWh of storage. The final 5% requires 1536 kWh.

Note: see added section below for calculations of total storage capacity required if the oversupply is 20% or 30% instead of the 4% here.

The first 1.5% of the storage capacity provides 50% of the required supply/demand matching gain.

Its interesting to look at what the use of the 1680 kWh store looks like across the 10 year model period:
The store is used most over winter, where electricity demand is highest due to heatpump space heating. We can see that the winters of 2010 and 2011 where particularly cold and that the extent of the storage requirement in this model is largely driven by these successive harsh winters and a less strong summer. If the modelling had only considered 2002 to 2010 we might have under specified the storage amount needed by half which highlights the importance of modelling over as many years as possible.

Utilisation, cycling

We can see roughly that the full extent of the store is only used once in 10 years and is largely needed to cover just 3.5 months at the start of 2011. Even if the store was half its size it would only be used fully 3 times in 10 years. The extend to which the store is cycled is an important consideration in store choice, both from the perspective of wear and financial payback.

The following graph charts annual cycle requirements vs storage size, highlighting how most of the storage requirement is cycled very infrequently. A 25 kWh store delivers the equivalent charge/discharge energy of 30 full cycles a year, 100% depth of discharge (DOD). The next 120 kWh would only be cycled 7.3 times a year. A 625 kWh store would only be cycled twice in a year and the full 1680 kWh store only 0.8 times a year.

Cycles per year vs store size:
The above gives us an initial degree of insight into the nature of the storage requirements and how reaching the final 10% of supply/demand matching requires magnitude more storage than the first 10%.

Its important to note that the results above are for a model based on uk climate and weather, it would be worth repeating this kind of modelling for warmer countries where air conditioning that matched solar pv generation was a large component of demand rather than winter heating.

The next blog post will look at some of the different storage technologies available and how they are suitable for different segments of the overall storage requirement.

Reducing storage requirements by oversupply 
Following the conversation with Dominic Zapman here, I decided to re-run the model with a higher degree of oversupply - nearer the oversupply level used by ZeroCarbonBritain. The results above are for an oversupply of 4% with 65391 kWh supplied over 10 years for a demand of 62771 kWh. A 1680 kWh store is 27% of the annual demand.

If we re-run the model with an oversupply of 20%, 100% supply/demand matching is reached with a 676 kWh store, 11% of annual demand.

If the oversupply is 30%, the storage requirement is reduced to 484 kWh, 8% of annual demand.

The ZeroCarbonBritain model exports 165 TWh out of the 738 TWh generated which is an oversupply of 22%. A further 180 TWh is used to generate synthetic fuels including power to gas methane storage. A high percentage of this demand will also be oversupply. The long term power to gas storage capacity in ZCB is 60 TWh, delivering on average 14 TWh/year of backup supply covering about 402 TWh of final demand excluding exports. Delivered backup is 3.5% of final demand.

Categories: Blog

New MyElectric Emoncms app, realtime power graph and energy totals

Thu, 30/07/2015 - 16:26


The MyElectric app has long been needing some work so that it both provides more useful information and also reports the daily kwh data correctly for different timezones and when the app is used as an always on display and the day changes.

There is now a new version available that adds a real-time power graph as well as totals for the week, month, year and all time and the daily kwh bar graph as before.

To generate the kWh per day graph this version focuses on supporting feeds either created with the "power to kWh" processor or "Wh accumulator" processor rather than the "power to kWh/d" processor and average power feeds. Trying to support each one was leading to quite a lot of bugs in addition to more fundamental issues with time zones present with the power to Kwh/d daily feed approach.

The "power to kWh" and "Wh accumulator" processors are both fully supported on the emonPi and emonBase running the low-write image. There's more on how this accumulating watt hour or kWh approach works here: Development: Calculating Wh totals on the emontx

I now have the new MyElectric app running alongside the MySolarPV app in my home and I'm really quite pleased with the results. The totals at the bottom and average kWh per day for each period gives me most of what data to see at a glance how my electricity consumption is fairing and having this information available on a wall mounted tablet really makes all the difference compared with having to login to emoncms on my computer to see the data.

I would like to make it easier to switch in between the different apps, a side swipe would be really nice. I would also like to look into a way to make it possible to download apps from an app repository from within emoncms itself so that new apps could be added without them having to be in the app repository on github, there's quite a bit of work needed to get there thought.

Categories: Blog

Adding a RTC to the emonPi

Thu, 09/07/2015 - 15:05
The emonPi updates its internal linux time from NTP when connected to the internet. However if the emonPi is to be used on an offline network or for an application when accurate timestamp is essential then a hardware Real Time Clock (RTC) can easily be added to the Pi's GPIO. We have tested using a DS3231 based RTC module. This RTC module communicates with the emonPi via I2C, it can be easily connected as follows by soldering a four-pin header onto the emonPi aux GPIO pins:
emonPi with hardware RTC module added
DS3231 based RTC module

I2C bus scan showing LCD & RTC
Full install guide can be found on the wiki:
Categories: Blog