Archived Forum

I probably have what you want. I have 2 PV arrays and 2 invertors facing 2 directions using all 3 emontx CT inputs. I modified the original emontx code for 2 PV arrays and the GLCD code to display the 2 PV outputs and the total PV output along with the house use and grid power. To get all the data on the display i divided it into 6 sections instead of the original 4.

I have recently been modifying Martin R's interrupt driven power divert code to handle 2 PV arrays so GLCD has divert power and triac temperature as well.

I also monitor 9 temperature sensors on 3 solar water panels, 2 tanks etc

Dashboards are here

http://emoncms.org/sedlescombe

Diverted power on the display is 1.1KW as i have no load fitted yet.

Paul

Hi Paul your original modifications to the code sound perfect, annoyingly I recently changed my gas boiler to a combi and ripped out the old copper tanks so at this point cannot benefit from the solar water heating.

If you would share the dual pv code that would be fantastic.

Dave

I'll have a look tonight and send you some code.

emontx - do you want the PLL diverting or original code?

nanodeRF - will need modifying to remove solar water and remote reporting, perhaps i'll put a #ifdef in there.

emonGLCD - see emontx

the emoncms dashboards you'll have to do yourself

Paul

Original code would be great and the ifdef would be really really usefull.

Thank you

Dave

you'll need your own api key for nandoeRF code

comment out TEMPS and REMOTE #ifdef in nanode RF

choose #ifdef GEN2 for second PV array and use original emonGLCD code

emontxPLL code is designed to export excess power to immersion see http://openenergymonitor.org/emon/node/1535

but you'll need extra hardware to switch immersion, but you couls comment out the divert section in emonGLCD

i probably have a 2 PV version of the original emontx code somewhere.

it's still in trial, but good luck

Paul

Paul,

My own panels are east/south so I really like what you have done with the east/south and push button.

I cant figure out how to remove the Triac from the lcd code, can you help with that.

Also I am using a raspberry pi so dont need to worry about the nanorf stuff I think ?

In the emontx code how do i set it to 868Mhz as the code has a line in hex but no obvious way to set to 868 not 434 ?

rfm_write(0xA640); // 434MHz

How can I remove the triac from the glcd ?

Its also confusing me which way round the CT clamps should go.

The AC from the fit meter in the garage comes into a breaker in the CU.

The AC from the fit meter in the house comes into the main switch in the CU.

The AC from comes into the main switch in the CU.

Dave

to change the frequency you need to change the line

rfm_write(0x80D7); // EL (ena dreg), EF (ena RX FIFO), 12.0pF

to

rfm_write(0x80E7); // EL (ena dreg), EF (ena RX FIFO), 12.0pF

this will switch to the 860MHz band

The 0xA640 command sets the frequency within the band and this is the same for both 434MHz and 868MHz

Hi Martin,

Thanks for the pointer I no longer get tx fail on the standard solar glcd but i dont seem to get any data back.

As nothing shows up on glcd ? stuff shows up if I use the standard emontxCT123 same group/band etc 

the output of screen /dev/ttyAMA0 9600 looks like this so data is coming ?

10 0 0 0 0 0 0 0 0 215 19 3 0 48 117
10 0 0 0 0 0 0 0 0 215 19 4 0 48 117
> 0s
-> 4 b

any thoughts on the clamps?

Dave

any thoughts on the clamps?

They all sound correct to me from your video.

I can't really help with your transmission problems as I'm not clear on exactly what you are doing.

the emonglcd code:

The critical bit is to use the same format of structure for the data transmission. The emontx sends

typedef struct { int grid, gen1, gen2, divert, freq, Vrms, temp ; } PayloadTX;     

so the Pi will need the same. This is not the same as the standard code.

What do you want to display instead of the divert power?

Been busy ove rthe weekend fitting immersion heater to tank so have not watched video yet.

Paul

That structure will not be a problem for the Pi. It just treats any payload as a series of integers so each variable, grid, gen1 etc., will appear as a separate input to EmonCMS.

No Worries, Martin confirms they are ok.

Martin,

Given

typedef struct { int grid, gen1, gen2, divert, freq, Vrms, temp; } PayloadTx; // Grid, PV gen 1, PV gen 2, Diverted, freq, volts, temperature

