EmonGLCD Template based display's

I have been thinking about how it could be possible to program an EmonGLCD display remotely or at least specify which displays are shown i.e if you could construct a command to tell the display to:

display solar pv page as page 1, use the solar power value from node 10. 

Skipping for now the how the commands are sent and interpreted, I think the first part of creating these specifiable displays is to convert the current display code into template functions which should be of benefit whether the displays are remotely programmed or not.

Here's my first attempt at this:

draw_power_page( "POWER" ,use, "USE", usekwh);
draw_temperature_time_footer(temp, mintemp, maxtemp, hour,minute);
draws the following page:

draw_solar_page(use, usekwh, gen, 2050, genkwh, temp, mintemp, maxtemp, hour,minute);

(thanks to drsdre for the icons!)

This is what the full code looks like:

#include <JeeLib.h>
#include <GLCD_ST7565.h>
#include <avr/pgmspace.h>
GLCD_ST7565 glcd;

unsigned long fast_update;

// Fixed values for this example
double temp = 17.4 ,maxtemp = 19 ,mintemp = 16;
int hour = 23, minute = 43;
double use = 252, usekwh = 2.5;
double gen = 1760, genkwh = 4.8;

void setup()

void loop()
  // Display update every 200ms
  if ((millis()-fast_update)>200)
    fast_update = millis();
    int S1 = digitalRead(15);
    int S2 = digitalRead(16);
    int S3 = digitalRead(19);

    if (S1==1)
      // powerstr, power, energystr, kwh
      draw_power_page( "POWER" ,use, "USE", usekwh);

      // temp, mintemp, maxtemp, hour, minute
      draw_temperature_time_footer(temp, mintemp, maxtemp, hour,minute);
    else if (S2==1)
      // powerstr, power, energystr, kwh
      draw_power_page( "SOLAR" ,gen, "GEN", genkwh);

      // temp, mintemp, maxtemp, hour, minute
      draw_temperature_time_footer(temp, mintemp, maxtemp, hour,minute);
      // use, usekwh, gen, maxgen, genkwh, temp, mintemp, maxtemp, hour, minute
      draw_solar_page(use, usekwh, gen, 2050, genkwh, temp, mintemp, maxtemp, 12,43);

To run this you will need the accompanying icons and templates files, its all available in the EmonGLCD repo here:

Interested to hear any thoughts on how best to take this forward.

Reading Watt-hour data from an Elster A100C electricity meter using IrDA by Dave Berkeley

If you have an Elster meter this is a fantastic way to read the exact accumulated watt hours that you have generated or used and can compliment and cross check a CT based measurement.

Dave Berkeley writes:

The A100C has an LCD display showing the number of kilowatt hours generated, but it also has two optical outputs. One flashes momentarily each time one watt hour is recorded. The second output is an infrared port which transmits the details of the meter, including accumulated Watt Hours, every second or so.

There are lots of commercial power meter readers around, and many homemade ones too. But they all seem to simply count the 1Wh optical pulses. This does give you an accurate measure of instantaneous power usage / generation, but does not give accumulated totals. If you get a malfunction in the reader you will lose counts. If you count the IrDA output it always gives you accurate accumulated totals.

Read the full build guide here: Electricity Meter Reader

and download the Arduino source code here: elec_meter.ino

The only thing you need to get this running on an arduino or an emontx is a TSL261R optical sensor, the TSL261R has the same pin out as the TSL257 so can be connected to the emontx pulse input.

We've put together a small kit available in the shop of all the components needed to connect it to an emontx including the TSL261R a male 3.5mm jack, 1m of cable and heat-shrink to save needing to get all the components from different places.

EmonGLCD Icons by Drsdre

Drsdre writes:

I've started experimenting with using icon based information with the goal to use the limited real estimate on the LCD more efficient and make the display more attractive.

Current features of this experiment:
  • Icons for current usage, grid, solar and temperature. 
  • Solar and temperature will shown different icons based upon solar wattage/temperature on scale -15 to 40c. Solar maximum value is auto-learning. 
  • If no EmonTX or EmonBase info is received, amount of seconds when last package was seen is shown. 
  • Assigned down button to switch on/off background light. 
Ideas: also add a animated wind energy icon, use an overall more graphical representation based upon a house with panel on the roof, wind mill in garden and connection to grid. It's in a very early stage and I love to hear your feedback.

Forked EmonGLCD sketch with changes can be found on

From the forum thread here:

Almost at the next emoncms release point

Over the last couple of months I have been working closely with Ildefonso Martínez Marchena from Spain on developing emoncms to the next level and we have been making really good progress.

We are almost at the next release point with a lot of big additions including:

  • Support for multiple dashboards
  • A fully visual dashboard editor
  • Public dashboards via username i.e
  • Support for ckeditor and simeo file manager
  • 8 different dial types and a hot water cylinder
  • LED’s widgets thanks to Lloyd
  • Published and unpublished dashboards for dashboards that are being worked on.
  • A reworked dashboard renderer implementation
