Optical pulse counting with the EmonTH

In addition to temperature and humidity sensing the EmonTH has a digital input (with interrupt) that can be used for pulse counting.

This can be used for wired pulse counting or with the Optical LED pulse sensor.

To use the Optical LED Pulse sensor the easiest way is to remove the RJ45 connector and then strip back the black sheathing to reveal the red (3.3V power), black (GND) and blue (pulse) wires.

Connect the red wire to the 3.3V terminal, the black wire to the GND terminal and the blue wire to the terminal labelled D3 (top) or IRQ1/D3 Pulse Counting (bottom of the board).

There are two firmware examples available for the EmonTH for pulse counting, the first is for Pulse counting in addition to DHT22 Temperature + Humidity sensing or DS18B20 temperature sensing:

The second is for pulse counting only if the temperature and humidity sensing is not needed:

To upload these firmware examples you will need the Arduino IDE and libraries installed and a USB to serial programmer to upload the firmware to the EmonTH.

The pulse count is accumulated on the EmonTH until the EmonTH is reset either by an outage or by turning off and on the power.

To record the total accumulated pulse count in emoncms use the wh_accumulator input process which detects resets continuing the total pulse count accumulation from the last value before the reset.

3CH WiFi Relay Control Board

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


The relay board can now be purchased direct from our shop: http://shop.openenergymonitor.com/three-channel-wifi-relay-thermostat/

Documentation & Set-up: 

Full technical details and set-up guide are available on Martin's Wiki: https://harizanov.com/wiki/wiki-home/three-channel-wifi-relaythermostat-board/

Overview demo of the board in action by Paul Reed: 

Posting status & sensor readings to Emoncms

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

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: https://github.com/TrystanLea/zcem/blob/master/python/storagerequirements.py

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 https://twitter.com/Zapaman/status/627806828865409024, 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.

New MyElectric Emoncms app, realtime power graph and energy totals


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.

Adding a RTC to the emonPi

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:

What is the embodied energy of a microcontroller?

Continuing with the investigation into the embodied energy that it takes to make an energy monitor, I thought I would explore in a little more detail the embodied energy of the microcontroller which is often associated with the most energy intensive aspect of electronics manufacture.

As I mentioned before I wouldn’t put a large amount of confidence in the accuracy of the figures below, computer chips are incredibly complex things that take a large number of manufacturing processes to make and I have found it hard to find open detailed information on energy requirements of these. The calculations below are based on the datasets that I could find including the EU ecodesign dataset which I'm told is one of the higher quality freely available sources. But I could not find much detail on how the figures where derived to know what it does and does not include and the breakdown of energy use in its manufacture.

The idea here is more to get an initial set of numbers that could be improved upon in the future. My motivation for looking into this started by being inspired by howies and patagonia's efforts on footprint and supply chain analysis, partly by reading sustainable energy without the hot air that identifies industry as being a significant part of overall energy use and also after reading the article here about 'the monster footprint of digital technology'.

The following starts by looking at the available datasets and then investigates deriving figures for the embodied energy of a chip by calculation of the actual semiconductor volume contained which compares well for the small IC embodied energy value.

1) Datasets

EU Ecodesign methodology
The EU ecodesign methodology downloadable here http://ec.europa.eu/DocsRoom/documents/5308/attachments/1/translations/en/renditions/native provides embodied energy values for a variety of electronic component categories, it provides two embodied energy values for IC's (integrated circuits) these are:

Large IC                        8021.88 MJ/kg
Small IC                        1786.73 MJ/kg

MJ/kg: 1,000,000 Joules per kg

The question is what constitutes a small or large IC? Dimensions? processing power? and there is a large difference between both of these values!

Another paper that lists sources for embodied energy values including the EU ecodesign dataset is this paper on the embodied energy of an offgrid light: http://users.humboldt.edu/arne/Alstone_etal_Lumina-TR9-Embodied-Energy_Jan11.pdf. It lists two other useful values:

