Archived Forum

Hello, yes your right, the tri-color LED's and light sensor are not used in the home energy monitor sketch.

The tri-color LED's are used in the PV monitoring sketch and we are yet to use the light sensor, but added it on there for future developments, your welcome to make use of it!

Update: their used now! The latest version of the Home Energy Monitor and Solar PV emonGLCD examples use the light level reading from the LCR to adjust the brightness level of the backlight. In bright light the backlight dims to save power. 

I have also implemented the tri colour LED's in the Home Energy Monitor example, the brightness of the red LED varies smoothly depending on the amount of power being consumed. This feature is a bit experimental, let us know what you think. 

Brilliant, thanks Glyn, will try it out this weekend

Still very noobie for this as just got everything up and running. Could you please point me to the direction of how enabling backlight in the HomeEnergyMonitor (newest version from github).

Ah - sorry for the silly question, there seemed to be a hardcoded clock time when the background light does not work and as I do not yet have EmonBASE running therefore of course the backgligh did not work.

Maybe in one of the future versions this includes also if (emonbase_notfound) then glcd.backLight(LDRbacklight);

I too have been looking at controlling both the backlight and the LED brightness - taking incident light and, for the LEDs, the power too into account. The big complication is the human eye works on a logarithmic scale, hence it is necessary to take account of that in the algorithm.

The objective was to maintain the backlight and LEDs at a constant perceived brightness irrespective of the ambient lighting conditions. So in bright conditions, backlight and LEDs are at maximum and in low light, both backlight and LEDs dim. It's early days yet but this seems to work reasonably well:

LED = 3.0 * 2 ^  (LDR * 0.0033 - 1)  *  2 ^ (pu_power * 3.2 - 1)  *  2 ^ (LDR * pu_power * 0.0036 - 1) 

where

LED is the PWM output scaled 0-255,
LDR is the light level from the sensor (scaled 0 - 1023),
pu_power is per unit power, scaled 0 - 1.0
' ^ ' is of course exponentiation [in Arduino-speak: pow(2,n) ]

The output (LED) needs to be limited to a maximum value of 255, which happens when the power is 100% and light is about 900.

The coefficients can be adjusted to change the relative effect of the inputs. Don't try this in a sketch, the best way to see what is happening is to write the equation into a spreadsheet and plot the values of LED (on a log scale) against light level with power as a parameter (I used steps of 25%, more gets confusing) and play with the numbers there before importing the values into your sketch.

For controlling the backlight, the same equation can be used, giving it a constant power of 1.05 (yes! - it means it hits maximum brightness slightly earlier than the LEDs). This works in the opposite direction to Glyn's - it reduces the backlight in low light levels thereby attempting to maintain a constant perceived brightness and contrast ratio.

In my fusion of MK2 controller and EmonGLCD I use the backlight and the LDR sensor. 

The light sensor monitors the ambient light level and adjusts the LCD display to compensate for room brightness. I don't bother to maintain a constant brightness simply to make sure that when the light levels are low the LCD display backlight doesn't blind anybody who may be in the room.

I also use the LED's to show if the data received from the emonTX indicates that the system is importing or exporting power. The LED's are set to run red if the house is importing and green if it is exporting. 

The LED's are set to stay on constantly if the light level is reasonably high and they turn off if the light level detected by the LDR shows a low level of light.

In addition to all of this, the LED's provide a heart beat to indicate that the system is receiving data from the emonTX. If the LED's are running constantly on they will momentarily pulse off every 4 seconds to show the receipt of data. Similarly, if the light level is low they will momentarily pulse on either red or green so as to indicate household import or export.

Take a look at the emonGLCD receiver sketch 

http://openenergymonitor.org/emon/node/1103

to see how it all threads together.

Good ideas - here is one more: Regardless of what are the other thoughts of Wattson (RIP) there was two particularly fine features in it: BIG numbers and varying colour based on consumption. So decided to make emonGLCD to show green light ath the background when consumption is low, red when its high - varying in between.

My maxPower during winter heating is 9Kw and normal summer time consumption around 650-800w. The below gives green light for below 1kw and moving gradually to full red. The dividers of /5 and /10 are used for adjusting the colour change to my preference.

...

   int greenPWRleds= map(cval, maxPower/5, 0, 0, 200);     
   int redPWRleds= map(cval, maxPower/10, maxPower, 0, 200);      
   redPWRleds = constrain(redPWRleds, 0, 200);    
   greenPWRleds = constrain(greenPWRleds, 0, 200);   

...

    analogWrite(redLED, redPWRleds);  
    analogWrite(greenLED, greenPWRleds);

....

the efergy LCD on right is just showing the air to water heatpump consumption, not noticeable at all whereas emonGLCD really shows when the tumbledryer and washing machine together are burning energy

Having a Wattson (as well as everything else), I can totally relate to your idea ! Nice one !!!