My input list has 7 items in emoncms however only two carry data.

A bad temp (makes sense as nothing is plugged in) with a value of 30000

A freq (i assume) 5079

all the others are 0 with 3 ct clamps connected (2 will be dead as the pv is dark) but grid should be live.

any thoughts ?

Dave

From you video - you have no voltage monitor input connected. Do you have a AC-AC adaptor?

Did you decide what you wanted instead of diverted power on the GLCD?

I forgot to mention the heatbeat indicators on the GLCD.

Top flashes every approx 1Hz to show s/w is running (had problems with lock ups)

Middle flashes each emontx message received

Bottom flashes each time message received from base station

emontx TX fail and base fail are shown when no data is received after a timeout.

Hi Paul,

I do not have an AC/AC adapter at this moment as I cant find it , they are all dc in the spares box, and i think i binned the one I had when i dumped my adsl.

Thanks for the update on the flashes, that makes sense and ties in with what I see.

Instead of diverted Power I guess Temp from emontx would be good as I plan to measure outside using the emontx and indoor with the glcd.

Is the AC/AC needed with this code, if so I guess I can buy another one

You need a AC-AC adaptor as this supplies the voltage to be measured and allows the PLL to lock to the phase. Without you will get no power measurements.

I expect Martin will confirm.

If i get time i will send an updated emonGLCD sketch

And read up about AC-AC adaptors on the openenergymon site, they are not all the same

Thank you.

Ordered the Mascot one from rs found on the list

http://openenergymonitor.org/emon/buildingblocks/different-acac-power-ad...

Try this emonGLCD code.

Replaced divert power with Temperature and replaced triac temperature with min max temps. Still displays 2 PV i/ps, total PV i/p, grid and use on a 6 square grid.

Note it only displays indoor temp. If you want outside temp from your emontx, you'll have to modify the code to use the temp received from the emontx. And you'll need a sensor plugged in.

Then you could replace the min max with outdoor temp

Paul

Paul,

That's fantastic, thanks for doing that, the ac adapter should arrive Thursday so I will let you know how it goes.

I have no idea where you are but if your ever in surrey let me know

Dave

It should all spark into life now. 

I'm out the country for 3 weeks from Wed, but will monitor forum

Paul

Thanks Paul, indeed it does all work now, very nice.

I also got my solarmax inverters talking directly to emoncms, so I will post that as well in another thread.

I think I need to perform calibration as the East panels claim 8watts at 21:55 in the dark, which is not right, wheras the South are fine.

Maybe the clamp is unhappy inside the consumer unit, I will look at moving it out.

Safe trip..

Dave

edit: figured this out and all sorted!

Martin,

Given My GLCD now reads between 6 and 12 watts (nominally 7) should I adjust the code section

#define POWERCORRECTION 7

perhaps set to 0?

Should I still carry out calibration for the values below.

Should the I2CAL & I3CAL values be 111.1 with the standard CT's from the shop

How do you work out I1,I2,3 LEAD  or should they stay at 5?

#define VCAL 227  // calculated value is 230:9 for transformer x 11:1 for resistor divider = 281
#define I1CAL 111.1 // calculated value is 100A:0.05A for transformer / 18 Ohms for resistor = 111.1
#define I2CAL 113.1 // this is for PV1_CT2, the solar PV current transformer
#define I3CAL 113.1 // ?
#define I1LEAD 5 // number of microseconds the Grid_CT1 input leads the voltage input by
#define I2LEAD 5 // number of microseconds the PV1_CT2 input leads the voltage input by
#define I3LEAD 5 // number of microseconds the PV2_CT3 input leads the voltage input by

Thanks

Dave

Paul,

I never seem to be able to make the led's go green they go red happily though.

For example when im generating 2.7kw and sending 2kw to the grid i would expect green leds ?

The screen seems to rotate through different modes of display but when it does the icons get messed up.

I have linked to a video showing the icons and a picture of the non green leds, or maybe im missing the point ?

http://www.youtube.com/watch?v=GppDo_1pSPg

Have you changed the GLCD code for your maximum panel outputs

const int maxgen1 = 1200;              // peak output of solar PV system in W - used to calculate when to change cloud icon to a sun
const int maxgen2 = 550;

and the powercorrection was tuned for my system