Data and core
  • CSV data input and identification by sensor node inputs.
  • Feed Autoconfig
  • New averaging process for creating daily temperature averages.
  • Setup script improvements
  • Thanks to Juan Sidrach for help with general code formatting and multilingual implementation. 
  • Twitter bootstrap based theme.
All this is available now on github and has been of course throughout development. At this stage we are just polishing the release and updating and writing documentation.
We've got the domain and have the latest version running there off the same server and database as so you can still access your data through

The idea here is to create a really nice launch page for emoncms and have the live instance hosted there which can be used as a main logging site or for testing before running it on your own server or both. will still be a beta service for now as its stability and reliability is established.

Bug testing
It would be great if you can try out the new version and let us know of any bugs you find so that we can try to get it as rock solid as possible before this release is complete.

Due to a couple of core implementation changes to visualisations and dashboards many of the visualisation URL’s and dashboard scripting have changed so it best to build any old dashboards from scratch using the new visual editor.

Have a look at the using emoncms documentation here if you need help with any of the steps:

Please submit any bug details either to the issue tracker on github here:
or on the forums here:
There is also a beginning on code documentation here that may come in useful.


Installation guides
To install emoncms on your own server have a look at these guides:

Let us know how you get on with it.

Open source sailing technology to clean up oil spills

What a great explanation of the importance of open hardware for developing environmental technology and the right conception of business where purpose comes first and profit is there to make the purpose happen rather than technology as a means to make profit, excellent!

emonGLCD V1.4

Introducing the current version of the emonGLCD. This post is a bit later than planned, we have actually been selling the V1.4 through the shop for the past month or so. This version features some minor incremental improvements rather than a new design. 

The main changes to this revision are:
  • This LCD power is connected to the 3.3V rail instead of instead of 5V. This will fix the problem with the LCD going blank due to over voltage, discussion thread here. *
  • The external power connection now routed through voltage regulator this means it can accept an input from 5-12V
  • The push switches are now active high, each with their own 10K pull down resistor, R7 and R8 are two additional 10K pull down resistors. 
The emonGLCD sketch examples on GitHub have been modified to work on the V1.4 as default. If you have V1.3 then you will need to uncomment the line that enables the internal pull up resistors (line 116 in emonGLCD_HEM) You will also need to comment line 199 and uncomment line 200 to change the action to active high rather than active low.

All other functions work exactly the same as previous emonGLCD versions. 

See the bottom of the main emonGLCD documentation page for a full change-log detailing the different versions over time. 

*Running the LCD at 3.3V instead of 5V is now within spec for the LCD unit, however running the LCD at a lower voltage did flag up an error in the orientation of C13 and C14 see forum discussion thread here. A note has been added to the build guide to instruct the insertion of C13 and C14 the opposite way round to what is marked on the PCB. 

emonGLCD V1.4 - Assembled (RFM12B missing)
emonGLCD V1.4 PCB - Front
emonGLCD V1.4 - Rear
The emonGLCD SolderPad page has been updated with the V1.4 Schematic and Board files:

Triac based MK2 PV Controller by Calypso Rye

Calypso Rye writes:

Based on the standard VI sketch which uses calcVI() in EmonLib, I’ve had a system in place for the last couple of months which diverts surplus PV power to our immersion heater. This system has proved to be both effective and reliable, and I am most grateful for everyone who has helped me along the way. The main downside to this arrangement is that it requires an expensive item of third-party kit to distribute the power. (I know that others have found cheaper ways, but my Carlo Gavazzi unit cost me £70).

Other contributors to this forum have shown that a standard triac can be easily controlled by an Arduino. By using a zero-crossing detector such as the Motorola MOC3041, it should be possible for the Arduino to allocate mains cycles directly to the load rather than delegating this task to a separate device.

A Mk2 system of this type has been working in our garage for the last few days. The sketch and a schematic diagram are attached, its main features being:

- a comprehensive 'debug' mode which allows real world conditions to be simulated ;

- a continuous mode of operation, for both measurement and distribution of power;

- an "energy bucket" concept which gives precise control of surplus power;

- interleaved windows for measurement and generation, each only 20mS;

- a rapid response time to changing conditions (50mS);

- suitable timing for 'arming' a zero-crossing trigger device;

- a single LPF which determines the dc-offset of raw VI samples;

- a programmable safety margin for biassing import v. export;

- minimal calibration is required.

Read the full post on the forum here:

Single AC power supply + voltage sensing

The idea of using the same AC-AC power adaptor for both sensing voltage and supplying power to emonTx has been discussed on the forums for months (see this topic), and about six weeks ago Glyn posted a simulation of a possible circuit.

I had the time this weekend to give it a try, bought the necessary components and put it all on a breadboard. After a sleepless night I can confirm: It works!

Here is my messy setup:

Small modifications had to be made to get it to work: I added a 1uF cap between 3.3v and GND to filter out some noise and redefined the voltage calibration coefficient in the code.But the main problem (took me all night to figure it out) is that the usual emonTx sketch wont work straight ahead. The line that lights up the LED (on pin 9) at the end of the setup loop has to be commented out, otherwise the setup won't work. It's no problem to flash it 2ms after each packet is sent, but apparently having it on in the beginning will prevent the program from starting. Maybe there isn't enough current to do it and move on (I must say that I use 10k ohm resistors for the voltage dividers). If it's not that then maybe full wave rectification could help.I used a humble Xprotolab to measure the Vin, Vout and at some other points in the circuit. It behaves almost exactly like the simulation. fft also shows very little noise.Would be great if other members could repeat this experiment to see if the results will be the same.Next step: Voltage sensing on the base ;) 

Getting visual

The Open Energy Monitor is all about getting visual. Using hardware to post collected data to emonCMS basically transforms the acquired data into easily understandable informations, and what's better than graphs.
Here is a similar initiative that converts absurd electricity bills into meaningful information:
You can compare it with with the old bill:

It is obvious that presenting the same information in a different way makes a big difference. The redesigned bill is much easier to understand, and the use of shapes and colors turns something very abstract into tangible information.

But I believe that if we really want to democratize energy monitoring, we should take it one step further. We should offer people who have no idea what 4.2 kW or 150 kWh are, a reference to compare with. For example, visualizing 1kWh as the energy than ten 100W light bulbs consume in one hour makes it understandable to your grandma. Or showing one week's consumption each hour on one matrix using colored circles.

More important is to give a feeling of the order of magnitude. Like showing a community average VS your consumption on a colored scale to have an idea how well you're doing, lets you have a good reference point.

I agree that with households community averages are quite complicated since households have extremely different consumption patterns: some work from home, some have many guests, others spend very little time at home, etc... But when it comes to businesses, benchmarking is much less complicated, you can compare bakeries or cafes electricity consumption patterns in a much meaningful way.

I think this should be a main target to be implemented in emonCMS, and I believe that the community has something to say and contribute to this topic, so I started this forum thread : please feel free to add your thoughts to it.

Arduino Leonardo (ATmega32U4) and RFM12B

I've just managed to get an RFM12B hooked up to an Arduino Leonardo. It's been a bit of port mapping nightmare!

The ATmega 32U4's  'special function' ports such as PWM, IRQ, SPI etc are quite different to the ATmega328. The Arduino port mapping table proves very useful, if a little difficult to interpret. I made a re-arranged table with the ports re-arranged into function groups. I'll publish it once I've tidied it up.

Once of the main differences is that the hardware ISP connections are no longer on digital pins 10,11,12 and 13. On the Leonardo they are

MISO -  Digital 14
SCK -   Digital 15
MOSI - Digital 16
SS -      Digital 17 

Unlike on the Arduino Uno These SPI pins are not accessible through any of the digital I/O pins, on om the Leonardo, their only accessible through the ICSP header. The SPI SS pin on the Leonardo is not broken out anywhere on the board, strangely it's used for the Rx LED. Can anyone explain why this is the case? It's not a big problem, we can use another pin as SS, digital 10 in this case.

The IRQ Interrupt connection is made to Digital 3 (INT0). This has moved from Digital 2 on the Arduino Uno.

The SEL connection is the same as with the Arduino UNO/ATmega328 goes to digital 10.

See the RFM12B documentation page for general info on RFM12B and details of how to interface with ATmega328: . 

Arduino Leonardo Connections to RFM12B via JeeLabs RFM12B breakout for level shifting to 3.3V
ICSP Header
Now the hardware is complete it's time to tackle the software. We use the RFM12B driver as part of the JeeLib library from JeeLabs: The library needs to be installed in the Arduino library's folder in the usual way. Arduino 1.0.1 is needed to be compatible with Leonardo.

To make the JeeLib library work with the Leonardo and RFM12B (hooked up as above) the following needs to be inserted into the RF12.cpp file on line 62 before the else // ATmega168, ATmega328, etc.

No change to RFM12.cpp is needed, just download the latest version, see update below.

#elif defined(__AVR_ATmega32U4__)

#define RFM_IRQ     0   //PD0, INT0, Digital3 
#define SS_DDR      DDRB
#define SS_PORT     PORTB
#define SS_BIT      6   //Dig10, PB6

#define SPI_SS      17     // PB0, pin 8, Digital17
#define SPI_MISO    14     // PB3, pin 11, Digital14
#define SPI_MOSI    16     // PB2, pin 10, Digital16
#define SPI_SCK     15     // PB1, pin 9, Digital15

I'm going to send JCW a git pull request to see if these changes can be integrated into the JeeLib library so it should work 'out of the box' in the future.

Update: Pull request has been merged, RF12 part of JeeLib Arduino library now has ATmega32U4 support :-) . Download it here:

For a simple RFM12B transmission demo/example see:

I'm planning on using the ATmega32U4 in the emonTx SMT that I'm currently working on. Spot the common thread in my last few blog posts!