Semiconductor Grade Si             35000 MJ/kg, Taiariol et al. 2001
EPROM Chip (M27C1001, 0.36 W IC)   12.5 MJ/chip,  Taiariol et al. 2001

Jean Claude Wippler of JeeLabs did an interesting post a couple of years ago on what is inside an ATmega8 chip. The Silicon part was extracted by dissolving the outer casing with sulphuric and nitric acid. http://jeelabs.org/2013/06/09/whats-inside-that-chip

The size of the semiconductor part inside the ATmega8 is 2855 x 2795 um, less than 3x3mm:

Is it possible to estimate the embodied energy of a microcontroller by working out the embodied energy of the silicon part and the casing part separately? and how would the figure compare with the embodied energy values given for a small and large IC in the EU ecodesign dataset?

To find the embodied energy of the silicon part we need to first work out the weight of that part. To do this we will need the density and thickness of the silicon wafer. The thickness of a silicon wafer can be anywhere between 275um and 926um.

Density of silicon: 2.3290 g.cm3 https://en.wikipedia.org/?title=Silicon

2855 x 2795 um x 275 um = 0.00219 cm3 x 2.329 g.m3 = 0.0051 g
2855 x 2795 um x 625 um = 0.00499 cm3 x 2.329 g.m3 = 0.0116 g
2855 x 2795 um x 926 um = 0.00739 cm3 x 2.329 g.m3 = 0.0172 g

The embodied energy of silicon grade Si is around 35000 MJ/kg, 35 MJ/g

0.0051 g x 35MJ/g = 0.178 MJ = 0.049 kWh
0.0116 g x 35 MJ/g = 0.406 MJ = 0.113 kWh
0.0172 g x 35 MJ/g = 0.602 MJ = 0.167 kWh

The weight of a SMT Atmega 328 is 0.14375g:

Large IC: 8021.88 MJ/kg = 1.153 MJ = 0.320 kWh
Small IC: 1786.73 MJ/kg = 0.257 MJ = 0.071 kWh

The EPROM Chip (M27C1001, 0.36 W IC) example is 12.5 MJ/chip = 3.47 kWh
Which is between 10 and 50x the large/small IC estimates and 20 to 70x the wafer only estimates.

The large IC is between 2x and 6x the wafer only and small IC is between 0.5x to 1.5x the wafer only estimate.

The weight of the silicon part of the chip for the ATmega8 should be between 3.5% to 12% of the total chip weight.

The rest of the weight is metal and plastic. Copper has an embodied energy of between 38MJ/kg and 142MJ/kg depending on manufacturing process and plastic is anywhere between 80-120MJ/kg. If we assume a copper/plastic mix of around 100MJ/kg as a rough estimate.

This would then contribute an additional 0.0132 MJ = 0.0037 kWh which would only increase the embodied energy of the chip by around 2-7%.

Our estimate therefore for the embodied energy of the small microcontroller is between 0.053 kWh and 0.171 kWh, mid range of 0.117 kWh for 625um wafer which compares well with the small IC estimate of 0.071 kWh (it is of the right magnitude). We would expect a certain amount of assembly energy for combining the plastic, copper and semiconductor parts which is not included when taking a constituent parts approach which will likely add a little more to the total.

Package type?

Calculating the embodied energy this way brings up an important question about the package type of the IC, I.e how much plastic and connector metal surrounds the semiconductor core. If the size of the semiconductor inside a through-hole and SMT version of a ATmega328 is the same then surely a total weight based measure is not a good guide for the embodied energy. Given that over 90% the embodied energy is associated with 3.5 - 12% of the weight.

RaspberryPi chips
The ATmega8 or ATmega328 is not a particularly powerful chip, the emonpi also uses a RaspberryPi which has three chips on board.

Its not clear what the volumes of the semiconductors inside these chips are. But given their small size and relatively large processing power lets assume for an initial calculation that the size of the package is very close to the size of the semiconductor. If the wafer thickness is 625um then the embodied energy of the chips can be estimated as:

Broadcom        14 x 14 mm x 625um = ~2.8 kWh
Elpida          12 x 12 mm x 625um = ~2.0 kWh
Smst            8.7 x 8.7 mm x 625um = ~1.1 kWh

These estimates which cover a quad core 900Mhz + 1GB ram computer are much larger than the ATmega8 estimate as we would expect but are still significantly lower than the embodied energy figure given for the 32MB 2g memory chip referenced in the article on the the monster footprint of digital technology of 20 kWh - while delivering much more functionality, almost a full computer!

Are these figures accurate? are the underlying datasets accurate for modern processors? Does it mean that newer miniaturised technology with the ability to pack much more computing power inside the same volume of semiconductor has resulted in a significant reduction in the embodied energy for equivalent amounts of computing digital technology functionality? These are all significant guesses at the moment and it would be really interesting and useful to see more open data available on the embodied energy of newer technology. It would be good to see greater interest from the manufacturers of these chips in calculating and giving information on the embodied energy of their products, making data available on this would really help with understanding this question about the impact of technology.

Open Source Circular Economy OSCEdays - emonPi Embodied Energy

Three weeks ago, time runs fast! I attended the open source circular economy event OSCEdays in London. It was a fantastic event with a lot of energy and ideas exploring how the circular economy could benefit from an open source approach.

OSCEdays at FabLab London

Initial draft embodied energy analysis of the emonpi
There was a wide range of challenges and projects there including: circular makerspaces submitted by the great recovery looking at how fablab's and makerspaces could encourage circular thinking, an initiative developing re-usable containers for cosmetics, a challenge looking at the implications of the circular economy for wearable technologies, 'trust is not waste' by the rubbish diet project and ours looking at the embodied energy and lifecycle analysis of the OpenEnergyMonitor EmonPi.

Id like to thank Rachel Stanley, David Green, WoonTan and Paidi Creed for all their help and input and for Erica Purvis and Sharon Prendeville for organising the event and the wider team that where involved in running the event in many other cities around the world.

Our discussions and findings are partly documented here, there's also a bit more that needs writing up which will be online soon: http://community.oscedays.org/t/headline-challenge-open-energy-life-cycles/662/2.

The research that I did on the embodied energy of the emonpi in the lead up to the event can be found here: http://openenergymonitor.blogspot.co.uk/2015/06/investigating-embodied-energy-of-emonpi.html

We are really interested in the lifecycle impacts and embodied energy side of OpenEnergyMonitor and so were going to keep building on this. I've almost finished a post that looks at the embodied energy calculation for the emonpi microcontroller and raspberrypi chips in more detail which will be up soon.

If your interested in embodied energy, lifecycle impacts, the circular economy and how open source could play a part do check out OSCEdays https://oscedays.org

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

The last 6 zero carbon energy model examples (linked below) have explored the core parts of a household energy model looking at supply and demand including the electrification of space heating demand and transport demand so that it can be provided for with renewable electricity.

This final model in this series brings all these components together to see how the combination of demands interact and how they affect the supply and demand matching.

It also explores the contribution of two small scale stores a 7kWh electrical store (such as a Tesla power wall) and a 10kWh heatstore.

The interactive modelling tool can be opened here:
Online tool: http://openenergymonitor.org/energymodel > navigate to 7. All

The following table show the results in terms of percentage of demand supplied directly of running the model with different electric vehicle charging profiles, and storage options. There is a small 4% oversupply.