I did not !

I have now set them both to 1980 (the arrays are the same)

how do you work out powercorrection ?

May i just say thanks to Martin for his PLL code. System is working well. See dashboard 'power diversion' listed above

Paul,

Thanks to you both, its fantastic and way more useful that the offering proposed by the PV installer.

I Still cant get green leds with this code though.

they are green with standard code for two CT's but they only go red on this combo other than that its working perfectly.

Can you confirm that in the picture I posted I should see green leds for 

2.4kw solar in-bound

374watts in use by the house

and 2.0kw >> to the grid, I will poke the code tonight and look for the obvious

Dave

Maybe a stupid question: If you install a test sketch that turns the green LEDs on, do they come on? (The basic GLCD test sketch emonGLCD_tester.ino flashes red and green alternately.)

they did, I will try now...

Ok yes they go green red and all the buttons work etc.

looking at the code it looks like it should work ok, certainly the red does the pwm dimming etc depending on how much i pull from the grid

if ((cval_gen1 + cval_gen2) > PV_gen_offset) {
      if ((cval_gen1 + cval_gen2) > 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);
   }

edit (clock also shows the correct time on glcd as I note it turns the leds off from midnight to 6 am)

This looks as if it might be wrong. I think PWRleds can go negative, but the following constrain( ) prevents that, thus you lose the negative part. I think the commented-out line is required:

int PWRleds= map(cval_use - (cval_gen1 + cval_gen2), 0, maxgen1 + maxgen2, 0, 255);     // Map importing value
                                                                //   from (LED brightness - cval3 is the smoothed grid value - see display above
    //if (PWRleds<0) PWRleds = PWRleds*-1;                        // keep it positive
PWRleds = constrain(PWRleds, 0, 255);                       // Constrain the value to make sure its a PWM value 0-255

(Or maybe neater:  PWRleds = abs(PWRleds); )

Thanks Robert,

I have un-commented the line and will have to wait till the sun comes up to see if it works !

Dave

Hi Robert,

I can confirm we now have green leds with

if (PWRleds<0) PWRleds = PWRleds*-1;

Thank you

Dave

It would be interesting to know why it was commented out in the first place.

And I really do object to that line of code. OK, it works, but aren't both of these better:

if (PWRleds<0) PWRleds = -PWRleds;

PWRleds = abs(PWRleds);

I don't know perhaps Paul does?

It doesnt seem to send temp from glcd back to the rpi either

If you want to add that, you need to copy the bits of code out of the standard GLCD sketches. Shout up if you need a steer on that (though I can't help with details at the RPi end, I suspect it will work straight away with no changes).

I would appreciate a huge steer, linux is no problem, but arduino might as well be rocket science

Right. I'll try to be gentle. The code is actually in your sketch, just that it's commented out.

What we're looking for is stuff to do with Temperature. We know from your existing sketch that data being sent to the GLCD and the base is packed in a struct, so we're looking for something like that as well. (I'm referring to line numbers as listed by my editor here.)

First, we need to add back in the structure to pass the data back to the RPi, lines 81 & 82. Those give us a variable called emonglcd.temperature, so we'll look for that - use your editor to search - and it's in lines 334 onwards.

Now it looks as if that'll do what you need. Line 334 is taking "temp" and putting it into emonglcd.temperature, and the rest are sending the data via the RFM12.  However, there are two problems. Some time ago, there was a big discussion about the GLCD locking up, and the library and the code to use it was changed. The commented-out bits of your sketch use the old, bad code. So go to the SolarPV sketch on Github and look at the equivalent lines, they're right at the bottom. You need to copy lines 265-267 from there to replace your lines 334 - 343.
The second problem is your sketch calls the GLCD temperture "inttemp", so instead of "temp" in line 334, you'll need "inttemp".

And I think that should do it.

Thanks Robert, I will take a look when I get home.

I noted that when I tried to add back in the code for the transmitter it called a non defined item.

I will let you know

Dave

Thanks for the help Robert, that works perfectly.

Next steer request :-)

How to get the glcd to alternate between indoor and outdoor temp !

Big ask I know!

I missed this!

I think the easy way will be each time the GLCD updates, you display the other temperature.

If your code is based on the standard, at the bottom is the "slow update" branch where the temperatures are read, and that's the obvious place. You need a boolean variable to store knowledge of the one presently displayed, then you negate this each time round and use it to steer the appropriate temperature into the display - it will display one for 10 s then the other for 10 s.

Something like:

(at the top)

boolean show_inside_temp = TRUE;

(in the 10 s branch)

show_inside_temp = ! show_inside_temp;

(then also in there after the temperature has been read and after the inside temp goes into the output struct for the RF module)

temp = show_inside_temp ? temp : outside_temp;

Of course, you'll need to get the outside temperature in some way, and if you want the corresponding min and max displayed, you'll need to replicate everything to do with those as well.

e.g. maxtemp = show_inside_temp ? maxtemp : maxtempoutside;

I don't use the Green leds as I divert excess power to a immersion heater.

And i commented out the sending of the room temp from the GCLD as i still got the occasional lockup, and i have another emontx which is monitoring all my temperatures anyway.

Dave.

Is it all working Ok now?

Hi Paul,

I missed the replies as the forum doesn't email me.

I got the red/green working and dropped the temp by 2 degrees so that its more accurate in my location.

Robert was a massive help.

I wanted to get the glcd to show inside temp and my outside temp and I will try what Robert suggests above but it doesn't make any sense really as I am not a coder, but I will give it a go.

At this time it is all working well, I have a couple of wish items and in the future I hope to get another emontx as I will need four ct clamps now as next month im getting an electric car !

it would be cool to get the cars charging monitored and im planning on pulling my inverter output data and posting it to the car to tell the car to charge up etc, but I will know more when the car arrives.

:-)

