Archived Forum

Right after the above change it does seem to work as expected. 
Well the live values anyway.. the "use today" shows "-0.0kW"  and the total for the PV is showing 0 but a +0 so something is not right..

also if 

Line 76 const int maxgen=3000; // peak output of soalr PV system in W - used to calculate when to change cloud icon to a sun

to 

Line 76 int maxgen=50; // peak output of soalr PV system in W - used to calculate when to change cloud icon to a sun
Line 195 if (cval_gen>maxgen) maxgen=cval_gen;

This should after 1 day of full sun set the max value for the generation.. (would save non savvy users editing code with the option for people to edit if they want,.)

Line 228 int PWRleds= map(cval_gen-cval_use, 0, maxgen, 0, 255); // Map importing value from 0-4Kw (LED brightness - cval3 is the smoothed grid value - see display above

Think its because PWRleds goes negitive so 

Line 229 PWRleds = constrain(PWRleds, 0, 255);

Fixes this at 0 

if you swap the cval_gen-cval_use to cval_use-cvall_gen the red les work but the green dont..

 Hi Rob, 

Sorry about the typo, I see you have notice that the '-' should be a '+'! The github sketch has been uodated. I have also updated the LED brightness mapping to use the 'maxgen' variable which is defined at the beginning of the sketch. You should set 'maxgen' to be equal to the peak output of your array in W. 

I think I can see you problem. The sketch assumes that the grid import/export feed (emontx.power1) is positive when importing and negative when exporting. Looking at your emoncms feed it looks like you need to flip the orientation of the CT for emontx.power1. You need to be using an AC-AC voltage sample adapter with the emonTx and running the emonTx voltage sketch for the direction of current flow to be detected. 

Thanks a lot for bearing with me on this, your feedback is much appreciated. Please let me know how this works and if you have any further improvment sugestions.

Cheers,  

Thanks Glyn

The emonTx has been in place for quite a few months and was working fine with the old firmware.

I'm sure the CTs are the correct way round as it was al fine before the new code. It seems that the totals are wrong not the live figures..

Iv fliped the CT round as you sugest but now just shows -

In this pic above  im only useing 54W. But i know im using 700+ currently. The Generation is correct.

This pic is how it was before but the totals are showing as 0 or -0 

This is using the code from the 27-July-2012 totals updateing (even if the backlight no longer works as the base firmware is too new..)

any ideas?

Right totals now working. (Not sure i trust them... Seem to low..). After loading all of the devices with the latest firmware...

BUT

Red leds not working.. Green work fine red do nothing..

On the subject of LEDs and backlight:

On my GLCD, I rewrote the backlight and LED logic somewhat. Maybe other people may like to consider this. The original backlight logic only works if you have a emonBase to provide the clock. Since I don't use an emonBase, I needed to change it anyway.

What I ended up with is basically:

1. Backlight brighness is updated every 200ms (instead of every 10s) and is based purely on the ambient light level. By tweaking the relationship between the light level and backlight brighness, I got it so that the backlight turns off completely in a darkened room - hence no need for a clock to turn it off at night.

2. The LEDs change colour gradually from fully red when importing more than 1 KW, to fully green if exporting more than 1KW. Between these extremes, the colour changes gradually through shades of orange and yellow. The Brighness of the LEDs is adjusted to follow the backlight.

For my purposes, this logic works very nicely and is I think an improvement on the original. If anyone wants to see the source code, please drop me a PM.

Martin

@Martin,

Ah great, I like the idea of the backlight going off when the room is dark, however the time is still needed for resetting the Kwh/d at midnight. Have you got a video demostrating the opperation of your LED's? We have yet to made use of yellow/orange shades of the tri-colour LED's. I thought it might be a bit confusing for non-techi users. As it stands, I think it's quite clear that green means that generation is more than meeting your current consumption needs and red means it's not and your importing power. The brightness of the LED's does change depneding on level of import / generation. 

@Rob

That's good news, progress at least. I'm struggling to work out why the Red LED 's arent working. The code controlling them is simply:

if (cval_gen>PV_gen_offset) {

      if (cval_gen > cval_use) {            //show green LED when gen>consumption cval are the smooth curve values  
analogWrite(redLED, 0);
analogWrite(greenLED, PWRleds);
        
      } else {                              //red if consumption>gen
        analogWrite(greenLED, 0);
analogWrite(redLED, PWRleds);
      }
    } else {                                //Led's off at night and when solar PV is not generating
      analogWrite(redLED, 0);
      analogWrite(greenLED, 0);
    }

So whenever gen<use red LED's should come on with brightness determind by PWRleds. Do you think you could get it to serial print cval_gen, cval_use and PWRleds to see what the problem is. cval is just a smoothing function. cval_gen and cval_use is what is displayed for use and gen on the LCD so we know they should be correct. 

I'm sure you have tested this but you could do a digital write high on pin 9 just to check the red LED's are working. 

Cheers, 

however the time is still needed for resetting the Kwh/d at midnight.

I reset the daily totals whenever the PV power becomes non-zero after being zero for at least an hour. This is therefore a kind of 'sunrise detector' in software. The daily totals will not reflect exactly 24 hours, but it's good enough for me.

Sorry - I don't have a video of my LED/backlight logic in operation, nor any particular inclination to create one. I'm happy though to share my source code if anyone wants to look, but it has now diverged in a several areas from the 'standard'.