No stores
4% OS + night charging62.3%
4% OS + 1/2day 1night charging76.2%
4% OS + flat charging78.3%
4% OS + smartcharging86.3%
Liion store
4% OS + night charging + 7 kWh li-ion store84.4%
4% OS + 1/2day 1night charging + 7 kWh li-ion store86.0%
4% OS + flat charging + 7 kWh li-ion store86.2%
4% OS + smart charging + 7 kWh li-ion store88.6%
4% OS + night charging + 10 kWh heatstore70.2%
4% OS + 1/2day 1night charging + 10 kWh heatstore81.0%
4% OS + flat charging + 10 kWh heatstore82.4%
4% OS + smartcharging + 10 kWh heatstore87.5%
Liion + heatstore
4% OS + 7 kWh li-ion store + 10 kWh heatstore + nightcharging85.5%
4% OS + 7 kWh li-ion store + 10 kWh heatstore + 1/2d 1n86.9%
4% OS + 7 kWh li-ion store + 10 kWh heatstore + flatcharging87.1%
4% OS + 7 kWh li-ion store + 10 kWh heatstore + smartcharging89.3%

Its interesting that a matching of 89.3% can be achieved with 7 kWh li-ion store, 10 kWh heatstore and electric car smartcharging up from a minimum of 62.3% with no stores and night time charging only. I think its quite impressive and encouraging that this high a level of matching can be achieved from a relatively small amount of storage and that 86% can be achieved with the smartcharging option only.

There are clearly different routes possible to achieve higher degree's of matching. If smart charging is technically possible with the flexibility used within the model and that it doesn’t provide too much of a burden on the user and only requires potentially a relatively small amount of electronics, embodied energy and cost compared to the li-ion store and heatstore then smart charging may be a more effective option.

A li-ion store and flat rate charging provides about the same benefit as smart charging and so if smart charging does not pan out to be practical then there may be an option to make up for it with a li-ion store, especially if the embodied energy and cost of storage reduces significantly.

The combination of measures provide smaller gains (if you apply smart charging first then the li-ion store only provides ~3% additional gains, however if you apply the li-ion first it looks like its the smart charging that only provides the small gain). Perhaps an important aspect is that a combination could provide important redundancy. It looks worthwhile to explore and develop each of the above solutions with a focus on how they integrate, the flexibility at which they can match supply, their costs and embodied energy.

The other blog posts in this series are linked below and the next model will explore the use of large capacity energy stores such as power to gas to reach 100% supply/demand matching. All the modelling behind this work is open source and available on github here: https://github.com/TrystanLea/zcem 

Hourly energy model example 6: Electric vehicles and a renewable energy supply

Continuing the blog series on building a hourly zero carbon energy model based on the ZeroCarbonBritain dataset the 6th example model explores another another key solution used in the ZeroCarbonBritain report and in David MacKay's book Sustainable energy without the hot air: the electrification of transport.

The intention here is to explore what level of supply/demand matching between a renewable energy supply and electric vehicle charging could be achievable with different electric vehicle charging profiles. A higher level of supply/demand matching reduces the amount of backup or energy storage required to meet demand.

The first example starts by integrating electric vehicles with a simple night time charge profile. The second example then explores more constant charge profile throughout the day – this constant charge profile could be the result of a large number of electric cars all charging at different times, some at work, others at home over night. The third example explores a basic smart charging approach where the charge rate can aligned with the availability of renewable energy. There are many people who are already choosing their charge times to align with domestic solar pv output and there is much discussion about the opportunity that this may provide for matching supply and demand.

To open the examples, launch the online tool:

Online tool: http://openenergymonitor.org/energymodel > navigate to 6. electric vehicles

Night time charging

The first model investigates night time charging between 1am and 8am (7 hours). The charge profile of an aggregation of electric vehicles is much more likely to be smoother than this with a distribution over the day especially as the number of work based charging facilities and rapid chargers increase but for interest we will consider this case.
Onshore wind Offshore wind Wave Tidal Solar
Installed capacity 0.86990.58640.99311.17832.9825
Percentage of demand
supplied directly

Flat charging profile