Dave

"it doesn't make any sense really as I am not a coder, but I will give it a go"

That's the spirit! As long as you keep a copy of your working version, you can always drop back to that. Best to sit down with a printout in a quiet corner and a pencil (and a rubber!) and mark where the loops start and end, and which piece of code does what. And only then look at what I wrote above. Post again if/when if doesn't make sense!

If you don't mind slowing your emonTx down a bit, you could add another c.t. to it. There are two spare analogue inputs, but you'd need to copy the input circuit for one of the existing c.t's (a jack socket, 3 Rs & 1 C) on a piece of stripboard and connect it to the emonTx via the Serial/I²C port header (3 wires: GND, V_CC (labelled 3V) and a spare AI, 4 or 5 - see here http://openenergymonitor.org/emon/emontx#portmap)

Hi Robert,

I ordered another CT from the store and finally have My Nissan Leaf so it would be cool to monitor it.

The supplier fitted a gsm meter which no doubt has IR but I guess a CT is more accurate?, although give the load is pretty constant when charging 6.6kw ramping down over time maybe the ir will do , what do you think?

Dave

btw its a smart meter just for the Car !

http://www.elstermetering.co.uk/en/AS230.html

You GSM meter is by definition totally accurate (unless of course you can prove that it isn't!) - and a carefully calibrated C.T. is probably much the same (but an uncalibrated one will be significantly worse). But do you know the protocol that the IR uses? If you don't (and if no-one else does nor can you find a unit to read it and output something we can read), then a c.t is probably the only way available to you.

It has software to read it but as I have a CT its easier.

so going back to what you previously said re a fourth CT I will give that a go.

You mentioned 'if i don't mind slowing it down' what did you mean?

Will it make the device noticeably less accurate or just update less as it has to process more?

"slowing it down" - It depends on the sketch you are using. Am I right in thinking it's a derivative of MartinR's PLL?  If so, you need to add another section like one of the existing c.t's in the interrupt routine - but beware, the last one is subtly different to the rest - and all the other supporting lines elsewhere. From memory, there's probably enough slack time in the original to read the extra c.t, but possibly not if a third has already been added. If it all goes wrong you'll need to reduce the number of sample sets per cycle to allow more time for the set of samples to be read. Reducing the number of samples will marginally reduce accuracy - but only if there's a lot of harmonics present (which there shouldn't be). I've now documented Martin's original sketch. Martin's sketch drives spare outputs while conversion is happening so by using an oscilloscope you can see how much spare time there is (but bear in mind it's used for reading temperature and sending by radio, so you do need some).

Yes, and it has three CT's already.

I will look at your documents but unless my nephew can figure it out I might just buy another board :-(