emonGLCD Solar PV PWM LED Proportional Indication

The tri-colour LED's on the emonGLCD V1.3 are connected the the hardware digital PWM lines on the Atmega328. This allows the brightness to be smoothly controlled in 0-255 steps.

Up-until now we have not made use of this feature.

The video below shows a demo of Solar PV generation and power consumption ramping up and down. The tri-colour LEDs smoothly increase in intensity green or red depending on the amount of power being imported or exported.

This should serve as a nice at-a-glance visual indicator to how much power is being imported or exported at any given time. At the moment the example has been configured so that the LED's are at their brightest when 4kW's are being exported or imported. In the future it would be great if the display learnt what size PV system (kWp) is installed.

It would be possible to implement a similar feature on the Home Energy Monitor display to indicate the level of power being consumed, but this will have to be done carefully not to annoy the user! The problem with this is what constitutes a high level of consumption? To be useful the display needs to 'learn' what's high and what normal level of consumption.

Thanks to Rob Walker and the discussion on this thread for help in implementing this. Rob has also implemented proportional control of the white LED backlight level based on the light level in the room measured by the on-board light sensor (LDR)..nice!

All these changes and some other minor improvements have been committed to the emonGLCD github repository: Please test and report feedback on the forums.

Update: The single CT Home Energy Monitor emonGLCD example sketch has been updated to also include proportional red LED PWM brightness control corresponding to the amount of energy being consumed.

Embodied Energy of Electronic Enclosure Materials

For us the underlying aim of energy monitoring is energy reduction. It's therefore important that over its useful life an energy monitoring system contributes to the saving of more energy than it involved in the embodied energy of it's production.

Recently we have been having the discussion as to which material is environmentally better to use for electronic enclosures.

So I did some research:

Caution: The figures below were obtained from reputable sources but should not be taken on face value.
  •  Extruded Aluminium takes approximately 40-80% more energy (KWh/Kg) to produce than ABS plastic [1][2] *
  • Aluminium is widely and easily recycled (even if its been anodised [2]) and the recycled product is of just as high a quality as the original. ABS plastic can be recycled in some locations but the recycled product is of much lower quality than the original, 'downcycling' would be a better term! 
  • Recycled aluminium takes about 30% less energy (KWh/Kg)  to produce than ABS plastic [3].
  • Plastic is made from oil which is a non-renewable fossil fuel.
  • Aluminium is the most abundant metal in the Earth's crust, extracting it requires lots of electricity which could be generated from renewable sources. 
With current processing and recycling methods we think aluminium could be the best material to use, it does take more energy to produce in the first place but once produced it can be recycled again and again to make new things with little extra energy.

What do you think?


*Aluminium is about 2.6 times denser than plastic therefore a similar case made from plastic could be lighter. Further research is required before drawing a conclusion. 

Engineers thermometer

I have just configured an emonGLCD and a battery-powered emonTx unit with 3 temperature sensors. This would make a useful heat-pump engineers tool, and probably has many other uses.