The results of running the model for a flat demand profile is the same as the earlier example where we considered the degree of matching between supply and a flat demand. Substantial improvements in matching compared to the night time charging profile is gained by just managing to distribute the charging requirements evenly across a day. This is unlikely to be possible on a single household basis but perhaps possible when the aggregate demand of many hundred cars are taken into account with day time charging at work encouraged.
Onshore wind Offshore wind Wave Tidal Solar
Installed capacity 0.86990.58640.99311.17832.9825
Percentage of demand
supplied directly
Percentage of time demand is
more or the same as the supply

Smart charging (variable rate charger that matches available supply)

Smart charging could allow electric vehicles that are left connected to the grid to charge when renewable electricity is available. The simple smart charging algorithm in this example starts by using available supply to charge the car's battery directly. A minimum SOC level required to cover the days journeys is maintained with a top-up charge if needed. The battery SOC is kept between 10% and 80% to help ensure long life is maintained.

The charge rate is based on a forecast of available supply over the next 24 hours, if the available supply is more than the forecast demand then the charge rate can be reduced. If there is twice as much supply forecast than demand then the rate of charge could by dropped to half the available supply in order to distribute the charge better across the 24h.
Onshore wind Offshore wind Wave Tidal Solar
Installed capacity 0.86990.58640.99311.17832.9825
Percentage of demand
supplied directly
Percentage of time demand is
more or the same as the supply

The results show substantial improvements again for the addition of smart charging, with smart charging + solar showing the largest gain. It is notable that the model suggests that a 2.98 kW solar PV array (a fairly typical amount for a home solar install) could provide 72.2% of almost 10000 miles a year of driving directly.

The feasibility of implementing this kind of variable rate smart charging on a household level with onsite solar pv needs a bit more investigation. The domestic charger on the nissan leaf can vary its charge rate in between 7A and 32A for the 6kW model or 7A and 13A for the 3kW model. Several people have already build open hardware variable rate electric car chargers making use of the fact that its possible to send a low voltage signal to an electric car to request a charge rate. Here are a couple of links to electric car charging related discussions and resources:

Dod Davies solar charge controller

OPenEnergyMonitor based electric vehicle charging

Smart Charging a EVSE with OpenEnergyMonitor RF data, Working! http://openenergymonitor.org/emon/node/4930

Open EVSE:

From: https://twitter.com/dodavies/status/541349518693117953

There are many aspects to consider and understand better when building a smart charger for electric vehicles for example it is suggested that to prolong the health of the battery its better to charge at a higher rate and up to the moment of starting your journey (rather than charge and let the battery sit at a high SOC). A more in depth understanding of the consequences of implementing this kind of charging and the balance point between battery life impacts and improved grid stability benefits or improved household economics would need to be understood.

Another possibility is that an aggregate demand profile for charging hundreds of electric cars could generally fit a renewable energy availability profile through a mixture of a larger portion of fixed rate charging cars charging at times of high availability than at other times.

In the next and final example in this zero carbon energy modelling series, we will combine the demand models for traditional electricity demand, electric heating and electric vehicles into one model and explore the implication of different electric vehicle demand profiles when interacting with multiple generation sources and multiple demand types.

Improved my solar application specific dashboard for tablet energy display's

With my Refurbished Samsung Galexy Tab 3 energy display up and running I've made a few changes to the solarPV application specific dashboard to make it work better. Thanks to Steve for many of the suggestions, see forum post.
  • The view now automatically updates as a rolling window, in any of the modes, 3 hour, 6 hour, day etc 
  • The balance Import/Export is now the same size as the solar & house consumption. 
  • Night time noise on the solar pv channel less than 10W is zeroed. 
  • The in-window stats are now easier to see at a distance with larger font.
  • The view buttons are easier to click on a touch screen.
  • Its possible to make up the consumption or solar generation feed from multiple feeds on the fly by entering comma separated feed id's in the configuration interface.
Here's the result:

To upgrade on the emonPi or latest emonbase image navigate to the admin tab in emoncms and then click the update button. Otherwise the app's module can be downloaded and updated using git: http://github.com/emoncms/app