One slightly wacky feature is that the LED brightness and ambient light sensor interact such as to give positive feedback to the brightness control. This means that is takes several iterations to stabilise to fully-off when I turn off the the lights - you see the backlight and LEDs gradually fade out over a couple of seconds.

Martin

 Glyn

Seems i was right.. Its a negitive number.. before the constrain so gets set to zero by it....

Red leds works fine with the older code....

PWRleds = -65   Before Constrain
PWRleds = 0       After..
cval_gen = 22
cval_use =473

so you can see where i put the print outs..

 int LDR = analogRead(LDRpin);                     // Read the LDR Value so we can work out the light level in the room.
    int LDRbacklight = map(LDR, 0, 1023, 50, 250);    // Map the data from the LDR from 0-1023 (Max seen 1000) to var GLCDbrightness min/max
    LDRbacklight = constrain(LDRbacklight, 0, 255);   // Constrain the value to make sure its a PWM value 0-255
    if ((hour > 22) ||  (hour < 5)) glcd.backLight(0); else glcd.backLight(LDRbacklight);  

    int PWRleds= map(cval_gen-cval_use, 0, 1750, 0, 255);     // Map importing value from 0-4Kw (LED brightness - cval3 is the smoothed grid value - see display above 
    Serial.print("PWRleds = "); 
    Serial.println(PWRleds);
    PWRleds = constrain(PWRleds, 0, 255);             // Constrain the value to make sure its a PWM value 0-255
   Serial.print("PWRleds = ");
   Serial.println(PWRleds);
   Serial.print("cval_gen = ");
   Serial.println(cval_gen);
   Serial.print("cval_use =");
   Serial.println(cval_use);

   if (cval_gen>0) {
      if (cval_gen > cval_use) {            //show green LED when gen>consumption cval are the smooth curve values  
 analogWrite(redLED, 0);         
 analogWrite(greenLED, PWRleds);    

Let me know if i can help further.
Rob

 Robin I would love to have a look that, It would help my battery usage on the Glcd as im using a LiPo pack on it..

Rob

Simple but great idea Martin. I like it, relying on the cycle of the earth to govern time, electronics being governed by the rotation of the earth! Yes, please do post your code. We could make an alternative solar PV example sketch on Github for those who don't use an emonBase based on your code. 

Cheers, 

 Glyn.. 

Been having a play around.. with the current code and old code..

But did not get very far as the sun set on me.. Damm this time of year.

As per prev comment it definatly because the value of 

int PWRleds= map(cval_gen-cval_use, 0, 1750, 0, 255);
  

Is a negitive..  Wonder if we could dectect this and flip it.?

Rob.

 Ah, I think that's it, PWRleds is going negative. Try the latest code from GitHub, I've just added:

int PWRleds= map(cval_use-cval_gen, 0, maxgen, 0, 255); // Map importing value from (LED brightness - if (PWRleds<0) PWRleds = PWRleds*-1; // keep it positive

Thanks for spotting this.  

OK - here's my GLCD code. Differences from the original are:

1. Commented out all references to the RTC and temperature sensor libraries

2. No RF from emonBase

3. Extra fields added to emontx payload to contain immersion heater output level and tank temperature.

4. bottom right quarter of main display has room temperature replaced by tank temperature, plus power and output level.

5. Added hot-water power usage to 7-day usage data.

6. Display page 2 (clock) removed.

7. 7-fay usage data is rolled-over based on a PV sun-rise detector instead of RTC.

8. New backlight and LED logic, as previously described.

See attached for main sketch code. 

 Ad

 Glyn

Have added the code and the red leds now work as expected..  Nice one..

The totals still go negitive though (should of got a pic when i got home as it said we were -15.7kWh Today (home) This is not possible as we have only generated 6+kWh) but forgot..

See pics below.. for after the code change.

This is shoing that its negitive with in a few mins of starting up..

Edit..  After a while of being home and the PV power reducing as the sun is setting.. the total is winding back towards a positiv number.. Was almost -1.0kWh and were now at -0.1kWh so its moving.. But i guess its counting the PV output... 

 Rob

Ive been running the latest code as from 12.15am and my totals are all looking correct.  This is along with the latest emonTx and emonbase sketches (minor alterations but nothing to do with totals etc.).

Your issues may be elsewhere?

Dennis

Dennis

Do you have a Type 1 system? 

Mines a Type 2 and have loaded the latest sketches on all 3 devices now and i still get the wrong totals. The live data is correct.. Eg Exporting / import, Generation and use. So im guessing its a calculation problem with the type 2 system.. Im not sure of the setup of Glyns system so he may not have a way of testing this out..

This was all working fine with the previous sketches (several months) so beleive nothing is wrong with the setup. (could be wrong on this).

Rob

 Yes I do have type 1 - if you'd write it, I never picked it up.  Sorry.

Dennis

 I think I'ved solved the Kwh/d use going negative for type two solar, it was a missing bracket. Changes have been pushed to github. 

Thanks Glyn

Will load the code in a min and report back tomorrow...

Also on a side note hope it fixes the totals recording wrong.. we supposedly used 17kWh in 4Hrs We don't use that in 3 days so hope its wrong...

Yup it should do. I've got it running here, it's working well. I've been working from home today so I've got round to upgrading my homesetup to the latest version. 

Glyn..

Working like a charm.. Thanks for all the hard work...