The emonTx has 2 probes (DS18B20's) on 2m cables, and one on-board the PCB. It's battery powered so can be put anywhere in range. The emonGLCD display shows the 3 emonTx temperatures and also a local temperature.  Temperatures are transmitted via wireless from the emonTx to the emonGLCD every 2 seconds.

Typical uses would be for balancing radiators. i.e T1 on the flow, T2 on the return. I have added T1 - T2 (delta T) because that is what you are often looking for.   It could also be used for air-in, air-off off an air source heat pump, or and flow/return situation.   It would make a good tell-tale device. i.e. to alert if any system goes out of its best operating ranges.

I also have the temperatures data going to a Nanode emonBase to be logged to emoncms so that graphs can display temperatures over time. You really need this to balance up central heating radiators. i.e. fix it to a different radiator every day and compare results. The flows can be balanced accordingly.

The DS18B20's are not ideal because they are a bit chunky (as opposed to thermocouples). On the other hand, the accuracy is excellent and it seems that the values can be relied upon. I have chosen to pot-up the probes myself.

They are fragile, and the ready-made sensors from the OpenEnergyMonitor shop are much more rugged and can easily be tie-wrapped to a copper pipe and insulated etc.

Next thing is to battery-power the emonGLCD so it becomes a portable tool.  

Another addition would be a LCD pulse input. This would give me a reading of kWh, and would save me using a stop-watch, as I have many over the years.

Adapting these devices could get addictive!!

By John Cantor

A short video of OpenEnergyMonitor Labs

Timelapse footage from inside and outside OpenEnergyMonitor Labs here in the mountains of Snowdonia, North Wales, UK.

We had lots of fun making this. If only each day was longer!

Faulty Batch of MCP1702 Voltage Regulators

We have noticed recently that a number of people have been having problems with the Nanode RF. The problems were brought to our attention through this thread on the forums.

Many people were getting the message "Failed to access Ethernet controller" when running an EtherCard example.

After much testing we have identified the problem. It turns out that the MCP1702 3.3V voltage regulator which supplies 3.3V to the Ethernet Chip (ENC28J60) was not supplying enough current to power the chip. The voltage was dropping down to 2.6V under load.

Swapping the voltage regulator for one from a different batch solved the problem. it looks like we have been sent a faulty batch of voltage regulators, our apologies for not spotting this sooner.

Note: this problem only applies to the MCP1702 voltage regulators in the latest batch of Nanode RF kits. All emonTx and emonGLCD kits are un-effected, they have always used regulators from another source.

If you have this problem we will send out two replacement regulators free of charge, one for the Ethernet chip and the other for powering the Atmega 328, it may be ok to leave the Atmega328 voltage regulator in place as the current requirements are not as high and it seems to work fine here without swapping it out, but we will send two out so that you can swap out as you prefer.

We have created a free voltage regulator entry in the online shop, just quote your previous OpenEnergyMonitor order ID when ordering and we will send them out:

All the Nanode RF's kits sold through the shop from today onwards will contain the non-faulty voltage regulators.

De-soldering tips
The easiest way to de-solder the regulator is to if possible cut two of the regulator legs, you can then pull out the third by pulling on the regulator body itself while holding the soldering iron tip on the solder surrounding the leg. Then use pliers to pull out the other legs one by one. It is usually easier to pull the legs out if there is actually plenty of (molten) solder around the leg. To clear the holes of solder with a solder sucker again make sure there is plenty of solder in the holes to start with, this usually leaves the cleanest result in our experience. An extra pair of hands can help make the whole job easier. 

elektro:camp(«2012.05») Workshop | Offenburg-Germany

Hackathons are great! The next one I am attending will be the electro:camp in Offenburg, in Germany, close to the french border. I think Trystan and Glyn will also be there as well as a number of cool hackers and makers, all interested in energy and automation.

Many great developments will result from this event and hope to see some of you there as well.

Here is the official website:

Speeding up emoncms feed data requests

If you log 5 second data you quickly amass a huge number of datapoints (about 6 million a year). If you then tried to visualise a years data by loading all 6 million datapoints you would be waiting a long time. The most we would want to load is the same number of datapoints as the pixel width of the visualisation, lets say around 1000 datapoints. So we need some way of picking out of our 6 million datapoints 1000 datapoints at equal interval.

When I first wrote emoncms I searched for mysql queries that could pick out table rows at given intervals and came across the following query that does this:

SELECT * FROM (SELECT @row := @row +1 AS rownum, time,data FROM ( SELECT @row :=0) r, $feedname) ranked WHERE (rownum % $resolution = 1) AND (time>'$start' AND time<'$end') order by time Desc

It seem to work really well. Fast forward 5 months my feed tables are approaching 2.5 million rows  and I'm starting to notice query times getting really quite long. After a bit of searching again, I came across a suggestion to a similar problem suggesting the use of an index. So I tried adding an index and creating a php for-loop to request a single row at given intervals:

$range = $end - $start;
$interval = $range / 1000;

for ($i=0; $i<1000; $i++)
  $qtime = $start + $i * $interval;
  $result = db_query("SELECT * FROM $feedname WHERE `time` >$qtime LIMIT 1");
    $row = db_fetch_array($result);
    $data[] = array($row['time'] * 1000, $row['data']);    

The following table shows the typical times for requesting data from both the indexed and non indexed tables and the different methods. At the same time I also tested whether request times where affected by the data type that time is stored as: mysql datetime or a unix timestamp stored as an unsigned int.

So it looks like the optimum configuration is primarily the addition of an index and use of the php data request method and then to reduce disk space use, switching to unix timestamp. The next step is to create a script to automate table conversion from datetime unindexed to timestamp indexed.

emonGLCD V1.3 Switches - fix!

It was mentioned in this blog post regarding the current version of the emonGLCD (V1.3) that a hardware error rendered the push switches un-usable. This is not the case any more!

It turns out that this error can be fixed in software. The switches can be made to work with no hardware modifications. The emonGLCD tester sketch has been updated with the required fix.

Here are the details:

The push switches are connected ADC 1,2 and 5 (digital 15,16 and 19). When pressed they are pulled low through resistor R5.
The Atmega328 has internal pull-up resistors (20K) which can be enabled by setting the port as output and doing a high digital write:

pinMode(switchpin, INPUT);

digitalWrite(switchpin, HIGH);

The switches are active low, meaning a logic 0 will be read on digital 15,16 and 19 when the relevant switch is pressed. 

Thanks to forum member Drsdre for bringing this elegant fix to our attention. This is a real open-hardware success story! If you've bought an emonGLCD from us we will send out on request the three switches to be added free of charge.

We have created an item for the extra switches in the shop, just click buy (it's free) and quote your original order number:

All emonGLCD kits bought from the shop from now on will include the switches.

Happy days.

Open source hardware and the free rider dilemna

I wrote a post on my personal blog about using content from open source projects in general and the Open Energy monitor in particular. Here is an extract of it:

There are now more than 960 registered members in the community, not all of them are active and quite a few contribute actively to the development of the project. But does that mean that the others are just passive members? free riders? is that fair?
I started toying with the idea of using an arduino to monitor electricity consumption about two years ago, and I found out that someone else (Trystan and Glyn and quite a few others) already started developing that idea and sharing their work and findings online. Sharing their work and code online does not only save other people (actually humanity in general) a lot of time and effort, but it also allows for a much wider scope of fellow tinkerers to review and improve that work.
You can read the post on my blog.

Heat Pump Monitoring

Over the past few months we have been working with John Cantor to develop, build and test the potential of a heat pump monitoring system. John has a lifetimes experience of installing, optimising and troubleshooting all types of heat pumps. John runs and has recently written a very informative book Heat Pumps for the Home

The rest of this post will be a guest post by John, over to you:

A heat pump works by transferring heat form one place to another. The electrical input power should be only a fraction (maybe 1/3rd or 1/4) of the available heat delivered. However, the energy efficiency can vary dramatically.  One of the biggest factors that affect this is the working temperatures on the cold (source) and the hot (sink) sides of the system.  This is mainly dictated of system design (radiators/underfloor-heating details etc), but it is also dependent on the way that the system is operated, see

It has become evident that a significant number of the UK’s heat pumps are not reaching their energy-efficiency potential.  In ordered for us to learn how best to install, set-up and operate heat pump systems, some form of real-time monitoring is vital.

We have developed a heatpump-specific variant of the OpenEnegyMonitor wireless web-connected emonBase and emonTx system. Emoncms was used as the web logging and graphing application.

This tool is as valuable as the stethoscope and X ray is to a doctor.  It allows a heating system to be analysed in detail and observed over time so that settings can be modified, use-patterns changed, and system modifications be made.

Our first test was on a heat pump in Scotland.  The owner initially had some very high electricity bills. After a brief spell of monitoring, we were able to pinpoint a few issues.
These related to the electric boost heater coming on unnecessarily and the under-floor heating poorly balanced causing frequent compressor ‘cycling’ (stop/start).  However, this installation was generally a good example. The data can be seen here:

Our second test was on a suspect system in Wales. This showed up some alarming temperatures on the source, and it is apparent that the refrigeration circuit is in poor health.  We plan to repair the system, then compare the graphs before and after.

The graphs below show just one aspect of the analysis.

There are many things that can be viewed using the web-dashboard. This includes the refrigeration circuit, the source, the underfloor heating and the compressor power-factor.  

It seems likely that there would be 2 main uses for this monitoring.
1)      For the installer or technically-minded owner to learn how best to operate their system, or to pinpoint any areas for attention and possible modification.
2)      For the owner to see some basic data relating to running cost etc. It would also be used as a remote monitor for holiday accommodation.

The diagram at the top shows the full version, but we are working on a simpler version that focuses on the user-control aspect of a system.